[ih] Baran and arbitrary reliability from arbitrarily unreliable components

[John Day]

The idea of "building reliable systems from unreliable parts" was 
very much in the air during this period, because of John von Neuman's 
seminal paper of roughly that title.  It is von Neuman's paper that 
first proposes triple modular redundancy and works out the math for 
it.  Everyone was reading it and the turn of phrase was common.

But I agree with Noel, that Baran had more than voice on his mind as 
applications.

At 12:19 -0400 2009/03/11, Noel Chiappa wrote:
>     > From: Vint Cerf <vint at google.com>
>
>     > Baran was designing a VOICE communication system for command and
>     > control. The "message blocks" that his system routed around ... were
>     > chunks of voice.
>
>I'm not sure that's correct. In later remarks he definitely includes data,
>telex, etc; see, for example, his Babbage Institute oral history interview,
>page 18, "The basic idea that once you went digital, signals from data,
>teletypewriters, facsimile, and voice would all be digitized." (No doubt he
>saw telex as filling the application/human-use role now played by email,
>which of course didn't exist then.) I briefly tried to find the range of
>applications listed in the original documents (to make sure this was not
>human memory cross-talk), but so far haven't, although in Volume XI, page
>vi, he speaks of attaching "telephones and typewriters", so he likely did
>have the full range in mind back then.
>
>This does point to an additional point about Baran's system - he saw that
>with packets one could support everything, whereas with circuits, the
>converse is not true. (Volume I, page 22: "While a standardized message block
>is common in many computer-communication applications, no serious attempt has
>ever been made to use it as a universal standard.")
>
>And of course if one is trying to send voice, limiting the message size is
>important to minimize end-end delay jitter (hello, ATM :-), once again
>driving towards breaking large (user-semantics) messages up into segments.
>
>
>In re-reading the documents to find these references, a couple of more points
>about his system came through: the systems' ability to provide a _reliable
>system_ with _unreliable components_, again a somewhat novel concept, but now
>taken for granted. As part of that, his system was entirely distributed, with
>no central control - something again now taken for granted. He also showed
>how a certain degree of redundancy would provide a system which was _highly_
>immune to _major_ losses of links and nodes; this is not so important in
>today's Internet, but was also a significant result.
>
>In short, I think an old quote from the first Unix paper in CACM also applies
>to Baran's system (this is from memory, so it's only approximate): 'the
>strength of Unix is not so much in new ideas, although there are a few new
>ones, as in the way in which a _carefully-selected set of mechanisms_ work
>together to provide a very powerful overall system'.
>
>
>     > 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).
>
>I'm sure there was some sort of error detection, because the way his system
>worked was that a node retained a copy of a message until it got an
>acknowledgement from the neighbouring node that it had been received
>correctly, only then would it discard it. Of course, many FEC mechanisms also
>provide 'found error that couldn't be correct' outputs, so perhaps it was
>FEC, and not just a data-integrity check.
>
>The system may have had FEC on the radio links, for the exact same reason as
>too (BER too high), but I didn't feel like reading the Volume on radio links
>to find out! :-)
>
>	Noel