End-to-end principle: Difference between revisions

End-to-end principle (view source)

Revision as of 17:41, 16 December 2020

3,643 bytes added , 16 December 2020

no edit summary

Amwelladmin

Bureaucrats, Interface administrators, Administrators

83,012

edits

@@ Line 1: / Line 1: @@
-{{a|tech|}}The [[end-to-end principle]] is a design framework for [[distributed system]]s. It counsels that the [[network]] should be kept as simple as possible and any necessary intelligence/{{risk|complexity}} be kept at the ends of the network - the entry points to it, in other words, as far as possible<ref>{{author|Lawrence Lessig}}, {{br|Code: Version 2.0}},126.</ref>.
+{{a|devil|}}
+{{quote|“I once got all the way to Glasgow from Edinburgh without a ticket. I walked.”
+:— Sid Snot, ''The Kenny Everett Video Show''.<ref>I cannot prove that I didn’t imagine this, as I can’t find it anywhere on the internet.</ref>}}
+{{quote|“There are more potential use-cases for a network, Horatio, than are dream’t of in your philosophy.”
+:—Shakespeare, ''Spamlet'', I: v}}
-On a computer network, that would mean "application-specific" complexity would be in the communicating end-nodes of the network, rather than in intermediary gateways and routers, that comprise establish the network.
+The [[end-to-end principle]] is a design framework for [[network]]s and [[complex system]]s. It says this:
-===Examples===
-'''Internet versus phone system''': In an old fashioned susbscriber dialling network you need to have the kit installed in your house before you can make a call, and you can call  in your [[Macintosh]] before it plugs into the network, and not on the routers and switchers through which the cleverly assembled messages from your Macintosh make their dematerialised way. The packets of data that fly across the net courtesy of the [[TCP/IP protocol]] are very simple indeed. The machine that collects them and reassembles them for a user at the other end of the network (also, likely, a Macintosh) is also very clever.
-'''Road versus rail''': In the case of a transport, compare a railway, in which you don't need any particular kit to ride on the underground, beyond a ticket, but you are severly constrained as to when and where and how you get from a limited number of points, and a road network, in which it is up to you what kit you bring to the network (you could walk, cycle, or show up in a Lamborghini Murcielago — your choice) but you choose when and where you travel, which route you take, and your catalogue of starting and ending points is almost infinite.
+:''Keep the [[network]] as simple as possible. Put all the complications/intelligence/{{risk|complexity}} at the ''edges'' of the [[network]]. Allow people to build whatever structures they like on their own turf, but keep the common spaces clear and simple.''
-Consequences of this design philosophy:
+{{author|Lawrence Lessig}} lays out the concept very well in his magnificent {{br|Code: Version 2.0}}.<ref>Page 126, analog freaks.</ref>.
-*You can innovate on the network without bothering the network "owner". This avoids "strategic" behaviour by the network owner (such as interfering to stifle the innovation).
+===Network layers===
+You can see any [[network]] as a series of layers, with only the most basic, bottom most layer connecting every item in the network. Each successive layer is more complex, but its use is suitable for a more limited number of “clients” with specific applications. That bottom layer must be as simple and universal as possible — universal in a literal sense, since every client of the network must be able to operate on it. Complications in the lower level of a network have costs for all higher-layer clients, even if those clients do not need the features. So the basic idea is to put complicating features in the highest possible layers such that every client operating at that layer (or higher) needs that feature.
+===Conceptual example: transport network===
+Say we are organising transport around an area of uncultivated, flat land.<ref>You can do other things with this network, too — build on it, grow things on it, but let’s keep it transport, to keep it simple.</ref>
+*'''Most basic level''': The whole area, as it is, At its most basic level  the network is maximally simple and flexible. You can access the “network” from anywhere (i.e., wherever you happen to be is an "entry-point" to the network) but you have to put in all the effort if you want to get anywhere. See Sid Snot quote above.
+*'''Second layer''': You can overlay a second layer suitable for people with a certain mode of transport. It will be necessarily less comprehensive than the basic layer, and will not suit all people, and will therefore have with a more limited set of entry-points. For example, a road system on the land optimizes the land for vehicular traffic, but some cost to those wanting travel some other way (and certainly to those wanting to use land for non-transport purposes) — so you don’t pave over the whole area, but built an road network, optimised for automobiles. People wanting to use the road the network need a car; people with other needs don’t use the road network at all. Once you have a car you can go anywhere on the road network; to go elsewhere in the area, you need to ditch your car and walk.
+*'''Third layer''': Say someone then operates a bus service on the road network. This is a third layer excellent for those who want to go whether the bus is going on the road network, but no good if you want to go somewhere else on the road network, let alone if you want to go elsewhere on the land.
+The classic example is of course the [[internet]] itself. At its most basic layer, it is a series of connected notes using the TCI/IP protocol and packet switching to which takes any type of data (text, video, audio etc) breaks it into tiny homogenous “packets” and sends them off across the network with an address, and the client at the receiving end reassembles them. There are all kinds of additional layers in it, be they walled gardens (Facebook etc) streaming services (Netflix), cloud servers and what not. Even as the fortunes of these services and gardens wax and wane (where are they now, AOL and MySpace) the un-owned internet grows ever stronger.
+===Consequences===
+This design principle has a number of advantages, especially in the digital commons where issues of physical property and the tragedy of real commons don’t apply:
+*'''It’s open source''': no-one needs to sanction the creation of a new layer. You can innovate on the network — create your own new bus company — without bothering the network “owner” 9if there even is one — there isn’t, on the internet. This also avoids “strategic” behaviour by the network owner ([[rent-seeking]], monopoly behaviour).
+*'''It’s permissive''': no-one is forced to use a more complex layer — clients retain autonomy and flexibility to select optimal levels at which to engage with the network: you can decide to walk, take a bus, take a car etc).
+*'''It’s competitive''': For the same reason, it incentives efficient and effective design: one can drop down to a more basic layer and instead implement an alternative, competing layer.
+*'''It’s agile''': Thus as use cases develop, the network develops organically to accommodate the new uses through the entrepreneurial  development of the network. So the internet has adapted from messaging to webpages, to VOIP and videostreaming etc etc etc.
+This applies in the design of all other kinds of multi-use systems, such as — for rather good example — a digital execution hub. There are a number of things you should not do when designing a network:
+*'''Teach to fish, do not give a fish''': Do not try to anticipate future uses. Acknowledge that the potential applications and use-cases
+{{sa}}
+({{br|Code: Version 2.0}}
 {{ref}}