[ih] Comments on Packet Radio
Jack Haverty
jack at 3kitty.org
Thu Mar 27 19:43:07 PDT 2025
That's actually the tectonic shift I was trying to describe. At the
time, "everyone knew" that datagrams wouldn't work with the virtual
circuit mechanisms migrated out of the various network switches and into
the end users' computers. Tradition and experience made it so.
But some people didn't believe it was impossible, and deemed it worth
trying experimentally to see if such a hare-brained scheme could work.
TCP was defined by a pair of out-of-the-box visionaries, and a gaggle of
implementors collected who also were unaware that their task was
hopeless. Together, they made The Internet work, and proved the
collective traditional wisdom wrong.
Jack
On 3/27/25 17:16, vinton cerf wrote:
> 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
>
-------------- 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/20250327/c79e8b26/attachment-0001.asc>
More information about the Internet-history
mailing list