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

[Jack Haverty]

I never got to actually use 0/3 messages, so my memory on how they 
behaved is fuzzy.  But IIRC they were also not subject to the normal 
IMP<->Host flow control mechanisms of RFNMs. Those mechanisms enabled 
the IMP to control the flow of data from a Host into the network, 
including the ultimate step of shutting off all data transfer from a 
Host at the 1822 hardware level by temporarily disabling the clock that 
regulated bit flow.  Just as effective as pulling the plug.  Perhaps 
Steve remembers, or someone could look at the old code to trace how it 
handled 0/3 messages.

I suspect that avoidance of Host-IMP flow control was likely a major 
reason for the opposition to widespead use of 0/3 service, or any use 
that might evolve into widespread use later, such as to support voice.  
If 0/3 permission enabled any host on the ARPANET to submit continuous 
flows of 0/3 data at Host-IMP line speed, that would probably have 
quickly caused problems that the NOC would have hads trouble diagnosing 
and fixing.

It seems that maybe today's switches (routers) avoid such problems 
simply by putting lots of now-inexpensive memory into the system, with 
the unfortunate side-effect of "buffer bloat".

Jack

On 4/4/22 09:43, vinton cerf wrote:
> i think the point about the type 0 subtype 3 is that they may not have 
> been reassembled and might have had limits as to size (unlike the 8000 
> bit "message"). As I recall they were "uncontrolled" which means the 
> space reservation protocol was not in force for them. Since these were 
> used for voice (and maybe video), they might have been limited to 
> single packet size (1000+ bits) and were not assured of delivery.
>
> Steve Casner, any more specifics? Copying Bob Kahn in case he is not 
> on the internet-history list
>
> v
>
>
> On Mon, Apr 4, 2022 at 12:27 PM 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
>