[e2e] TCP retransmissions at end of data stream

[Nahur Fonseca]

Dear Dan,

If I uderstand it correctly, 
after a time-out, TCP (Vegas, Reno, NewReno) 
enters Slow-Start again.

So in the example you metion the receiver will
ACK the first packet sent after the time-out.
Then the sender will open its window by one and
send two packets and so on.

Am I missing something here?

-nahur



On Sat, 14 Jun 2003, Agthorr wrote:

> Hello,
> 
> I'm a graduate student at the University of Oregon.  I'm working on a
> packet-level simulator (derived from ns-1.4) for a peer-to-peer
> application.  I've encountered a glitch in my NewReno TCP
> implementation that causes performance problems.  I can think of some
> ways to fix it, but I'm wondering if there is a standardized way to
> handle this case.  My advisor, Daniel Zappala, suggested this mailing
> list might be a good place to ask.
> 
> 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.
> Needless to say, this makes transmitting those last few packets
> extremely slow.  What should my implementation be doing?  Is this
> documented anywhere?
> 
> -- Dan Stutzbach
> 
>