[e2e] TCP retransmissions at end of data stream

[Eric Travis]

Dan,

>The problem occurs when there is packet loss at the end of the data
>stream.  For example, if the server only has 8 more packets of data to
>send, and they are all lost.  Since there is no more data to send, the
>receiver will not generate any duplicate ACKs, and the sender
>eventually times out.  The sender retransmits the first lost packet,
>and the receiver ACKs it.  What happens next?
>
>Right now, in my implementation, the sender times out again and
>retransmits the second lost packet, with exponential backoff.
>  
>
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.

Since you've already sent the FIN, you know that you will
not have any new data to send:

    Upon receipt of an ACK for the initial retransmitted
    segment, you should be able to *immediately* send
    the next segment (the new snduna); When this segment
    is ACKed, you get to repeat this cycle (snduna moving
    toward your segment that contains the FIN) until you've
    gotten an ACK covering the FIN.

    (Being able to go into slow-start at this point is of
     no help in most implementations, as there is nothing
     at send_next)

Assuming that *all* the in-flight segments were lost, this
will still require one rtt per segment in flight, but this
is still better than waiting an RTO between retransmitting each
of the outstanding segments.

Eric