[e2e] TCP retransmissions at end of data stream

[Guglielmo Morandin]

After the first retransmission is acked, you still have 7 packets in 
your queue.
The ack arrival should trigger another transmission
(tcp_input() should call tcp_output(), in a bsdish implementation).

You don't need new data from the application.

-Guglilemo


On Saturday, June 14, 2003, at 07:51 PM, Agthorr wrote:

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