[e2e] Question on ssthresh setting in RFC 2581

[Ted Faber]

On Sat, May 13, 2006 at 03:13:43PM +0200, Detlef Bosau wrote:
> O.k., one day later....
> 
> 
> Daniel Minder wrote:
> 
> >Hi,
> >
> >can anybody explain why equation (3) in RFC 2581 is
> > ssthresh = max (FlightSize / 2, 2*SMSS)
> >and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used.
> > 
> >
> at least one  remark is made in rfc2581 itself:
> 
> >  Implementation Note: an easy mistake to make is to simply use cwnd,
> >  rather than FlightSize, which in some implementations may
> >  incidentally increase well beyond rwnd.
> >
> Hm.
> 
> The motivation is clear: The sender must not  send more data to the 
> network than the receiver is able / willing to accept.

Apparently the motivation, like the function, is not clear.

Cwnd increases by roughly 1 MSS per window of data.  When calculating
the window size to use to determine how many packets a TCP connection
can have outstanding, the application usually does something like: cwnd
= min(rwnd, cwnd).  Few TCP implementations, if any, make the mistake of
overunning flow control - sending more than the receiver indicates it's
willing to accept.

What the Note is describing is a situation in which a TCP implementation
increments cwnd without bound and doesn't keep track of flightsize or
uses cwnd in its congestion calculations rather than flightsize.

Here's a concrete error case.  You have a low-loss,
nor-particularly-high-capacity network.  Let the network have enough
capacity that rwnd packets can be in flight.  If a single TCP is on that
network for a long time without loss - transferring a large file, for
example - it will get into a state where the window is bounded by rwnd,
cwnd may be an order of magnitude larger than rwnd, but rwnd limits the
number of packets actually sent so flightsize and rwnd are the same.
That is flightsize == rwin, cwnd >> rwin (where that ">>" is a
mathematical ">>" not a C ">>" - much, much greater than).

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
long-time sender should reduce its measurable sending rate, not some
internal variable.  Hence 2581 mandates using flightsize instead of cwnd
to calculate the new cwnd, which forces a real rate reduction.

(We don't just use rwnd because the actual available capacity may be the
limiting factor (rwnd  > line rate * delay)).

We now return to e2e, now in progress.

-- 
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/d4b192a5/attachment.bin