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

From: Mark Allman <[email-masked]>
Date: Mon, 04 Aug 2003 10:47:38 -0400

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

---

From: Andrei Gurtov <[email-masked]>
Date: Tue, 05 Aug 2003 18:34:31 -0700

>the remote hosts (94%) advertised SACK.  That seems like pretty good
I don't claim to know the answer, but what data on Sally's page tells is 
that although many SYNs have a SACK-perm option only few SYN-ACKs have 
it. It may mean that either web servers are using some old OS that do 
not support SACK or that they don't want to bother with extra overhead 
of keeping SACK state.

If SACK is universally deployed why would we be updating NewReno RFC?

>when do we stop patching known suboptimal recovery?  Etc., Etc.,
I'll send some scenarios next week that might motivate the need for it. 
I think that since implementing them is not a big deal and the NewReno 
draft anyway discusses the issue
it might be a good place to mention them. In the current ns2 snapshot

test-all-tcpOptions timeouts_newreno (shows DUPACKs due to a lost packet)
test-all-newreno reno2 (shows DUPACKs due to duplicate segments )

>duplicate ACKs start rolling in?
ack_new has the same cum ACK as DUPACKs, ack_prev is the previous ACK before
DUPACKs

>sure I think this is a practical approach.
Well, we did publish Eifel based on timestamps. I wouldn't be surprised 
if timeouts due to bugfix are far more common than spurious timeouts in 
the Internet.

Andrei