Solution
= Solution
The <Internet> still reflects the original principles strongly in its common communication substrate, while many applications concentrate decisions and essential services in fewer hands. It is therefore necessary to distinguish the location of machines, the authority to control a service, and the placement of the checks that establish its correctness. A geographically extensive service can remain centrally controlled; a service with independently operated participants still needs to establish its promised result at the relevant <endpoints>.
The <end-to-end principle> is a test of function placement. If an application's required property depends on what happens at its <endpoints>, placing a partial implementation in the intervening network cannot establish the whole property. A receiver can accept bytes and then fail before storing the requested file correctly. The sender therefore needs the appropriate <application-layer acknowledgement>, rather than treating a transport acknowledgement as proof of durable storage. In this sense, <application correctness is not determined by a network trace>. Local recovery can still improve performance; it complements the application check rather than replacing it.<End-to-end arguments in system design by Jerome H. Saltzer and others>[Printed pp. 1–3 and 7: function placement, careful file transfer and application acknowledgements]{ref}
This principle does not imply that <routers> must be devoid of useful functions, nor that every mechanism belongs at precisely one layer. Its benefit is a clear account of which component supplies a promised result. <Internet Protocol> offers a common interface across different underlying networks. The <IP hourglass> permits different applications above that interface and different transmission technologies below it. New application behaviour need not require every intermediate network to be redesigned.<Architectural Principles of the Internet (RFC 1958)>[§§2.2–2.4: internetworking, end-to-end responsibility and concentrating application intelligence at endpoints]{ref}
There is nevertheless a real departure from a simple picture of directly communicating hosts. <Middleboxes> can inspect, alter or constrain traffic in ways that ordinary packet forwarding does not. A <firewall> makes a decision about permitted communication; a <proxy server> can become a separate application participant. Such mechanisms may address legitimate local needs, but an application's assumptions about what the path will carry now require additional justification. A new <transport protocol> cannot infer successful deployment merely from the existence of compatible host implementations.<Middleboxes: Taxonomy and Issues (RFC 3234)>[§1.2 and §2: the hourglass model and the catalogue of intermediary functions]{ref}
<Network address translation> gives a concrete state-management example. With <network address and port translation>, several private hosts can share an externally visible address through mappings in an intermediary. A particular active connection can depend on the continued presence of its mapping, not just on the two host implementations. Loss of that mapping can interrupt the connection even when those hosts remain operational. This qualifies the <fate-sharing> goal of keeping indispensable communication state with the participants that depend on it. It does not mean every translation failure is permanent or that a service cannot establish a new connection; the interrupted operation and its recovery behaviour must be specified.<Traditional IP Network Address Translator (Traditional NAT) (RFC 3022)>[§§2–3: traditional NAT/NAPT mappings, session state and routing constraints]{ref}
Concentration at the application layer is a separate issue. A <content delivery network> can place copies close to demand and direct requests to suitable delivery <endpoints>. This can reduce <network latency> and avoid repeatedly transferring the same content from its origin. Those are useful engineering results. However, <geographical replication does not imply decentralised control>: many delivery sites can still answer to one authority or depend on the same origin. Interconnection between delivery networks also requires explicit arrangements for request routing and metadata, rather than arising automatically from their physical distribution.<Framework for Content Distribution Network Interconnection (RFC 7336)>[§§1.2–3.1: actors, request redirection, content acquisition and interconnection interfaces]{ref}
Users consequently need to ask which operations remain possible when a provider or shared component is unavailable. Two service replicas might hold the same data in different regions yet both require one <identity provider> for each new <authentication>. That provider is then a <mandatory service dependency> for the new-user operation. More replicas of the data do not remove the dependency. Already admitted users might continue to work under a different design, so the conclusion concerns the declared operation rather than every possible use of the service. This is why <failure domains> and <service availability> must be analysed through dependencies as well as geography.
\Image[/past-exam-of-the-internet-technologies-and-regulation-course-of-the-university-of-oxford/2019-service-dependencies.png]
{title=Two service replicas with one mandatory identity dependency}
{description=Original schematic for an operation that requires a fresh identity check. An arrow points from a replica to a component whose response it requires. Loss of the shared identity provider can block that operation at both replicas even while their data remains intact; the diagram makes no claim about operations that do not require a new <authentication> response.}
The <endpoint> boundary also determines what a security promise means. <Transport Layer Security> protects communication to the actual <TLS> peer. Version 1.3 had been standardised in August 2018, before this sitting. If an authorised <CDN edge> terminates that connection, it is a participant in the protected communication and can obtain the application plaintext. That can be an intentional delegation, but it cannot simultaneously promise secrecy from that same participant merely because the connection carries an <encryption> label. A promise of secrecy from the intermediary requires suitable <end-to-end encryption> with the relevant decryption capability at the intended application <endpoints>.<The Transport Layer Security Protocol Version 1.3 (RFC 8446)>[August 2018, §1 and §2: goals and the authenticated, confidential channel between TLS peers]{ref}
Not every delegated function requires that stronger secrecy promise. A <client> might instead need to check that an object came from an identified publisher while permitting any suitable <cache> to deliver it. A <digital signature>, verified against the intended publisher's authenticated <public key>, can separate the delivery source from the authority for the content. It does not establish that the publisher's statements are true or make the object reachable. The useful design step is to state the promised property before deciding which component must be trusted to establish it.
For future services, one option is <internet service federation>: independently operated services exchange requests through compatible <communication protocols>.<Simple Mail Transfer Protocol (RFC 5321)>[§2.1 and §5: exchange between independently addressed mail systems and domain-based routing]{ref} This can permit a choice of provider, but it does not by itself eliminate shared naming dependencies or guarantee that all participants apply compatible policies. <Data portability> is a distinct requirement: users may need to take their state to another provider. A nominally open <protocol> is insufficient if the application's useful state cannot move with them.
The engineering response is therefore selective. Retain <endpoint> checks for the promised application result, identify every <mandatory service dependency>, and decide explicitly where control and state should reside. Use <caching>, <data replication> and authorised intermediaries when they improve the intended service, while testing whether common dependencies defeat the expected <fault tolerance>. Where independent operation is a requirement, test that requirement directly rather than counting machines. This preserves the adaptable part of the original architecture without pretending that every application must have the same trust boundary or administrative arrangement.<Architectural Principles of the Internet (RFC 1958)>[§1 and §§2.3–3.1: architectural evolution, application responsibility and design choices]{ref}