[ih] Fwd: Packet Radio Info

Thu Apr 16 16:38:42 PDT 2026

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20260416/768a9246/attachment-0001.asc>