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

[Jack Haverty]

My recollections agree with Louie's - TCPs created a new packet from the
unacked window contents when a retransmission was generated.

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.

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.

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?

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.

I can easily see how a similar situation could occur with TCP and its
related protocols.

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.

Related curiousity question - does Internet traffic today actually get
Fragmented?  How's that been working?

/Jack Haverty



On Mon, May 26, 2014 at 4:46 PM, Louis Mamakos <louie at transsys.com> wrote:

>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140526/91771ecb/attachment.htm>