]>

martenseemann@gmail.com

Apple Inc.

vidhi_goel@apple.com

Transport QUIC QUIC ECN QUIC defines a variant of the ACK frame that carries cumulative count for each of the three ECN codepoints (ECT(1), ECT(0) and CE). From this information, the recipient of the ACK frame cannot deduce which ECN marking the individual packets were received with. This document defines an alternative ACK frame that encodes enough information to indicate which ECN mark each individual packet was received with. This information is essential for accurately performing adjustments to congestion window and sending rate of the sender. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Some congestion control algorithms would benefit from not only knowing that some packets were marked with Congestion Experienced (CE) bit, but exactly which ones. In the general case, this is not possible with the standard ACK frame, since it only contains cumulative ECN counts. This information is helpful to congestion control algorithms in following ways:

1. To perform additive increase and multiplicative decrease accurately, it is important to know the exact sequence of CE marked and non-CE marked packets, as the sequence determines how the congestion was experienced at the bottleneck.
2. Some congestion control algorithms (for example L4S congestion controllers, see ) would benefit from knowing exactly which packets were not CE-marked. These algorithms apply an additive increase for non-CE marked packets even if some other packets were CE marked in the same round trip.

This document defines an alternative ACK frame, the ACCURATE_ACK_ECN frame, which encodes the corresponding ECN codepoint alongside the ACK range. This encoding comes at a cost: In the presence of ECN markings, this will lead to ACCURATE_ACK_ECN frames containing more ACK ranges compared to a regular ACK frame. However, this is not expected to significantly inflate the size of ACCURATE_ACK_ECN frames. For example, in the steady state, L4S applies the CE marking to two packets per roundtrip. In the absence of packet loss, two of the ACCURATE_ACK_ECN frames sent during that RTT would contain two ACK ranges instead of one.

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 when, and only when, they appear in all capitals, as shown here.

ACCURATE_ACK_ECN Frame The ACCURATE_ACK_ECN frame looks similar to an ACK frame. It uses a different encoding for ACK ranges (see and ). Except for the two ACK Range fields, all the fields are the same as defined in . All packets within an ACK range MUST have been received with the same ECN code point. If a range of packets with contiguous packet numbers, but different ECN markings is received, this MUST be reported using multiple ACK ranges. Similar to regular ACK frames, ACCURATE_ACK_ECN frames are not ack-eliciting (see ), nor are they congestion-controlled.

First ACK Range

ACK Range Length:

A variable-length integer indicating the number of contiguous packets preceding the Largest Acknowledged that are being acknowledged with the same ECN code point. That is, the smallest packet acknowledged in the range with the same ECN code point is determined by subtracting the First ACK Range Length value from the Largest Acknowledged field.

ECN Marking:

The ECN code point all packets in this range were received with: Non-ECT is encoded as 0, ECT(1) as 1, ECT(0) as 2 and CE as 3. Values larger than or equal to 4 are invalid, and the receiver MUST close the connection with a FRAME_ENCODING_ERROR if it receives an ACK range with an invalid ECN marking value.

ACK Ranges Each ACK Range consists of alternating Gap, ACK Range Length and ECN Marking values in descending packet number order. ACK Ranges can be repeated. The number of ranges is determined by the ACK Range Count field; one of each value is present for each value in the ACK Range Count field. ACK Ranges are structured as shown in .

ACK Ranges

The fields that form each ACK Range are:

Gap:

A variable-length integer indicating the number of contiguous unacknowledged packets preceding the packet number given by the smallest in the preceding ACK Range. Note that this definition differs by one from the Gap definition of the standard QUIC ACK frame in . This is necessary to allow encoding of contiguous ranges of packet numbers that were received with different ECN markings.

ACK Range Length:

A variable-length integer indicating the number of contiguous acknowledged packets preceding the largest packet number, as determined by the preceding Gap.

ECN Marking:

The ECN code point all packets in this range were received with, as defined in .

As described in , given a largest packet number for an ACK range, the smallest value is determined by: To calculate the largest value for a subsequent ACK Range, the formula differs from the standard QUIC ACK frame which can be calculated using: If any computed packet number is negative, an endpoint MUST generate a connection error of type FRAME_ENCODING_ERROR.

Example Consider a scenario where 10 packets (from packet number 1 to 10) were sent with ECT(1) but receiver received a total of 9 packets where packet number 8 was lost and packet number 6 and 9 were CE marked. The ACCURATE_ACK_ECN frame would look like below.

Negotiating Extension Use Endpoints advertise their support of the extension by sending the accurate_ack_ecn (0x2051a5fa8648af) transport parameter () with an empty value. Implementations that understand this transport parameter MUST treat the receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. After negotiating this extension, endpoints MUST report received packets using the ACCURATE_ACK_ECN frame. This only applies to the application data packet number space. Initial and Handshake packets are acknowledged using the regular ACK frame. It is invalid to send regular ACK frames in the application data packet number space after negotiating this extension. Endpoints MUST close the connection using a PROTOCOL_VIOLATION error when they receive an ACK frame in the application data packet number space after this extension was negotiated. When using 0-RTT, both endpoints MUST remember the value of this transport parameter. This allows acknowledging 0-RTT packets using ACCURATE_ACK_ECN frames. If 0-RTT data is accepted by the server, the server MUST NOT disable this extension on the resumed connection.

Security Considerations The sender of an ACCURATE_ACK_ECN frame might be able to burden its peer by encoding a large number of ACK ranges. With the ACK frame defined in it is not possible to split a contiguous sequence of packet numbers into multiple ranges, which becomes possible when using the ACCURATE_ACK_ECN frame. The number of ACK ranges is implicitely by the requirement that each frame fits into a QUIC packet. Receivers SHOULD make sure that they can process an ACCURATE_ACK_ECN frame containing a few hundred ACK ranges efficiently.

IANA Considerations TODO consider IANA

Normative References This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load. The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.