[ih] Baran and arbitrary reliability from arbitrarily unreliable components

[Vint Cerf]

Adding to Noel's excellent remarks:

Baran was designing a VOICE communication system for command and  
control. The "message blocks" that his system routed around ("hot  
potato routing") were chunks of voice. Small packets for rapid  
delivery (low latency). Radio based. Small packets also reduce  
likelihood that error correction would fail (this from guesswork and  
memory, I may be wrong about forward error correction but I believe it  
was included).

a very radical piece of work. It was rejected by the then telecom  
experts of the Defense Department who "KNEW" that the only way to do  
telecom was circuit switching.

How wrong they were.

v


Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Mar 10, 2009, at 10:27 PM, Noel Chiappa wrote:

>> From: mbaer at cs.tu-berlin.de
>
>> I still cannot quite figure out what the factual and logical role of
>> Paul Baran was for the development of the internet.
>
> It's not so much "the Internet", as packet networks in general; the  
> Internet
> is just the virtually omnipresent network which has subsumed the  
> many small,
> independent packet-switching networks that used to exist.
>
>
>> His writings strike me as very early and elegant descriptions of the
>> basic notion that a little redundancy in routes ... solves the  
>> problems
>> of connectivity, congestion avoidance and recovery in shared
>> (multiplexed) packet networks without (virtual) circuits.
>
> That is an important contribution, but not, to me, his most  
> important. I
> would say that his most important single contribution was the  
> concept of
> breaking a long "message" up into small, relatively fixed-size,
> self-describing segments (later named "packets").
>
> I say 'relatively fixed size' because the size range is restricted  
> to a
> relatively small range, compared to the size of the data objects  
> sent over
> the network; IPv4 packets ranged from 0 bytes to 576 (or slightly  
> larger
> now). That is tiny compared to files of many megabytes, which  
> existed even
> back then. The relatively small maximum size leads to many important
> consequences, both engineering and fundamental.
>
> One advantage is that buffering is much easier with relatively small  
> maximum
> sizes. Another is that all real links have a non-zero bit error  
> rate, and the
> chances of segment being corrupted by an error goes up as the  
> segments get
> large, so an extremely large segment has a small chance of getting  
> through
> without an error. Yet another is that if you want to have varying
> precedences, a large low-priority segment can block out other traffic.
>
> Sending the segments independently through a _shared_ switching  
> fabric which
> is shared in a non-pre-scheduled manner among the users is also  
> important,
> but there are precedents for that idea (e.g. the telegraph network,  
> the road
> network, etc).
>
>
> But really, his vision was for an overall _system_, and to draw  
> attention to
> one specific novel aspect - be it the small, self-describing  
> segments, or the
> on-demand sharing of the fabric (although that has precedents), or the
> dynamic routing (also with precedents), is to miss the novelty of  
> his entire
> vision.
>
> It's hard to imagine, now, what communications systems looked like  
> before
> Baran, but to really understand what he did, you need to try and go  
> back, and
> see the world as it was in, say, 1957.
>
> The idea of a modem, of sending digital data over a telephone line,  
> was only
> about 10 years old (I think the Whirlwind/Cape Cod system had the  
> first
> ones). Most communication was voice, over networks which dedicated a  
> circuit
> (some of the links of which perhaps used links shared in a fixed  
> way, through
> frequency-division, or later time-division, multi-plexing) to the  
> call, and
> there had to be a set-up, and tear-down, and the circuit was 'up'  
> until the
> call was completed. Telex was similar, although its data was  
> effectively
> digital, not analog. Telegraph networks were the closest thing  
> (conceptually)
> to the packet networks of today.
>
> In this environment, Baran's system, described in a series of papers
> (available online here:
>
>    http://www.rand.org/about/history/baran.list.html
>
> which you should really read if you are i) interested, and ii) have  
> not done
> so already) was truly radically different. His description of the  
> advantages
> of his system (see, e.g. pages 22-23 of Volume I) is clear, and far- 
> seeing;
> the advantages he lists (e.g. sharing a single infrastructure among  
> users
> with a wide range of bandwidth requirements) are still true today.
>
>
>> Had it simply been that this was not immediately relevant for the
>> Arpanet at first (RFNM), and the later developments leading to the
>> internet (multiple ASs, routing based on business considerations)?
>
> Baran's specific ideas have little direct relevance to the Internet;  
> many of
> the specific mechanisms (e.g. congestion control, routing, etc) are  
> very
> different _in detail_.
>
> But the _basic_ concept, of a system for digital communication,  
> based around
> packets, is the foundation of all data networks since then.
>
> 	Noel