A computer network connects computing devices so they can exchange data using communication protocols. Packet switching shares communication links among many exchanges; routers forward network packets between connected networks. The arrangement of machines and links need not coincide with the arrangement of administrative control.
Network latency is the delay associated with communication over a network, distinguished from the rate at which data can be transferred. Moving a delivery endpoint closer to demand can reduce some path delay, but does not by itself establish application correctness or independent control.
A router forwards network packets between networks using forwarding information. Ordinary Internet Protocol forwarding is distinct from a middlebox function that translates addresses, terminates a transport connection or applies an application-specific transformation.
Packet switching carries separately represented units of data over shared communication links. Different packets can share forwarding resources; the network service need not reserve one dedicated circuit for an entire application exchange.
A network packet carries a unit of data together with protocol information used to interpret or deliver it. Internet Protocol carries datagrams; transport and application messages can span several such packets.
A layered network architecture separates responsibilities behind communication interfaces. A transport protocol can offer an application a service built over Internet Protocol without requiring each underlying network to implement that application. Layer boundaries are engineering choices: the end-to-end principle helps assess which properties a lower layer can actually establish.
A transport protocol provides communication services between its transport endpoints over an underlying network. Transmission Control Protocol supplies a reliable ordered byte stream; User Datagram Protocol supplies datagrams without that built-in recovery service. Applications can implement further mechanisms over either interface.
QUIC is a transport protocol designed over User Datagram Protocol with multiple streams and cryptographic protection. At the 17 January 2020 examination date, the cited November 2019 design was an Internet-Draft and work in progress. This historical description does not treat a later standard as already available.[ref]
QUIC: A UDP-Based Multiplexed and Secure Transport (Internet-Draft 24). 4 November 2019, §1 and Status of This Memo
User Datagram Protocol supplies a datagram transport interface without built-in reliable ordered-stream delivery. An application or another protocol can add recovery over that interface, as the pre-2020 QUIC design illustrates.
Transmission Control Protocol provides a reliable ordered byte-stream service between its endpoints, using sequencing, acknowledgements and retransmission. Receipt by that transport does not establish that a receiving application has durably stored the data or completed a user operation.[ref]
The Internet interconnects independently operated computer networks using the Internet Protocol suite. Its common inter-network interface supports diverse underlying networks and applications; individual services can still depend on centrally controlled providers.
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]
Framework for Content Distribution Network Interconnection (RFC 7336). §1.2 and §2.1: reference model and request redirection
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.
The Domain Name System provides a hierarchical namespace with delegated administration and distributed servers. Caching and replication help supply its service. A consistent namespace is compatible with distribution of responsibility across organisations.[ref]
Internet Protocol supplies an inter-network datagram interface. Its basic packet delivery does not itself guarantee arrival, order, absence of duplicates or completion of an application operation. IPv4 and IPv6 are versions of this network-layer protocol.
IPv6 uses 128-bit addresses and a revised packet format. More address space does not remove firewalls or decide which application providers must be trusted.[ref]
Internet Protocol, Version 6 (IPv6) Specification (RFC 8200). §1: expanded addressing and other protocol changes
IPv4 uses 32-bit addresses. Address sharing through network address and port translation is one response to pressure on its globally usable address space.
An IP address identifies an interface or destination according to the relevant Internet Protocol addressing rules. It is not inherently the identity of a person, and address translation can change the address visible across a boundary.
The Internet architecture comprises its protocol interfaces, addressing and naming arrangements, placement of functions and assumptions about communication. Physical connectivity, administrative control and application trust are distinct dimensions of this architecture.[ref]
Architectural Principles of the Internet (RFC 1958). §§2–3: internetwork layer and design issues
Internet service federation permits independently administered services to communicate through agreed protocols. Internet mail is an example: separate domains can exchange messages without every user joining one provider. Federation differs from placing many replicas behind one mandatory account authority, and it does not itself establish cryptographic confidentiality or freedom from software failures.[ref]
A middlebox performs a function on a communication path beyond ordinary Internet Protocol forwarding, such as address translation, traffic filtering or proxying. The function can be embedded in a device rather than implemented in a separate physical box. Its state and assumptions can affect failure recovery and protocol evolution.[ref]
A proxy server performs communication operations on behalf of another participant. Whether it can inspect plaintext depends on the protocols and keys it uses: relaying opaque encrypted bytes differs from authorised TLS termination.
A firewall enforces a communication policy, for example by filtering packets or tracking permitted exchanges. Blocking unwanted incoming traffic is a policy decision; it is not the definition of network address translation.
Network address translation maps IP addresses between address realms. State and path constraints can affect sessions. Network address and port translation additionally maps transport ports. Translation does not itself require decryption of application payloads.[ref]
Traditional IP Network Address Translator (Traditional NAT) (RFC 3022). Abstract and §§1–2: address and port translation, state and limitations
Network address and port translation permits several internal addresses and transport ports to share an external address by maintaining distinct translated bindings. Losing a binding can disrupt an exchange even when the application endpoints retain their own state.
Fate-sharing places state needed by a communicating endpoint with that endpoint, so that failure of an unrelated forwarding component need not erase the state of an ongoing exchange. This can help communication recover after a route change when a path becomes available again. It does not mean every router lacks state or that communication can survive loss of all paths.[ref]
The design philosophy of the DARPA Internet protocols by David D. Clark. §4: survivability and placement of essential connection state
The IP hourglass describes a common narrow inter-network layer supporting many applications above it and many network technologies below it. Keeping that interface general limits the need for every application developer and link provider to coordinate separate application-specific changes.[ref]
Architectural Principles of the Internet (RFC 1958). §§2.1–2.4: common internetwork protocol and independence from underlying media
Network decentralisation concerns the distribution of relevant control, authority or indispensable dependencies across independently operated participants. It is a property relative to a specified decision or service: distributed forwarding can coexist with centralised naming, credentials or application data. Counting physical servers is insufficient.
Construct a service with replicas in ten locations, all controlled by the same operator and all requiring that operator's account authority. The physical deployment is distributed, but control and the account dependency remain centralised. Increasing the number of sites leaves that counterexample intact. To assess decentralisation, state which operators can independently authorise participation, change protocol behaviour or preserve service when another operator fails.
When fully implementing a required function needs endpoint information, a lower-layer implementation cannot replace endpoint responsibility. Lower-layer mechanisms can still improve efficiency. The principle concerns function placement, not a requirement for peer-to-peer topology. Jerome H. Saltzer, David P. Reed and David D. Clark articulated the argument.[ref]
End-to-end arguments in system design by Jerome H. Saltzer and others. Author-hosted reprint, pp. 1–3: the argument and careful file transfer
Suppose an application's required property depends on endpoint state that is not determined by the network trace. Consider two executions with identical messages and forwarding behaviour: in one the receiver stores the received byte correctly; in the other it corrupts that byte after reception. The network trace is the same, but the required stored-file correctness differs. Any decision based only on that trace must give the same answer in both executions and therefore cannot establish the property for all executions.
This is an indistinguishability argument for that failure model, not a claim that network checks are useless. A link checksum may reduce transmission errors while an application endpoint still has to check the property that spans its storage and processing. Specify the endpoint boundary before claiming an end-to-end guarantee.
A communication protocol specifies the format and meaning of exchanged messages and the permitted behaviour of participants. Compatibility requires agreement about both message syntax and the state changes that messages cause.
An application-layer acknowledgement confirms a condition specified by an application's communication protocol. Receipt, successful processing and durable storage are different conditions. A Transmission Control Protocol acknowledgement of received bytes does not itself establish any stronger application promise; the relevant endpoint must establish that promise.[ref]
End-to-end arguments in system design by Jerome H. Saltzer and others. Printed p. 7: the SWALLOW example distinguishes message delivery from safe storage
A communication endpoint is a participant at the boundary of a specified communication function. Always identify the level: a TLS peer, a transport endpoint and an application endpoint need not represent the same boundary of correctness or trust.
Protocol ossification occurs when deployed implementations or intermediaries make established behaviour difficult to change, for example by rejecting an unfamiliar transport format or assuming fields will never evolve. Endpoint support alone may then be insufficient for deployment over real paths.[ref]
Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (RFC 7663). §§2–5: interface and middlebox constraints on evolution