[ih] principles of the internet

[John Day]

>
>
>To return to my initial go with the list of principles, let me put
>forward a revised version applicable to the classic definition of the
>Internet ("roughly transitive closure of IP-speaking systems"):
>
>The classic end-to-end arguments (as exemplified by the case of file
>transfer to the standard of the application ends, not the more fuzzy
>reasonings about possibly excessive efforts in the network to the
>detriment of other applications) place a lower bound on the level and
>type of functionality that needs to sit with the application ends (which
>may not have to be very much).

Sorry I find the above very difficult to parse.  Can you try again? 
What classic e2e arguments are you referring to? Those in 1972 or 
those in 1982?

>
>Economic efficiency concerns and the imperative of complexity avoidance
>further narrow the actual balance of functions (in the abstract). Plus,
>the concern for economy of interface between application ends and

What does this mean?

>intermediary nodes severely limits the scope for having functions
>implemented in some cooperative way (see congestion control, two
>open-loop systems; routing, almost exclusively in the network; and

Probably shouldn't have been and isn't now.  This was hold over 
beads-on-a-string think.

>fragmentation, completely with the end hosts), discrete parts will thus

Fragmentation is not limited to the hosts.  Reassembly is, not fragmentation.

>fall to either side, and the communication, if any, will be implicit
>rather than explicit (see the fate of IP options and ICMP messages).
>
>So far, we still have plenty of scope for functions in the network.
>However, once we take minimal coupling, least privilege, cascadability,
>and best effort into account, there is actually a fairly low upper bound
>on what functions the intermediary network nodes may assume without
>collapsing the potential scale of the Internet to trivial proportions.
>
>That sort of summarizes my current gut feeling about the reality of the
>Internet (and silently neglects the point that the Internet today is
>probably anything but IP connectivity).

If I can make any sense out of this at all, it does not ring true for 
me.  In the ARPANET and other early networks, it always seemed to me 
that big difference was that this was being done by Operating System 
people, not telecom people.  Hence there was an attempt to put an OS 
imprint on it.  Make it look like it would look if they were 
facilities of an OS.  That is why I think (and others) believed it 
succeeded.  One of the things most perturbing in the Internet of the 
last 20 years is the degree to which telecom concepts have reasserted 
themselves.

As for other issues, we talked of principles such as relaying at 
layer (N) required error control at (N+1).  The media access relayed 
(MAC), data link any necessary error control, network relayed, 
transport did any necessary error control, applications could relay 
(and hence need routing) but mail didn't do end to end error control, 
but check-point recover in FTP did.

I don't see the OS perspective in all of this and it was key to our 
thinking.  At least for a lot of us.

Have you looked at Distributed Systems Architecture and 
Implementations by Lampson, et al.?

Take care,
John