[e2e] TCP retransmissions at end of data stream

[Agthorr]

Well, it opens the window and enters Slow Start, but there's no new
data to send, so my implementation doesn't send any.  Is there some
algorithm for deciding when to retransmit data during a Slow Start
after a time out?

-- Dan Stutzbach

On Sat, Jun 14, 2003 at 10:26:18PM -0400, Nahur Fonseca wrote:
> 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?
> > 
> > 
> > 
>