QUIC Extension 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 28 April 2022.¶

Copyright Notice

Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified 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 using a new ACK_RECEIVE_TIMESTAMPS frame type.¶

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. Extension Negotiation

The use of the ACK_RECEIVE_TIMESTAMPS frame is negotiated using the following two transport parameters (Section 7.2 of [RFC9000]):¶

max_receive_timestamps_per_ack (TBD):

A variable-length integer indicating that the sending endpoint would like to receive ACK_RECEIVE_TIMESTAMPS frames from the peer containing no more than the given maximum number of receive timestamps.¶

Upon receiving this parameter with a non-zero value, the peer SHOULD send ACK_RECEIVE_TIMESTAMPS frames instead of ACK frames if new receive timestamp information is available. The peer MAY still send regular ACK frames (e.g. if no timing information is available), in which case the endpoint MUST still support processing regular ACK frames as defined by Section 19.3 of [RFC9000].¶

Each ACK_RECEIVE_TIMESTAMPS frame sent MUST NOT contain more than the specified maximum number of receive timestamps, but MAY contain fewer or none.¶

receive_timestamps_exponent (TBD):

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

5. ACK_RECEIVE_TIMESTAMPS Frame

Receivers send ACK_RECEIVE_TIMESTAMPS (type=TBD) frames in place of--and in the same manner as--regular ACK frames as described in Section 13.2 of [RFC9000]. However, ACK_RECEIVE_TIMESTAMPS frames contain additional fields to report packet receive timestamps.¶

ACK_RECEIVE_TIMESTAMPS frames are formatted as shown in Figure 1.¶

ACK_RECEIVE_TIMESTAMPS Frame {
  Type (i) = TBD
  // Fields of the existing ACK (type=0x02) frame:
  Largest Acknowledged (i),
  ACK Delay (i),
  ACK Range Count (i),
  First ACK Range (i),
  ACK Range (..) ...,
  // Additional fields for ACK_RECEIVE_TIMESTAMPS:
  Timestamp Range Count (i),
  Timestamp Ranges (..) ...,
}

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

ACK_RECEIVE_TIMESTAMPS frames contain the following additional fields:¶

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

Timestamp Range {
  Gap (i),
  Timestamp Delta Count (i),
  Timestamp Delta (i) ...,
}

6. Discussion

7. Security Considerations

TODO Security¶

8. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses