Re: [Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N

(way late, as usual ... sorry)

> The long-term solution to this problem is SACK (to prevent
> unnecessary retransmissions) and DSACK (to resolve the DUPACK
> ambiguity if unnecessary retransmissions do happen).  However,
> most TCP connections today still do not use SACK.
> http://www.icir.org/floyd/sack-questions.html
> 
> Until SACK is universally deployed two methods to resolve the
> DUPACK ambiguity might be useful.

First, I am not sure I am willing to believe that SACK is not pretty
well deployed.  3 years ago I reported 40% of the web clients that
hit our web server here at NASA were using SACK (and the trend was
growing steadily) [All00].  I don't have good data from that server
right now, but I took a quick look at a server at BBN that I have
been monitoring for the last ~11 days.  In that time I have seen
6545 web connections (yeah, not terribly heavy traffic) and 6183 of
the remote hosts (94%) advertised SACK.  That seems like pretty good
deployment to me.

I am not sure what that says about additional "bugfix" tricks.  Do
we need them?  Do we not need them?  The above data is not
necessarily conclusive or representative.  The changes would add
complexity to a TCP implementation.  On the other hand, not that
much complexity and maybe would provide a decent enough win.  But,
when do we stop patching known suboptimal recovery?  Etc., Etc.,
Etc.    ??????

> ACK-heuristic: if seq(ack_new)-seq(ack_prev)<=2 MSS then trigger
> fast retransmit on 3rd DUPACK This method is based on observation
> that to trigger a false fast retransmit, a TCP sender has to
> retransmit unnecessarily at least 3 adjucent packets. In this case
> there will be a jump in a cumulative ACK at the sender of at least
> three segments.

I am trying to wrap my head around this and cannot yet do so.  Can
you define "ack_new" and "ack_prev"?  Are these the two ACKs before
duplicate ACKs start rolling in?

> Using the timestamp option: if ts_echo(ack_new) == ts (seg_una)
> then trigger fast retransmit on 3rd DUPACK In case of a missing
> segment both RFC1323 or RFC1323bis (expired update draft) require
> that DUPACKs echo a timestamp from the segment below the missing
> one.

Timestamps are less prevalent (by default) than SACK is, I think
(11% of the connection in the BBN trace described above, which is in
the ballpark of what was reported in [All00], too).  So, I am not
sure I think this is a practical approach.

[All00] Mark Allman. A Web Server's View of the Transport Layer, ACM
    Computer Communication Review, 30(5), October 2000.
    http://roland.grc.nasa.gov/~mallman/papers/webobs-ccr.ps

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg