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

[Ethan Blanton <[e-mail]>]

Henderson, Thomas R spake unto us the following wisdom:
> 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.

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.

> - 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.  

OK.

> - 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. 

Correct, according to my reading.

> - 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.

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 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).   

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"