The QUIC Latency Spin Bit

The QUIC transport protocol uses Transport Layer Security (TLS) to encrypt most of its protocol internals. In contrast to TCP where the sequence and acknowledgement numbers and timestamps (if the respective option is in use) can be seen by on-path observers and used to estimate end-to-end latency, QUIC’s wire image (see ) currently does not expose any information that can be used for passive latency measurement techniques that rely on this information (e.g. , ). This document adds an explicit signal for passive latency measurability to the QUIC short header: a “spin bit”. Passive observation of the spin bit provides one RTT sample per RTT to passive observers of QUIC traffic. This document describes the mechanism, how it can be added to QUIC, and how it can be used by passive measurement facilities to generate RTT samples.

The latency spin bit enables latency monitoring from observation points on the network path throughout the duration of a connection. Since it is possible to measure handshake RTT without a spin bit, it is sufficient to include the spin bit in the short packet header. The spin bit therefore appears only after version negotiation and connection establishment are completed.

specifies using the third most significant bit of the first byte in the short header for the spin bit (0x20, labeled S in ). The Spin bit is set 0 or 1 depending on the stored spin value that is updated on packet reception as explained in .

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |0|1|S|R|R|K|P P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Connection ID (0..144) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (8/16/24/32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Each endpoint, client and server, maintains a spin value, 0 or 1, for each QUIC connection, and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent out. The spin value is initialized to 0 at each endpoint, client and server, at connection start. Each endpoint also remembers the highest packet number seen from its peer on the connection. The spin value is then determined at each endpoint within a single connection as follows: When the server receives a packet from the client, if that packet has a short header and if it increments the highest packet number seen by the server from the client, the server sets the spin value to the value observed in the spin bit in the received packet. When the client receives a packet from the server, if the packet has a short header and if it increments the highest packet number seen by the client from the server, it sets the spin value to the opposite of the spin bit in the received packet. This procedure will cause the spin bit to change value in each direction once per round trip. Observation points can estimate the network latency by observing these changes in the latency spin bit, as described in . See for further illustration of this mechanism in action.

Each client and server resets it spin value to zero when sending the first packet of a given connection with a new connection ID. This reduces the risk that transient spin bit state can be used to link flows across connection migration or ID change.

When a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT). An on-path observer can observe the time difference between edges (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single direction to measure one sample of end-to-end RTT. Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete). It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. However, application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are much greater than network RTT. When the sender is application-limited and e.g. only sends small amount of periodic application traffic, where that period is longer than the RTT, measuring the spin bit provides information about the application period, not the network RTT. Simple heuristics based on the observed data rate per flow or changes in the RTT series can be used to reject bad RTT samples due to lost or reordered edges in the spin signal, as well as application or flow control limitation; for example, QoF rejects component RTTs significantly higher than RTTs over the history of the flow. These heuristics may use the handshake RTT as an initial RTT estimate for a given flow. An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit to measure “upstream” and “downstream” component RTT; i.e, the component of the end-to-end RTT attributable to the paths between the observer and the server and the observer and the client, respectively. It does this by measuring the delay between a spin edge observed in the upstream direction and that observed in the downstream direction, and vice versa.

Implementations SHOULD allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis. Even when the spin bit is not disabled by the administrator implementations SHOULD disable the spin bit on a randomly chosen fraction of connections. The selection process SHOULD be designed such that on average the spin bit is disabled for at least one eighth of network paths. The selection process SHOULD be externally unpredictable but consistent for any given combination of source and destination address/port. For instance, the implementation might have a static key which it uses to key a pseudorandom function over these values and use the output to determine whether to send the spin bit. The selection process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. Note that where multiple connections use the same path, the use of the spin bit MAY be coordinated by endpoints, recognizing that this might not be possible in many cases. When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST accept any incoming value. It is RECOMMENDED that they set the spin bit to a random value either chosen independently for each packet, or chosen independently for each path and kept constant for that path.

This document has no actions for IANA.

The spin bit is intended to expose end-to-end RTT to observers along the path, so the privacy considerations for the latency spin bit are essentially the same as those for passive RTT measurement in general. It has been shown that RTT measurements do not provide more information for geolocation than is available in the most basic, freely-available IP address based location databases. The risk of exposure of per-flow network RTT to on-path devices is in most cases negligible. There is however an exception, when parts of the path from client to server are hidden from observers. An example would be a server accessed through a proxy. The spin bit allows for measurement of the end-to-end RTT, and will thus enable adversaries near the endpoint to discover that the connection does not terminate at the visible destination address. Endpoints that want to hide their use of a proxy or a relay will want to disable the spin bit. However, if only privacy-sensitive clients or servers ever disabled the spin bit, they would stick out. The probabilistic disabling behavior explained in ensures that other endpoints will also disable the spin bit some of the time, thus hiding the privacy sensitive endpoints in a large anonymity set. It also provides for a minimal greasing of the spin bit, in order to mitigate risks of ossification.

RFC Editor’s Note: Please remove this section prior to publication of a final version of this document.

Adding section on disabling the spin bit and privacy considerations.

This document is derived from , which was the work of the following authors in addition to the editor of this document: Piet De Vaere, ETH Zurich Roni Even, Huawei Giuseppe Fioccola, Telecom Italia Thomas Fossati, Nokia Marcus Ihlar, Ericsson Al Morton, AT&T Labs Emile Stephan, Orange The QUIC Spin Bit was originally specified in a slightly different form by Christian Huitema. This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement.