[ih] Comments on Packet Radio

[vinton cerf]

ironically, larry roberts rejected TCP/IP and developed X.25/X.75 because
he said he could not sell TCP/IP and datagrams but he thought he could sell
"virtual" circuits.

v




On Thu, Mar 27, 2025 at 8:12 PM John Day via Internet-history <
internet-history at elists.isoc.org> wrote:

> Jack,
>
> The difference between virtual-circuit (VC) and datagrams is the
> difference between static and dynamic resource allocation. Dynamic resource
> allocation is much more efficient, by orders of magnitude. The earliest
> result on this that I have found is a paper by Peter Denning from 1968 on
> supporting terminals for a time-sharing system, where the difference is so
> stark that it is obvious it is a general result. I know of at least 3 other
> times this result was rediscovered in networking. The last time in 2004
> where it was found that 90% of the buffers in core routers were unnecessary.
>
> The first datagram network that broke with VC was CYCLADES and the first
> datagram network was their CIGALE network that became operational in
> mid-1973. It was Louis Pouzin of CYCLADES that led the controversy with the
> PTTs over VC vs datagrams. His efforts caused the CYCLADES project to be
> shut down prematurely.
>
> Actually Transport protocols are not VC. This was an argument introduced
> by the phone companies to confuse matters. It was not effectively countered
> at the time and largely distracted the focus on connection establishment,
> when the actual difference between is wholly within the data transfer phase.
>
> In a VC technology, the path of the packets is fixed and while the
> buffering in the switches didn’t have to be static, it often was. But VC
> does require the allocation of capacity to be static (the fixed path). The
> ‘connection’ nature of Transport-like protocols is totally different. It is
> created by the feedback mechanisms for retransmission and flow control, not
> by making the path or the buffering static.  Hence, the real debate is
> between VC and datagram, which to my mind there is no debate.
>
> I hope this clarifies matters.
>
> Take care,
> John Day
>
> > On Mar 27, 2025, at 19:29, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > There may be a larger historical milestone revealed in these discussions.
> >
> > In the early 1970s, networks were traditionally "closed" technologies,
> with all internal mechanisms designed, built, and operated by a single
> group.   Such networks also presented a "virtual circuit" service to their
> customers.  Both Packet Radio and ARPANET networks had internal mechanisms
> to enforce a reliable byte-stream behavior, and were managed uniformly by a
> single team. I think other contemporary networks were similar, e.g. IBM's
> SNA (or whatever it was called then).
> >
> > The Internet, and TCP in particular, broke with that tradition, by
> moving the "virtual circuit" mechanisms out of the underlying switching
> systems and into the masses of "host" computers.  Each users' computer was
> now responsible for providing a "virtual circuit" service to its own users,
> as well as offering a new unguaranteed "datagram" service for users who
> needed minimal latency.
> >
> > To me, that was always the root theory to be tested in the "Internet
> Experiment" -- to answer the question "Is it possible to create a wide area
> network in which the wildly diverse and numerous users' computers provide
> much of the required mechanisms and the many components inside The Internet
> are not designed, installed, managed, or operated by a single owner or
> company?"
> >
> > It still seems to me like such a system shouldn't work very well. But it
> does.....
> >
> > Jack
> >
> >
> > On 3/27/25 15:21, Vint Cerf via Internet-history wrote:
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>