Re: [Tsvwg] new revision of early retransmit available

[Mika Liljeberg <[e-mail]>]

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

On Fri, 2003-08-22 at 19:27, Mark Allman wrote:
>  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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg

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