[ih] principles of the internet

[John Day]

SNA was not a packet switched network, but a 
traditional data comm network. A packet switched 
network besides sending packets was a peer 
network and SNA was definitely not.

(Although pedantically it was.  Codex use to take 
umbrage that their stat muxes (that supported) 
SNA were NOT doing packet switching.  By the 
mid-80s I  finally got them to admit that the 
primary difference was the granularity of the 
packet switching.)  But the point is that SNA 
came from entirely different paradigm than the 
packet switched idea.

At 14:49 -0400 2010/06/01, Richard Bennett wrote:
>It seems that you're not reaching back all the 
>way to the beginning in your search for 
>principles, and have therefore landed in some of 
>the mythology rather than the core ideas. It 
>seems to me that you can't describe the Internet 
>without acknowledging two facts as primary:
>
>1. Packet-switching. The Internet is one of a 
>series of exercises in the practical application 
>of packet-switching technology to computer 
>networking that began with ARPANET and continued 
>through SATNET, PRNET, CYCLADES, the Internet, 
>DECNet, XNS, SNA, and ISO OSI. The Internet 
>protocols all more or less assume a 
>packet-switching service, and in cases seek to 
>control this service.
>
>2. Internetworking. The Internet assumes that 
>there will be a service that transports IP 
>reliably. The Internet also defers certain 
>decisions about the management of packets - or 
>frames, to be more precise - to a networking 
>function that is specific to a given technology 
>such as ARPANET, PRNET, etc. Hence the Internet 
>specification is incomplete by design, insofar 
>as it leaves the layer two and layer one design 
>to the operator of the layer two networks.
>
>Many of the principles in your list - 
>simplicity, end to end, and symmetry, for 
>example - are actually side-effects of the 
>project, which was inter-networking packet-based 
>networks built on diverse technologies.
>
>The Internet protocols are agnostic about 
>privilege and best-effort, as these are layer 
>two functions that are simply outside the scope 
>of a system that goes from layer three to layer 
>seven (or whatever number you assign to 
>applications.) So the absence of a particular 
>function in the IP stack doesn't always mean 
>that it's frowned upon, it can mean that it's 
>expected to be provided somewhere else.
>
>I don't know that economics has much to do with 
>this, beyond the assumption that 
>packet-switching is more economical for 
>human-computer interactions than 
>circuit-switching is. The Internet wasn't 
>designed by economists.
>
>You do have to beware that the Internet has 
>developed its own hype machine that imbues it 
>with all sorts of magical properties that 
>probably werent' in the minds of its original 
>designers. The End-to-End Arguments paper, for 
>example, followed the design of the protocols by 
>nearly ten years, so to the extent that it 
>describes the Internet at all, it could only be 
>taken as a post-hoc explanation. And it doesn't 
>even pretend to describe the Internet really, 
>it's a general tome on distributed systems.
>
>
>On 6/1/2010 11:07 AM, Matthias Bärwolff wrote:
>>Dear all,
>>
>>I am in the middle of an argumentative research exercise in which I try
>>to map a set of principles that are central to the Internet (descriptive
>>principles, as informed by practices and universality of applicability;
>>not normative principles following purposes other than system stability
>>and individual liberty). Since most here have plenty of hands-on
>>experience I would be very appreciative of some feedback -- on-list,
>>off-list; long, short; however you like it.
>>
>>I made up the following list:
>>
>>1. original end-to-end arguments and economic efficiency concerns
>>(speaking to completeness and efficiency of implementation)
>>
>>2. modularity, minimal coupling, and layering (speaking to the general
>>architecture)
>>
>>3. least privilege, and best effort (speaking to the actual shape of the
>>interdependencies)
>>
>>4. cascadability and symmetry (speaking to the rules of efficient and
>>flexible protocol design)
>>
>>5. running code, complexity avoidance, rough consensus, and path
>>dependence (speaking to the governance process and its stability)
>>
>>Thanks for all your takes.
>>
>>Matthias
>>
>>
>
>--
>Richard Bennett
>Research Fellow
>Information Technology and Innovation Foundation
>Washington, DC