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

[Stephen Casner]

Answering Vint and Jack inline...

On Mon, 4 Apr 2022, 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.

Correct, 1822 says the type 0 subtype 3 messages were limited to 991
data bits in addition to the 96-bit leader.  Also there was no
source-to-destination control of these messages (no retransmission, no
RFNM, no error reports).

For packet voice we did not want packets any larger because we wanted
to limit the packetization delay.  In the NTC 78 paper mentioned here
recently we tested 5 to 18 50-bit LPC parcels per packet (250 to 900
bits).  Each parcel encoded 10 ms of voice.

No video during that era over ARPANET.  Video came later on the
Wideband Satellite Network.

On Mon, 4 Apr 2022, Jack Haverty wrote:

> 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.

There was no specialization of the IMP<->Host interface for the type 0
subtype 3 messages.  The bit-level transfer was the same.  The IMP
could discard the message as soon as it came in, so there would be no
reason to delay transfer at the bit level

> 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.

Depends how effective the discard implementations were.

                                                        -- Steve