[e2e] Question on ssthresh setting in RFC 2581

[Ted Faber]

On Tue, May 16, 2006 at 01:51:19AM +0200, Detlef Bosau wrote:
> >Now one or more other TCP sources show up.  Our hero (the long-running
> >TCP) detects a loss and cuts cwnd in half (this is the error described
> >in the note).  Because cwnd >> rwnd its sending rate does not change -
> >the limiting factor is rwnd, not cwnd.  That's clearly an error; the
> >
> Why?
> 
> You may argue, that you want the sender to reduce the CWND more quickly. 
> This is fine.
> But the situation as described is not an error.
> 
> First of all, cwnd is not cut in the half. In case of a timeout, cwnd is 
> reset to 2 segments. ssthresh is defined cwnd/2.
> So if ssthresh exceeds the available path capacity, our hero will 
> encounter a congestion during slow start. Right?
> So you want ssthresh to converge more quickly to an appropriate value. 
> This is perfectly o.k. But neigher cwnd is simply cut in the half, nor 
> the situation is an "error" that would make TCP fail.
> 
> >long-time sender should reduce its measurable sending rate, not some
> >internal variable.  Hence 2581 mandates using flightsize instead of cwnd
> >
> Excuse me, but as you know the sender´s rate is determind by the ACK 
> rate - not by cwnd.
> Why do you want to change a sender´s _rate_?
> 
> NB: TCP is window controled, not rate controled.

Let's not split hairs.  I can produce a perfectly precise statement of
what's going on here, too, but those details are not at issue in why
flightsize is used.  You can think in terms of rate or packets, whatever
makes you happy.  A TCP implementation is using network resources
proportional to changes in either of them and TCP's use of either needs
to be reduced in times of congestion.

If a TCP implementation uses cwnd instead of flightsize, it can be
unresponsive to congestion in a variety of plausible network conditions.
That's just not true of using flightsize.

The error is that if cwnd is allowed to grow larger than rwnd or the BDP
and a TCP implementation only reduces its cwnd based on the current cwnd
rather than basing the reduction on its flightsize (an action that the
RFC defines to be a bug) that TCP sender can detect congestion and not
react to it in any measurable way.  I said it's sending rate doesn't
change, but you'd say that the number of packets it releases into the
network over an RTT doesn't change.  The point is that the sender is a
congestion-insenstive source; its use of network resource is constant
under congestion and that's a dandy recipe for congestion collapse.

OK, strictly speaking the congestion response is probably only delayed
by several RTTs, but that's cold comfort if the network's collapsed in
the meantime.

To split the hair, that implementation is in violation of the criterion
in Section 3 RFC 2581: 

      [...] In some situations it may be beneficial for a TCP sender to
      be more conservative than the algorithms allow, however a TCP MUST
      NOT be more aggressive than the following algorithms allow (that
      is, MUST NOT send data when the value of cwnd computed by the
      following algorithms would not allow the data to be sent).

Flightsize is an estimate, but it's only an overestimate in fairly
perverse conditions - looping packets, delays where the variance is
larger than the RTT, that kind of serious corner case where there's
trouble no matter what.  The RFC requires flightsize because it is almost
always a conservative way to react to congestion.  Being conservative
is much preferred to being excessively aggressive because it makes
congestion collapse much less likely.

That's all there is to flightsize.  It's a conservative estimate of the
real sending window.

Notice that all of this is only tangentially related to how much the
receiver indicated it's willing to accept - the advertised receive
window - which is you mentioned in the mail I first responded to.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060515/14827c73/attachment.bin