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

[Jack Haverty]

If the IMP used its ability to discard 0/3 messages, and did so 
aggressively (i.e., most "effectively"), that seems to me more powerful 
even than stopping bit flow at the hardware level. It would permit 
"normal" traffic to flow unimpeded, while discarding 0/3 bits, so that 
the 0/3 traffic only travelled when there was little else to send.

Such an algorithm would seem to have the effect of making 0/3 traffic 
absolutely lowest priority.  E.g., if there was other traffic, perhaps 
several FTPs in progress involving several Hosts but sharing one or more 
IMP-IMP circuits, I would expect that traffic to "clog up" all of the 
channels, even if those Hosts were careful about RFNM counting to avoid 
being hardware-blocked.   So while such "other" normal traffic was 
heavy, all 0/3 traffic might just disappear.

I wonder if your test data showed such effects... I.e., did the tests 
you did involve paths through several IMPs, while they were handling 
lots of other competing traffic?    Did 0/3 flow drop off (get 
discarded) when normal traffic increased?  What was the bottom line 
result - were 0/3 messages useful for carrying voice while coexisting 
with other traffic?

My suspicion, not knowing how the IMP code behaved, is that the "normal" 
traffic was the primary concern, and 0/3 got any bandwidth that was left 
over.   But it would probably take a dive into the code to figure that 
out for sure.   Maybe Alex remembers more.

After the ARPANET paths were replaced by circuits directly between IP 
routers, the "Source Quench" mechanisms could perform the similar 
function of dropping datagrams when there were no resources to handle 
them.  Were similar voice tests done in that environment, using UDP 
rather than IMP 0/3?  How did they compare....?

I guess I'm still curious how "buffer bloat" evolved over time. More 
memory would prevent "uncontrolled" traffic like UDP from being 
discarded, of course with the side effect of possibly getting delivered 
long after it was still usable.

Jack


On 4/5/22 16:42, Stephen Casner wrote:
> 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