Subject: [Tsvwg] new revision of early retransmit available

From: Mark Allman <[email-masked]>
Date: Fri, 22 Aug 2003 12:27:19 -0400

Folks-

We have just sent a new version of the Early Retransmit internet
draft to the secratariet.  It should appear in the archives in a
couple of days.  It is available from:

 http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-02.txt

now.

The largest change in the document is that it now includes a variant
that uses SACK information to make ER more robust.  The problem that
we have found is that the instances where ER will help are windowed
quite a bit when it just counts duplicate ACKs.

First consider two states the reciever could be in....

  * S1: the receiver has ACKed all data received
  * S2: the receiver has received a packet but is delaying its ACK
    for another arrival (or the timer)

When the receiver is in S1 and an out-of-order segment arrives a dup
ACK will be triggered and ER will work nicely (or, as nicely as
possible).

When the receiver is in S2 and an out-of-order segment arrives the
receiver will send an immediate ACK, but it will not be a duplicate
-- but, rather it will cover previously unACKed data.  In this case,
ER is not in a happy place because it expects a duplicate ACK from
all but one of the segments outstanding.

So, we (meaning Josh, really) figured out that if we leveraged SACK
information we could just tell when all but one packet has arrived
at the receiver and key on that for ER, rather than try to count
duplicate ACKs.  (Because even if the ACK for out-of-order data is
cumulatively ACKs previously unACKed data (i.e., is not a dup ACK)
it will still have SACK information indicating what packet triggered
the ACK.)  This scheme seems more robust.

At the moment both schemes are in the draft.  But, we are seriously
considering ripping out the version that does not use SACK on the
grounds that if you're not using SACK and you are interested in good
loss recovery in 2003 then you really can't be all that interested.
(Recent measurements: I am seeing > 90% of web clients support SACK
at a web server I am watching.  I ran tbit against 61,000+ web
servers and 65% support SACK.)

We'd be interested in getting feedback on any of the above issues
(and the text of the draft itself, of course).

Thanks!

allman

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

---

From: Mika Liljeberg <[email-masked]>
Date: 24 Aug 2003 12:36:03 +0300

Mark,

The SACK variant looks a lot more robust compared to the ack counting
variant. I would feel fairly confident in putting this into an
implementation. I tend to agree that today there's really no excuse to
not do SACK if one is at all interested in performance, so I think a
SACK only variant would be fine.

One suggestion for improvement, though.

Standard Nagle will prevent any smaller than MSS sized segment of new
data from being sent unless all the preceding segments have been acked
first. This means that limited transmit typically cannot be applied with
the last segment of a data burst and, in particular, at the end of the
connection. 

The draft discusses the problems observed with limited transmit and a
small congestion window but doesn't mention the interaction with Nagle
anywhere. I would be good to give some attention to this as well. Early
retransmit can help in both cases.

	MikaL