[e2e] TCP retransmissions at end of data stream

[Valentin Ossman]

Dan,
Whenever an ACK is not received on the data and the transit time-outs,
slow start should be started. This means:
1. send the first un-acked packet again and wait for ack.
2. send the second and third packets again and wait for ack and so on.
You should not set a time-out timer per packet, but one per connection
that will timeout on the oldest in-acked packet.

Best Regards,
Valentin Ossman



-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org] On Behalf Of Nahur Fonseca
Sent: Sunday, June 15, 2003 4:26 AM
To: Agthorr
Cc: end2end-interest at postel.org
Subject: Re: [e2e] TCP retransmissions at end of data stream


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