[ih] Baran and arbitrary reliability from arbitrarily unreliable components

[Matthias Bärwolff]

John Day wrote:
> 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.
Baran refers to the 1956 von Neuman paper in a 1960 RAND report (P-1995,
http://rand.org/pubs/papers/2008/P1995.pdf) and also to one by Moore and
Shannon on the same subject.

On my initial question: I gather from your responses that the
intellectual influence of Baran is significant, and that many of the now
commonplace ideas about networking are due largely to him (and Pouzin).

However, I recall having read in several places that ARPA had not been
influenced by Baran's work at all, and Roberts only had been made aware
of Baran's work by Davies in the 1967. Just found that odd. Has the RFQ
in 1968 been written in complete ignorance of Baran's work? After all,
it envisages packet orientation and distributed routing.
>
> 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
>