problem with draft-allman-tcp-sack-11.txt
Henderson, Thomas R <thomas.r.henderson <at> boeing.com>
2002-07-09 15:28:11 GMT
A recent paper at ICC 2002 ("Improving TCP Performance after a Long Channel
Outage" by Murakami, Wu, and Inoue) describes some pathological behavior
that might arise due to strict observance of draft-allman-tcp-sack-11.txt.
The problem is basically as follows:
- consider a TCP, with a somewhat large usable window, that traverses a path
that becomes blocked for a duration of time that it is able to "swallow"
roughly a window's worth of data and ACKs.
- this TCP will time out eventually (setting cwnd to 1 segment) and resend
its oldest unacked segment. At some point, the blockage clears and a
retransmission and ACK thereof make it through the channel.
- this first ACK received will have no SACK blocks since all of the data off
the top of the window was lost. According to the algorithm, HighACK will
grow by one segment, so pipe will decrement a corresponding amount. But
pipe will still be a large (multiple segments), and greater than cwnd. Note
that the internet-draft does not say anything about touching any of the
variables determining "LeftNetwork()" when a timeout occurs.
- at this point, correct behavior is somewhat ambiguous (underspecified).
Murakami et al., who cite draft-allman-tcp-sack-07.txt, describe a TCP
sender that waits again for timeouts for each subsequent retransmission
(ever increasing the backoff), resulting in recoveries that can last for
tens of minutes. If instead the TCP sender always permits at least one
transmission upon receipt of an ACK, it may instead send the next
retransmission in response to this ACK, without waiting for a timeout. But
the bottom line is that it seems that at most one segment can be recovered
per RTT if pipe control is used and pipe > cwnd.