Reverso for the QUIC protocol
draft-frochet-quicwg-reverso-for-quic-00

QUICWG                                                         F. Rochet
Internet-Draft                                                    UNamur
Intended status: Standards Track                       16 September 2024
Expires: 20 March 2025

                     Reverso for the QUIC protocol
                draft-frochet-quicwg-reverso-for-quic-00

Abstract

   This document describes a QUIC extension re-designing the layout of
   the QUIC protocol to avoid memory fragmentation at the receiver and
   allows implementers seeking a more efficient implementation to have
   the option to implement contiguous zero-copy at the receiver.  This
   document describes the change from QUIC v1 required in packet
   formats, variable-length integers and frame formats.  Everything else
   from QUIC v1 described in [RFC9000] is untouched.

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-frochet-quicwg-reverso-for-
   quic/.

   Source for this draft and an issue tracker can be found at
   https://github.com/https://github.com/frochet/draft-rochet-reverso-
   generic.

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 20 March 2025.

Rochet                    Expires 20 March 2025                 [Page 1]
Internet-Draft        Reverso for the QUIC protocol       September 2024

Copyright Notice

   Copyright (c) 2024 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.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   4.  Streams . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Frame Formats . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Ack Frame's details . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  Reversed ACK Ranges . . . . . . . . . . . . . . . . .   5
       5.1.2.  Reversed ECN Counts . . . . . . . . . . . . . . . . .   6
   6.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Header Protection . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Frame ordering  . . . . . . . . . . . . . . . . . . . . .   8
   7.  Variable-Length Integer Encoding  . . . . . . . . . . . . . .   8
   8.  Packing frames  . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   QUIC is a general-purpose transport protocol with mandatory
   encryption leveraged from a TLS 1.3 key exchange.  QUIC is specified
   in [RFC9000], and is the result of several years of efforts from
   several major companies, independent individuals and academics.  One
   of the main benefits of QUIC is to resist ossification thanks to a
   two-levels encryption design (header and payload), supporting
   extensions and modifications of internal QUIC information to resist
   friction from independent lower layers at deployment time.

Rochet                    Expires 20 March 2025                 [Page 2]
Internet-Draft        Reverso for the QUIC protocol       September 2024

   However, it is of notoriety that the QUIC design is CPU costly.  The
   root cause of QUIC's high CPU cost isn't unique, and this document
   addresses one of them: a misalignment between QUIC's protocol
   specification and encryption usage.  Indeed, the QUIC design in
   [RFC9000] unavoidably fragments Application Data and forces any
   implementation to perform at least a memory copy to provide a
   contiguous bytestream abstraction to the upper layer, at the
   receiver.

   This documents suggests slight changes to the QUIC protocol to offer
   the opportunity for implementers to provide a contiguous zero-copy
   abstraction at the receiver side, which is otherwise impossible to do
   from [RFC9000]'s specifications using atomic interfaces from
   crypgraphy backends.  We temporally call this extensions QUIC
   VReverso.  With this extension, frames' content are encoded in
   reverse ordering and would be processed from right to left at the
   receiver, instead of the usual left to right as in any protocol.

2.  Goals

   We aim to change how the QUIC protocol specifies its frames to
   support contiguous zero-copy.  A few more bytes have also to be added
   within the protected short header.  Those changes are however
   engineered with goals to:

   *  Create minimal work for existing implementation to migrate to this
      extension.

   *  Does not modify any of the QUIC's transport properties and does
      not conflict with the goals of any ongoing work on QUIC extensions
      (e.g., MPQUIC).

   *  Does not impact QUIC's security.

   *  Does not modify encryption/decryption implementations such that
      compatibility with existing crypto backends are preserved.

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.

Rochet                    Expires 20 March 2025                 [Page 3]
Internet-Draft        Reverso for the QUIC protocol       September 2024

4.  Streams

   Stream ID values start at 1.  The value 0 is reserved to indicate
   within the new short header (see Section 6.1) that no stream frame is
   packed within the payload.

5.  Frame Formats

   Frames' structure written on the wire are altered in this QUIC
   version to support backward processing of QUIC packets.  With the
   exception of the ACK frame, all the other frames are straightforward
   to adapt from [RFC9000].  Essentially, on [RFC9000], each frame
   begins with a Frame Type followed by additional type-dependent
   fields, and are represented as this:

   Frame {
     Frame Type (i),
     Type-Dependent Fields (..),
   }

   This representation follows the implicit rule that what we specify
   from top to bottom is written and read from left to right on the
   wire.

   If QUIC VReverso is used, frames are reversed.  Type-dependent fields
   appear first (from left to right on the wire), and the frame
   terminates with the Frame Type.  We represent those frames by
   reversing as well their representation in specifications:

   Frame {
     Type-Dependent Fields (..),
     Frame Type (i),
   }

   Of course, within an implementation, the relative order of elements
   within Structs or Objects does not matter, and can stay untouched.
   Only writing on wire and reading from the wire would be altered.

   The choice of order of Type-Dependent Fields only matter to smooth
   transition and adaptation of existing code handling [RFC9000]'s frame
   format.  Reversing the existing ordering, and not making other
   changes within the relative order of elements supports
   straightforward adaptation of existing code.  For example, in
   [RFC9000], the MAX_STREAM_DATA Frame is defined as:

Rochet                    Expires 20 March 2025                 [Page 4]
Internet-Draft        Reverso for the QUIC protocol       September 2024

   MAX_STREAM_DATA Frame {
     Type (i) = 0x11,
     Stream ID (i),
     Maximum Stream Data (i),
   }

   Which would translate to:

   MAX_STREAM_DATA Frame {
     Maximum Stream Data (i),
     Stream ID (i),
     Type (i) = 0x11,
   }

   Other frames are altered with the same reversing logic.  It includes
   reversing internal structures in a given Frame if any, such as the
   ACK Frame.

5.1.  Ack Frame's details

   The Ack Frame is reversed as well, but requires further changes on
   the ACK Range's specification and ECN Counts.  The goal is to
   guarantee no change in processing logic of a ACK Frame, and minimal
   change to existing code.  We have for this proposal the ACK Frame
   reversed:

   ACK Frame {
     [ECN Counts (..)],
     ACK Range (..) ...,
     First ACK Range (i),
     ACK Range Count (i),
     ACK Dealy (i),
     Largest Acknowledged (i),
     Type (i)  = 0x02..0x03,
   }

   Where the ACK Range contains ranges of packets that are alternately
   not acknowledged (Gap) and acknowledged (ACK Range).  All other
   fields are untouched, only their order on the wire is modifierd.

5.1.1.  Reversed ACK Ranges

   In [RFC9000], each ACK Range consists of alternating Gap and ACK
   Range Length values _in descending packet number order_ as appearing
   on the wire.  The ranges in [RFC9000] contain the information in
   reversed ordering, starting from the largest acknowledged packets.
   In this proposal, to accommodate backward processing of the frame and
   minimal algorithmic changes, the ACK Range consists of alternating

Rochet                    Expires 20 March 2025                 [Page 5]
Internet-Draft        Reverso for the QUIC protocol       September 2024

   ACK Range Length and Gap in _ascending packet number order_.

   ACK Range {
     ACK Range Length (i),
     Gap (i),
   }

                            Figure 1: ACK Ranges

   As explained in [RFC9000], the fields that form each ACK Range are:

   ACK Range Length:  A variable-length integer indicating the number of
      contiguous acknowledged packets preceding the largest packet
      number, as determined by the last processed Gap.

   Gap:  A variable-length integer indicating the number of contiguous
      unacknowledged packets preceding the packet number one lower than
      the smallest in the last processed ACK Range.

   Since ACK Range Length and Gap are defined as relative integer; to
   keep efficient processing, and unchanged algorithmic compared to
   [RFC9000], each ACK Range describes progressively lower-numbered
   packets while being processed backwards.  However, on the wire, from
   left to right, each ACK Range describes progressively higher-numbered
   packets.

   Therefore, while processing this information backwards, and given the
   largest packet number for the current range, the smallest value is
   determined by the following formula (like [RFC9000]):

      smallest = largest - ack_range

   Where the largest value for an ACK Range is determined by
   cumulatively subtracting the size of all preceding ACK Range Lengths
   and Gaps.  The first largest value is obtained with the ACK Frame's
   Largest Acknowledged field.  Subsequent largest for each Ack Range is
   then computed similarly to [RFC9000]:

      largest = previous_smallest - gap - 2

5.1.2.  Reversed ECN Counts

   The ACK frame uses the least significant bit of the type value to
   indicate ECN feedback.  The ECN Counts order is reversed compared to
   [RFC9000] to support minimal change to processing logic in existing
   implementations while being processed backwards (i.e., the order of
   processed elements stays the same).

Rochet                    Expires 20 March 2025                 [Page 6]
Internet-Draft        Reverso for the QUIC protocol       September 2024

   ECN Counts {
     ECN-CE Count (i),
     ECT1 Count (i),
     ECT0 Count (i),
   }

                         Figure 2: ECN Count Format

6.  Packet Formats

   For implementers to take advantage of Reverso, we require to know the
   Stream ID of any stream frame within the payload, and the data
   offset.  These two integers are added in the QUIC short header and
   protected with the mask.

6.1.  Header Protection

   Header of 1-RTT short header packets is extended to add at most 8
   bytes of information, requiring a 13-bytes mask.  Application of the
   mask follows the same procedure as specified in [RFC9001], as a
   minimum of 16 bytes are currently available from the current header
   protection algorithms.

   1-RTT Packet {
     Header Form (1) = 0,
     Fixed Bit (1) = 1,
     Spin Bit (1),
     Reserved Bits (2),         # Protected
     Key Phase (1),             # Protected
     Packet Number Length (2),  # Protected
     Destination Connection ID (0..160),
     Packet Number (8..32),     # Protected
     Stream ID (8..32)          # Protected
     Offset (8..32)             # Protected
     Protected Payload (0..24), # Skipped Part
     Protected Payload (128),   # Sampled Part
     Protected Payload (..),    # Remainder
   }

   The 1-RTT packets has the following modifications from QUIC v1:

   *  Packet Number: The Packet Number field is 1 to 4 bytes long with
      the least significant two bits of the last byte containing the
      length of the Stream ID.  This length is encoded as an unsigned
      two-bit integer that is one less than the length of the Stream ID
      field in bytes.  This is field is protected using [RFC9001]'s mask
      up to consume 5 bytes (including the header's first byte) from the
      minimum guaranteed 16 bytes in total.

Rochet                    Expires 20 March 2025                 [Page 7]
Internet-Draft        Reverso for the QUIC protocol       September 2024

   *  Stream ID: The Stream ID field is 1 to 4 bytes long with the least
      significant two bits of the last byte containing the length of the
      Offset.  This is length is encoded as an unsigned two-bit integer
      that is one less than the length of the Offset field in bytes.  A
      1-byte value of 0 for the this field is reserved to indicate that
      the encrypted payload does not contain any Stream frame.  This
      field is protected using [RFC9001]'s mask, up to consume 9 bytes
      from the minimum guaranteed 16 bytes in total.

   *  Offset: The Offset field is 1 to 4 bytes long, and encodes a value
      based on the knowledge of the maximum acknowledged offset,
      similarly to the Packet Number field encoding a value based on the
      maximum acknowledged packet number.  On the receiver, the decoding
      procedure is similar to decoding packet numbers.  This field is
      protected using [RFC9001]'s mask, up to consume 13 bytes from the
      minimum guaranteed 16 bytes in total.

6.2.  Frame ordering

   In Reverso, a Stream Frame, if any, MUST be the first frame within
   the payload.  The Stream frame can be followed by any number of
   control frames up to the packet boundary.  Any other Stream frame
   SHOULD NOT be added within the same QUIC packet.

7.  Variable-Length Integer Encoding

   QUIC v1 uses variable-length encoding for non-negative integer values
   to encode fewer bytes on the wire than usual host representations.
   In QUIC v1 the encoding reserves the two most significant bits of the
   first byte, and encode the integer in the remaining bits, in network
   byte order.  In this version, we encode the length in the two least
   significant bits of the last byte to accommodate processing the
   information by rewinding the buffer.  The remaining bits encode the
   integer value in network byte order.

          +======+========+=============+=======================+
          | 2LSB | Length | Usable Bits | Range                 |
          +======+========+=============+=======================+
          | 00   | 1      | 6           | 0-63                  |
          +------+--------+-------------+-----------------------+
          | 01   | 2      | 14          | 0-16383               |
          +------+--------+-------------+-----------------------+
          | 10   | 4      | 30          | 0-1073741823          |
          +------+--------+-------------+-----------------------+
          | 11   | 8      | 62          | 0-4611686018427387903 |
          +------+--------+-------------+-----------------------+

             Table 1: Summary of Integer Encodings with Reverso

Rochet                    Expires 20 March 2025                 [Page 8]
Internet-Draft        Reverso for the QUIC protocol       September 2024

8.  Packing frames

   To take advantage of backward processing of QUIC VReverso packets,
   some constraints SHOULD be respected.  The order and number of data
   chunks within a single encryption matters.  The Stream frame if any
   MUST be the first element within the encrypted payload, followed by
   any number of control frames, up to the packet boundary.  We SHOULD
   pack a single Stream frame per encryption.  More than one would force
   an unavoidable memory copy of all but the first Stream frame within a
   packet.

   Lost frames being resubmitted SHOULD be packed within their own
   packet, and other control frames SHOULD not be multiplexed with
   retransmissions.  This allows for spurious retransmissions that have
   been already processed but not acknowledged fast enough to not
   require the two-levels decryption.  Only header decryption and
   information contained within the QUIC VReverso short header would be
   enough to decide whether the packet payload should be decrypted, or
   could be dropped before payload decryption is attempted.

9.  References

9.1.  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>.

9.2.  Informative References

   [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>.

   [RFC9001]  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>.

Acknowledgments

   TODO acknowledge.

Rochet                    Expires 20 March 2025                 [Page 9]
Internet-Draft        Reverso for the QUIC protocol       September 2024

Author's Address

   Florentin Rochet
   UNamur
   Email: florentin.rochet@unamur.be

Rochet                    Expires 20 March 2025                [Page 10]