Summary

  • RFCs 9621–9623 let an application state hard requirements and softer preferences while a Transport Services implementation combines them with system policy, cached history and the candidates available on the current network.
  • A Ready event is an establishment receipt. It does not disclose why one candidate won, prove that every preference was honoured, or establish that the selected path produced the intended application result.

The incident record looked complete. The application had called Initiate; the connection had emitted Ready; requests were flowing. Yet one question could not be answered: why had this host used Wi-Fi with TCP when another host, given the same application request, had used LTE with SCTP?

Nothing in that difference necessarily violates the standards. It exposes what the standards deliberately place below the application.

RFC 9621 defines an architecture in which an application describes the transport service it needs and receives an abstract Connection. The Transport Services implementation may resolve a name into several endpoints, consider several interfaces, construct more than one protocol stack and race the eligible choices. RFC 9622 defines the abstract API. RFC 9623 explains how an implementation can gather, order and race candidates.

The purpose is not to conceal a mistake. It is to stop every application from carrying its own rigid TCP-or-UDP decision tree. New transports and paths can become usable without rewriting the application's whole networking layer. A message-oriented API can preserve application intent while a platform adapts to the network it actually sees.

That division of labour is valuable. It also moves the selection decision into a control surface that an operator must learn to audit.

Five words with different force

RFC 9622 gives most Selection Properties five possible strengths: Require, Prefer, No Preference, Avoid and Prohibit. They are not stylistic shades.

Require keeps only paths and protocols that provide the property; if none can, establishment must fail. Prohibit does the mirror image. Prefer and Avoid influence which candidate is tried first, but the implementation may proceed without satisfying them. The document requires the outcome to respect every Require and Prohibit. It also says outcomes based on preferences can vary between systems and contexts.

That distinction changes how a product promise should be written. “Prefer an unmetered interface” means the service may still use a metered path. “Prohibit metered access” means no candidate using that access should survive, even if it is the only fast route. A preference optimizes continuity; a prohibition defines a boundary. Replacing one with the other is a product and risk decision, not a harmless tuning change.

The RFC also warns against treating an interface label as evidence of another property. Wi-Fi does not inherently mean unmetered, private or cheap. Cellular does not inherently mean expensive or insecure. If cost, privacy or a provisioning domain matters, it needs its own property and evidence.

One request meets three policy owners

The application is not the only source of selection rules. RFC 9623 identifies application preferences, dynamic System Policy and default implementation policy. A current administrative rule might prevent an application from using a metered interface. A platform default might withhold an interface unless the application expressly requests it. Available protocols and paths can change between two otherwise identical calls.

RFC 9621 makes a consequential limit explicit: because System Policy is platform-dependent and does not affect application-level interoperability, the abstract API does not specify a portable interface for reading or writing it. The application can state intent without necessarily receiving a portable account of every rule that shaped the result.

This is where success can become hard to explain. A selected stack must satisfy the applicable constraints. But the Ready event does not carry a policy digest, candidate list or ranking trace. A correct implementation may therefore produce a connection that is compliant yet operationally opaque.

The remedy is not to move every platform policy into a global standard. It is to separate the common contract from the local decision record. The application should be able to depend on hard properties. The operator that controls local policy should preserve enough evidence to explain which eligible choice it made and why.

The candidate tree has an order

Candidate selection is not a flat contest among complete alternatives. RFC 9623 recommends branching first by network path, then by protocol option, then by derived endpoint. That order can decide which combination is ever attempted.

Its example is revealing. An application prefers Wi-Fi and also prefers a feature available through SCTP. If cached information says SCTP is unavailable on Wi-Fi, the Wi-Fi branch can contain TCP while the LTE branch contains SCTP and TCP. Because the path preference is applied first, Wi-Fi/TCP can be attempted before LTE/SCTP. Neither preference is ignored. They are resolved through a tree whose precedence matters.

This is not the same as calculating a single universal score for every tuple. An audit that records only “Wi-Fi preferred” and “SCTP preferred” cannot reconstruct the result. It also needs the tree shape, pruned nodes and ordering rule.

Candidate gathering itself depends on the moment. DNS may return different answers on different interfaces. A proxy can change the endpoint and port. A protocol may be available on one path and absent on another. A configuration can fail before racing if its hard properties conflict or no supported protocol can satisfy them. A valid configuration can later yield NoCandidates, resolution failure, establishment failure or a policy prohibition.

The fastest eligible answer wins a bounded contest

RFC 9623 describes simultaneous, staggered and failover racing. Simultaneous attempts can reduce delay, but they consume network resources and create state that may never be used, so the document advises against making them the default. Staggered racing starts the next branch after a delay and can let attempts overlap. Failover waits for a preferred choice to fail before trying a less preferred one.

The last mode matters when speed is not the highest authority. If policy prefers a proxy, aggressive racing between the proxy and a direct route can turn a small timing difference into a policy bypass. Failover preserves the preference by giving the proxy a meaningful chance before the direct alternative begins.

RFC 8305, Happy Eyeballs v2, supplies a familiar model for staggered address-family choice. TAPS generalizes the problem: a branch can differ not only by address, but also by interface, endpoint derivation and protocol stack. The first success is meaningful only inside the set of candidates that were correctly admitted.

Security makes that boundary non-negotiable. RFC 8922 describes how security requirements fit the transport-services model. RFC 9623 warns that an attacker who knows alternatives are being raced can block the first attempt and induce a secondary one. If the fallback is weaker, the race rewards interference. Alternate stacks must preserve hard security requirements and should normally have equivalent security properties. “It connected” is not a defence against a downgrade that the candidate set should never have permitted.

Yesterday's success can choose today's route

The selector can remember. RFC 9623 discusses protocol state such as DNS answers, TLS session tickets and TCP Fast Open cookies, along with performance observations such as round-trip time, establishment latency and success rate. That history can change which candidates are generated, ranked or pruned on the next connection.

RFC 9040 provides the wider TCP background for sharing control-block information. Reuse can save time and avoid repeating work. It can also preserve an obsolete belief. A path that was fast yesterday may now be congested; an endpoint that once failed may now be healthy. The standards do not promise that the same properties produce the same winner each time.

Cache boundaries carry a privacy consequence too. RFC 9621 permits separate Connection Contexts so applications can isolate state and avoid linkability through reused tickets or multiplexed connections. The optimization record is therefore not just performance data. It can disclose that two activities share a history.

A useful receipt should record the cache namespace and the age and expiry basis of the observations that materially affected ranking. It should not expose session secrets, raw tickets or user identifiers. Auditability and data minimization are compatible if the record names the decision input without copying the sensitive state itself.

What Ready actually closes

RFC 9623 says establishment is complete once at least one Protocol Stack has reached the point where it can transmit and receive application data. RFC 9622 exposes that state transition as Ready for an initiated connection.

That closes an important question: did the local Transport Services system establish an eligible stack? It does not answer several later questions. It does not say that a particular soft preference won. It does not reveal the alternatives. It does not prove that the remote application processed a message, that a deadline was met, that a paid interface was avoided or that a user received the intended result.

This boundary is different from the Sent event. Ready belongs to establishment; Sent belongs to local message disposition. Neither event should borrow authority from remote processing or business outcome.

RFC 9623 lists Apple's Network framework, NEAT, NEATPy and PyTAPS as implementations that were, to some degree, aligned with the guidance when the RFC was written. Apple's Network documentation shows the practical attraction of a connection API that combines protocol options and path constraints. The list is evidence that the architecture has running relatives, not a certification that every system exposes the same policy, properties or trace.

Sources