= Solution
\b[By January 2020, the <Internet> had retained a broadly interoperable packet-delivery substrate while acquiring substantial centralisation of services and more functionality inside communication paths. The departure is real but uneven: independent network operation, physical replication, application control and placement of security functions are different architectural dimensions. Future service design should preserve <endpoint> responsibility for application correctness and make any delegation of control, state or trust explicit.]
<Network decentralisation> means that important decisions and dependencies are spread across independently controlled participants, rather than being concentrated in one indispensable operator. It is not established merely by counting machines. A <distributed system> can run in many locations under one administrative authority. The <end-to-end principle> addresses a different question: where should a function be implemented? If fully satisfying an application requirement needs knowledge available at the communicating applications, an implementation confined to the intervening network cannot replace that application-level responsibility. The two ideas often reinforce one another, because a general communication service leaves applications free to evolve, but they are not equivalent.
The original argument by <Jerome H. Saltzer>, <David P. Reed> and <David D. Clark> is about completeness of a system function, not a blanket prohibition on intelligent <routers>. Consider transferring a file whose correctness includes the bytes eventually stored at the destination. Perfect link checks do not exclude a subsequent storage error. The application still needs a check at the relevant <endpoint>. Local error recovery may improve efficiency, while the end-to-end check establishes the requested property over the complete path through the system. The reusable argument is that <application correctness is not determined by a network trace> whenever two executions can have identical network behaviour but different <endpoint> outcomes.<End-to-end arguments in system design by Jerome H. Saltzer and others>[Author-hosted reprint, pp. 1–3: function placement and the careful-file-transfer example]{ref}
This division also explains the <Internet>'s <layered network architecture>. <Internet Protocol> provides a common packet-delivery interface across different underlying networks; it does not promise reliable, ordered application completion. <Transmission Control Protocol> implements a reliable ordered byte stream between its transport <endpoints>, but receiving bytes is still different from completing the application's intended operation. <Fate-sharing> places essential communication state with the hosts that depend on it, reducing the need to preserve that state in every intermediate forwarding device. A route change can then leave the <endpoint> state intact, provided connectivity returns and the <protocol> can recover before it gives up. This does not mean <routers> contain no state: forwarding tables are different from indispensable per-connection state.<The design philosophy of the DARPA Internet protocols by David D. Clark>[§§2–4, goals, survivability and fate-sharing]{ref}
The <IP hourglass> gives this separation an evolutionary advantage. Many applications can use the same narrow inter-network interface, while many transmission technologies can support it. An application need not redesign every intermediate network before it can introduce a new service. However, the early architecture was not an entirely flat collection of equal peers. The <Domain Name System> is both hierarchical and distributed, with delegated authority and replicated information. Its design replaced a centrally distributed host-name file, so some architectural developments increased distribution. A common <protocol> or a logically coordinated namespace is compatible with independently administered components. The relevant baseline is a set of design goals and compromises, not an earlier <Internet> with no <servers>, hierarchy or coordination.<Architectural Principles of the Internet (RFC 1958)>[§§2.1–2.4: common internetwork layer, end-to-end functions and distributed responsibility]{ref}<Domain Names - Concepts and Facilities (RFC 1034)>[§§2.1–2.2 and 4.2: host-file scaling, distributed maintenance and zones]{ref}
A clear departure from direct <endpoint> reachability is <network address translation>, particularly <network address and port translation>. A translator can let several privately addressed hosts share an externally usable address by maintaining mappings for their traffic. This helped accommodate address scarcity and could be introduced incrementally. It also made the path depend on an additional stateful intermediary: incoming traffic generally needs an appropriate mapping or explicit configuration, mappings can expire, and moving a flow to a different translator can break it unless the necessary state is available there. Two applications being willing to communicate is consequently not sufficient for connectivity. Application-specific gateways and relays may become necessary. The benefit is practical deployment; the cost is reduced address transparency and extra recovery and deployment constraints.<Traditional IP Network Address Translator (Traditional NAT) (RFC 3022)>[§§1–2 and 6: address/port mapping, state, route changes and limitations]{ref}
<Firewalls> and <application proxies> make another important qualification to the ideal of an unrestricted path. A <firewall> deliberately restricts traffic according to a security policy. An <application proxy> can perform a function on behalf of an <endpoint>, sometimes with information and permissions beyond ordinary <packet> forwarding. Such arrangements can protect vulnerable systems or provide a useful service; treating every intervention as an architectural mistake would ignore actual security and operational requirements. The cost must nevertheless be recognised: an intermediary can become an additional failure point, a source of incompatible assumptions or an authority whose permission is needed to deploy a new application. Different <endpoint> operators may have conflicting objectives, so assuming universally cooperative, trustworthy hosts is insufficient as a design method.<Middleboxes: Taxonomy and Issues (RFC 3234)>[§1.1, §§2.9–2.15 and §4.1: forwarding versus middlebox functions, firewalls, proxies and architectural consequences]{ref}<The Rise of the Middle and the Future of End-to-End (RFC 3724)>[§§3.1–3.3: changing trust relationships and service demands]{ref}
One consequence is <protocol ossification>. If devices along a path recognise only familiar <packet> formats or alter fields in undocumented ways, changing the transport <endpoints> alone may not be enough to deploy a new <transport protocol>. An extension can fail even when the two hosts support it. This is a loss of the original freedom to innovate at the edges, rather than simply an increase in the number of network devices. By 2015 an architectural workshop had explicitly examined <middlebox> and interface constraints on transport evolution. A new service therefore needs a deployment strategy that accounts for real paths, including appropriate negotiation, measurement and fallback, rather than assuming every syntactically valid <packet> will pass.<Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (RFC 7663)>[§§2–5 and §6.1: ossification, incentives and encapsulated transports]{ref}
Application architecture has also become less decentralised in a way that is not reducible to <middleboxes>. A service can concentrate user accounts, authoritative data and <protocol> decisions in a provider while running many geographically separated <servers>. <Cloud computing> and a <content delivery network> can reduce the effort needed to deploy a service, improve <network latency> by placing content closer to users, and spread load across sites. A <content delivery network> can direct requests to delivery <servers> and use <caching> to keep copies near demand; the origin provider can authorise this arrangement. These are substantial engineering gains. Yet losing access to a provider's identity, configuration or authoritative data service can disable an application even while <IP> forwarding remains available. <Geographical replication does not imply decentralised control>.<Framework for Content Distribution Network Interconnection (RFC 7336)>[§1.2 and §§2.1–3.1: content providers, delivery networks, request redirection and content acquisition]{ref}
A browser communicating with a central application <server> is not, merely for being <client-server model>, a violation of the <end-to-end principle>. The <server> may be exactly the application <endpoint> that has the necessary knowledge. The architectural concern is whether users can choose or replace that <endpoint>, whether independent implementations can interoperate, and what additional parties must be trusted. <Internet service federation> addresses the administrative dimension: independent providers communicate using an agreed <protocol> instead of every participant needing an account at one authority. <Internet> mail supplies an established example of communication across separately operated domains, even though individual organisations may use large central <servers>. Federation does not itself guarantee <cryptographic confidentiality>, <fault tolerance> or choice among many operators; it changes who can participate and which dependencies are mandatory.<Simple Mail Transfer Protocol (RFC 5321)>[§§2.1–2.3: basic model, relays and destination-domain mail delivery]{ref}
The distinction is especially clear for <encryption>. <Transport Layer Security> protects a channel between its cryptographic <endpoints>; it does not define those <endpoints> as the two ultimate human users. In one design, a browser's <TLS> peer is the origin <server> and intermediate <routers> lack the channel keys. In another, the origin authorises a <CDN edge> to terminate <TLS> and the <CDN edge> uses a second protected channel to the origin. Both links can be encrypted while the <CDN edge> processes plaintext. <TLS termination moves the confidentiality boundary>. This is not automatically an unauthorised interception, but it is a different trust arrangement that should be documented. <Network address translation> alone does not require decrypting a <TLS> payload.<The Transport Layer Security Protocol Version 1.3 (RFC 8446)>[§1: channel properties between peers and dependence on application interpretation of authentication]{ref}
\Image[/past-exam-of-the-internet-technologies-and-regulation-course-of-the-university-of-oxford/2020-trust-boundaries.png]
{title=Forwarding and address translation differ from authorised TLS termination: two protected channels can expose plaintext at their shared endpoint}
If a service promises secrecy from its own relay or storage provider, transport <encryption> to that provider is insufficient. <End-to-end encryption> must keep the relevant plaintext and decryption capability at the intended application <endpoints>. Similarly, a <client> can verify a publisher's <digital signature> on an object obtained through a <cache>, separating the source of delivery from the authority for content. Neither mechanism alone hides all communication metadata, solves <endpoint> compromise, or ensures the service is reachable. The design question is which party needs which information, and what property the user is actually promised, rather than whether every segment has an <encryption> label.
These changes therefore call for selective preservation of the original principles. At the network layer, favour general interfaces and independently deployable extensions rather than unnecessary application-specific assumptions. <IPv6> expands the address space and can remove a reason for address sharing; it does not compel operators to permit incoming connections, remove <firewalls> or decentralise application ownership. It would be unjustified to expect a larger address alone to restore the whole earlier architectural ideal. Address transparency, security policy and application control require separate choices.<Internet Protocol, Version 6 (IPv6) Specification (RFC 8200)>[§1: expanded addressing and other changes from IPv4]{ref}<Internet Transparency (RFC 2775)>[§§2.1–2.3, §§3.3–3.6 and §5.1: distinct end-to-end properties, intermediaries and limits of address-space remedies]{ref}
At the transport layer, the November 2019 <QUIC> Internet-Draft provides a timely example of trying to evolve functionality at the <endpoints> over the widely deployed <User Datagram Protocol>. It includes encrypted transport machinery, connection identifiers and support for changes of network path. As of this examination it is work in progress, not a completed <Internet> standard. Its approach shows how deployment constraints can stimulate a new <endpoint> implementation, but it is not proof that every network will carry <UDP> or that encapsulation abolishes all <middlebox> dependencies. Designers must preserve <congestion control> and explicitly assess the tradeoff between encrypted <protocol> details and information needed for network operation.<QUIC: A UDP-Based Multiplexed and Secure Transport (Internet-Draft 24)>[4 November 2019 version, §1, §§5–6, §9 and §12: endpoint transport, negotiation, migration and UDP packets; Status of This Memo identifies work in progress]{ref}
At the application layer, put the final checks for the promised result at the <endpoints> that can actually observe it. An intermediate acknowledgement should not be confused with successful storage or completion of a user operation. When an intermediary is useful, specify its authority, its failure behaviour and the state it holds; make security-sensitive delegation visible rather than silently expanding trust. Separate this from the performance decision to use <data replication> or <caching>. Those optimisations may be valuable even when <endpoint> verification remains indispensable.
Resilience likewise requires examining dependencies across operators and components, not just counting replicas. Identify which failures can be tolerated while an application still makes progress, including failure of a naming, identity or configuration service. Where appropriate, use independently operated services, interoperable <protocols> and <data portability> so that users can move state or change providers. These options have costs: federation requires compatibility between implementations, while replicas need coherent handling of updates. A centrally operated component can be a reasonable choice when its benefits justify a clearly identified dependency. It should not acquire the label decentralised simply because it is replicated.
A useful evaluation would test the service from independently administered networks, including one with address translation, and distinguish connection establishment, <endpoint> correctness and recovery after an intermediary restart. For a delegated delivery service, separately test what an authorised <CDN edge> can observe and what an application-level authenticity check validates. Such tests make the architectural claims concrete; a successful throughput measurement alone cannot establish freedom from mandatory intermediaries or secrecy from a delivery provider.
\b[The strongest January 2020 assessment is that end-to-end function placement remains a valuable criterion, while universal reachability and independent control have been constrained at several layers. The design goal for subsequent services is a clear allocation of correctness, trust and failure responsibility, with the benefits and dependencies of intermediaries exposed rather than hidden behind a simple centralised/decentralised label.]
Back to article page
