QUIC Accurate ECN Acknowledgements
draft-seemann-quic-accurate-ack-ecn-00

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]