End-to-end principle: Difference between revisions

End-to-end principle (view source)

Revision as of 08:42, 20 December 2020

1,023 bytes added , 20 December 2020

no edit summary

Amwelladmin

Bureaucrats, Interface administrators, Administrators

82,998

edits

@@ Line 18: / Line 18: @@
 ===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.
+====Most basic level====
-*'''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.
+The whole area, as it is, at its unimproved, is the basic level the network. It is maximally simple and flexible. You can access the “network” directly, by walking, and 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. You can access the network through a “device” you supply yourself — a vehicle — but not all vehicles work well directly on the basic network. Tractors and tanks do, but other vehicle types might go faster if there were a second layer on part of the network.
-*'''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.
+====Second layer====
+Such a second layer — a road network, for example — enable those with certain transport “devices” to move very efficiently from point to point on that second network layer.  It will be necessarily less comprehensive than the basic layer, will have with a more limited set of entry-points and will not suit all “clients” of the network. Roads are optimised for vehicular traffic, but those having to travel some other way (and those wanting the land for some other purpose) will find the road has a cost. Those wanting to use the road the network need to bring an expensive and highly complicated device with them: a car. You are not permitted to access the network without one, and version vehicles are practically, or legally, prohibited — trains, combine harvesters, planes.  There are some who wish too use the road network, but don’t have their own device. For these people, third layers evolve. Bus services, taxi services, ride-sharing services.
-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.
+====Third layer====
+Third layer networks bring access to the network to those without their own device, but at a cost of flexibility. The bus only goes at certain times, to certain places. Taxis and ride shares have an elevated running cost and are somewhat less convenient for regular use than private vehicles.
+===T’internet===
+The classic case of end-to-end design is of course the [[internet]] itself. At its most basic layer, it is a network of interconnected nodes. You send any data type (text, video, audio etc) across it using a routing protocol (the [[TCI/IP protocol]]) which decomposes the file  into tiny “data packets”, addresses them, and routes them individually across the network. Each packet goes its own way, through the network, and is only reassembled into a file by the recieving client at the other end of the network. 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.
 ==Design==
 ===Systems theory===
-{{quote|We don’t want to sell you Life Insurance . . we want you to know and have ''what life insurance will do''. A 1/4 million drills were sold last year: no one wants a [[drills and holes]]. What they want is the hole.
+{{quote|We don’t want to sell you Life Insurance . . we want you to know and have ''what life insurance will do''. A 1/4 million drills were sold last year: no one wants a [[drills and holes|drill]]. What they want is the hole.
 :—The ''Manhattan Mutual Life Company'' advertisement, Manhattan Kansas, 1946}}
-A new tool is not an end-goal in itself but a means to improving an existing [[Systems theory|system]] to create a certain output. In figuring out how to improve that system bear in mind the stocks, flows and feedback loops already in that system: these are what you need to influence; your machine needs to influence them. So bear in mind:
+A new tool is not an end-goal in itself but a means to improving an existing [[Systems theory|system]] to create a certain output. In figuring out how to improve that system bear in mind the stocks, flows and feedback loops already in that system: these are what you need to influence; your machine needs to influence them.
+Networks are systems. They develop, [[Ouija board]]-style, as a result of their actual use. Development is beyond the control of the system owner: indeed, most ''systems are not owned''.
-Systems develop for reasons that are beyond the control of the system owner: indeed, most ''systems are not owned''. Not all the reasons motivating the configuration of the system will be good ones from the perspective of an end user (in any [[Agency problem|agency]] scenario the hard to persuade an entrenched agent that she her role in the revised system should change — she has invested her capital in getting to where she is, and will not want to give up that capital, nor control over that position. If her role in the revised system will be deprecated — will change for the worse — it will be impossible to persuade her to adopt the new system. Why should she?
+Not all the reasons motivating the configuration of the system will be good ones from the perspective of an end user (in any [[Agency problem|agency]] scenario, it is hard to persuade an entrenched agent that she her role in the system should change — she has invested her capital in getting to where she is, and will not want to give up her position, nor control over how she develops it. If her role in the revised system will be ''deprecated'' — will change for the worse — it will be ''impossible'' to persuade her to adopt the new system. Why should she? Hence the eternal dilemma of the [[change manager]]: you can take a horse on a [[customer journey]] to water, but you can’t make her drink.
-But no participant in the system has a monopoly on it. If the system appears to necessitate such a behaviour change: to oblige someone to embark on a new journey that they don’t control, the better approach might be to leave that agent in situ, as it, but give other participants in the system an alternative route to achieving their goal. In the [[digital commons]] this is particularly easy to do. This way you have changed the dynamics of the ''remainder'' of the system in a way that obliges the agent in question to change her approach.
+But no system participant has a monopoly: that's a fundamental network design principle. If the system has an open architecture — conforms to the end-to-end principle — then be entrepreneurial: build your new layer in the system and see if the system adjusts to it. Leave the recalcitrant agent in situ, but give other system participants an alternative route to their goal. In the [[digital commons]] this is easy to do. This way you have changed the dynamics for the ''remainder'' of the system in a way that obliges the recalcitrant agent to change her approach. If she does not, water will flow around her, like traffic around a pedestrian at a neopolitan roundabout.
-Take the arrival of email. Had its success criteria involved shutting down the physical email system first, and replacing it with email — obliging people to buy the computer equipment and networks needed before a single switch-over day, it would never happen.
+Take the arrival of email. Had its success criteria involved “taking the physical postal system on a journey” to convert it to email — obliging people to buy the computer equipment and networks needed before a single switch-over day, it would never have happened. How would you even start on that process?
 ===Do this===