Another greybeard has left us: Packet pioneer Larry Roberts dies at 81

One of the internet's founding fathers, ARPANET packet-switching pioneer Larry Roberts, has died aged 81. Before ARPANET, telecommunications connections were carried over "circuit-switched" networks. A voice call, for example, used dedicated resources end-to-end, and the rudimentary data networking of systems such as Telex …

[A.P. Veening]

May he rest in peace.

[Flakk]

Godspeed, Mr. Roberts, and thank you.

[illuminatus]

Or indeed

In pieces. Which can be reassembled after routing into their correct configuration upon delivery to wherever he may be headed next

[Jellied Eel]

TTL exceeded

I think Roberts really was the engineer behind the Internet, and much of modern telecomms... But that's part of the bellhead vs nethead debate that ARPANET spawned. Personally, I think X.25 had a lot of advantages over TCP/IP, but the downside was it's perceived complexity.. So TCP/IP 'won', even though the underlying networks all pretty much rely on some form of packet switching.

[Anonymous Coward]

Re: TTL exceeded

Upvote for the Title ^^^

[Danny 2]

Re: TTL exceeded

Personally, I think X.25 had a lot of advantages over TCP/IP, but the downside was it's perceived complexity.

Anyone here 40 years or younger won't get this. Network theory, connectivity, was highly disputed into the mid 1990s.

I have some awful, awful tech books from then, very expensive nonsense, I would be eager to donate if El Reg started a library of tech crap.

25 years ago the main role of any third line engineer was to correct the lies of the salesmen without losing customers.

[Fruit and Nutcase]

Re: TTL exceeded

@Danny 2

I have some awful, awful tech books from then, very expensive nonsense, I would be eager to donate if El Reg started a library of tech crap.

Why not give first refusal to...

http://www.tnmoc.org/support/donate-equipment

Also, commentards may be able help with the wanted list...

http://www.tnmoc.org/support/donate-equipment/archive-wanted-list

[Danny 2]

Re: TTL exceeded

@Fruit and Nutcase

I've never heard of The National Museum of Computing before. I will certainly dig through my loft and make a car journey to Milton Keynes. Ta, you!

[Fruit and Nutcase]

Re: TTL exceeded

@Danny 2 - re TNMOC

Hopefully the Bletchley Park Trust and TNMOC are no longer at loggerheads and the "willy waving" has stopped. Anyway, when you visit, just ensure you go follow the directions on the website, passing the BPVC on your left, ignoring the first sighting of a car park. A while since I've been there, but the directions seem to be the same.

And resist the temptation to sit on the Cray!

[Mr Benny]

Re: TTL exceeded

I'm not convinced what weve ended up with at the hardware level is particularly great today either. 10baseT ethernet is jusf a serial protocol in disguise and the wrist thick ducted cable bundles and rats nest of cabling in even the smallest bridge cabinet in most offices testifies to its unsuitability IMO. An improved version of 10base2 or token ring would be a much tidier solution.

[Mr Benny]

Re: TTL exceeded

"@Mr Benny: If this is trolling, I take my hat off to you sir."

No, I'm not trolling. 10baseT is an absolute fucking disaster from an infrastructure POV. Alexander graham bell would probably be shocked by the rats nest of wiring it creates never mind those of us who worked with other systems that just required a single wire going around the room. There's is nothing wrong with daisy chain style networking so long as a machine can be automatically bypassed if its not working and with modern protocols the speed could still be kept suitably high enough for 99% of office scenarios.

[Alan Brown]

Re: TTL exceeded

"There's is nothing wrong with daisy chain style networking so long as a machine can be automatically bypassed if its not working "

Even with that part sorted, the complexity and collisions were why it was rapidly dumped.

A common bus is ok in _theory_ but in practice once you start running at any rate of speeds, time of flight (1ns per foot roughly) becomes such a critical factor that it's a lot more expensive to implement than simply running more (very cheap) wires.

[Jellied Eel]

Re: TTL exceeded

A common bus is ok in _theory_ but in practice once you start running at any rate of speeds, time of flight (1ns per foot roughly) becomes such a critical factor that it's a lot more expensive to implement than simply running more (very cheap) wires.

In my youth, we discovered that when an Amdahl 5990 wouldn't boot. Speeds and time-of-flight are still an issue, ie TCP's LFP problem, or just understanding how intercontinental Ethernet will perform, and why it might be a bad idea.

Same I think is true for other parts of Robert's legacy. So TCP/IP doesn't really scale well. X.25/ATM were a little better and designed for packet (and circuit) switching at higher speeds.. Although high speed then wasn't the Tbps we have today. But as mentioned futher down, it did spawn flow switching, which begat tag switching, which became MPLS. With a 56byte 'packet' to look at and act on. Funny that. Internally, that may have also become a 64byte 'J-Cell', but backplane builders and hardware types knew that to work at Gbps+ speeds efficiently, working on a fixed, small header made switching/forwarding a whole lot easier.

[Mr Benny]

Re: TTL exceeded

"So TCP/IP doesn't really scale well"

Its scaled across the planet. What sort of scale are you looking at , the universe?

[Jellied Eel]

Re: TTL exceeded

So standard response :)

https://tools.ietf.org/html/rfc760

The internet protocol is specifically limited in scope to provide the

functions necessary to deliver a package of bits (an internet

datagram) from a source to a destination over an interconnected system

of networks. There are no mechanisms to promote data reliability,

flow control, sequencing, or other services commonly found in

host-to-host protocols.

And oddly, also became part of discussions around the 'Interplanetary Internet', or 'Ciscos in Spaaaace!' as I called it before being disinvited. People doing space comms had some really neat, lighweight and reliable protocols used to communicate with spacecraft, satellites and probes to deal with latency, reliability and all the things IP relies on applications or the network to figure out.

TCP is one simple example. It built on IP to add some of the stuff that was missing. So FCS via SYN/ACK, MTU sizes, checksums, etc. Send a packet, wait for the ACK, send next packet.. Which is ok when latency is low, but as it increases, delays from SYN/ACK increase, so throughput decreases. Hence why FTP'ng a file from say, London-NY via a 1Gbps link won't get you close to 1Gbps throughput given the latency. So that's the 'Long Fat Pipe' issue. Transmit it via UDP instead and you'll be able to saturate the link.. But UDP's fire and forget, so if there's any dropped packets, the app needs to know. Somehow. Especially if your file transfer isn't the only traffic on that link, then you may be wanting some kind of congestion avoidance/management.. Which IP doesn't include.

There are other workarounds, like selective ACK'ng, but caution is sometimes needed. A reason why the Internet went global is it's 'open standards', which is great when they're really open and compatible with other vendor's implementations.

There can be other challenges, like a 'simple' MTU size & dealing with fragmentation, especially between layers. So common issue can be fragmentation on '1500' byte packets over Ethernet (especially emulated Ethernet) that has <1500byte payload frame. Which can be an issue on xDSL links given the way they're delivered. In the good'ol days, that could also be an issue for folks with 3Com networks because that used a larger MTU size. Stock answer to new customers saying they couldn't get to website X was ask if they were a 3Com shop, and if yes, reduce MTU.

Then there can be application specific issues. So VoIP on a network with no implicit congestion management/avoidance. Especially if that's by regulation and CoS/QoS is forbidden on the Internet because Net Neutrality. Or video. Mcasting was supposed to do that, but in no way scales to Netflix/YT like levels. Or had features a lot of content owners wanted, like control over subscribers. IPv6 isn't much better, but the Internet copes (thus far) because the solution is often to throw more bandwidth at the problem.

[Mr Benny]

Re: TTL exceeded

Why answer is "So what?" so all of that. IP was never meant to provide a reliable link and if it did it would screw up certain applications such as video and audio that rely on data arriving as fast as possible where some lost packets matter far less than prompt timing.

[Mr Benny]

Re: TTL exceeded

"Even with that part sorted, the complexity and collisions were why it was rapidly dumped."

So don't use a broadcast-at-will system. There are alternatives.

"A common bus is ok in _theory_ but in practice once you start running at any rate of speeds, time of flight (1ns per foot roughly) becomes such a critical factor that it's a lot more expensive to implement than simply running more (very cheap) wires."

I really don't think it makes a whole heap of difference to Sharon opening a Word document on the file server in the next room whether it takes 1ns or 2. Plus a modern 2 way ring bus system could have large numbers of tokens flowing at any one time. 10baseT is pointless - for point to point you might as well just use USB or firewire.

[Alan Brown]

Re: TTL exceeded

On a bus like 10Base2/10b5, EVERY packet is a broadcast packet.

You can play TDMA games, but then you're getting back into bellhead games instead of nethead statmux ones - and that in turn means you may have _guaranteed_ bandwidth on the wire, but it's only N/stations instead of allowing bursts up to much higher values (on the basis that stations are idle 99%+ of the time, even when carrying active voice sessions)

"I really don't think it makes a whole heap of difference to Sharon opening a Word document on the file server in the next room whether it takes 1ns or 2. "

It does matter when you have several classrooms of Sharons ALL trying to open a word document at once and collisions + backoffs turn that into a few thousand ns (try explaining to a school administrator that $1000 switch is better than $100 hub because it allows lessons to actually proceed)

"10baseT is pointless - for point to point you might as well just use USB or firewire."

Neither of which travel as far and by creating yet another standard you invoke https://xkcd.com/927/

In any case, 10bT was initially deployed in _hubbed_ (not bridged) evolutions of 10b2/10b5 which meant it still needed all the collision avoidance algorithms. It was only when moving to a switched environment that a lot of things could have been simplified and that was well into 100MB/s days (I can remember 100Mb/s hubs and paying $2k for 8 port 10Mb/s Lantronix switches that didn't work very well with my tulip cards)

Ethernet and TCP/IP didn't win because they were "better" technically.

They won because they weren't subject to stupidly high licensing fees, gateway charges or proprietary preciousness.

You could reuse the protocols and standards in different environments WITHOUT having to relicense them all over again. You didn't have to pay through the nose to learn them or make the chips or install the cabling and you could adapt them without having lawyers jump down your throat demanding royalties or hitting you with cease-and-desists.

There are some lessons there that various outfits which like to spout on about the value of IP repeatedly fail to take on board (ie: It's only of value if it's used)

[MyffyW]

Re: TTL exceeded

I vote for 10Base5 ... not because of any intrinsic architectural benefits but because the hardware and cabling looked like something from Battlestar Galactica

- Kara Thrace of Llantisilly

[Jellied Eel]

Re: TTL exceeded

25 years ago the main role of any third line engineer was to correct the lies of the salesmen without losing customers.

These days, that's often grounds for dismissal. Or just correcting the lies after they come waving signed contracts. Best example of the protocol wars was a large contract where our bit was X.25, handing off to another supplier who ran IP. Problems occured, fingers got pointed, but X.25 had non-repudiation features. Sometimes more useful than spewing out a stream of UDP and hoping for the best.

And as for books, I think I still have a copy of BT's pocket guide to their planned 'Open Network Architectutre'. The X-Men lost that one as well...

[Anonymous Coward]

Somewhere I have an edition of "ICL Network News" from the mid-1970s describing the UK Experimental Packet Switched Network (EPSS).

[Yes Me]

EPSS

the UK Experimental Packet Switched Network (EPSS)

That was a primitive first cut at X.25. You can argue that it derived from Davies' work at NPL, and in no way from the US efforts.

[a_yank_lurker]

RIP as another pioneer goes of to the Great Computer in the Sky

[astounded1]

A Good Man With A Very Dry Wit And A Big Brain

I knew Dr. Roberts around the time he founded Anagran. That company was more successful then you may think. He built traffic prioritizing "flow routers" that captured the attention of Microsoft, which then introduced Larry to a number of Pentagon types and the flow routing technology was suddenly gone underground. He didn't pass away broke, I can assure you. It's a very useful technology for giving network transit priority to packets like near real-time battlefield data flow, as you might imagine you'd desire, if a network is also carrying other, rather less critical information like supply chain logistics and an assortment of additional non-time-critical data. Versions of his discoveries in packet identification/prioritizing are under development all the time in the non-secret world. Related technology to flow routing allows mysterious network operators to throttle your excessive streaming of various stuff and such.

True story: Larry was stood before an audience in the Seattle area at a conference some years back where I was fortunate to share a panel with him. He was presenting slides to some 800 or so rapt audience members on the development of the ARPANET when he dryly intoned to the audience that "we didn't design it to be a television network." This received a big laugh, although I do not think Larry was kidding. (You could never tell, however, due to his aforementioned dry wit.)

The good doctor spent a lot of time thinking about packets. It's quite good he did, as it turns out. Dr. Larry, please prioritize my packets to a good place when I step across the river, if you wouldn't mind. See you then.

[TheOneEyedMan]

Re: A Good Man With A Very Dry Wit And A Big Brain

What a lovely theory, that Larry's flow routing technology has been snaffled away by agencies whose activities you're not supposed to know about. Sadly though it isn't true. I knew him better than most people in the last decade or so. Flow routing was a brilliant idea but Cisco and others were too well entrenched to be successfully attacked by a poorly funded startup. No, there was no conspiracy there either. Back on topic, I'm very sorry and very sad to hear that he has passed on so young, for this day and age. He was truly a genius, and like all geniuses, sometimes quite a challenge. I was at that conference in Seattle too, and Larry was at his absolute finest there.

[Mr Benny]

He was a genuine pioneer of the internet

Unlike people like zuckerberg and bezos who make billions on the back of other peoples ideas both technical and business.

[StuntMisanthrope]

The Giants Shoulders On Standing.

I propose an epigram. A font tapped forever. #cheers

[James R Grinter]

Small correction

It’s *Leonard* Klenrock.