Internet DRAFT - draft-seemann-quic-accurate-ack-ecn
draft-seemann-quic-accurate-ack-ecn
QUIC M. Seemann
Internet-Draft Protocol Labs
Intended status: Standards Track 18 November 2023
Expires: 21 May 2024
QUIC Accurate ECN Acknowledgements
draft-seemann-quic-accurate-ack-ecn-00
Abstract
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.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://marten-
seemann.github.io/draft-seemann-quic-accurate-ack-ecn/draft-seemann-
quic-accurate-ack-ecn.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-seemann-quic-
accurate-ack-ecn/.
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/marten-seemann/draft-seemann-quic-accurate-ack-
ecn.
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/.
Seemann Expires 21 May 2024 [Page 1]
Internet-Draft QUIC Accurate ECN Acknowledgements November 2023
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 21 May 2024.
Copyright Notice
Copyright (c) 2023 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. ACCURATE_ACK_ECN Frame . . . . . . . . . . . . . . . . . . . 3
3.1. First ACK Range . . . . . . . . . . . . . . . . . . . . . 3
3.2. ACK Ranges . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Negotiating Extension Use . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. 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 [RFC9000] ACK frame, since it only
contains cumulative ECN counts.
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
Seemann Expires 21 May 2024 [Page 2]
Internet-Draft QUIC Accurate ECN Acknowledgements November 2023
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 [RFC9331] 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.
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.
3. ACCURATE_ACK_ECN Frame
The ACCURATE_ACK_ECN frame looks similar to an [RFC9000] ACK frame.
It uses a different encoding for ACK ranges (see Section 3.1 and
Section 3.2).
ACCURATE_ACK_ECN Frame {
Type (i) = 0x2051a5fa,
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (..),
ACK Range (..) ...,
}
Except for the two ACK Range fields, all the fields are the same as
defined in Section 19.3 of [RFC9000].
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 Section 13.2 of [RFC9000]), nor are they congestion-
controlled.
3.1. First ACK Range
First ACK Range {
ACK Range Length (i),
ECN Marking (8),
}
Seemann Expires 21 May 2024 [Page 3]
Internet-Draft QUIC Accurate ECN Acknowledgements November 2023
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.
3.2. 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 Figure 1.
ACK Range {
Gap (i),
ACK Range Length (i),
ECN Marking (8),
}
Figure 1: 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 Section 19.3.1 of [RFC9000]. 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 Section 3.1.
Seemann Expires 21 May 2024 [Page 4]
Internet-Draft QUIC Accurate ECN Acknowledgements November 2023
As described in Section 19.3.1 of [RFC9000], given a largest packet
number for an ACK range, the smallest value is determined by:
smallest = largest - ack_range
To calculate the largest value for a subsequent ACK Range, the
formula differs from the standard QUIC ACK frame which can be
calculated using:
largest = previous_smallest - gap - 1
If any computed packet number is negative, an endpoint MUST generate
a connection error of type FRAME_ENCODING_ERROR.
3.3. 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.
Seemann Expires 21 May 2024 [Page 5]
Internet-Draft QUIC Accurate ECN Acknowledgements November 2023
ACCURATE_ACK_ECN Frame {
Type (i) = 0x2051a5fa,
Largest Acknowledged (10),
ACK Delay (i),
ACK Range Count (4),
First ACK Range {
ACK Range Length (0),
ECN Marking (1),
},
ACK Range {
Gap (0),
ACK Range Length (0),
ECN Marking (3),
}
ACK Range {
Gap (1),
ACK Range Length (0),
ECN Marking (1),
}
ACK Range {
Gap (0),
ACK Range Length (0),
ECN Marking (3),
}
ACK Range {
Gap (0),
ACK Range Length (4),
ECN Marking (1),
}
}
4. Negotiating Extension Use
Endpoints advertise their support of the extension by sending the
accurate_ack_ecn (0x2051a5fa8648af) transport parameter (Section 7.4
of [RFC9000]) 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.
Seemann Expires 21 May 2024 [Page 6]
Internet-Draft QUIC Accurate ECN Acknowledgements November 2023
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.
5. 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 [RFC9000] 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.
6. IANA Considerations
TODO consider IANA
7. 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>.
[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>.
[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/rfc/rfc9331>.
Seemann Expires 21 May 2024 [Page 7]
Internet-Draft QUIC Accurate ECN Acknowledgements November 2023
Acknowledgments
TODO acknowledge.
Author's Address
Marten Seemann
Protocol Labs
Email: martenseemann@gmail.com
Seemann Expires 21 May 2024 [Page 8]
