QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps

Status of This Memo

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 3 September 2026.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

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.¶

2. Motivation

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 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.¶

3. Conventions and Definitions

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.¶

4. New ACK_RECEIVE_TIMESTAMPS Frame Wire Format

Once the receive timestamps extension is negotiated (see Section 6), an endpoint MAY use the ACK_RECEIVE_TIMESTAMPS frame defined below to report receive timestamps to its peer. An endpoint MAY continue to use the existing ACK frames as specified in Section 19.3 of [RFC9000] if it does not have any receive timestamps or does not want to report them.¶

Endpoints send ACK_RECEIVE_TIMESTAMPS frames in 1-RTT packets, with 0 or more receive timestamps following the Ack Ranges and optional ECN Counts. Similar to to the ACK frame types (x02..0x03), the ACK_RECEIVE_TIMESTAMPS frame defines two frame types (0x38..0x39) to indicate whether the frame includes ECN counts. ACK frames are never sent in 0-RTT packets, so the same applies to ACK_RECEIVE_TIMESTAMPS frames.¶

ACK_RECEIVE_TIMESTAMPS Frame {
  Type (i) = 0x38..0x39,
  Largest Acknowledged (i),
  ACK Delay (i),
  ACK Range Count (i),
  First ACK Range (i),
  ACK Range (..) ...,
  [ECN Counts (..)],       // included iff Type == 0x39
  Receive Timestamps (..)  // see {{ts-ranges}}
}

The fields Largest Acknowledged, ACK Delay, ACK Range Count, First ACK Range, ACK Range and ECN Counts are the same as for ACK (type=0x02..0x03) frames specified in Section 19.3 of [RFC9000].¶

The format of the Receive Timestamps field is shown in Figure 2.¶

Receive Timestamps {
  Timestamp Range Count (i),
  Timestamp Range (..) ...
}

Timestamp Range Count:

A variable-length integer specifying the number of Timestamp Range fields in the frame.¶

Timestamp Ranges:

Ranges of receive timestamps for contiguous packets in descending packet number order; see Section 4.1.¶

Timestamp Range {
  Delta Largest Acknowledged (i),
  Timestamp Delta Count (i),
  Timestamp Delta (i) ...,
}

5. PATH_ACK_RECEIVE_TIMESTAMPS Frame Wire Format

When both the receive timestamps extension and the multipath extension [MULTIPATH] are negotiated, an endpoint MAY use the PATH_ACK_RECEIVE_TIMESTAMPS frame defined below to report receive timestamps for packets received on a specific path. An endpoint MAY continue to use the existing PATH_ACK frames as specified in Section 4.1 of [MULTIPATH] if it does not have any receive timestamps or does not want to report them.¶

Endpoints send PATH_ACK_RECEIVE_TIMESTAMPS frames in 1-RTT packets, with 0 or more receive timestamps following the Ack Ranges and optional ECN Counts. Similar to the PATH_ACK frame types (0x3e..0x3f), the PATH_ACK_RECEIVE_TIMESTAMPS frame defines two frame types (0x3a..0x3b) to indicate whether the frame includes ECN counts.¶

PATH_ACK_RECEIVE_TIMESTAMPS Frame {
  Type (i) = 0x3a..0x3b,
  Path Identifier (i),
  Largest Acknowledged (i),
  ACK Delay (i),
  ACK Range Count (i),
  First ACK Range (i),
  ACK Range (..) ...,
  [ECN Counts (..)],       // included iff Type == 0x3b
  Receive Timestamps (..)  // see {{ts-ranges}}
}

Compared to the ACK_RECEIVE_TIMESTAMPS frame defined in Section 4, the following field is added:¶

Path Identifier:

The path ID associated with the packet number space of the 1-RTT packets which are acknowledged by this frame, as specified in Section 4.1 of [MULTIPATH].¶

All other fields are the same as for the ACK_RECEIVE_TIMESTAMPS frame (Section 4). The Receive Timestamps field follows the same format described in Section 4.1.¶

When truncation is necessary to fit within the max_receive_timestamps_per_ack limit or reduce the size of the frame, the receiver SHOULD retain timestamps for the most recently received packets and omit timestamps for older packets.¶

6. Extension Negotiation

max_receive_timestamps_per_ack (0xff0a002 temporary value for draft use):

A variable-length integer indicating that the maximum number of receive timestamps the sending endpoint would like to receive in an ACK_RECEIVE_TIMESTAMPS or PATH_ACK_RECEIVE_TIMESTAMPS frame.¶

Each ACK_RECEIVE_TIMESTAMPS or PATH_ACK_RECEIVE_TIMESTAMPS frame sent MUST NOT contain more than the peer's maximum number of receive timestamps.¶

receive_timestamps_exponent (0xff0a003 temporary value for draft use):

A variable-length integer indicating the exponent to be used when encoding and decoding timestamp delta fields in ACK_RECEIVE_TIMESTAMPS and PATH_ACK_RECEIVE_TIMESTAMPS 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.¶

7. Discussion

8. Examples

To illustrate the usage of the Receive Timestamps fields, consider a peer that sent 14 packets with numbers 87 to 100.¶

Assume the receiver receives packets 87 to 91 and 96 to 100 at the following timestamps relative to the basis:¶

When it's time to acknowledge these packets, the receiver will send an ACK frame with two ranges, as follows:¶

Largest Acknowledged: 100
...
Timestamp Ranges Count: 2

Timestamp Range 1:
  Delta Largest Acknowledged: 0 // Starting at packet 100
  Timestamp Delta Count: 5
  Timestamps Deltas: 380, 10, 10, 5, 5

Timestamp Range 2:
  Delta Largest Acknowledged: 9 // Starting at packet 91
  Timestamp Delta Count: 5
  Timestamp Deltas: 20, 10, 10, 5, 5

After that assume that the receiver receives packets 92 to 95 out-of-order at the following timestamps relative to the basis:¶

The receiver can send a new ACK frame with all of the timestamps, as follows:¶

Largest Acknowledged: 100
...
Timestamp Ranges Count: 3

Timestamp Range 1:
  Delta Largest Acknowledged: 5 // Starting at packet 95
  Timestamp Delta Count: 4
  Timestamps Deltas: 395, 1, 2, 2

Timestamp Range 2:
  Delta Largest Acknowledged: 0 // Starting at packet 100
  Timestamp Delta Count: 5
  Timestamps Deltas: 10, 10, 10, 5, 5

Timestamp Range 3:
  Delta Largest Acknowledged: 9 // Starting at packet 91
  Timestamp Delta Count: 5
  Timestamp Deltas: 20, 10, 10, 5, 5

In this particular scenario, the receiver can also choose to report the first timestamp range only since the timestamps for the other two ranges have already been reported.¶

9. Security Considerations

TODO Security¶

10. IANA Considerations

This document has no IANA actions.¶

11. References

Acknowledgments

The editors would like to thank Connor Smith for writing the initial draft. The editors would also like to thank Sharad Jaiswal, Ilango Purushothaman, and Brandon Schlinker for their contributions to the design of this QUIC extension.¶

Authors' Addresses