On 22-mrt-2006, at 18:21, Erik Nordmark wrote:
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.
The two reasons I remember being stated for why slow-start isn't necessary the obvious answer are:- the transport protocol needs to be robust against the case when the route in the network changes from a high to a low capacity one. - Not all changes are for the worse; when going from a low to a high capacity path then there is no need to make things go slower.
Well, I do agree with the second point but I still worry about the situation where rehoming is from a fast path to a much slower one, resulting in massive congestion. The trouble is that buffers on slow interfaces can take seconds to empty, so filling them all the way up and letting the packets drop where they may is not a very good solution. Add to that the potential for trouble when many hosts do the same thing at the same time...
But we're going to do a reachability check before the rehoming, which is important in two ways:
- we get an idea about the round trip time- while we wait for this the session isn't rehomed yet so all packets sent are lost and very likely TCP will go in slow start anyway
So this may all work out without us having to do anything. Still, congesion control is absolutely vital so we absolutely have to get this right or we'll "break the internet".