On 21-mrt-2006, at 17:08, marcelo bagnulo braun wrote:
Now say that hehas implemented some shim6 extensions that allow him to simultaneously send packets with the shim6 context tag over the second locator pair while continuing to send packets over the ULID-ULID pair. These extensions alsoinclude modifications to his TCP stack such that he can independently track the congestion windows (and run the TCP congestion avoidance algorithm) for each locator pair.
But if you need to change both the shim and TCP perhaps this is too many changes...
As long as the changes can be made to one end of the communication independently this shouldn't be much of a problem.
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 wihtout requiring modifications to TCP would make this is much more attractive i guess
How are you going to handle congestion issues?We need to figure that out for regular shim stuff anyway, though. When a gigE link goes down and you get to rehome to 28 kbps GPRS link you REALLY don't want to do congestion control the hard way... It has been suggested in the past that a rehoming should trigger slow start, but I remember someone disagreeing with this, don't remember why.
We may even want to go so far as to drop packets at the source in the shim to enforce this...
i guess that we need to understand the impact of this in the shim6 base protocol and the failure detection mechanismm, since both of them are currently designed to use a single locator pair to exchange traffic.
I think this would mostly be an API issue: TCP would have to be able to tell the shim to test extra paths even if there is no failure, and tell the shim which packets should go over which path. Essentially, the upper layer would be making the decisions and the shim would only be used as a bag of tools to do what the ULP wants to happen.
Ifnot, should I start writing up an Internet-Draft on it? I brought this up in the shim6 Jabber room today, and was told that this might be logicalfollowup work to the base shim6 spec.
Blame me for that. :-)
Do others agree with thatassessment? (This is my first IETF, so if anyone has any other newbieadvice, feel free to speak up.)
You may want to review the shim6 and multi6 archives, but those are big...
Do you think the issues are clear enough to be able to write a draft at this point? And of course you may want to check with some TCP people...