[e2e] TCP retransmissions at end of data stream

[Mark Allman]

> >I believe that the common (but not the most agressive) solution
> >to this - and a simple tweak for your implementation - is to
> >recognize the *special case* where you experience a timeout while
> >the FIN is in flight.
>
> I found no  rationale in this. 

Right, there is no special case needed here.  The spirit of RFC2581
is that you retransmit in slow start following an RTO -- in all
cases, not just at the end of the connection.  And, this *is*
justified because the TCP sender has weathered an RTO in which *no*
(or, very few) ACKs have arrived.  So, the TCP sender is reasonably
sure that it's OK to retransmit during slow start.

Having said that, the retransmission behavior during slow start
based recovery is pretty gross in some cases -- often leading to
lots of unnecessary retransmits.  The behavior could be refined (in
a newreno sort of way).  But, if you use newreno or SACK to begin
with you can often avoid messy slow start based loss recovery
events.  (Although, I realize not the specific case that was brought
up at the beginning of this thread.)

There is data on all of this in the following paper (which is under
submission):

    Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss Rates
    With TCP. May 2003. 
    http://roland.grc.nasa.gov/~mallman/papers/least-submit.ps

(on which comments are certainly welcome!)

allman


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