Exchanging Congestion Control Data in QUIC
draft-yuan-quic-congestion-data-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yuan Jinghao , Xiao Lei , Mike Bishop | ||
| Last updated | 2025-10-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yuan-quic-congestion-data-00
QUIC 袁靖昊 (J. Yuan)
Internet-Draft 肖磊 (L. Xiao)
Intended status: Standards Track Bytedance
Expires: 13 April 2026 M. Bishop
Akamai Technologies
10 October 2025
Exchanging Congestion Control Data in QUIC
draft-yuan-quic-congestion-data-00
Abstract
This draft defines a new transport frame which enables consenting
endpoints to share congestion control state about the network
connection for various purposes. It also allows an endpoint's own
congestion control state to be echoed back to it by a peer for
consideration at the beginning of a future connection.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-yuan-quic-congestion-data/.
Discussion of this document takes place on the QUIC Working Group
mailing list (mailto:quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/quic/. Subscribe at
https://www.ietf.org/mailman/listinfo/quic/.
Source for this draft and an issue tracker can be found at
https://github.com/MikeBishop/quic-samsara.
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."
Yuan, et al. Expires 13 April 2026 [Page 1]
Internet-Draft Congestion Data Frame October 2025
This Internet-Draft will expire on 13 April 2026.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Peer Visibility . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4
2. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 4
3. Network Statistics . . . . . . . . . . . . . . . . . . . . . 5
3.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Path Tuple . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Slow Start Status . . . . . . . . . . . . . . . . . . . . 7
3.4. Network Type . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Maximum Congestion Window . . . . . . . . . . . . . . . . 8
3.6. Maximum In-Flight Data . . . . . . . . . . . . . . . . . 8
3.7. Smoothed RTT . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Minimum RTT . . . . . . . . . . . . . . . . . . . . . . . 8
3.9. RTT Variance . . . . . . . . . . . . . . . . . . . . . . 9
3.10. Latest Bandwidth . . . . . . . . . . . . . . . . . . . . 9
3.11. Maximum Bandwidth . . . . . . . . . . . . . . . . . . . . 9
3.12. Throughput . . . . . . . . . . . . . . . . . . . . . . . 9
3.13. Send Rate . . . . . . . . . . . . . . . . . . . . . . . . 9
3.14. Receive Rate . . . . . . . . . . . . . . . . . . . . . . 10
3.15. Input Rate . . . . . . . . . . . . . . . . . . . . . . . 10
3.16. Loss Rate . . . . . . . . . . . . . . . . . . . . . . . . 10
3.17. Buffer Length . . . . . . . . . . . . . . . . . . . . . . 10
4. Frame Types . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. CONGESTION_DATA Frames . . . . . . . . . . . . . . . . . 10
4.1.1. Sending Network Statistics . . . . . . . . . . . . . 11
4.1.2. Integrity Tag . . . . . . . . . . . . . . . . . . . . 12
4.2. CONGESTION_DATA_RECALL Frames . . . . . . . . . . . . . . 13
4.2.1. Recalling Network Statistics . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Yuan, et al. Expires 13 April 2026 [Page 2]
Internet-Draft Congestion Data Frame October 2025
6.1. New QUIC Transport Parameters Entry . . . . . . . . . . . 15
6.2. New QUIC Network Type Registry . . . . . . . . . . . . . 15
6.3. New QUIC Network Statistics Registry . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Sample Integrity Tag implementation . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
All Internet transports are required to either use a congestion
control algorithm, or to constrain their rate of transmission
[RFC8085]. Most congestion control algorithms take time to ramp up
the sending rate, called the "Slow-Start phase." This defines a time
in which a sender intentionally uses less capacity than might be
available so as to avoid or limit overshoot of the available capacity
for the path. This is because any overshoot can have detrimental
effects both for the current flow and for any other flows with which
it shares network bottlenecks.
At the same time, using less capacity than is available necessarily
limits performance early in the connection. Careful Resume
[CAREFUL-RESUME] is a mechanism whereby remembered congestion control
parameters can be validated as potentially applicable to a new
connection, probed, and ultimately used to grow the congestion window
more rapidly than slow-start would otherwise permit.
One optimization approach is to use historical congestion information
to provide the congestion algorithm with reliable input to help it
exit the slow start phase. The most direct and reliable information
can be samples collected during the congestion algorithm, such as the
congestion window size and probe bandwidth.
While clients often connect to a manageable number of servers and can
retain such state, servers typically service orders of magnitude more
clients and cannot feasibly retain such information. Further,
servers are often deployed with many instances and attempting to
coordinate the sharing of this information between them may prove
impractical. Thus, for a server to implement Careful Resume, some
external means of recalling its previous state is useful.
This document specifies a mechanism which allows a QUIC [QUIC]
endpoint to periodically export its congestion control state,
optionally in an integrity-protected manner. This exported state is
sent to the peer in a CONGESTION_DATA frame. When establishing a
subsequent connection, an endpoint with persistent storage can
Yuan, et al. Expires 13 April 2026 [Page 3]
Internet-Draft Congestion Data Frame October 2025
include this data in a CONGESTION_DATA_RECALL frame in its 0-RTT or
1-RTT packets, assisting its peer to recall the information necessary
to perform Careful Resume.
This mechanism is comparable to HTTP cookies, [COOKIES], but for
transport information. This data may also be useful for application-
layer purposes, such as adaptive-bit-rate video. The exported
information is readable by the peer and can be exposed to the
application through local interfaces.
1.1. Peer Visibility
The peer's viewpoint of a connection can be useful for debugging and
as additional information to be considered by on-path entities such
as congestion controllers and application-layer protocols.
Therefore, this extension deliberately does not encrypt the data
reported to the peer. Instead, the data is provided in cleartext
with an optional integrity tag.
If a server wishes to recall information about past connections
without sharing that data with the client, this information can
already be encoded in address validation tokens without requiring the
cooperation of the client; see Section 8.1.3 of [QUIC].
1.2. 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.
This document also uses terminology defined in [QUIC] and [QUIC-TLS],
in particular the frame layout notation from Section 1.3 of [QUIC].
2. Transport Parameter
Desire and willingness to receive the frames defined in this
specification is indicated by means of the following QUIC transport
parameter:
support_congestion_data(i)
The support_congestion_data value is a variable-length integer that
encodes these three one-bit flags:
CONSUME (0x01): This indicates that the sender is interested in
Yuan, et al. Expires 13 April 2026 [Page 4]
Internet-Draft Congestion Data Frame October 2025
receiving CONGESTION_DATA frames for its own uses during the
current connection, independent of the receiver's ability to reuse
the data in the future.
CACHE (0x02): This indicates that the sender is willing to receive
CONGESTION_DATA frames and potentially return the contents in a
CONGESTION_DATA_RECALL frame on a subsequent connection.
CONSIDER (0x04): This indicates that the sender is willing to have
values it may have provided on a previous connection returned to
it in a CONGESTION_DATA_RECALL frame.
All other bits MUST be set to zero when sending and MUST be ignored
on receipt.
The default for this parameter is 0, which indicates that the
endpoint does not support CONGESTION_DATA or CONGESTION_DATA_RECALL
frames. A value other than 0 indicates that the endpoint supports
the indicated frame types and is willing to receive such frames on
this connection.
An endpoint MUST NOT send CONGESTION_DATA or CONGESTION_DATA_RECALL
frames until it has received the support_congestion_data transport
parameter with a non-zero value during the handshake (or during a
previous handshake if 0-RTT is used).
An endpoint MUST NOT send CONGESTION_DATA frames to a peer which did
not set the CONSUME or CACHE flags. An endpoint MUST NOT send
CONGESTION_DATA_RECALL frames to a peer which did not set the
CONSIDER flag. An endpoint that receives a frame for which it has
not indicated support via the transport parameter MUST terminate the
connection with an error of type PROTOCOL_VIOLATION.
3. Network Statistics
Each network statistic is structured as a TLV:
Network Statistic structure {
Type (i),
Length (i),
Value (..),
}
This structure includes the following fields:
Type: Indicates the statistic being offered, encoded as a variable-
length integer.
Yuan, et al. Expires 13 April 2026 [Page 5]
Internet-Draft Congestion Data Frame October 2025
Length: The length of the Value field in bytes, encoded as a
variable-length integer.
Value: A Type-specific value carrying the payload of the indicated
statistic.
This specification defines a number of initial statistics, but
additional statistics can be added by registering a value in the
appropriate registry (see Section 6). An implementation MUST ignore
any statistics it cannot understand, but MAY decline to return
protected statistics to a peer if it cannot verify that it is willing
to share the contained information.
A receiver may get a message with multiple occurrences of a
particular TLV value. If the values are identical, the reciever
SHOULD ignore them. If they differ, and one of the values is
protected by an integrity tag, the receiver SHOULD treat this as an
attack and close the connection. If none of the instances are
integrity-protected, the receiver MAY ignore them, use only one of
the instances, or close the connection as it determines to be most
appropriate.
In the sub-section below, only the names are used; the numeric value
that appears in the protocol is defined in Section 6.3.
3.1. Timestamp
The Timestamp statistic indicates the time at which the sender
generated this frame. This can be used on future connections to
determine whether the recalled statistics are recent enough to be
useful.
*Note* Format of the timestamp is TBD.
3.2. Path Tuple
The Path Tuple statistic encodes an identifier of the path on which
these statistics were generated. Knowing the connection addresses as
seen from the peer's perspective can be useful for a number of
scenarios (e.g., [STUN]). The reciever MAY use this to to compare
similarity of the previous endpoints to those of a new connection
will when deciding if returned statistics might be applicable to a
new connection.
The structure of the value is:
Yuan, et al. Expires 13 April 2026 [Page 6]
Internet-Draft Congestion Data Frame October 2025
Path Endpoint structure {
Type (i) = 0x202,
Length (i) = 12/36,
Local IP (4/16),
Local Port (2),
Remote IP (4/16),
Remote Port (2),
}
*NOTE* I am confused about this structure. Is the Type and Length
from the TLV? If so, should "0x202" be the assigned number "0xca" ?
It contains the following fields:
Local IP: The sender's IP address on the associated transport path,
encoded as either 4 or 16 bytes depending on IP version.
Local Port: The sender's port number on the associate transport
path, encoded as a two-byte integer.
Remote IP: The receiver's IP address as observed by the sender on
the associated transport path, encoded as either 4 or 16 bytes
depending on IP version.
Remote Port: The receiver's port number as observed by the sender on
the associated transport path
The IP version being used can be inferred from the length of the
payload.
3.3. Slow Start Status
The Slow Start Status statistic indicates whether the sender's
congestion controller is in the Slow Start phase. The value is a
single byte, set to 0x00 if the sender is not in Slow Start and 0x01
if the sender is in Slow Start.
3.4. Network Type
The Network Type statistic indicates the sender's understanding of
its network access medium, encoded as a single byte value. Note that
this is purely advisory, since applications will only be aware of the
local network at best.
The defined values are at Section 6.2.
Yuan, et al. Expires 13 April 2026 [Page 7]
Internet-Draft Congestion Data Frame October 2025
3.5. Maximum Congestion Window
The Maximum Congestion Window statistic indicates the maximum
congestion window (CWD) sampled within the observation period,
measured in bytes. It is encoded as a variable-lenth integer. CWD
is a key metric in congestion control algorithms, as it represents
the amount of unacknowledged data that a sender can have in flight on
the network. A larger CWD generally allows for a higher sending
rate.
3.6. Maximum In-Flight Data
The Maximum In-Flight Data statistic indicates the maximum in-flight
data sampled within the observation period, measured in bytes. It is
encoded as a variable-length integer. This represents the highest
number of bytes sent by the sender that have not yet been
acknowledged by the receiver during the measurement period. This
metric provides insight into the actual amount of data in transit at
any given time, which can be useful for diagnosing network
performance issues.
3.7. Smoothed RTT
The Smoothed RTT statistic indicates the most recent smoothed Round-
Trip Time (RTT) within the observation period, measured in
milliseconds. It is encoded as a variable-length integer. It is
calculated as defined in [RFC9002]. RTT is a key metric for
congestion control, estimating the time it takes for a packet to
travel from the sender to the receiver and back. The smoothed RTT
calculation accounts for both the latest RTT and a historical
average, helping to dampen the effect of short-term network
fluctuations.
3.8. Minimum RTT
The Minimum RTT statistic indicates the minimum RTT sampled within
the observation period, measured in milliseconds. It is encoded as a
variable-length integer, This metric provides a baseline for the
best-case network latency observed during the measurement period. A
low minimum RTT can indicate a stable and efficient network path,
while a high one might suggest persistent latency issues.
Yuan, et al. Expires 13 April 2026 [Page 8]
Internet-Draft Congestion Data Frame October 2025
3.9. RTT Variance
The RTT Variance statistic indicates the most recent RTT deviation
within the observation period, measured in milliseconds. It is
encoded as a variable-length integer. It is calculated as defined in
[RFC9002]. This metric quantifies the variability of the RTT,
providing insight into network jitter and stability. A low RTT
variance suggests a consistent network path, while a high value
indicates significant fluctuations in network latency.
3.10. Latest Bandwidth
The Latest Bandwidth statistic indicates the current raw throughput
of the connection, measured in kilobits per second (kbps). It is
encoded as a variable-length integer. This metric represents the
instantaneous sending capacity as perceived by the sender and is a
crucial input for congestion control algorithms.
3.11. Maximum Bandwidth
The Maximum Bandwidth statistic indicates the maximum raw throughput
sampled within the observation period, measured in kbps. It is
encoded as a variable-length integer. This metric provides a view of
the peak network capacity observed during the measurement period,
which can be useful for understanding the best possible performance
on the current network path.
3.12. Throughput
The Throughput statistic indicates the useful throughput for data,
excluding retransmissions, within the observation period, measured in
kbps. It is encoded as a variable-length integer. This metric is a
measure of the effective data rate delivered to the receiver's
application layer. It isolates the useful data rate, providing a
more accurate measure of application-level performance than the raw
sending rate, which includes retransmitted data.
3.13. Send Rate
The Send Rate statistic indicates the sending rate for all data,
including retransmissions, within the observation period, measured in
kbps. It is encoded as a variable-length integer. This metric
provides a measure of the total data rate at which the sender is
transmitting data. It is useful for understanding the sender's total
load on the network.
Yuan, et al. Expires 13 April 2026 [Page 9]
Internet-Draft Congestion Data Frame October 2025
3.14. Receive Rate
The Receive Rate statistic indicates the receiving rate within the
observation period in kbps. It is encoded as a variable-length
integer. This metric measures the total rate at which the receiver
is acknowledging data, including both new data and retransmissions.
It is useful for understanding the receiver's perspective on the data
flow and can be used to compare against the sender's rate to identify
potential bottlenecks.
3.15. Input Rate
The Input Rate statistic indicates the input bitrate from the
application layer within the observation period in kbps. It is
encoded as a variable-length integer. This metric represents the
rate at which data is being provided to the receiving application.
It gives an end-to-end view of the application data flow.
3.16. Loss Rate
The Loss Rate statistic indicates the arithmetic mean of the packet
loss rate samples within the observation period. The value is
expressed as a percentage at 0.1% resolution within a range of 0 to
1000 inclusive. It is encoded as a variable-length integer. This
metric provides a clear measure of the quality of the network path,
as it quantifies the proportion of packets that are sent but not
received. A high loss rate often indicates network congestion or
instability.
3.17. Buffer Length
The Buffer Length statistic indicates the current amount of data
cached by the QUIC connection layer buffer when the observation frame
is generated in bytes. It is encoded as a variable-length integer.
This metric reflects the amount of data the sender is holding in its
buffer before transmission, which can be an important indicator of
the sender's ability to keep up with the application's sending rate
and can also be a sign of network congestion.
4. Frame Types
4.1. CONGESTION_DATA Frames
CONGESTION_DATA frames (type TBD1) provide a list of Network
Statistics values which the sender chooses to share about the state
of the network connection from its viewpoint.
Yuan, et al. Expires 13 April 2026 [Page 10]
Internet-Draft Congestion Data Frame October 2025
CONGESTION_DATA Frame {
Type (i) = TBD1,
Protected Count (i),
Protected Network Statistics (..) ...,
[Integrity Tag (1..)],
Unprotected Count (i),
Unprotected Network Statistics (..) ...,
}
CONGESTION_DATA frames contain the following fields:
Protected Count: A variable-length integer representing the number
of Network Statistics in the Protected Network Statistics field.
Protected Network Statistics: A sequence of Network Statistics
objects whose length is given by the Protected Count.
Integrity Tag: A message integrity check, as described in
Section 4.1.2. This field is absent if Protected Count is zero.
While this document provides some examples, the format of the
check MUST be treated as opaque by the receiver.
Unprotected Count: A variable-length integer representing the number
of Network Statistics in the Unprotected Network Statistics field.
Unprotected Network Statistics: A sequence of Network Statistics
objects whose length is given by Unprotected Count.
CONGESTION_DATA frames are not retransmittable, though a loss event
might trigger the generation of a new CONGESTION_DATA frame; see
Section 4.1.1.
CONGESTION_DATA frames can be sent at any point in the connection
after 0-RTT or 1-RTT keys have been established, though useful data
will likely not be available until at least one round-trip has
occurred. If a CONGESTION_DATA frame is received in an Initial or
Handshake packet, it MUST be treated as a connection error of type
PROTOCOL_VIOLATION.
4.1.1. Sending Network Statistics
If an endpoint wishes to receive CONGESTION_DATA_RECALL frames on
future connections with the peer and the peer has set the CACHE flag,
the endpoint MAY send CONGESTION_DATA frames containing the values it
wishes to recall in future connections in the Protected Network
Statistics field. It MAY send additional CONGESTION_DATA frames when
these values have changed significantly and it wishes to update the
stored values, or when a previous CONGESTION_DATA frame is declared
Yuan, et al. Expires 13 April 2026 [Page 11]
Internet-Draft Congestion Data Frame October 2025
lost.
If the peer has set the CONSUME flag, an endpoint SHOULD send
CONGESTION_DATA frames periodically throughout the connection's
lifetime. However, an implementation SHOULD NOT send additional
CONGESTION_DATA frames if the connection has been idle since the last
such frame was sent.
In addition to any values the endpoint placed in Protected Network
Statistics, the endpoint includes such other values as it is willing
to provide in the Unprotected Network Statistics field.
If an endpoint sends multiple CONGESTION_DATA frames, it is not
required to include the same set of network statistics in each frame.
For example, some statistics are more useful sent at a regular
frequency, while others only need to be sent if they have changed
significantly from the last value known to have been received.
However, as the server does not control which CONGESTION_DATA will be
cached, it SHOULD include the same Protected Network Statistics
fields in each frame.
4.1.2. Integrity Tag
The integrity tag is calculated over the Protected Count and
Protected Network Statistics field by the sender. This field is a
variable-length set of bytes, whose format is known only to the
sender. The purpose of this field is to provide suitable assurance
to the sender that, when the statistics are later sent back to it
through the CONGESTION_DATA_RECALL frame, that they have not been
modified. This is often called a "message authentication code"
(MAC). To emphasize that only a portion of a message is protected,
this document does not use that term.
The algorithm for generating and verifying an integrity tag MAY
depend on the ordering of the Protected fields although some
implementations may perform a simple canonicalization by sorting the
statistics by type identifier. Because of this, receivers SHOULD NOT
modify the content or ordering of any of the Protected statistics in
any way, unless they have out-of-band knowledge that it is safe to do
so.
If the server has a nonce or other private material, it can hash that
with the incoming Protected fields and use that as the outgoing
Integrity tag. This can be either a simple hash of both parts, or
the HMAC keyed hash [RFC2104] can be used.
Yuan, et al. Expires 13 April 2026 [Page 12]
Internet-Draft Congestion Data Frame October 2025
Being able to change algorithms without large-scale protocol
modifications is important. Servers may wish to use a fixed-number
of leading bytes to indicate the algorithm they are using. It is
also a best practice to generate new private data periodically, while
still allowing old messages to be validated. To handle this, it is a
good idea to use a fixed number of secondary bytes to act as a key or
nonce identifier.
A sample implementation is provided in Appendix A.
4.2. CONGESTION_DATA_RECALL Frames
CONGESTION_DATA_RECALL frames (type TBD2) contain a list of Network
Statistics values which the sender received from the recipient during
a previous connection.
This frame SHOULD be sent as early as possible in the connection once
0-RTT or 1-RTT keys are available. While the frame MAY be sent at
any point in the connection, if it arrives after the recipient has
exited slow-start the values it contains will likely not be useful.
CONGESTION_DATA_RECALL Frame {
Type (i) = TBD2,
Protected Count (i),
Protected Network Statistics (..) ...,
Integrity Tag (1..),
}
*NOTE* Do we want to allow unprotected statistics here also, with the
caveat that the receiver may reject them, or even the whole message?
CONGESTION_DATA_RECALL frames contain the following fields:
Protected Count: A variable-length integer representing the number
of Network Statistics in the Protected Network Statistics field,
received in a CONGESTION_DATA frame from the peer on a previous
connection.
Protected Network Statistics: A sequence of Network Statistics
objects whose length is given by Protected Count, received in a
CONGESTION_DATA frame from the peer on a previous connection.
Integrity Tag: The integrity tag, received in a CONGESTION_DATA
frame from the peer on a previous connection. See Section 4.1.2.
If a CONGESTION_DATA_RECALL frame is received in an Initial or
Handshake packet, it MUST be treated as a connection error of type
PROTOCOL_VIOLATION.
Yuan, et al. Expires 13 April 2026 [Page 13]
Internet-Draft Congestion Data Frame October 2025
4.2.1. Recalling Network Statistics
Upon receipt of a CONGESTION_DATA_RECALL frame, an endpoint computes
the expected Integrity Tag value as in Section 4.1.2. If the
Integrity Tag value does not match, the frame is ignored.
If the tag is acceptable, the endpoint takes the network statistics
contained in the frame and incorporates them into its congestion
control strategy. For example, it might exit the Reconnaissance
Phase of Careful Resume [CAREFUL-RESUME]. The specifics of how this
is done are outside the scope of this extension.
Endpoints MUST NOT process more than one CONGESTION_DATA_RECALL frame
on a connection. Subsequent CONGESTION_DATA_RECALL frames MUST be
ignored without processing, regardless of whether the first frame was
valid.
5. Security Considerations
Clients choosing to return network statistics to a server provide a
potential tracking mechanism. However, this tracking mechanism
provides no additional capabilities to a server beyond those already
enabled by the address validation tokens defined in Section 8.1.3 of
[QUIC]. While address validation tokens are opaque and can contain
any data the server might wish to recall, the statistics being
transported by this mechanism are visible to the clients. Clients
can inspect the values to ensure that nothing objectionable is being
saved; implementations MAY choose not to send CONGESTION_DATA_RECALL
packets which contain statistics they cannot interpret.
Clients SHOULD NOT send CONGESTION_DATA_RECALL packets on connections
where they would not have sent an Address Validation token if one
were available. A client MAY also decide not to send the packet if
the length of the integrity tag does not correspond to a digest
length and a few additional bytes. This is admittedly inelegant. and
could be avoided if the format of the tag were publicly defined, and
an IANA registry for tag algorithms defined.
Clients SHOULD discard stored network statistics when other potential
tracking mechanisms (e.g. HTTP Cookies) are cleared by the user.
6. IANA Considerations
IANA is requested to take the following actions, replacing "ThisRFC"
with the RFC number when assigned.
Yuan, et al. Expires 13 April 2026 [Page 14]
Internet-Draft Congestion Data Frame October 2025
6.1. New QUIC Transport Parameters Entry
Add a new entry to the "QUIC Transport Parameters" registry with the
following values:
+===================+=========================+
| Field Name | Value |
+===================+=========================+
| Value | TBD |
+-------------------+-------------------------+
| Parameter Name | support_congestion_data |
+-------------------+-------------------------+
| Status | permanent |
+-------------------+-------------------------+
| Specification | ThisRFC |
+-------------------+-------------------------+
| Date | TBD |
+-------------------+-------------------------+
| Change Controller | IETF |
+-------------------+-------------------------+
| Contact | quic@ietf.org |
+-------------------+-------------------------+
| Notes | None |
+-------------------+-------------------------+
Table 1
6.2. New QUIC Network Type Registry
A new registry "QUIC Network Type" is created with the following
fields:
Value: Numeric value
Meaning: Brief textual description
Reference: A pointer to the defining document
The registration policy for this registry is "Specification Required"
as described in [RFC8126], Section 4.6.
The initial value of the registry is as follows:
Yuan, et al. Expires 13 April 2026 [Page 15]
Internet-Draft Congestion Data Frame October 2025
+=======+===============+===========+
| Value | Meaning | Reference |
+=======+===============+===========+
| 0x00 | Reserved | ThisRFC |
+-------+---------------+-----------+
| 0x01 | Wire/Ethernet | ThisRFC |
+-------+---------------+-----------+
| 0x02 | Reserved | ThisRFC |
+-------+---------------+-----------+
| 0x03 | WLAN | ThisRFC |
+-------+---------------+-----------+
| 0x04 | 2G Mobile | ThisRFC |
+-------+---------------+-----------+
| 0x05 | 3G Mobile | ThisRFC |
+-------+---------------+-----------+
| 0x06 | 4G Mobile | ThisRFC |
+-------+---------------+-----------+
| 0x07 | 5G Mobile | ThisRFC |
+-------+---------------+-----------+
Table 2
6.3. New QUIC Network Statistics Registry
A new "QUIC Network Statistics" registry is created. It follows the
registration policies defined in [RFC9000], Section 22.1. In
addition to the fields described in that section, permanent
registrations MUST include the following fields:
Type: The type of statistic, as described in ThisRFC,
Section Section 3.
Name: A short name for the field.
The initial value of the table is:
Yuan, et al. Expires 13 April 2026 [Page 16]
Internet-Draft Congestion Data Frame October 2025
+======+===========================+
| Type | Name |
+======+===========================+
| 0xc8 | Timestamp |
+------+---------------------------+
| 0xca | Path Tuple |
+------+---------------------------+
| 0xcb | Slow Start Status |
+------+---------------------------+
| 0xcc | Network Type |
+------+---------------------------+
| 0xcd | Maximum Congestion Window |
+------+---------------------------+
| 0xce | Maximum In-Flight Data |
+------+---------------------------+
| 0xcf | Smoothed RTT |
+------+---------------------------+
| 0xd0 | Minimum RTT |
+------+---------------------------+
| 0xd1 | RTT Variance |
+------+---------------------------+
| 0xd2 | Latest Bandwidth |
+------+---------------------------+
| 0xd3 | Maximum Bandwidth |
+------+---------------------------+
| 0xd4 | Throughput |
+------+---------------------------+
| 0xd5 | Send Rate |
+------+---------------------------+
| 0xd6 | Receive Rate |
+------+---------------------------+
| 0xd7 | Input Rate |
+------+---------------------------+
| 0xd8 | Loss Rate |
+------+---------------------------+
| 0xd9 | Buffer Length |
+------+---------------------------+
Table 3
These fields are permanent, and therefore all have the following
values for the common fields:
Yuan, et al. Expires 13 April 2026 [Page 17]
Internet-Draft Congestion Data Frame October 2025
+===================+===============+
| Field Name | Value |
+===================+===============+
| Status | permanent |
+-------------------+---------------+
| Specification | ThisRFC |
+-------------------+---------------+
| Date | TBD |
+-------------------+---------------+
| Change Controller | IETF |
+-------------------+---------------+
| Contact | quic@ietf.org |
+-------------------+---------------+
| Notes | None |
+-------------------+---------------+
Table 4
7. References
7.1. Normative References
[QUIC] 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>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[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>.
Yuan, et al. Expires 13 April 2026 [Page 18]
Internet-Draft Congestion Data Frame October 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>.
[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>.
7.2. Informative References
[CAREFUL-RESUME]
Kuhn, N., Stephan, E., Fairhurst, G., Secchi, R., and C.
Huitema, "Convergence of Congestion Control from Retained
State", Work in Progress, Internet-Draft, draft-ietf-
tsvwg-careful-resume-24, 1 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
careful-resume-24>.
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/rfc/rfc2104>.
[STUN] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/rfc/rfc5389>.
Appendix A. Sample Integrity Tag implementation
This section is not normative.
We define an Integrity Tag format that consists of a one-byte
algorithm identifier, two bytes of private nonce, and a digest.
Based on the choice of algorithm, this is a 32-byte SHA256 digest.
The entire tag is therefore 35 bytes long.
*NOTE* Do we need ASCII art for that layout?
The digest will be computed over the nonce, five bytes of 0x01, and
the wire-format of the protected fields.
Yuan, et al. Expires 13 April 2026 [Page 19]
Internet-Draft Congestion Data Frame October 2025
In this example, we will use our third nonce, which is the ASCII
values of "quic-new-frame":
algid = 1
keyid = 3
nonces[] = [
[ None ], [ None ],
[113, 117, 105, 99, 45, 110, 101, 119, 45, 102, 114, 97, 109, 101]
]
padding = [ 0x01, 0x01, 0x01, 0x01, 0x01 ]
The Network Statistics values are:
*NOTE* TBD; need a sample network statistics
Which have the following wire representation:
*NOTE* Calculate them
The value for the Integrity tag is represented by the following
psuedo-code:
digest = sha56.new()
digest.add(14, nonce[2])
digest.add(5, padding)
digest.add(??, network_statistics)
value = digest.finish()
Acknowledgments
TODO acknowledge.
Authors' Addresses
Junghao Yuan
Bytedance
Email: yuanjinghao@bytedance.com
Additional contact information:
袁靖昊
Bytedance
Lei Xiao
Bytedance
Email: xiaolei.shawn@bytedance.com
Yuan, et al. Expires 13 April 2026 [Page 20]
Internet-Draft Congestion Data Frame October 2025
Additional contact information:
肖磊
Bytedance
Mike Bishop
Akamai Technologies
Email: mbishop@evequefou.be
Yuan, et al. Expires 13 April 2026 [Page 21]