[ih] Some comments on the history

Tue Jan 28 23:53:36 PST 2025

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 <mailto: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
> 
> 
> until further notice
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
> https://elists.isoc.org/mailman/listinfo/internet-history