QUIC C. Smith
Internet-Draft NVIDIA
Intended status: Informational I. Swett
Expires: 4 September 2025 Google LLC
J. Beshay
S. Jaiswal
I. Purushothaman
B. Schlinker
Meta Platforms, Inc.
3 March 2025
QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps
draft-smith-quic-receive-ts-01
Abstract
This document defines an extension to the QUIC transport protocol
which supports reporting multiple packet receive timestamps using a
new ACK_EXTENDED frame type which can carry multiple optional fields.
Discussion Venues
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.
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 4 September 2025.
Smith, et al. Expires 4 September 2025 [Page 1]
Internet-Draft QUIC Receive Timestamps March 2025
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
4. Enabling Extensibility in the ACK frame . . . . . . . . . . . 3
5. ACK_EXTENDED Frame . . . . . . . . . . . . . . . . . . . . . 4
5.1. Timestamp Ranges . . . . . . . . . . . . . . . . . . . . 5
6. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6
6.1. Receive Timestamp Basis . . . . . . . . . . . . . . . . . 8
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Best-Effort Behavior . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 using a
new ACK_EXTENDED frame type.
Smith, et al. Expires 4 September 2025 [Page 2]
Internet-Draft QUIC Receive Timestamps March 2025
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 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.
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. Enabling Extensibility in the ACK frame
The QUIC transport protocol defines two different frame types for
acknowledgements Section 19.3 of [RFC9000]. The endpoint sending
acknowledgements decides which type to use depending on whether it
wants to report ECN counts. This approach works well with one set of
optional fields, but grows exponentially with more sets of optional
fields.
This document defines a new set of optional fields to report receive
timestamps. Using a new frame type for each variant of the ACK frame
would require adding 2 new frame types, for a total of 4. Instead,
this document defines one new frame type (ACK_EXTENDED), that can
carry multiple optional sections, reducing the number of new frame
types from 2 to 1, and avoids futre extensions causing an exponential
growth in frame types.
Smith, et al. Expires 4 September 2025 [Page 3]
Internet-Draft QUIC Receive Timestamps March 2025
5. ACK_EXTENDED Frame
Endpoints send ACK_EXTENDED (type=0xB1 temporary value) frames in
place of--and in the same manner as--regular ACK frames as described
in Section 13.2 of [RFC9000]. ACK_EXTENDED frames contain additional
fields to enable reporting two optional sets of fields: - ECN Counts
(from Section 19.3 of [RFC9000]) - Receive Timestamps (defined in
this document)
ACK_EXTENDED frames are formatted as shown in Figure 1.
ACK_EXTENDED Frame {
Type (i) = 0xB1
// Fields of the existing ACK (type=0x02) frame:
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (i),
ACK Range (..) ...,
Extended Ack Features (i),
// Optional ECN counts (if bit 0 is set in Features)
[ECN Counts (..)],
// Optional Receive Timestamps (if bit 1 is set in Features)
[Receive Timestamps (..)]
}
Figure 1: ACK_EXTENDED Frame Format
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].
Extended Ack Features: A variable-length integer whose bit-wise value
indicates which optional fields are included in the ACK. This
document defines two sets of fields corresponding to the two least
significant bits of the value: - Bit 0 indicates whether ECN count
fields are included in the frame - Bit 1 indicates whether Receive
Timestamps are included in the frame
When Extended Ack Features has bit 0 set, the frame will include ECN
Counts as defined in Section 19.3.2 of [RFC9000].
When Extended Ack Feature has bit 1 set, the frame will include the
following additional fields for the receive timestmaps:
Timestamp Range Count: A variable-length integer specifying the
number of Timestamp Range fields in the frame.
Smith, et al. Expires 4 September 2025 [Page 4]
Internet-Draft QUIC Receive Timestamps March 2025
Timestamp Ranges: Ranges of receive timestamps for contiguous
packets in descending packet number order; see Section 5.1.
5.1. Timestamp Ranges
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 Gap 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).
Note that reporting receive timestamps for packets received out of
order is not supported. Specifically: for any packet number P for
which a receive timestamp T is reported, all reports for packet
numbers less than P must have timestamps less than or equal to T; and
all reports for packet numbers greater than P must have timestamps
greater than or equal to T.
Timestamp Ranges are structured as shown in Figure 2.
Timestamp Range {
Gap (i),
Timestamp Delta Count (i),
Timestamp Delta (i) ...,
}
Figure 2: Timestamp Range Format
The fields that form each Timestamp Range are:
Gap: A variable-length integer indicating the largest packet number
in the Timestamp Range as follows:
For the first Timestamp Range: Gap is the difference between (a)
the Largest Acknowledged packet number in the frame and (b) the
largest packet in the current (first) Timestamp Range.
For subsequent Timestamp Ranges: Gap is the difference between (a)
the packet number two lower than the smallest packet number in the
previous Timestamp Range and (b) the largest packet in the current
Timestamp Range.
Timestamp Delta Count: A variable-length integer indicating the
number of Timestamp Deltas in the current Timestamp Range.
Smith, et al. Expires 4 September 2025 [Page 5]
Internet-Draft QUIC Receive Timestamps March 2025
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 6.
Timestamp Deltas: 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 6.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_EXTENDED
frame (see Section 6):
6. Extension Negotiation
The use of the ACK_EXTENDED frame is negotiated using the following
three transport parameters (Section 7.2 of [RFC9000]):
extended_ack_features (0xff0a004 temporary value for draft use): A v
ariable-length integer indicating the sending endpoint would like
to receive ACK_EXTENDED frames with the specified set of features.
The bit-wise value of the integer indicates the features the
endpoint can accept in the ACK_EXTENDED frame. The value of this
paramter is interpreted in the same way as the Extended Ack
Features field in the ACK_EXTENDED frame, i.e., - Bit 0 indicates
whether ECN count fields are included in the frame - Bit 1
indicates whether Receive Timestamps are included in the frame
Smith, et al. Expires 4 September 2025 [Page 6]
Internet-Draft QUIC Receive Timestamps March 2025
Upon receiving this parameter, the receiving peer SHOULD send
ACK_EXTENDED frames with the features supported by the endpoint
which sent the parameter, and set the Extended Ack Features field
accordingly. The receiving peer MAY choose to send ACK_EXTENDED
frames with less features (and set the equivalent Extended Ack
Features field value) if the requested features are not available
or there is no data to send (e.g. if no timing information is
available for receive timestamps). The receiving peer MAY send
regular ACK and ACK_ECN frames, in which case the endpoint MUST
still support processing regular ACK frames as defined by
Section 19.3 of [RFC9000].
ACK_EXTENDED frames written by the peer receiving this parameter
MUST not have bits set in the Extended Ack Features that were not
set by the sending endpoint in the transport parameter. An
endpoint receiving an ACK_EXTENDED frame with features it did not
include in the transport parameter should terminate the connection
with a PROTOCOL_VIOLATION violation error.
The receiving peer SHOULD NOT send ACK_EXTENDED frames with 0
features.
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_EXTENDED frame.
The sending endpoint MUST sent this transport parameter if sends
the extended_ack_features transport parameter with bit 1 set in
its value. A peer that receives this transport parameter but not
an extended_ack_features transport paramter with bit 1 set MUST
ignore this transport parameter.
Each ACK_EXTENDED frame sent MUST NOT contain more than the
specified maximum number of receive timestamps, but MAY contain
fewer or none.
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_EXTENDED
frames sent by the peer (see Section 5.1). If this value is
absent, a default value of 0 is assumed (indicating microsecond
precision). Values above 20 are invalid.
Smith, et al. Expires 4 September 2025 [Page 7]
Internet-Draft QUIC Receive Timestamps March 2025
6.1. Receive Timestamp Basis
Endpoints which send ACK_EXTENDED frames must determine a value,
receive_timestamp_basis, relative to which all receive timestamps for
the session will be reported (see Section 5.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.
TODO: Discuss (here or below) why receive timestamps are reported
relative to the basis, rather than in absolute time to avoid clock
synchronization between endpoints and to make the field more compact.
7. Discussion
7.1. Best-Effort Behavior
Receive timestamps are sent on a best-effort basis and endpoints MUST
gracefully handle scenarios where receive timestamp information for
sent packets is not received. Examples of such scenarios are:
* The packet containing the ACK_EXTENDED frame is lost.
* The sender truncates the number of timestamps sent in order to (a)
avoid sending more than max_receive_timestamps_per_ack
(Section 6); or (b) fit the ACK frame into a packet.
8. Security Considerations
TODO Security
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Smith, et al. Expires 4 September 2025 [Page 8]
Internet-Draft QUIC Receive Timestamps March 2025
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
10.2. Informative References
[I-D.ietf-rmcat-gcc]
Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S.
Mascolo, "A Google Congestion Control Algorithm for Real-
Time Communication", Work in Progress, Internet-Draft,
draft-ietf-rmcat-gcc-02, 8 July 2016,
<https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-
gcc-02>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
[RRBNC] Cottrel, R. V. R. R. B. R. N. J. and L., "pathChirp:
Efficient Available Bandwidth Estimation for Network
Paths", 2003.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Connor Smith
NVIDIA
Email: connorsmith.ietf@gmail.com
Ian Swett
Google LLC
Email: ianswett@google.com
Joseph Beshay
Meta Platforms, Inc.
Email: jbeshay@meta.com
Sharad Jaiswal
Meta Platforms, Inc.
Email: sj77@meta.com
Smith, et al. Expires 4 September 2025 [Page 9]
Internet-Draft QUIC Receive Timestamps March 2025
Ilango Purushothaman
Meta Platforms, Inc.
Email: ipurush@meta.com
Brandon Schlinker
Meta Platforms, Inc.
Email: bschlinker@meta.com
Smith, et al. Expires 4 September 2025 [Page 10]