[Iccrg] Can TCP stay in slow start 'for ever'?

[Bob Briscoe]

Folks,

It seems the specs [RFC2581, RFC5681] allow/encourage the behaviour 
described below. Does anyone know whether implementers typically put 
in additional checks and balances to stop this?

If the source limits the data feeding into a TCP connection to a 
fairly constant low rate,
and if it initially sets ssthresh arbitrarily high [RFC2581, RFC5681]
and if the receiver advertises a huge rwnd
then cwnd will continue to grow exponentially until it hits the 
arbitrarily high value of ssthresh, even though the app isn't using 
anything like this window.

Then, if the app suddenly gets a burst of data to send, the source 
TCP would jump instantily to line rate, which might be a step-change 
of many orders of magnitude.

After one or two RTT, the sending TCP would have to do fast 
retransmit/fast recovery with a halving of cwnd per RTT. In the mean 
time, the source would be continually dumping huge amounts of excess 
data into network buffers. This might continue for half a dozen or 
more halvings - one per RTT - to get back down to the operating point 
of the network path (which might be just above the rate it had 
originally been limiting itself to).


Given there is a lot more app-limiting of TCP connections these days 
(e.g. for video), this would seem to be a potential issue.



Bob


________________________________________________________________
Bob Briscoe,                                BT Innovate & Design