Feeds

Dr. Strangepackets or: How distributed systems foiled nuclear strikes

Precious digital signals

Secure remote control for conventional and virtual desktops

Into the Valley Poor Paul Baran has been forced to recount the motivations behind his work developing distributed networks and packet switching time and again. Such is the curse of a successful inventor, and to Baran's credit, he's as patient as ever when telling his story.

In case you've missed it, the tale goes like this. In 1961, with the Cold War being red hot, the US needed to devise communications technology that could withstand a major strike from the USSR. At the time, it seemed a large nuclear strike would disrupt communications networks to the point that command and control services would collapse. That's bad news when the ability to return fire on a massive scale serves as a major deterrent to an enemy making a first strike.

"The desire was to have what's called a second strike capability," Baran said, during a speech last night here at the Computer History Museum. "If you can survive a first strike and return a second in kind, there's a better chance of surviving. And the point of greatest vulnerability for accomplishing this was the command and control communications."

In addition, the US feared that the Soviets would likely hit us with everything they had, if their communications systems broke down. The idea being that a commander who cannot reach higher-ups would just assume that war was on, and that it was time to fire away.

"It was a very dangerous time," Baran said. "We were scared stiff. Without the communications, you would have a commander with missiles, and he would think a war is on and the Soviet response in that situation was to fail hot."

So, Baran set out to accomplish two things. The first was setting up a communications network with a mesh-like distributed design. Computers could be used to route traffic around numerous interconnected systems and if one or several boxes failed, the network would keep on ticking. This removed a reliance on a centralized system where a single box fed and received information from many.

In addition, Baran began work on packet switched networks that would break up data into smaller bits. Each packet could make its own way to the destination following the most efficient route available and then reassemble with other packets to form the original data. Baran originally called the smaller data components "message blocks." In the UK, Donald Davies independently came up with a similar idea and coined the term "packets" about five years after Baran started his work.

(There's a pretty hilarious Flash demo on packet-switching available here.)

"The telephone company said it wouldn't work and that I was crazy," Baran said. "Every time there was an objection, I had to go out and write a paper. Eventually, I ran out of reasons why it wouldn't work."

The telephone crowd was more used to the idea of circuit switching where a dedicated line is held open while information is being exchanged between two parties. They could not quite understand how one bit of information could be broken into parts with the parts taking different routes to an end point and that all this could happen more or less instantly, Baran said.

"These were people waiting for retirement," he said. "They were just old analog types, and they had no idea about digital."

It took years and years for the government and telephone companies to adopt Baran's methods. Eventually, much of the methodology developed by Baran was used as the basis for the Arpanet in the 1970s. Later this work would pave the way for the internet.

Rather comically, when asked if the US tried to patent or classify Baran's work, the networking pioneer disclosed that the government actually hoped the Soviets would borrow the technology.

"We would feel a more secure if the Russians had more secure command and control systems," Baran said.

If you ever have the chance to hear Baran speak, take it. Few IT luminaries can claim as much modesty or clarity as the RAND veteran and co-founder of the Institute for the Future. Baran emphasized again and again that no invention originates out of thin air and that he, like others, relied on the work of previous scientists and engineers.

"I think people in the popular press are lazy and paint a picture of people as being ten feet tall," Baran said. "It takes a combination of people (to do these things.) There is a piece here and there."

However, Sun Microsystems Fellow and security guru Whitfield Diffie credited Baran with unique abilities. Diffie, an audience member at the Sun sponsored Computer History Museum event, said that he "would be surprised if you could name anyone else" with the breadth of vision or foresight that Baran had at the time. ®

Remote control for virtualized desktops

More from The Register

next story
Azure TITSUP caused by INFINITE LOOP
Fat fingered geo-block kept Aussies in the dark
NASA launches new climate model at SC14
75 days of supercomputing later ...
Yahoo! blames! MONSTER! email! OUTAGE! on! CUT! CABLE! bungle!
Weekend woe for BT as telco struggles to restore service
You think the CLOUD's insecure? It's BETTER than UK.GOV's DATA CENTRES
We don't even know where some of them ARE – Maude
DEATH by COMMENTS: WordPress XSS vuln is BIGGEST for YEARS
Trio of XSS turns attackers into admins
BOFH: WHERE did this 'fax-enabled' printer UPGRADE come from?
Don't worry about that cable, it's part of the config
Cloud unicorns are extinct so DiData cloud mess was YOUR fault
Applications need to be built to handle TITSUP incidents
Astro-boffins start opening universe simulation data
Got a supercomputer? Want to simulate a universe? Here you go
prev story

Whitepapers

Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
How to determine if cloud backup is right for your servers
Two key factors, technical feasibility and TCO economics, that backup and IT operations managers should consider when assessing cloud backup.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
The Heartbleed Bug: how to protect your business with Symantec
What happens when the next Heartbleed (or worse) comes along, and what can you do to weather another chapter in an all-too-familiar string of debilitating attacks?