QUIC Stream Groups

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 11 January 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

This document defines a QUIC extension that introduces the concept of stream groups. Unidirectional and bidirectional streams are added to different stream groups. Additional limits for the number of streams and the flow controlled data are applied to each group.¶

This extension adds another layer of flow control for data sent on streams, by adding a data limit per stream group. For the number of streams opened, this extension replaces the mechanism described in ([RFC9000]).¶

Logically, the flow control mechanisms of QUIC ([RFC9000]) can be regarded as the degenerate case of this extension: A connection that only has a single stream group.¶

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. Using Stream Groups

This extension doesn't prescribe any specific usage pattern for stream groups. Applicationsrunning on top of a QUIC connection might check the peer assigns streams to the correct stream groups, based on some application-defined logic.¶

4. Negotiating this Extension

Endpoints advertise their support of the extension described in this document by sending at least one of the following transport parameters (Section 7.4 of [RFC9000]).¶

initial_max_stream_groups (0x2a4c1f8e9b6d2c01):

The initial maximum stream group is an integer value that contains the initial value for the maximum stream group.¶

initial_max_group_streams_bidi (0x2a4c1f8e9b6d2c02):

The initial maximum bidirectional streams group parameter is an integer value that contains the initial maximum number of bidirectional streams the endpoint that receives this transport parameter is permitted to initiate in a new stream group. If this parameter is absent or zero, the peer cannot open bidirectional streams until a MAX_GROUP_STREAMS frame is sent.¶

initial_max_group_streams_uni (0x2a4c1f8e9b6d2c03):

The initial maximum unidirectional streams group parameter is an integer value that contains the initial maximum number of unidirectional streams the endpoint that receives this transport parameter is permitted to initiate in a new stream group. If this parameter is absent or zero, the peer cannot open unidirectional streams until a MAX_GROUP_STREAMS frame is sent.¶

initial_max_group_data (0x2a4c1f8e9b6d2c04):

The initial maximum data parameter is an integer value that contains the initial value for the maximum amount of data that can be sent on a newly established stream group. This is equivalent to sending a MAX_GROUP_DATA frame for the stream group immediately after establishment of the stream group.¶

Any of these transport parameters enables the use of this extension. The missing transport parameters take a default value of 0.¶

An implementation that understands these transport parameters MUST treat the receipt of an empty value or a value that is not a QUIC varint for any of these parameters as a connection error of type TRANSPORT_PARAMETER_ERROR.¶

When negotiating this extension, the initial_max_streams_bidi (0x08) and the initial_max_streams_uni (0x09) transport parameters MUST NOT be used. The receiver MUST treat receipt of any of these parameters as a connection error of type TRANSPORT_PARAMETER_ERROR.¶

TODO: define which of these parameters need to be remembered for 0-RTT¶

5. Limiting the Number of Streams

QUIC ([RFC9000]) identifies a stream by one number, its stream ID. When using this extension, a stream is identified by the tuple of the stream group and the stream ID.¶

6. Flow Control

7. Changes to Existing Frames

When this extension is negotiated, an additional Stream Group varint is added to a number of QUIC frames:¶

STREAM Frame {
  Type (i) = 0x08..0x0f,
  Stream Group (i),
  Stream ID (i),
  [Offset (i)],
  [Length (i)],
  Stream Data (..),
}

RESET_STREAM Frame {
  Type (i) = 0x04,
  Stream Group (i),
  Stream ID (i),
  Application Protocol Error Code (i),
  Final Size (i),
}

STREAMS_BLOCKED Frame {
  Type (i) = 0x16..0x17,
  Stream Group (i),
  Maximum Streams (i),
}

8. New Frames

The following new frames are defined.¶

TODO: define eligibility for 0-RTT¶

MAX_STREAM_GROUP Frame {
  Type (i) = 0x1b37fd9a08c2e500,
  Maximum Stream Group (i),
}

MAX_GROUP_DATA Frame {
  Type (i) = 0x1b37fd9a08c2e501,
  Stream Group (i),
  Maximum Data (i),
}

GROUP_DATA_BLOCKED Frame {
  Type (i) = 0x1b37fd9a08c2e520,
  Stream Group (i),
  Maximum Data (i),
}

GROUP_DATA_BLOCKED Frame {
  Type (i) = 0x1b37fd9a08c2e521,
  Stream Group (i),
}

9. Security Considerations

We succeeded at encrypting all the things. Isn't it wonderful to have a protocol that middleboxes can't mess with?¶

10. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

TODO acknowledge.¶

Author's Address