On 8-jan-2007, at 17:11, Wesley Eddy wrote:
I think it's entirely reasonable for TCP or other transport protocols to have different behaviors for path changes where the speed difference is 1:2 vs where the speed difference is 1:1000.
Well, even though the speed of the links may be known, the amount oftheir capacity that is currently available at the time of a failover isprobably much less well known to the shims. This knowledge also says nothing about the paths after those links.
Sure, there is lots of stuff that we don't know. But when we have a 80 Mbps stream going through a 100 Mbps or faster interface, and then the path changes so that the next hop is over a 56 kbps interface, we know that bad stuff is about to happen unless we take action.
One other point is that setting the congestion window to some percentageof its previous value based on the ratio of failover link capacity to primary link capacity is fairly naive, and ignores the significant amount of other relevent TCP state.
In theory, the TCP window should be such that it throttles the data stream to almost exactly the available bandwidth. In practice, this of course doesn't work because the logic that determines the window size isn't all that good.
I don't think there is a simple action that can be taken that's always the right response. The only thing I do know is that this is an issue that we can't ignore, we must say _something_ in the protocol document and hopefully the implementers will be smart enough to come up with something reasonable or at least do some testing to avoid problems from becoming too big when all of this hits the streets.
TCP can easily be smart enough to do the right thing if shim6 just lets it know that there's been a failover.
Sounds good, except that not all failovers are created equal so some additional information, when available, would be even better. Especially as the main issue is going in and changing specifications and implementations, making the list of signals a bit longer is inconsequential.