[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?

[Fred Baker]

What you describe is pretty much what happened with each of a variety  
of different transports and transport implementations in the 1970's  
and 1980's. In 1983, I wrote an implementation of XNS SPP at CDC  
(having just designed an instance of the BBN Class Four Transport,  
which was in that year withdrawn, and then ISO extracted the state  
machine from it and turned it into the ISO Class Four Transport). In  
that SPP, I included procedures pretty similar to what have become  
known as the Van Jacobsen Congestion Control Procedures, which he  
wrote up in 1988. You see, although the Internet Transport is pretty  
specific that one is supposed to send a packet train, in the last  
packet request an Ack, and send the next packet train when the Ack  
arrives, we read some papers from Digital that indicated that they  
had experienced problems with that model in early DECNET  
implementations and instituted AIMD procedures to deal with them...

On Sep 26, 2006, at 10:29 AM, Craig Partridge wrote:

>
> In message <8f884bb031b3678c4b56874456ec25aa at mac.com>, rick jones  
> writes:
>
>> Maybe I'm trying to pick a nit, but was the underlying problem  
>> that it
>> was bursty in the initial transmission, or was the underlying problem
>> really that it continued to retransmit the bursts, without any (IIRC)
>> exponential backoff?
>
> Hi Rick:
>
> Excellent question, on which my memory is imperfect.  Here's my best
> recollection.
>
> Pre-1988 BSD TCP (and, indeed, I believe all TCPs) would start by  
> sending
> as close to an entire window's worth of traffic as they could (e.g.  
> as fast
> as the application could stuff the transmission queue, data got  
> sent up
> to the window size).
>
> In case of loss, TCP retransmitted only the missing segments, but  
> as soon as all
> losses were recovered from, TCP resumed hammering full bursts.  So  
> TCP was
> not go-back-N, but had a sort of strange burstiness of the form:
>
>     initial burst -- causing loss -- followed by recovery --  
> followed by
>     new burst
>
> Others who were there, please correct, update as appropriate.
>
> Thanks!
>
> Craig