<div dir="ltr">My recollections agree with Louie's - TCPs created a new packet from the unacked window contents when a retransmission was generated.<div><br></div><div>However, I think it's still an interesting question if there are TCPs out "in the wild" of the global Internet that were implemented as the designer interpreted the published spec, and thus may have kept packets for retransmission when needed.</div>
<div><br></div><div>I suspect all of the TCPs that "we" know about don't do that.  But "we" were involved in the Internet research community and the discussions on mail lists, RFCs, conferences, etc.   Many engineers were not.</div>
<div><br></div><div>What do TCPs look like internally when they were implemented by someone who only had access to the published specs - i.e., the "Official Standard" RFCs of the day?   How did an engineer at a cellular radio company, or a consumer appliance company, implement a TCP, especially if their experience had been with other technologies?</div>
<div><br></div><div>I encountered something like this back in the 1990 timeframe, when my cousin called to ask me about some aspects of the X.25 specification that were unclear to him.  He was an RF engineer, but had gotten the assignment to add X.25 to some system doing radio stuff.   As I talked with him, it became clear that he was interpreting the tome of the X.25 spec quite precisely and literally, and what he was focused on had little relationship to how X.25 was actually being used in real deployed networks.   His approach would have created an implementation that was functionally correct, but far from the "best practice" that had developed in the networking community.</div>
<div><br></div><div>I can easily see how a similar situation could occur with TCP and its related protocols.</div><div><br></div><div>This is what motivated my question in that other thread about observing today's live large-scale Internet and its behavior over history.   I have no idea how the millions (billions?) of TCPs out there have actually been implemented, what algorithms they chose to incorporate, and how it's been working out.</div>
<div><br></div><div>Related curiousity question - does Internet traffic today actually get Fragmented?  How's that been working?</div><div><br></div><div>/Jack Haverty</div><div> </div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Mon, May 26, 2014 at 4:46 PM, Louis Mamakos <span dir="ltr"><<a href="mailto:louie@transsys.com" target="_blank">louie@transsys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On May 26, 2014, at 5:20 PM, Detlef Bosau <<a href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a>> wrote:<br>
<br>
> Am <a href="tel:21.05.2014%2021" value="+12105201421">21.05.2014 21</a>:08, schrieb Noel Chiappa:<br>
><br>
><br>
>> And as to what to do when a timeout happened (which usually, although not<br>
>> always, indicates that a packet has been dropped due to congestion), it says:<br>
>><br>
>>  if the retransmission timeout expires on a segment in the retransmission<br>
>>  queue, send the segment at the front of the retransmission queue again<br>
>>  [and] reinitialize the retransmission timer<br>
><br>
> thanks a lot, I should read texts much more carefully.<br>
>> That's it! Again, note the focus on 'hey, we gotta get the user's data there<br>
>> as fast as we can'.<br>
><br>
> However, at a first glance (I will implement this) this appears as a<br>
> "quasi GBN".<br>
><br>
> Do I understand this correctly: When the packet is retransmitted, a copy<br>
> is _appended_ to the retransmission queue?<br>
<br>
</div>Just to be clear, of the 4 or 5 different TCP stacks I’ve crawled around in<br>
and/or co-authored in one case, the contents of the send window are retransmitted,<br>
not the packet.  I’ve not seen a particular TCP implementation that keeps<br>
previously transmitted segments around for retransmission.  (I can see how<br>
some low memory, constrained implementations might make a choice to keep<br>
previously transmitted packets around, however, and this lets them re-use<br>
the same fragmentation ID in the IP header, too.<br>
<br>
Every TCP stack I’ve seen just regenerates segments, and the retransmit<br>
queue is really the TCP send window.  Certainly the IP stack we did for<br>
the UNIVAC 1100 did this, the various 2.{8,9,10,11} BSD and 4.x BSD Berkeley<br>
stacks did this, as probably did the BBN TCP stack for 4.1. Pretty sure<br>
the Fuzzball TCP stack also used this strategy.<br>
<br>
I can often be the case, of course, that the retransmission attempt generates<br>
a segment larger the the one that wasn’t acknowledged if additional data was<br>
placed into the send window by the local application.  Might was well fill up<br>
the retransmitted packet to the the MSS.  This was pretty obvious to see with<br>
interactive (e.g., telnet) traffic and Nagle’s algorithm that would suppress<br>
additional tinygrams until the ACK was returned.<br>
<br>
louie<br>
<br>
<br>
</blockquote></div><br></div>