[ih] Comments on Packet Radio

[Vint Cerf]

thanks Don!
v


On Thu, Mar 27, 2025 at 6:09 PM Don Nielson <nielsonz at pacbell.net> wrote:

> I don't understand this internet history routing but I need to
> reply to Vint's observation about ETE reliability in the PRNET.
>
> In the early days of the PRNET it was sometimes envisaged to
> be a stand alone net to serve Army and other needs.  To make it
> reliable to users, some intranet ETE protocol was needed.  (Beyond
> the reliable SPP used to maintain the packet radio units themselves.)
> I thought I recalled some pre-TCP effort but I may well be mistaken.
> For as early as 1977 TCP was suggested for PRNET *intranet* use
> as well as an overlay for internet traffic through the PRNET.  (Attached
> is an excerpt from a Jan 1978 final report to DARPA indicating that use.)
> In essence TCP emerged to fill that stand alone need.
>
> A feature of the PRNET in dealing with its uncertain mobile environment
> led to its reliability even though packets were lost.  One reason for loss
> was a error checking technique in each PRU that would immediately discard
> bad packets. The other was simply channel failure.  To help, a hop-by-hop
> retransmission/ack arrangement was used with limited repeats and a
> concurrent local detection scheme to discard duplicates.  While still
> retained, the scheme was able to be simplified once TCP came into use.
> Don
>
> On 3/27/25 2:30 AM, Vint Cerf wrote:
>
> I was not sure whether Don's note got to the internet-history list, so
> apologies if this is a duplicate.
>
> I went back and re-read the long paper on Packet Radio in Proceedings of
> the IEEE Special Issue published November 1978.  Don is correct that there
> was a reliable Station-PRU protocol (called SPP) but I believe this was
> only used for Station/PRU communication. Not all traffic was carried that
> way and this, in part, motivated the development of the end/end TCP/IP
> protocol.
>
> https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1455409
>
> vint
>
> On Thu, Mar 27, 2025 at 2:46 AM Don Nielson <nielsonz at pacbell.net> wrote:
>
>> Sorry, didn't pay attention to limited addressees below.
>> Also a few typos corrected below.  Don
>>
>>
>> -------- Forwarded Message --------
>> Subject: Re: [ih] TCP RTT Estimator
>> Date: Wed, 26 Mar 2025 23:36:21 -0700
>> From: Don Nielson <nielsonz at pacbell.net> <nielsonz at pacbell.net>
>> To: Barbara Denny <b_a_denny at yahoo.com> <b_a_denny at yahoo.com>,
>> Internet-history <internet-history at elists.isoc.org>
>> <internet-history at elists.isoc.org>
>>
>> Hi, All,
>> The threads here are a bit random so I think I'll just try to give
>> a few comments that hopefully will answer much at issue.
>>
>> 1. The Packet Radio Network (PRNET) was, from the outset, to be a self-
>> forming network with a central controlling node called a station, but with
>> the ongoing potential of stationless operation.  That station had
>> an ARPANET interface for maintaining its software. The PRNET was
>> dynamic in the sense of self-restructuring with the addition or loss of
>> nodes. As early as 1974-5 it interconnection to the ARPANET was planned.
>>
>> 2. The packet radio units (PRUs) were at once a network repeater
>> and an entrance node to the network.  Some were placed at
>> promontories for area coverage and some were sited at user sites
>> as nodes for network access.  They were half digital/half radio and
>> sophisticated for their time.  For example, any PRU could be
>> software-maintained (debugged) remotely.  This obviously required
>> reliable PRNET protocols I think we called SPP and NCP they rode atop a
>> channel access layer that resided only in the PRUs.  That PRU layer
>> faced all the early issues of contention, routing, and efficiency and
>> the PRU radio section was designed as best to deal with mulitpath, etc.
>>
>> 3. The PRUs required interfaces to the terminals/hosts to which
>> they were connected.  (Exceptions to that were some traffic
>> generators built for early testing and some IMP interfaces to the PDP-11
>> station computer.). SRI built the terminal interface units and it was
>> in those that TCP was eventually placed.
>>
>> 4.  SRI was testing PRNET configurations in 1974-5 and doing so had
>> a number of PRUs (and one station computer) available.  By the end
>> of 1975 we had at least a half dozen in use and probably more in
>> backup.  By the end of 1976 about 14 were on site.
>>
>> 5.  Before mentioning TCP it needs to be said that PRNET intranet
>> protocols were end-to-end reliable, handling all the problems of
>> flow control, duplicate detection, sequencing, and retransmission.
>>
>> 6.  TCP implementation was anticipated in 1975 and preparations for
>> a station gateway that arrived in early 1976.  TCP for the SRI
>> TIUs was, according to one report, based on Stanford Tech Note 68
>> by Vint dated Nov 1975.  As Vint said, Jim Mathis lead that
>> implementation.
>> In early 1975 the BBN-provided gateway from Ginny Strazisar was
>> first tested without PRUs and early problems resolved.
>>
>> 7. So, with the gateway operating, it was time to take TCP to the field
>> and after some brief testing it was decided to have a little celebration
>> in that regard.  Ron Kunzelman of SRI suggested a nice accessible spot
>> for the SRI van and was at least one PRNET hop from the station/gateway
>> was Rossotti's. (I don't recall or if anyone with ever know whether other
>> PRNET repeaters that day were passing this traffic.  Given the absence
>> of other PRNET traffic, it would have been improbable.)
>>
>> Several SRI participants were there, one Army visitor, and I took
>> the pictures.  Please recall that the PRNET protocol was reliable,
>> so testing TCP exclusively on it wouldn't have made sense.
>> While the PRNET could halt under environmental issues, that didn't mean
>> it was lossy.  While the demo at Rossotti's was not mobile, we had
>> countless mobile demos of numeric patterns in which transmission
>> often would be interrupted, but we never saw errors.  We even would
>> disable the PRU radio unit to halt transmission to show no errors.
>>
>> 8. TCP reliability was, now that I think about it, at that point mainly a
>> test of the
>> new gateway and possibly if the ARPANET routing was somehow lossy.
>> If you saw the very lengthy weekly report entered manually from Rossotti's
>> you would see how well it all worked end-to-end.
>>
>> If I haven't bent your ears enough, I could try and answer anything the
>> above doesn't mention or errors in my memory.  I did look back at some
>> of the packet radio notes for the dates and numbers.   Don
>>
>>
>>
>>
>>
>> On 3/26/25 5:30 PM, Barbara Denny wrote:
>>
>> Having trouble sending to the email list again so I shortened the
>> original thread. Hope no duplicates.
>>
>> ****
>> I might be repeating but I will add a few comments. Hope my memory is
>> pretty good.
>>
>> Packet Radio nodes could act as sink, source, or repeater/relay for
>> data.  They could also have an attached device (like a station, end user
>> host, tiu, etc).  I think the packet radio addressing space was broken up
>> so you could determine the type of entity by the ID (need to double check
>> this). The station provided routes to packet radios when the packet radio
>> didn't know how to reach a destination. Any packet radio could be mobile.
>> I don't remember if there was a limit initially on how many neighbors a
>> packet radio could have.  Packet radio nodes did not use IP related
>> protocols but could handle IP traffic generated by other entities.
>>
>> Packet Radio nodes also had multiple hardware generations (EPR, UBR, IPR,
>> VPR, and also  the LPR which was actually done under a follow-on  program
>> called SURAN) .  There were also multiple versions of the radio software
>> known as CAPX where X was a number.   I think the earliest version I
>> encountered was CAP5 so I have no knowledge of the protocol implementation
>> used in the simulation Greg Skinner presented in his email message.
>>
>> In the early 1980s packet radio was implementing multi-station so you
>> could have more than one station in a packet radio network. I think this
>> was known as CAP 6.2 (6.4???).  There was also a stationless design being
>> discussed at the close of the packet radio program (CAP7).
>>
>> barbara
>> On Wednesday, March 26, 2025 at 04:07:34 PM PDT, Vint Cerf
>> <vint at google.com> <vint at google.com> wrote:
>>
>>
>> Jim Mathis wrote TCP/IP for the LSI-11/23. Nice piece of work.
>>
>> v
>>
>>
>> On Wed, Mar 26, 2025 at 5:26 PM John Day <jeanjour at comcast.net> wrote:
>>
>>
>>
>> On Mar 26, 2025, at 17:17, Vint Cerf <vint at google.com> wrote:
>>
>> yes, the gateway was colocated with the Station (on the same computer).h
>>
>>
>> I missed something. What is the Station?
>>
>> The Station managed the Packet Radio network, maintained information
>> about connectivity among the radio relays. PRNET was not a star network.
>>
>>
>> That is what I was assuming.
>>
>> Topology changes were tracked by the mobile nodes periodically reporting
>> to the station which other Packet Radios they could reach.
>>
>>
>> So a sort of centralized routing on the Station. An early ad hoc network.
>>
>> Hosts on the PRNET nodes could communicate with each other and, through
>> the gateway, with Arpanet and SATNET hosts. The PRNET nodes did NOT run
>> TCP,
>>
>>
>> So there were distinct machines acting as 'PRNET routers’ and PRNET hosts.
>>
>> that was running on the hosts like the LSI-11/23's or the Station or....
>>
>>
>> ;-) an LSI-11/23 wasn’t a lot of machine. ;-)  We had a strip down Unix
>> running on one the year before but as a terminal connected to our Unix on
>> an 11/45 but it was running NCP.
>>
>> Thanks,
>> John
>>
>>
>> v
>>
>>
>> On Wed, Mar 26, 2025 at 5:08 PM John Day <jeanjour at comcast.net> wrote:
>>
>> And those nodes relayed among themselves as well as with the gateway?
>>
>> IOW, PRNET wasn’t a star network with the gateway as the center, like a
>> WIFI access point.
>>
>> So there would have been TCP connections between PRNET nodes as well as
>> TCP connections potentially relayed by other PRNET nodes through the
>> gateway to ARPANET hosts.  Right?
>>
>> Take care,
>> John
>>
>>
>>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346 <(571)%20213-1346>
>
>
> until further notice
>
>
>
>
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice