---
title: The QUIC Latency Spin Bit
abbrev: QUIC Spin Bit
docname: draft-ietf-quic-spin-exp-latest
date: {DATE}
category: exp
ipr: trust200902
workgroup: QUIC
keyword: Internet-Draft
stand_alone: yes
pi: [toc, sortrefs, symrefs]
author:
-
ins: B. Trammell
role: editor
name: Brian Trammell
org: ETH Zurich
email: ietf@trammell.ch
-
ins: M. Kuehlewind
name: Mirja Kuehlewind
org: ETH Zurich
email: mirja.kuehlewind@tik.ee.ethz.ch
normative:
QUIC-TRANSPORT:
title: "QUIC: A UDP-Based Multiplexed and Secure Transport"
date: {DATE}
seriesinfo:
Internet-Draft: draft-ietf-quic-transport-latest
author:
-
ins: J. Iyengar
name: Jana Iyengar
org: Fastly
role: editor
-
ins: M. Thomson
name: Martin Thomson
org: Mozilla
role: editor
informative:
CACM-TCP:
title: Passively Measuring TCP Round-Trip Times (in Communications of the ACM)
author:
-
ins: S. Strowes
date: 2013-10
TMA-QOF:
title: Inline Data Integrity Signals for Passive Measurement (in Proc. TMA 2014)
author:
-
ins: B. Trammell
-
ins: D. Gugelmann
-
ins: N. Brownlee
date: 2014-04
PAM-RTT:
title: Revisiting the Privacy Implications of Two-Way Internet Latency Data (in Proc. PAM 2018)
author:
-
ins: B. Trammell
-
ins: M. Kuehlewind
date: 2018-03
--- abstract
This document specifies the addition of a latency spin bit to the QUIC
transport protocol and describes how to use it to measure end-to-end latency.
--- note_Note_to_Readers
This document specifies an experimental delta to the QUIC transport protocol.
Specifically, this experimentation is intended to determine:
- the impact of the addition of the latency spin bit on implementation and
specification complexity; and
- the accuracy and value of the information derived from spin bit measurement
on live network traffic.
The information generated by this experiment will be used by the QUIC working
group as input to a decision about the standardization of the latency spin
bit. Although this is a Working Group document, it is currently NOT a Working
Group deliverable.
Discussion of this draft takes place on the QUIC working group mailing list
(quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Working Group information can be found at <https://github.com/quicwg>; source
code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-spin>.
--- middle
# Introduction
The QUIC transport protocol {{QUIC-TRANSPORT}} uses
Transport Layer Security (TLS) {{?TLS=I-D.ietf-tls-tls13}} 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 {{?WIRE-IMAGE=I-D.trammell-wire-image}}) currently does
not expose any information that can be used for passive latency measurement
techniques that rely on this information (e.g. {{CACM-TCP}}, {{TMA-QOF}}).
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 Spin Bit Mechanism
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.
## Proposed Short Header Format Including Spin Bit
As of the current editor's version of {{QUIC-TRANSPORT}}, this proposal
specifies using the sixth most significant bit (0x04) of the first octet in
the short header for the spin bit.
~~~~~
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|K|1|1|0|S|R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~~~
{: #fig-short-header title="Short Header Format including proposed Spin Bit"}
S: The Spin bit is set 0 or 1 depending on the stored spin value that is
updated on packet reception as explained in {{spinbit}}.
R: Two additional bits are reserved for experimentation in the short header.
## Setting the Spin Bit on Outgoing Packets {#spinbit}
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 {{usage}}.
See {{?QUIC-SPIN=I-D.trammell-quic-spin}} for further illustration of this
mechanism in action.
## Resetting Spin Value State
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.
# Using the Spin Bit for Passive RTT Measurement {#usage}
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.
An observer can store the largest observed packet number per flow, and reject
edges that do not have a monotonically increasing packet number (greater than
the largest observed packet number). This will avoid detecting spurious edges
caused by reordering events that include an edge, which would lead to very low
RTT estimates if not ignored.
If the spin bit edge occurs after a long packet number gap, it should be
ignored: this filters out high RTT estimates due to loss of an actual edge in
a burst of lost packets.
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 application or flow
control limitation; for example, QoF {{TMA-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.
# IANA Considerations
This document has no actions for IANA.
# Security and Privacy Considerations
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
{{PAM-RTT}} 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 therefore negligible.
# Change Log
> **RFC Editor's Note:** Please remove this section prior to
> publication of a final version of this document.
## Since draft-ietf-spin-exp-00
Nothing yet.
# Acknowledgments
{:numbered="false"}
This document is derived from {{QUIC-SPIN}}, 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.