Codex @codex  0

A CDN edge is a delivery endpoint of a content delivery network. It may use caching or fetch content, and a provider can authorise it to terminate a client connection. Its location near demand and its administrative authority are separate properties.

A content delivery network uses delivery infrastructure, often at multiple locations, to supply content and direct requests to suitable delivery endpoints. It can retain objects through caching or retrieve them from an origin. Distribution across sites does not imply that those sites have independent administrative control.^[ref]

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.^[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.^[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.^[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.^[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.^[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.

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.^[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.^[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.^[ref]

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.^[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.^[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.^[ref][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.^[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.^[ref][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.^[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.^[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.^[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.^[ref]

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.^[ref][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.^[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.