[ih] ARPANET uncontrolled packets (was: GOSIP & compliance)

[Alex McKenzie]

 Jack and others,
I'm a one finger typist so I'm not going to go into a lot of detail, but there are some misstatements in your message.1. 0/3 messages were restricted to a length which would fit in one IMP packet, so they were not fragmented and reassembled by the IMPs.2. 0/3 messages were not subject to end-end control by the IMP subnet, so in that sense they were not subject to error control, flow control, and congestion control as normal Host-Host messages were.3. All packets were subject to error control, flow control, and to some extent to congestion control between each pair of adjacent IMPs.  Error control was by hardware checksums, timeouts, and retransmissions.  Flow control was the limit of 8 "logical channels" over each IMP-IMP circuit.*  There could only be one outstanding (un-acked) packet on each logical channel. If there were more packets waiting they were queued.4. Congestion control of sorts was provided by the IMPs including queue length for a given outgoing line as part of the "distance" measurement in computing routes (this was not implemented in the IMPs until at least the mid-70s).
I believe 0/3 packets were not placed on transmission queues if there was not an available "logical channel" for immediate transmission, but I could be wrong about that.
* I believe there were additional logical channels provided for the USA-Norway and the California-Hawaii satellite links but perhaps this never got implemented.
Cheers,Alex

    On Monday, April 4, 2022, 12:27:56 PM EDT, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 Guilty!  I've always found it difficult to get the correct terminology.

Actually, thinking and remembering a bit more, to be even more precise 
those "type 0, subtype 3" globs of bits weren't "packets" either.   They 
were "messages", passed back and forth between a Host and its attached 
IMP.   The IMP carved those messages up and put the data into one or 
more "packets" which were what actually got sent over the wires.  
Actually, there may have been more technical chicanery involved there, 
with things like "frames" in the mix.  At the final IMP in the path, all 
those "packets" were "reassembled" and the data delivered to the Host in 
"messages".   But I don't recall if the receiving Host could tell that 
an incoming message was sent out as a type 0, subtype 3 from the 
transmitting Host.

IIRC, it was the IMP-to-IMP packets which were uncontrolled, and handled 
outside the normal mechanisms of error control, flow control, congestion 
control, etc.  I don't think I ever knew exactly how all that worked -- 
but the old IMP code is available online should anyone be curious.

Then of course if you looked more closely, you might see that the TCPs 
involved were sending and receiving data from their users' application 
programs.  At one point there were even "Letters" passing across that 
interface, which the TCP would carve up into "datagrams", which it might 
supply to an attached ARPANET port as "messages".  Somewhere down the 
path, a Gateway might receive a message, determin that it wouldn't fit 
into the next network, so it would carve up the datagram into 
"fragments", which were themselves smaller datagrams, leaving putting it 
all back together as a challenge for the TCP running in the Host at the 
ultimate destination.

Complicating things even further, if the applications involved were 
transferring electronic mail, they would be also accepting "messages" 
from human users, carving them up into "letters" for TCP, which would 
carve them up into "datagrams", which might become a string of a 
different kind of "messages", which might become a gaggle of "packets", 
with "fragments" spontaneously appearing in the fray from time to 
time.   The life of a bit in its travels through the Internet is crazy 
and frenetic.   Ask any bit which has gotten discarded along the way and 
now lies in a bit bucket somewhere in the net.

There just weren't enough words to precisely describe the carnage 
involved in computer networking...reminds me of those old late-night TV 
ads "It slices, it chops, it dices, it shreds!  Call this number to 
order your Acme Kitchen Wizard!  Call now and get two for the price of one!"

Jack Haverty




On 4/3/22 22:58, Stephen Casner wrote:
> On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote:
>
>> UDP defined a "datagram mode" somewhat analogous to the ARPANET's
>> "uncontrolled packets" ("type 3" IIRC).  The ARPANET operators at BBN were
>> staunchly opposed to allowing such packets to be used, for fear that they
>> would seriously disrupt the normal "virtual circuit" mechanisms internal to
>> the ARPANET structure.  So "datagrams" on the ARPANET, while possible, were
>> only rarely permitted, for specific experiments, between specific Hosts.
> I have often seen/heard the ARPANET uncontrolled packets referenced as
> "type 3", e.g. by our late Danny Cohen.  But they were actually "type
> 0, subtype 3".  I remember implementing that for packet voice.  Check
> BBN 1822 pp. 3-14 and 3-35.
>
>                                                          -- Steve

-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history