Path-switch-triggered congestion (Was: RE: Extending shim6 to use multiple locator pairs simultaneously)

[Scott Leibrand <sleibrand@internap.com>]

On 03/23/06 at 12:01am +0200, john.loughney@nokia.com wrote:

> Erik,
>
> >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.
>
> Current behavior is that TCP doesn't really take into account radical
> chances in link capacity.  There is some on-going work in TSVWG on how
> to handle extreme congestion events, but this isn't really something
> solved.

But how much of a problem is this in reality?  Say you are transmitting at
1Gbps (1,000,000 kbps), and get switched to a 28.8 kbps modem link.
Since each packet lost halves the sending rate, and you've reduced your
throughput by a factor of approximately 2^15, it should take approximately
15 dropped packets to throttle back the sending rate sufficiently.

I understand the concern about it taking a long time to drain a modem
link's buffer, though: I've managed to buffer about 10 seconds of data on
my parents' modem link.  :)

Does anyone here have a good understanding of how existing TCP
implementations set their retransmission timer?  Is is usually/always less
than 2 * the average RTT?  If so, I suspect that in the case of a switch
from a fast link to a deep-buffering modem link, the retransmission timer
on the sender will expire well before enough packets drain the buffer for
the receiver to start sending duplicate ACKs.

IMO this is not a show-stopping problem, as TCP will throttle back fairly
quickly, and the impact should be limited to approximately the depth of
the slow link's buffer.  That's not to say it's not worth addressing (in
the TSVWG), but it doesn't seem to me like something that should hold up
shim6...

-Scott