[ih] Fwd: Packet Radio Info

Thu Apr 16 17:21:53 PDT 2026

Jack's summary is pretty accurate. The lossiness of packet radio, packet
satellite and ethernet all drove TCP reliability but the real-time
applications did not always benefit from assured delivery if that
introduced delay. Hence the transition from TCP2 and TCP/IP versions 3 an
4.

vint

On Thu, Apr 16, 2026 at 7:38 PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> Re Barbara's comment: "In the past, I have also mentioned my curiosity
> about whether, and how, packet radio might have influenced TCP
> decisions."I can confirm that the early experiments with Packet Radio
> definitely influenced the evolution of TCP.   In particular it paid a
> large part in the substantive changes made to advance from TCP version 2
> to version 4.
>
> At the time (late 1970s), the Internet was an experimental project of
> the US Department of Defense orchestrated by its ARPA component
> (Advanced Research Projects Agency).  I recall at one of the first
> meetings I attended Vint described military scenarios that the Internet
> was required to support.  The buzzword of the era was C3I -
> Communications, Command, Control, and Intelligence.   The Internet was
> envisioned to provide the Communications component of C3I. Intelligence
> would gather information about situations in the field, Command would
> digest that information and decide what to do, and Control would convey
> instructions to all of the appropriate military elements to implement
> those decisions.
>
> One of those scenarios I still remember pretty clearly.  It began with a
> soldier on some battlefield noticing an enemy force coming into view.
> That "intelligence report" was to be conveyed, along with all sorts of
> other similar observations, back to Command - which might be located "in
> the rear" or even back at the Pentagon. Decisions would be made and
> commands issued to units in the field to take appropriate actions.  For
> example, an Army unit might be ordered to move, an Air Force operation
> might be ordered to attack somewhere, or perhaps a Naval ship would be
> ordered to launch artillery or missiles at some targets.
>
> The technology of the 1970s was of course limited compared to what is
> available now.  Real-time video was not even a dream.   But it did seem
> feasible in the near future for each participant in Intelligence,
> Control, and Command to have some kind of device with a screen, and some
> form of voice communication, and some device (such as a light pen) which
> they could use to point at their screen.   The Internet would provide
> the Communications infrastructure to connect all of these devices
> together, possibly even all at the same time.  If you've used today's
> conferencing tools (such as Zoom and its competitors) that's the idea,
> but of course much more primitive to reflect the technical capabilities
> of the 1970s.
>
> In the 1970s military scenario, all screens might be displaying a map of
> a battlefield.  The soldier would use a light pen to point at a part of
> the map, and say something like "Three tanks and an enemy platoon just
> came out of the forest at this location, heading toward this location
> (while pointing to another part of the map)."  Somewhat later, orders
> might come back from Command.   Using the same screen/voice/pointer, the
> commander might say "Army Delta, move to this location.  Air Attack,
> strike this location.  Naval, begin shelling this location.   Execute!"
>
> Obviously timing and synchronization between the map, voice, and light
> pen were crucial to make sure that the Commands were communicated
> accurately.
>
> The task of the Techies (that was us...) building the Internet was to
> make sure the Communications infrastructure would support this and other
> similar scenarios.   It also had to work under battlefield conditions,
> where some parts of the infrastructure might spontaneously disappear, or
> even get captured by the enemy and remain functional.
>
> TCP2 was not up to the task.  In particular, early experiments with
> Voice over the Internet (and ARPANET) had surfaced the need for a
> communications service that focused on getting as much data as possible
> delivered quickly, in contrast with TCP's "virtual circuit" service of
> getting all of the data delivered, in order and intact, but it might
> take a while.  Other "types of service" might also be necessary -- e.g.,
> since maps were largely static, they might be delivered by some kind of
> "bulk transfer" service which was handled with much lower priority, and
> perhaps different paths, than the voice and light-pen transmissions.
>
> Field units using Packet Radio were probably most likely to disappear or
> be captured.      IIRC, the PR radio units used "spread spectrum" driven
> by a secure key, which made their transmissions much harder to detect
> and locate.
>
> The overall Internet would use Packet Radio for terrestrial and airborne
> units "in the field", SATNET/MATNET for ships and transoceanic linkage,
> DDN/ARPANET for terrestrial sites, and of course whatever kinds of LANs
> existed at the time.
>
> Lots of research was needed to develop appropriate routing and other
> internal mechanisms to make the most use out of whatever communications
> resources still were operational as conditions changed.  No one knew how
> to do that although there were lots of ideas to be pursued.  We were
> pretty far away from "rough consensus and running code".
>
> Meanwhile, it was possible to evolve TCP from TCP 2 to TCP 4.  TCP and
> IP were split apart, so that UDP could be added as a service that did
> not guarantee any kind of virtual circuit behavior.  Other protocols
> could be run on top of UDP, for example to deliver conversational
> voice.  Routing could possibly evolve to send different types of traffic
> over different routes - such as using satellite paths when latency was
> not a concern.  Techniques might be created to detect and isolate parts
> of the Internet that had been captured, as well as to avoid routes for
> critical traffic that were most vulnerable.
>
> The "Type Of Service" field was added to the packet headers, providing a
> means for specifying the needed service characteristics.  Of course at
> the time we didn't know how to do that, so all service choices were
> handled in the same way.   But the "hooks" were put in to make it
> possible to add such algorithms, as soon as research figured out what
> they were.
>
> Similarly, the "Options" mechanism was added to allow experiments that
> no one had anticipated.  I believe DCEC (Defense Communications
> Engineering Center) use that mechanism to experiment with some ideas for
> "S/P/T", which IIRC was an existing technique used to characterize the
> need for Security, Precedence, and something else I forget (the T).
>
> After the mid-1980s, I personally lost track of the research efforts.
> As far as I'm aware, the Internet hasn't ever developed multiple types
> of service, or more elaborate routing mechanisms to better support those
> now ancient military scenarios.  Perhaps technology has evolved in such
> a way that such approaches are no longer necessary.   But the military
> scenarios, including the use of Packet Radios, definitely influenced the
> evolution of TCP at the time when TCP 2 became TCP 4 and a required DoD
> Standard.
>
> /Jack Haverty
>
>
>
>
> On 4/16/26 00:38, Greg Skinner via Internet-history wrote:
> > Forwarded for Barbara
> >
> >> Begin forwarded message:
> >>
> >> From: Barbara Denny<b_a_denny at yahoo.com>
> >> To: Internet-history<internet-history at elists.isoc.org>
> >> Sent: Thursday, April 16, 2026 at 12:10:49 AM PDT
> >> Subject: Packet Radio Info
> >>
> >> Jack's somewhat recent email caused me to do some poking around the net
> for early info on packet radio.  I decided to share a brief summary of what
> I found in case anyone is interested.
> >>
> >> See my inline comment below for the start of this discussion.  See the
> original email for the rest of Jack's contribution.
> >>
> >> barbara
> >>
> >> On Thursday, March 12, 2026 at 12:26:01 PM PDT, Jack Haverty via
> Internet-history<internet-history at elists.isoc.org> wrote:
> >>
> >> ***** Deleted info ****""""""
> >>
> >> Prior to that, the Internet had largely been a project focused on
> >> military needs, with a "pipeline" driving technology from research to
> >> operations.  The most prominent example of full progress through that
> >> pipeline was the ARPANET, which evolved into the DDN as the
> >> comprehensive data communications system for all military needs.  But
> >> there were other projects proceeding down the pipeline, such as SATNET,
> >> which evolved into MATNET as a US Navy prototype, and Packet Radio,
> >> which evolved into prototype testing in Army exercises.   I don't know
> >> if either of those technologies advanced further down the pipeline.
> >>
> >> ****** Rest of Jack's  email deleted. ********
> >>
> >> For those who don't know much about Packet Radio, its reach went well
> beyond the Army (Besides demos and participation in Army exercises, there
> were testbeds at Fort Bragg and maybe Fort Sill).  There were a large
> number of demos/events for other DoD officials including the Marines,  the
> Air Force (The RP experiments with at least one demonstration at SAC), the
> Navy (I think the packet network in the Bay Area was extended down to the
> Naval Post Graduate School for an event for example.  There might have been
> a link problem that prevented its actual use during this event.),  DCA,
> and the Warrior Prep Center at Einseidlerhof, Germany (LPR for that one in
> the early 90s). There were also other small installations like at Xerox
> PARC and BBN. I also think the Fort Bragg testbed, which had  IMPs as well,
> was designed for operational service (24/7 with military users). I think
> planning for this testbed started in 1979 and packet radio participation
> continued with the release of the LPR in
> >    the mid 80s.
> >> The following two references contain more information about the Fort
> Bragg testbeds (ADDS and ADDCOMPE). These testbeds might have had the same
> Army people involved but reflected different periods in time. I only knew
> Fort Bragg had a testbed when I was working on packet radio at BBN.
> >>
> >> M. Frankel, "Advanced Technology Testbeds for Distributed Survivable
> Command, Control, and Communications", Milcom 1982.
> >> M. Frankel, C. Graff, L. Dworkin, and Thomas Klein," An Overview of the
> Army/DARPA Distributed Command Processing Experiments",  IEEE JSAC 4(2),
> 1986, pp. 207-215.
> >>
> >> I also confirmed that the Eichler site, used in the 1977 event at
> Zott's, was on Stanford land. It was not at the dish but nearby.
> >>
> >> The reference below contains more info about AALPs which was developed
> for the Fort Bragg ADDS testbed (XVIII Airborne Corp) using AI technology
> at the time.  A previous email mentioned this application.
> >>
> >> Debra Anderson, Charles Ortiz, "AALPS - A Knowledge-based System for
> Aircraft Loading", IEEE Expert 2(4),1987, pp. 71-79.
> >>
> >> I also tripped on a BBN Final Report in the Defense Technical
> Information website which includes brief information about the various
> versions of CAP (Channel Access Protocol)  software up until December
> 1980.  BTW, I believe there were two more CAP versions.  CAP6 included
> multi-station support and CAP7 was a stationless implementation. There may
> have been changes to the radio software for CAP6 and CAP7. I only worked on
> issues associated with the station so my knowledge is sketchy about other
> possible modifications. Things, like power control for example, were
> discussed at meetings but I don't know what was included.   See ADA093135
> in discover.dtic.mil for this report.
> >>
> >> In the past, I have also mentioned my curiosity about whether, and how,
> packet radio might have influenced TCP decisions.  I discovered the TCP
> working group had at meeting at SRI in October 1977 (
> https://www.rfc-editor.org/ieni/ien66.pdf <
> https://www.rfc-editor.org/ien/ien67.pdf>). Participants were given a
> packet radio demo using the mobile/bread van.  The TCP meeting notes
> mention the demo but there is no indication that it provoked any discussion
> relating to packet radio and TCP afterwards.  However if you look at the
> next TCP  meeting notes in January (
> https://www.rfc-editor.org/ien/ien67.pdf) , questions generated are
> recorded.  One response to a question suggests that there might be a way to
> improve TCP in a lossy environment. I haven't had a chance to look at later
> TCP reports.
> >>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>