Architecture and Requirements for Transport Services
Extracted elements (30)
Connection Contexts allow applications to explicitly force separation of Cached State and Protocol Stacks between Connection Groups. The primary motivations are privacy: preventing linkability from reused TLS session state or HTTP cookies, and preventing a Remote Endpoint from inferring that multiple connections originate from the same application via HTTP/2 or QUIC multiplexing.
Racing (borrowing terminology from Happy Eyeballs, RFC 8305) is built into the Transport Services Implementation rather than requiring each application to implement it separately. This enables simultaneous, synchronous, serial, or hybrid attempts across Candidate Paths and Protocol Stacks to select the most optimal combination.
The API uses Messages rather than a byte-stream abstraction because most applications already interpret structure within streams (HTTP/1.1 uses delimiters, TLS uses record headers, HTTP/2 uses frames). Exposing Messages provides the Protocol Stack with additional information (deadlines, reliability preferences, multistreaming assignment) without changing on-wire formats.
The architecture requires applications to specify Endpoint Identifiers at a higher level of abstraction (hostname or URL) rather than IP addresses, so that the Transport Services Implementation can perform resolution, path selection, and racing on the application's behalf, enabling automatic protocol and path agility without application changes.
The Transport Services API is event-driven and fully asynchronous rather than blocking, as in the Socket API. This more naturally reflects the nature of network interactions in time and avoids the try-and-fail model required to emulate asynchrony over sockets.
Neither the Transport Services API (RFC 9622) nor the implementation guidelines (RFC 9623) define new on-wire protocols or protocol capabilities. A Transport Services System MUST NOT require a peer to use the same API or implementation; it must interoperate with any conforming transport protocol implementation.
The Transport Services System is designed to coexist with the Socket API rather than replace it entirely, as coexistence has been recommended for incremental deployability (RFC 8170). Only applications built on the Transport Services API are managed by the Transport Services Implementation.
A Transport Services Implementation MUST NOT automatically fall back from secure protocols to insecure protocols, or fall back to weaker versions of secure protocols. The API MAY allow applications to explicitly specify which versions of a protocol are permitted.
A Transport Services Implementation SHOULD only race Protocol Stacks where the transport security protocols within the stacks are identical. It MUST only select Protocol Stacks that meet application requirements per RFC 8922.
A Transport Services System MUST NOT require that a peer on the other side of a connection use the same API or implementation. A Transport Services Implementation can communicate with any existing Endpoint that implements the selected transport protocol(s).
An application SHOULD NOT rely on specific caching behavior of the Transport Services Implementation; instead, it ought to explicitly request any required or preferred Properties via the Transport Services API.
Any functionality common across multiple transport protocols SHOULD be made accessible through a unified set of calls using the Transport Services API. As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by transport protocols defined in RFC 8923.
If an application provides a certificate to only be used as client authentication for outbound TLS and QUIC connections, the Transport Services System MUST NOT use this automatically in other contexts such as server authentication for inbound connections or in non-equivalent security protocol handshakes.
In normal use, a given version of a Transport Services System SHOULD result in consistent protocol and interface selection decisions for the same network conditions, given the same set of Properties, to provide predictable outcomes to applications.
It is RECOMMENDED that default values for Properties be selected to ensure correctness for the widest set of applications; for example, reliability should be enabled by default because both reliability-requiring and non-requiring applications can function when reliability is provided.
It is RECOMMENDED that the Transport Services API offer Properties common to multiple transport protocols, and that those Properties be applicable to a variety of network-layer interfaces and paths. Each Property is expected to have a default value.
Cached state (TLS session state, HTTP cookies, previous racing results) can lead to linkability if reused across different Connection contexts. Applications control whether cached information is used during establishment, enabling trade-offs between efficiency and privacy from on-path observers. Applications with 'incognito mode' features align with using separate Connection Contexts.
A Connection Group is a set of Connections that shares Connection Properties and Cached State. Properties are 'entangled': changing a Connection Property on any Connection in the group changes it for all others, except for Connection Priority. Only Connections within the same Connection Group may be multiplexed together.
A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints. It can represent a connection-oriented protocol (TCP), a fully specified 5-tuple for connectionless protocols (UDP), a pool of transport instances, or a stream of a multistreaming protocol.
A Framer is a data translation layer added to a Connection that defines how to encapsulate/encode outbound Messages and decapsulate/decode inbound data into Messages, enabling Message boundary preservation over byte-stream transports such as TCP.
A Listener object accepts incoming transport protocol connections from Remote Endpoints and generates corresponding Connection objects. It is created from a Preconnection and by default registers with multiple paths, protocols, and Local Endpoints unless constrained by Selection Properties.
A Message object is a unit of data whose bytes are assumed to be ordered. If an application does not care about order between two spans of bytes, those spans are considered independent Messages. Messages are sent as payload of IP packets; one packet can carry one or more Messages or parts of a Message.
A Preconnection object represents a Connection that has not yet been established. It holds the Local Endpoint Identifier, Remote Endpoint Identifier, and Transport Properties. It is fully or partially specified, and is used to Initiate, Listen, or Rendezvous.
Cached State is the state and history the Transport Services Implementation keeps for each set of associated Endpoints previously used. It can include DNS results, TLS session state, previous success and quality of transport protocols over certain paths, and other information used to inform candidate selection.
Candidate Racing encompasses three sub-types: Protocol Option Racing (attempting multiple Protocol Stacks differing in protocol composition or options), Path Racing (attempting stacks across different available paths, each performing separate DNS resolution), and Remote Endpoint Racing (attempting stacks differing by resolved Remote Endpoint Identifier such as a specific IP address).
System Policy is input from an operating system or other global preferences that constrains or influences how an implementation gathers Candidate Paths and Candidate Protocol Stacks and races candidates during Connection establishment. The Transport Services API does not specify an interface for reading or writing System Policy.
Transport Properties are subdivided into three kinds: Selection Properties (influence path and protocol selection, set on Preconnection only), Connection Properties (configure per-connection behavior, settable before and after establishment), and Message Properties (per-message transmission details).
The Transport Services System MUST NOT automatically fall back from secure to insecure protocols or to weaker protocol versions. If an application requests a specific TLS version and it is unavailable, the connection fails rather than silently downgrading. Applications may explicitly specify minimum acceptable versions.
When racing between two different Protocol Stacks, both stacks must use the same security protocols and options. A Transport Services Implementation can race different security protocols only if the application explicitly specifies it considers them equivalent.
A Connection object passes through three lifecycle phases: Preestablishment (configuring Preconnection with Endpoint Identifiers, Properties, Security Parameters), Established (sending/receiving Messages, receiving events such as Connection Ready and Path Properties Changed), and Termination (Close for graceful end or Abort for immediate drop). Establishment is triggered by Initiate, Listen, or Rendezvous actions.