[ih] Some comments on the history

[Vint Cerf]

thanks Len - that's consistent with what I have understood for many years.
v


On Wed, Jan 29, 2025 at 2:53 AM Leonard Kleinrock <lk at cs.ucla.edu> wrote:

> Vint, Steve, Scott, et al,
>
> Thank you for adding those useful comments in this chain. I would like to
> comment on  two of them:
>
> 1. First, regarding the issue of an early focus on large networks, i.e.,
> the scaling effect:      As you correctly point out,  Farouk Kamoun and I
> focused strongly on the impact of large networks and the efficiencies to be
> obtained in large networks as evidenced in our papers (1976
> <https://www.lk.cs.ucla.edu/data/files/Kamoun/Data%20Communications%20through%20Large%20Packet-Switching%20Networks.pdf>
> , 1977
> <https://www.lk.cs.ucla.edu/data/files/Kleinrock/Hierarchical%20Routing%20for%20Large%20Networks,%20Performance%20Evaluation%20and%20Optimization.pdf>
> , 1979
> <https://www.lk.cs.ucla.edu/data/files/Kamoun/Stochastic%20Performance%20Evaluation%20of%20Hierarchical%20Routing.pdf>,
>  1980
> <https://www.lk.cs.ucla.edu/data/files/Kleinrock/Optimal%20Clustering%20Structures%20for%20Hierarchical%20Topological.pdf>
> ).
> Moreover, my early research was to address the networking issues in large
> communication nets; indeed, the opening line of my 1961 PhD thesis
> proposal “Information Flow in Large Communication Nets
> <https://www.lk.cs.ucla.edu/data/files/Kleinrock/Information%20Flow%20in%20Large%20Communication%20Nets.pdf>”
> is *“The purpose of this thesis is to investigate the problems associated
> with information flow in large communication nets.”.  *I again referred
> to large networks later in the proposal, namely, *“The two important
> characteristics of the communication nets that form the subject of this
> thesis are (1) the number of nodes in the system is large, and … “ *
> So there we see the recognition that scaling to large networks was a
> consideration in the earliest days of network research.
>
> 2. Second, regarding the history of recognition that packetization of
> messages provided many benefits and the discussion as to when Larry Roberts
> learned about the advantages of packetization:     I introduced the idea of
> packetizing messages into short fixed length blocks in my 1962
> <https://www.lk.cs.ucla.edu/data/files/Kleinrock/Information%20Flow%20in%20Large%20Communication%20Nets1.pdf>
> paper <https://www.lk.cs.ucla.edu/data/files/Message%20delay%20Phd.pdf> and
> there I show that the round robin protocol already used in computer
> timesharing systems could be adapted to data networks and that motivated me
> to provide the first mathematical model of packetization and analyzed the
> exact gains to be had for short messages.  I clearly pointed out that the
> notion of chopping units into fixed length blocks was specifically intended
> for messages in a communication network; for example, in my 1963 PhD
> dissertation
> <https://www.lk.cs.ucla.edu/data/files/Message%20delay%20Phd.pdf>, I say,
> “*We now explore the manner in which message delay is affected when one
> introduces a priority structure (or queue discipline) on the set of
> messages …”.    *As was pointed out*, *Larry was my officemate at MIT and
> we discussed my (and his) research constantly (in fact he wrote a
> metacompiler for the program I wrote to simulate communication nets).  He
> was intimately familiar with my research and he clearly knew about
> packetization and its benefits as early as 1961. As a side note, Larry
> himself stated *“In order to plan to spend millions of dollars and stake
> my reputation, I needed to understand that it would work. Without
> Kleinrock's work of Networks and Queuing Theory, I could never have taken
> such a radical step… . ”*
>
> I hope this adds more color and background to the discussion of these
> issues.
>
> Len
>
> On Jan 28, 2025, at 5:49 AM, Vint Cerf via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> roberts would also have been aware of Len Kleinrock's queueing theory
> analysis of message switching which, mathematically, was not very different
> from packet switching. They were both at MIT if memory serves and got their
> Ph.D's the same year, 1963.
>
> v
>
>
> On Tue, Jan 28, 2025 at 7:50 AM John Day <jeanjour at comcast.net> wrote:
>
> Brian,
> I agree with you. In the Baran reports, he describes something that sounds
> like a datagram. However, he never explores it much other than to define
> hot-potato routing. His focus is very centered on survivability and
> resilience, which makes sense it was research for the DoD. There is also
> the consideration that so far as I have been able to determine, all of the
> projects Baran was involved in afterwards were virtual-circuit, as were
> Roberts.
>
> OTOH, NPL didn’t do military research, so I guessed that their impetus for
> exploring packet switching had to be different and indeed it was. We have
> found a memo Davies wrote (and a similar one by Derek Barber) that Davies
> had attended the IFIP Congress in the US in 1965 and heard lots of papers
> on timesharing and the time slicing scheduling that timesharing used. The
> advantage being that while batch systems did FCFS and short jobs got stuck
> behind long ones, timesharut ing interleaved jobs and while short jobs were
> still delayed but their *completion* times were shorter. Davies told Derek
> that that was what they should do with communications and they did. Their
> impetus for packet switching was very different. (But there were two
> problems. ;-) 1) Donald got promoted and less time for research, ;-) and 2)
> the GPO got involved and the government directed NPL to concentrate on
> “practical” projects, so they had to move to virtual-circuits.
>
> Scantlebury told Roberts about packet switching at the Gatlinburg
> conference and convinced him to use it. When Roberts returned to DC, he
> found he had Baran’s reports in a stack of documents but hadn’t read it
> yet. Based on the NPL experience Roger also convinced Roberts not to use
> 2.4Kbps lines but 50Kbps, which was a large part of the ARPANET success.
> (Slower speed would have worked but been so slow people would have said it
> wasn’t practical, etc.)
>
> There is much more to be said about all of this. But that seems to be the
> core of it. I find it very interesting how minor events have major effects.
>
> Take care,
> John Day
>
> On Jan 27, 2025, at 20:47, Brian E Carpenter via Internet-history <
>
> internet-history at elists.isoc.org> wrote:
>
>
> Vint, and Noel,
>
> I just glanced through Baran's 1964 paper, and it clearly recognized
> statelessnesss (and a standard packet header) as important for network
> survivability and adaptive routing. But although he mentions networks
> of intercontinental size, I didn't spot any discussion of scalability
> as such.
>
> Interestingly, exactly the same applies to Dave Clark's 1988 "Design
> Philosophy" paper.
>
> In RFC 1958, we did note as principle 3.3 that "All designs must scale
> readily to very many nodes per site and to many millions of sites".
> I guess that by then (1996) this was too obvious to ignore, and it was
> written when IPv4 address exhaustion was considered inevitable.
>
> Maybe somebody who knows the early literature better than me can find
> something. But it's almost as if the intrinsic scalability of stateless
> packet switching was an unnoticed and accidental property.
>
> Regards
>  Brian
>
> On 27-Jan-25 11:16, Vint Cerf via Internet-history wrote:
>
> statelessness was an important design choice and was made consciously so
> that paths were not critical to successful transport. For example we did
> not want to have to reassemble along a particular path. Even though we
> deprecated fragmentation, at the time we thought it was important, we
>
> did
>
> not want gateway (router) state to be necessary to accomplish reassembly
> regardless of path. I don't know that we recognized the scalability
>
> aspect
>
> but we definitely cared a lot about statelessness of the gateways.
> v
> On Sun, Jan 26, 2025 at 4:25 PM Noel Chiappa via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> From: Jack Haverty jack at 3kitty.org
>
>
> At the time, the "ARPANET crowd" was skeptical that the
>
> "datagram"
>
> nature of TCP could be made to work. Traditional networks,
>
> including
>
> the ARPANET, had elaborate internal mechanisms to provide a
>
> "virtual
>
> circuit" service to its users.
>
>
> I was thinkking about this, and wondering if internetworking was a more
> fundamental advance than the ARPANET (relegating the latter to a
> 'ground-breaking experiment'), and I had another thought.
>
>
> Internetworking (following in the track of CYCLADES) made much of the
> fate-sharing aspect - that the data needed to ensure reliable
>
> transmission
>
> was co-located was the application. One good reason for that (that we
>
> knew
>
> at
> the time) was that it made the network itself simpler.
>
> But there's another side to that, one that was even more important, and
> which
> I'm not sure was obvious to us at the time (1977-79), which is that
>
> because
>
> it means the intermediate packet switches in the overall internet
>
> carry no
>
> state about the connections travelling through them, there's no scaling
> limit. This, to me, has been the single biggest reason why the
>
> Internet has
>
> been able to grow to the stupendous size it has.
>
> I don't think we could have been thinking 'this aspect of lack of
>
> state in
>
> the internet packet switches neans it will scale indefinitely',
>
> because I
>
> don't think we had any idea, at that point, about how to do path
>
> selection
>
> in
> a global-scale internet - so global-scale internets could not have
>
> been in
>
> our thinking.
>
> Did that infinite scalability turn out to be just a happy accident, a
> side-effect of good fundamental design (but one whose true complete
>
> value
>
> wasn't obvious to us at the time), one that moved state out of the
>
> internet
>
> packet switches?
>
>        Noel
> --
> 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
>
>
>
>
> --
> 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
>
>
>

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