[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ih] Baran and arbitrary reliability from arbitrarily unreliable components

    > 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

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:


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.