RE: Extending shim6 to use multiple locator pairs simultaneously

[<john.loughney@nokia.com>]

Eric,

For SCTP + SHIM (which Marcelo & I had a hallway chat about - and maybe
should write-up), there could be confusion about what the 'path' is
when combined.  I think the SHIM API should have a mechanism to signal
up to the transport layer that the SHIM layer has re-homed so that the
transport layer could decide what should be done - if it thinks
slow-start
should be run, etc. 

John

>-----Original Message-----
>From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
>Behalf Of ext Erik Nordmark
>Sent: 22 March, 2006 19:19
>To: Scott Leibrand
>Cc: marcelo bagnulo braun; shim6@psg.com
>Subject: Re: Extending shim6 to use multiple locator pairs 
>simultaneously
>
>
>Scott,
>
>This is an interesting idea. I think that the hard parts about 
>this fall squarely in the transport protocol, and that the 
>shim might not need to change at all (You might just need to 
>have the transport tell the shim to do forked contexts, and 
>that way the shim will automatically verify that the two paths 
>are working.)
>
>Scott Leibrand wrote:
>
>> Ok, that's certainly worth study.  In some mental modeling I've done 
>> so far, the biggest problem I see in not using TCP 
>congestion control 
>> on each locator pair is in deciding how much traffic to send 
>over each 
>> link.  I suppose you could use both links equally, which would allow 
>> you to use (# of links) * (the bandwidth of the slower link) rather 
>> than the sum of the bandwidths of all the links.  IOW, as 
>soon as one 
>> link experiences congestion, the sending rate would be 
>halved over all links.
>
>I suspect there are other issues than congestion control.
>For instance, you will have some skew between the different 
>paths, causing packets to arrive at a different order than 
>they were sent. This will cause the receiving TCP to send 
>duplicate ACKs, and after the sender has received 3 duplicate 
>ACKs, it will do a fast retransmit. 
>Those types of algorithms would need to be make robust against 
>packets arriving out of order.
>
>In terms of thinking about this, it might make sense to start 
>with SCTP, since SCTP already supports tracking congestion 
>information for each path. Then you can ask yourself what 
>would be needed if both paths were used as the same time. Once 
>we know what to do, then applying it to TCP would be 
>conceptually simple (even though it might be hard in 
>practice.) Note that SCTP only uses one path at a time, and 
>only switches after detecting a failure. So AFAIK the SCTP 
>folks didn't explore what would happen is both paths are used 
>concurrently.
>
>    Erik
>
>
>
>