[Iccrg] RFC5681: why halving FlightSize not cwnd?

Yuchung Cheng ycheng at google.com
Thu Sep 6 19:42:37 BST 2012


RFC 5681 specifically calls to use FlightSize instead of cwnd for cwnd
reduction.

"""When a TCP sender detects segment loss using the retransmission timer
   and the given segment has not yet been resent by way of the
   retransmission timer, the value of ssthresh MUST be set to no more
   than the value given in equation (4):

      ssthresh = max (FlightSize / 2, 2*SMSS)            (4)

   where, as discussed above, FlightSize is the amount of outstanding
   data in the network.

   [...]

   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.
"""
When a sender sends cwnd==20 packets
a) fast-recovery: only 17th packet got dropped. FlightSize == 4
(pipe==1), ssthresh=2
b) timeout: 17-20th packets are dropped. FlightSize == 4(pipe==4), ssthresh=2

As a result, the next transaction, e.g., an HTTP response, will almost
exit slow-start immediately and slowly increase cwnd per RTT. But
AFAIK, ssthresh is based on slow-start overshoot by half of cwnd (of
previous round trip), not current FlightSize.

This has been implicitly addressed in Laminar, but I want to call this
out b/c I don't understand the rwnd argument in RFC5681. As long as
the sender respects rwnd, what's the problem?



More information about the Iccrg mailing list