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

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 9 Jul 2002 08:28:11 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Ethan Blanton <[email-masked]>
Date: Tue, 9 Jul 2002 12:07:10 -0400

> roughly a window's worth of data and ACKs.

It appears to me that by this you mean that the packets are actually
*lost*, and not just delayed for a ridiculous period of time.

> retransmission and ACK thereof make it through the channel.  

OK.

> variables determining "LeftNetwork()" when a timeout occurs. 

Correct, according to my reading.

> per RTT if pipe control is used and pipe > cwnd.

This appears to be incorrect.  At this point the TCP sender is not
being governed by draft-allman-tcp-sack-11, but by traditional slow
start with the added condition that "Update () MAY continue to be used
appropriately upon receipt of ACKs".  Because of this, the values of
LeftNetwork (), HighData, etc. are not relevant.

There may in fact be some issues if there is a second loss (after the
RTO) losing a segment below HighData.  I will look at this.

> the receiver has discarded SACKed data).   

My personal feeling on this matter (and, I think, shared by my
co-authors) is that an RTO is a Bad Thing.  We are working under the
assumption that if our SACK-aware fast recovery was not sufficient
something very wrong has happened (small windows do break this
assumption in some cases) and all possible caution is merited.

If I'm misunderstanding something here, please let me know.

Ethan

-- 
Now if I wasn't such a weenie do ya think you'd still love me,
Pretendin' I'm an airplane on the living room floor?
                -- The Offspring, "I Choose"