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

[Stephen Casner]

On Tue, 5 Apr 2022, Jack Haverty wrote:

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

Yes, 1822 says "If at any time there are insufficient resources in the
network to handle one of these messages, it will be immediately
discarded."

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

Yes, but in practice at the time we were doing the packet voice work
in the 1970s this was not a problem.  The severe ARPANET congestion
occurred later in the 1980s.

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

The tests reported in the NTC 78 paper were for traffic between ISI
and LL.  That was a cross-country path through a minimum of 8 IMPs.  I
don't recall if we chose test times when competing traffic was low,
but the paper does not report packet losses.  The effect of higher
packet rates was more delay through the network (presumably) due to
processing delays in the IMPs.

What I recall about our use of type 0 subtype 3 packets was that the
first tests required coordination with the NOC to enable the packets
on the designated test IMPs at the arranged test time.  But over time
as the tests showed that the traffic was not going to crash the
network the policy became more relaxed.  Eventually the facility was
always enabled on our IMPs and it was used routinely for our packet
voice work.

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

Certainly the packet audio and video work progressed to use UDP over
the DARTnet, for example, in later years.  I don't recall Source
Quench ever being a useful function, though.  Packets were just
dropped.  Initially such traffic worked well only on network paths
with low loads, but over time as network capacity grew the packet
audio and video presented a smaller portion of the overall load so the
best-effort service worked most of the time in most places.  That's
essentially where we are today.

                                                        -- Steve