Reverso for the QUIC protocol

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

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

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

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

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:¶

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

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

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

   smallest = largest - ack_range

   largest = previous_smallest - gap - 2

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

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

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
}

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

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

Acknowledgments

TODO acknowledge.¶

Author's Address