[ih] principles of the internet

[Matthias Bärwolff]

On 06/01/2010 06:02 PM, Dave Crocker wrote:
> 
> 
> On 6/1/2010 8:47 AM, Matthias Bärwolff wrote:
>>>> 4. cascadability and symmetry (speaking to the rules of efficient and
>>>> flexible protocol design)
>>>
>>> What do you mean by the term "cascadability"?  What do you mean by
>>> "symmetry" in this context.
>>
>> There are ways in which you can have protocols doing similar things
>> (e.g. file transfer) but which are not possible to concatenate (or
>> cascade) without violating their semantics (pertaining to
>> acknowledgments and other such control actions).
> 
> Do you have some examples of 'cascadability' for the Arpanet or
> Internet?  I am still not quite seeing how it applies to the design or
> operation of the protocols.

The notion of "cascadability" arose in the context of interconnection of
different networks (Internet versus X.25/X.75), and has primarily been
addressed in some early Pouzin INWG notes (ca. 1973) -- the basic point
being that only a fairly simple service can be cascaded at all. The term
"cascadable" pops up in a 1979 Gien and Zimmerman paper. Generally
speaking, things like virtual circuits, end-to-end acknowledgements, and
buffer allocations seem to inhibit cascadability.

Examples for protocols that are not easily cascadable are Arpanet's
RFNMed normal message service which made any interconnection (e.g. with
Alohanet) at the packet level very awkward. Moving to the application
protocol level, an extreme example would be the logical impossibility of
concatenating sequential FTP with MIT's experimental Blast protocol
(send the whole file at once without flow control or sequential
acknowledgments, and then wait for a list of holes to resend).

Examples for nicely cascadable protocols are Arpanet raw messages (which
were not RFNMed) and IP.

Coming to think of it, maybe the notion of cascadability is a little too
obvious and trivial to actually count as a principle. (But then again,
in retrospect things often look much more obvious than at the time when
they were contested.)

> 
> 
>> Symmetry just means that neither end is conceptually master or slave,
>> instead both being equal peers (cf. Telnet symmetry).
> 
> At the application level, symmetry is either absent or a myth, for
> almost all applications.

True, applying a symmetry requirement/principle to the app protocol
level would probably go a little too far. For there is enough room for
all sorts of protocols there without prejudicing others, so there's no
need to be adamant about such things.

> 
> It also is not always present at lower layers (e.g., dhcp and I believe
> TLS.)
> 
> Hmmm.  For that matter, I suspect the Arpanet NCP was not all that
> symmetrical, although I do not remember enough of the details.  I also
> do not remember how symmetrical the IMP behavior was.  (But perhaps the
> Arpanet is going back too far for your discussion.)

As for packet forwarding, the IMPs were symmetrical as far as I can
tell; there wasn't much going on other than sending individual packets
either way (and waiting for ACKs, and then trow packets away; or resend
them if no ACK was coming back). The Arpanet Host-Host protocol was made
symmetrical at some point, I believe (it wouldn't matter who'd issue a
Request for Connection first, or if both issued them ar once; and both
sides could send stuff, once the connection was up).

> 
> The telnet reference is particularly salient.  When I was running an
> Internet software stack development group, we were seeking authorization
> to sell to the US government and they sent out a person to verify our
> standards compliance. During this, he required that we demonstrate that
> a host could sent the user (that is, serve to client) to WILL ECHO.  In
> other words, we had to support having the user's system echo data from
> the host server back to the host server.
> 
> We noted that this was illogical and highly undesireable.  He calmly
> agreed with us but them pointed to the symmetry of the protocol and said
> the formalities required us to support it.
> 
> We hacked the change long enough to pass the test, continuously shaking
> our heads in disbelief.
> 
> 
>>>> 5. running code, complexity avoidance, rough consensus, and path
>>>> dependence (speaking to the governance process and its stability)
>>>
>>> This sub-list merges at least two very different areas of concern.  One
>>> is the process for developing specification and the other pertains to
>>> technical characteristics of specifications.  The latter is also
>>> reflected elsewhere in your list.
>>
>> Agreed, the latter stands out somewhat. As for the separation you
>> mention, I would think, though, that the feasibility of getting anywhere
>> involves both the organization of the process, and the characteristics
>> of the resultant artifacts. I will have to think more about this.
> 
> I am not saying that they are not each important, but that combining
> them might confuse them as distinguishing concepts.
> 
> d/

-- 
Matthias Bärwolff
www.bärwolff.de