[Tsvwg] problem with draft-allman-tcp-sack-11.txt

["Henderson, Thomas R" <[e-mail]>]

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.

Suggested fix:
--------------------
Data that has been sent before a timeout event should be considered as
having left the network.  "pipe" should equal one segment immediately after
the first retransmission following a timeout, and zero when this first
retransmission's ACK arrives (i.e., ability to send retransmissions after a
timeout should be governed by cwnd).  Perhaps a case e) in LeftNetwork()
defined as follows:
"(e) 'S1' was most recently transmitted before the TCP sender incurred its
most recent timeout."

The question of whether HighData should be changed upon a timeout is
interesting.  A cautious approach would be to not reset it so as to avoid
false fast retransmissions that might arise from dupacks that are generated
due to previously received segments that the sender retransmits-- this would
be in line with NewReno principles.  However, if the receiver is properly
sending SACK blocks, unnecessary retransmissions should be avoided, and
dupacks would probably indicate an additional segment loss (or possibly that
the receiver has discarded SACKed data).   

Thoughts?

Tom

p.s. Interestingly, we have observed similar behavior using SackFullTcp in
ns-2, but for a different reason.  ns-2 SackFullTcp only enables pipe
control when fast retransmission is entered via dupack action.  However,
after a timeout, SackFullTcp does not use pipe control but instead
mistakenly considers itself in fast recovery mode, suppressing cwnd growth.
As a result, cwnd is stuck at one segment until snd_nxt grows beyond
HighData again, and we can only retransmit 1 segment at a time (per RTT).  

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg