| Internet-Draft | QUIC Receive Timestamps | April 2025 |
| Smith, et al. | Expires 24 October 2025 | [Page] |
This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps for post-handshake packets.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/.¶
Source for this draft and an issue tracker can be found at https://github.com/wcsmith/draft-quic-receive-ts.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 October 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The QUIC Transport Protocol [RFC9000] provides a secure, multiplexed connection for transmitting reliable streams of application data.¶
This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps.¶
QUIC congestion control ([RFC9002]) supports sampling round-trip time (RTT) by measuring the time from when a packet was sent to when it is acknowledged. However, more precise delay signals measured via packet receive timestamps have the potential to improve the accuracy of network bandwidth measurements and the effectiveness of congestion control, especially for latency-critical applications such as real-time video conferencing or game streaming.¶
Numerous existing algorithms and techniques leverage receive receive timestamps to improve transport performance. Examples include:¶
The WebRTC congestion control algorithm described in [I-D.ietf-rmcat-gcc] uses the difference between packet inter-departure and packet inter-arrival times as the input to its delay-based controller.¶
The pathChirp ([RRBNC]) technique estimates available bandwidth by measuring inter-arrival time of multiple packets.¶
Notably, these techniques require receive timestamps for more than one packet per round-trip in order to best measure the network.¶
Additionally, receive timestamps can provide valuable network telemetry, even if they are not used by the congestion controller.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Endpoints send ACK frames in 1-RTT packets as they otherwise would, with 0 or more receive timestamps following the Ack Ranges and optional ECN Counts. Receive timestamps MUST NOT be sent in Initial or Handshake packets, because the peer would not know to use the extended wire format. ACK frames are never sent in 0-RTT packets, so there is no change to 0-RTT.¶
Once negotiated, the ACK format is identical to RFC9000, but with an additional section for receive timestamps at the end:¶
ACK Frame {
Type (i) = 0x02..0x03,
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (i),
ACK Range (..) ...,
[ECN Counts (..)],
// Timestamp Extension, see {{ts-ranges}}
Receive Timestamps (..)
}
The fields Largest Acknowledged, ACK Delay, ACK Range Count, First ACK Range, and ACK Range are the same as for ACK (type=0x02) frames specified in Section 19.3 of [RFC9000].¶
A variable-length integer specifying the number of Timestamp Range fields in the frame.¶
Ranges of receive timestamps for contiguous packets in descending packet number order; see Section 4.1.¶
Each Timestamp Range describes a series of contiguous packet receive timestamps in descending sequential packet number (and descending timestamp) order. Timestamp Ranges consist of a Delta Largest Acknowledged indicating the largest packet number in the range, followed by a list of Timestamp Deltas describing the relative receive timestamps for each contiguous packet in the Timestamp Range (descending). Packets within a range are in descending packet number and timestamp order. Ranges are in descending timestamp order but do not have to be in descending packet number order.¶
Timestamp Ranges are structured as shown in Figure 2.¶
Timestamp Range {
Delta Largest Acknowledged (i),
Timestamp Delta Count (i),
Timestamp Delta (i) ...,
}
The fields that form each Timestamp Range are:¶
A variable-length integer indicating the largest packet number in the Timestamp Range as a delta to subtract from the Largest Acknowledged in the ACK frame. For example, 0 indicates the range starts with the Largest Acknowledged.¶
A variable-length integer indicating the number of Timestamp Deltas in the current Timestamp Range.¶
The sum of Timestamp Delta Counts for all Timestamp Ranges in the frame MUST NOT exceed max_receive_timestamps_per_ack as specified in Section 5.¶
Variable-length integers encoding the receive timestamp for contiguous packets in the Timestamp Range in descending packet number order as follows:¶
For the first Timestamp Delta of the first Timestamp Range in the frame: the value is the difference between (a) the receive timestamp of the largest packet in the Timestamp Range (indicated by Gap) and (b) the session receive_timestamp_basis (see Section 5.1), decoded as described below.¶
For all other Timestamp Deltas: the value is the difference between (a) the receive timestamp specified by the previous Timestamp Delta and (b) the receive timestamp of the current packet in the Timestamp Range, decoded as described below.¶
All Timestamp Delta values are decoded by mulitplying the value in the field by 2 to the power of the receive_timestamps_exponent transport parameter received by the sender of the ACK frame (see Section 5):¶
A variable-length integer indicating that the maximum number of receive timestamps the sending endpoint would like to receive in an ACK frame.¶
Each ACK frame sent MUST NOT contain more than the peer's maximum number of receive timestamps.¶
A variable-length integer indicating the exponent to be used when encoding and decoding timestamp delta fields in ACK frames sent by the peer (see Section 4.1). If this value is absent, a default value of 0 is assumed (indicating microsecond precision). Values above 20 are invalid.¶
Endpoints which negotiate the extension need to determine a value, receive_timestamp_basis, relative to which all receive timestamps for the session will be reported (see Section 4.1).¶
The value of receive_timestamp_basis MUST be less than the smallest receive timestamp reported, and MUST remain constant for the entire duration of the session. The receive_timestamp_basis is a local value that is not communicated to the peer.¶
Receive timestamps are reported relative to the basis, rather than in absolute time to avoid requiring clock synchronization between endpoints and to make the frame more compact.¶
Receive timestamps are sent on a best-effort basis. Endpoints MUST gracefully handle scenarios where the receiver does not communicate receive timestamps for acknowledged packets. Examples of such scenarios are:¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶