[ih] internet-history Digest, Vol 84, Issue 4

[Louis Mamakos]

On May 26, 2014, at 5:20 PM, Detlef Bosau <detlef.bosau at web.de> wrote:

> Am 21.05.2014 21:08, schrieb Noel Chiappa:
> 
> 
>> And as to what to do when a timeout happened (which usually, although not
>> always, indicates that a packet has been dropped due to congestion), it says:
>> 
>>  if the retransmission timeout expires on a segment in the retransmission
>>  queue, send the segment at the front of the retransmission queue again
>>  [and] reinitialize the retransmission timer
> 
> thanks a lot, I should read texts much more carefully.
>> That's it! Again, note the focus on 'hey, we gotta get the user's data there
>> as fast as we can'.
> 
> However, at a first glance (I will implement this) this appears as a
> "quasi GBN".
> 
> Do I understand this correctly: When the packet is retransmitted, a copy
> is _appended_ to the retransmission queue?

Just to be clear, of the 4 or 5 different TCP stacks I’ve crawled around in
and/or co-authored in one case, the contents of the send window are retransmitted,
not the packet.  I’ve not seen a particular TCP implementation that keeps 
previously transmitted segments around for retransmission.  (I can see how
some low memory, constrained implementations might make a choice to keep
previously transmitted packets around, however, and this lets them re-use
the same fragmentation ID in the IP header, too.

Every TCP stack I’ve seen just regenerates segments, and the retransmit 
queue is really the TCP send window.  Certainly the IP stack we did for 
the UNIVAC 1100 did this, the various 2.{8,9,10,11} BSD and 4.x BSD Berkeley
stacks did this, as probably did the BBN TCP stack for 4.1. Pretty sure
the Fuzzball TCP stack also used this strategy.

I can often be the case, of course, that the retransmission attempt generates
a segment larger the the one that wasn’t acknowledged if additional data was
placed into the send window by the local application.  Might was well fill up
the retransmitted packet to the the MSS.  This was pretty obvious to see with
interactive (e.g., telnet) traffic and Nagle’s algorithm that would suppress
additional tinygrams until the ACK was returned.

louie