[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extending shim6 to use multiple locator pairs simultaneously


El 21/03/2006, a las 10:25, Scott Leibrand escribió:



First i would like to understand what would be the effect of using
multiple locator pairs in order to use multiple parallel paths without 
modifying TCP. I guess that this would be nasty for TCP, but i would
like to make quantify the results of such approach. I mean, having the
shim to support this without requiring modifications to TCP would make
this is much more attractive i guess


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.
well, you have the preference option that would allow to the receiver to inform about how he woudl preffer to distribute incoming load, which could possibly reflect the access bandwidth that the receiver has, but this of course does not reflect the badwidth of the path nor congestion issues. 
having congestion window information would be indeed useful for this

But i see two levels of issues here:
- on one hand we have the issue of whether using this multiple path extension wihtout any TCP mofiffication would result in problems for TCP and even degraded performance. I mean it may be the case that becuase of reordering, using the shim to exchamge packets through multiple paths simultaneously results in worse perfomance than using a single path. If this is the case, then it does not make sense to use this without upgrading TCP - on the other hand it may be the case that using the shim to use multiple paths for the same communication simultaneously result in ehanced performance without any TCP modification but it can indeed perform better if TCP is modified or at least, as you mention there is a richer information exchange between TCP and the shim, like congestion window information exchnge
I guess that the fist step would be to clear out the first issue and then move on 

regards, marcelo




This would allow the sending host to fully utilize the available
bandwidth on both his links for a single TCP session, which otherwise
would be impossible (without bonding the two links with some sort of
per-packet load balancing, which you can do for outbound, but not for
inbound with two different providers).  It would require some
modifications to the sending host in order to keep track of
everything, but the receiving host need only do ordinary shim6 and ack 
packets as they came in.
i guess that we need to understand the impact of this in the shim6 base 
protocol and the failure detection mechanism, since both of them are
currently designed to use a single locator pair to exchange traffic.
I don't think that there would be much trouble with supporting this,
though
Yes, definitely. I've read the I-D's, but I should probably re-read them 
with this in mind and see if I can better understand the impact...


 Since the shim would be in place, the recipient's TCP stack would be
completely unaware of the fact that his packets are coming over two
different paths.

Can anyone think of any show-stopper reasons why this wouldn't work?


I would like to understand how badly this behave if we use it without
updating TCP
Ok. Let me do some quick modeling and confirm that my mental model above 
seems to be correct.  I'll also have to consider whether out-of-order
packet arrival will be much of a problem...

Thanks,
Scott