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

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

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

>>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?
>
ack_new has the same cum ACK as DUPACKs, ack_prev is the previous ACK before
DUPACKs

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

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