[ih] Internet-history Digest, Vol 50, Issue 6

[John Day]

The primary advantage of datagrams, which was why CYCLADES pursued it (and what I was alluding to) is dynamic resource allocation being a couple of orders of magnitude more efficient. There is a 1968 paper by Peter Denning that shows this.  However, in routers, the amount of memory required was still being calculated based on a static allocation model.  

Yes, you can get too much of the wrong kind of state in the network and that seems to be where things have gone with DPI.  However, that doesn’t mean it should be as pure as driven snow.

As I said, CYCLADES was built to do research on networks. Datagrams were part of their minimal platform to investigate what else was needed. They were as surprised everyone else when datagrams seemed sufficient for the initial applications. (Confirmed by Jean-Louis Grangé, who implemented CIGALE).

By the time, more was needed, that idea (and how to investigate it) had been lost.

Take care,
John

I will respond to your PS separately.

> On Jan 11, 2024, at 17:33, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Vint Cerf
> 
>> the last point about speed adaptation is a key value in packet switching
> 
>> From: John Day
> 
>> Packet switching had many advantages .. was the improvement over
>> message switching
> 
> Packet switching - at least non-virtual-circuit packet switching (I'm not
> sure what the current technical term is for that now - would 'datagram packet
> switching' be it?), the flavour of packet switching everyone takes for
> granted these days, when 'packet switching' is used - has one key advantage,
> for a global-scale network, in addition to the speed/delay issues you all
> mention. Moreover, it's an advantage that IIRC we didn't appreciate at the
> time - and an advantage that nobody has really thought about since, because
> it _solves a problem that never happened_ - because NVC packet switching
> solved it before anybody realized it _was_ a problem!
> 
> Moreover, it's an advantage over actual circuit networks, as well as virtual
> circuit neworks - which makes it clear that it's not (just) the 'packets'
> alone that are the solution to our never-problem, it's a _particular kind_ of
> packets.
> 
> I refer to the growth of state in intermediate switches. If a data
> communication system involves _any_ state in intermediate switches related to
> a particular communication flow, the growth of that state, as the network
> gets bigger, is going to be a real problen. The (obvious, in retrospect)
> solution is to move all such state out to the leaves (hosts); since the
> number of leaves will grow roughly at the same rate as the network itself -
> problem solved - built-in scaling.
> 
> Maybe one of you smart people realized this beore I showed up, so it was not
> necessary to talk about it - because I certainly don't recall any discussion
> at any point after my arrival. (Then again, we were up to our chins - and
> later noses - in real, pressing problems! :-) I remember reading a memo
> written by Dave Clark, soon after I joined, which made the point that moving
> the state out to the edges was good for _robustness_. Something much like it
> was printed some years later (1988), a copy here:
> 
> http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf
> 
> I wonder if anyone has a copy of the original, it would have been circa 1978
> or so -  ISTR the phase 'they will all go together if they go', of
> the connection state and the application. However, that note says nothing
> about _scaling_.
> 
> So either it was so obvious it didn't need to be talked about - or it hadn't
> been thought about - perhaps because the choice of NVC packets meant it was
> (accidentally?) never a problem.
> 
> 
> This was brought home to me forcefully a year or so ago, when people on the
> UNIX history list, TUHS, started reminiscing about Datakit, and how nice it
> had been, and roughly (from memory) 'Gee, it's too bad the Internet didn't use
> Datakit'. My reaction be imagined. (OK, maybe not! :-) I did a quick 'back of
> the envelope' calculation and asked them, given the average HTTP TCP
> connection length, how many connection setups per second a Datakit backbone
> switch with a couple of OC48 links would have to do. (It's _many_ milions per
> second, or something like that.) Nothing more of how wonderful Datakit would
> be for the Internet was heard on that thread.
> 
> (I am perhaps more attuned to this issue because controlling state growth
> _was_ an issue for Nimrod, with flows; I invented stacked flow-ids - RFC 1753
> - as part of the solution. This mechanism was ater recycled as the 'label
> stack' in MPLS.)
> 
> 
> 
> PS: > From: John Day 
> 
>> Packet switching had many advantages, but from the point of view of the
>> inventors (Baran and Davies)
> 
> I'm putting this down here, so it won't distract from my main point (above),
> I would like to point out that an abstract of Baran's 1964 IEEE ToCS paper
> (Paul Baran, "On Distributed Communications Networks", IEEE Transactions on
> Communications Systems, Vol. CS-12 No. 1, pp. 1-9, March 1964) had been
> published in "IEEE Spectrum" (circulation about 160,000 in those days) in
> August 1964, so Baran's basic idea had been circulated very widely well
> before Davies started to think about the problem.
> 
> Which is not to say that Davies _didn't_ genuinely completely independently
> re-invent the concept of packet switching! But it's also _possible_ that the
> germ for the idea came to him, say, in a lunch-time conversation with someone
> who had either i) read about it in IEE Spectrum, or ii) had themselves heard
> about it from a third person.
> 
> At this point, we'll never know for absolute sure. All we _can_ say, _for
> sure_, was that Baran's ideas were published in the open literature in 1964.
> 
>     Noel