[ih] principles of the internet

[Matthias Bärwolff]

On 06/01/2010 07:23 PM, John Day wrote:
> Are you talking about principles in the formal sense, i.e. deriving from
> fundamentals, or more in the folklore sense, i.e. those contributing to
> myth?  I presume the latter.

I was thinking more about principles in the way Denning has reasoned
about them in his Library of Great Computing Principles project, that
is, be (1) universal, (2) recurrent, and (3) broadly influential
(http://cs.gmu.edu/cne/pjd/GP/gp_criteria.html). My idea was to find
those that have shaped the Internet.

> 
> Strictly speaking, your definition of symmetry is correct.  The other
> way to put it is that the protocol machines on either end of the flow
> are the same.  I commiserate with Dave's tale of dumb conformance
> testers.  I have seen them myself. However, I would disagree with him
> that all application protocols must be asymmetrical. While it represents
> the majority of those done so far, I would also contend that our
> applications so far are pretty rudimentary.  I think the Telnet example
> is quite exemplary.  The vast majority of that type of protocol at the
> time were asymmetrical.  Their designers lacked the insight to see it as
> a symmetrical problem.  Most thought that it was a terminal to host
> protocol or a remote login protocol (some textbooks still describe
> Telnet that way), when in fact it is a device driver protocol.  But then
> these points are moot since there is really only one application
> protocol required anyway.  The variety was just an indication of our
> lack of understanding at the time.
> 
> The economic issue is a good one.  I always point to the failure of the
> early NETRJE as an example of the obvious (elegant) solution being wrong
> for economic reasons.
> 
> It is the case that once an asymmetrical protocol is introduced into an
> architecture, it makes very difficult to build anything on top of it.
> 
> The running code/rough consensus is probably one of the more important
> aspects of driving the Internet to a artisan tradition rather than a
> more scientific one.  This is has probably contributed most to the
> stagnation we currently see.

(Off topic) I can't help but think that the running code/rough consensus
tradition has helped finding common ground among the vastly different
parties involved, which in turn was the basis for making progress at
all. It sure might be prone to all sorts of bias and even mediocrity,
but how else to do it? Can't see much of an alternative.

> 
> An odd complement to the aversion to complexity, there seems to be an
> aversion to sophistication that leads to greater simplicity.
> 
> The other phenomena which I have noticed but not been able to explain
> was that if one group did X (and didn't quite do it right), the Internet
> would do "not X" rather than "let us show you how to get that right."
> 
> It might be worthwhile to distinguish those principles that pre-dated
> the Internet itself vs those that were developed in the various
> precursors and were or were not taken up by the Internet

That sounds like a good idea. However, it would probably take quite some
effort to do it, given the world of prior experiments, experiences, many
of which are poorly documented at that. Arpanet and early Internet are
probably the easiest to find literature about, and follow actual stages
of evolution.

Matthias

> 
> Take care,
> John
> 
> At 17:47 +0200 2010/06/01, Matthias Bärwolff wrote:
>> Dave, thanks for your response.
>>
>> On 06/01/2010 05:33 PM, Dave Crocker 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).
>>
>> Symmetry just means that neither end is conceptually master or slave,
>> instead both being equal peers (cf. Telnet symmetry).
>>
>>>
>>>>  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.
>>
>> Matthias
>>
>>>
>>>  d/
>>
>> -- 
>> Matthias Bärwolff
>> www.bärwolff.de
> 

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