QUIC on Streams

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 19 August 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

QUIC version 1 [QUIC] is a bi-directional, authenticated transport-layer protocol built on top of UDP [UDP]. The protocol provides multiplexed flow-controlled streams without head-of-line blocking as a core service. It also offers low-latency connection establishment and efficient loss recovery.¶

However, there are downsides to QUIC.¶

One downside is that QUIC, being based on UDP, is not as universally accessible as TCP [TCP], due to occasionally being blocked by middleboxes.¶

Another downside is that QUIC is computationally more expensive compared to TLS [TLS13] over TCP. This increased cost is partly because QUIC encrypts each packet, which is smaller than the encryption unit of TLS, leading to more overhead, and partly because UDP is less optimized within computing infrastructures.¶

Due to these limitations, applications are often served using both QUIC and TCP. QUIC is employed to provide the optimal user experience, while TCP acts as a fallback for ensuring network reachability and computational efficiency as needed.¶

One such example is HTTP, which has different bindings for QUIC (HTTP/3 [HTTP3]) and TCP (HTTP/2 [HTTP2]). Recently, security concerns have prompted proposals to revise HTTP/2 ([h2-stream-limits]), which has sparked discussions about the costs of maintaining multiple HTTP versions.¶

Another example is WebTransport, a superset of HTTP. Because HTTP has different bindings for QUIC and TCP, WebTransport defines its own extensions for the two HTTP variants ([webtrans-h3], [webtrans-h2]).¶

To reduce or eliminate the costs associated with duplicated efforts in providing services on top of both transport protocols, this document specifies a polyfill that allows application protocols built on QUIC to run on transport protocols that provide single bi-directional, byte-oriented stream such as TCP or TLS.¶

The specified polyfill provides a compatibility layer for the set of operations (i.e., API) required by QUIC, as specified in Section 2.4 and Section 5.3 of [QUIC].¶

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. The Protocol

QUIC on Streams can be used on any transport that provides bi-directional, byte-oriented stream that is ordered and reliable; for details, see Section 3.1.¶

QUIC frames are sent directly on top of the transport.¶

The frames are not encrypted. It is the task of the transport (e.g., TLS) to provide confidentially and integrity.¶

QUIC packet headers are not used.¶

For exchanging the Transport Parameters, a new frame called QS_TRANSPORT_PARAMETERS frame is defined.¶

4. QUIC Frames

In QUIC on Streams, the following QUIC frames can be used, as if they were sent or received in the application packet number space:¶

• PADDING¶

• RESET_STREAM¶

• STOP_SENDING¶

• STREAM¶

• MAX_DATA¶

• MAX_STREAM_DATA¶

• MAX_STREAMS¶

• DATA_BLOCKED¶

• STREAM_DATA_BLOCKED¶

• STREAMS_BLOCKED¶

• CONNECTION_CLOSE¶

The frame formats are identical to those in QUIC version 1. Likewise, the meaning and requirements for the use of these frames are consistent with QUIC version 1, with the exception to the specific changes made to the STREAM frames, as detailed in Section 4.1.¶

Use of other frames defined in QUIC version 1 is prohibited. Namely, ACK frames are not used, because the underlying transport guarantees delivery. Use of frames that communicate Connection IDs and those related to path migration is forbidden.¶

If an endpoint receives one of the prohibited frames, the endpoint MUST close the connection with an error of type FRAME_ENCODING_ERROR.¶

QS_TRANSPORT_PARAMETERS Frame {
  Type (i) = 0x3f5153300d0a0d0a,
  Length (i),
  Transport Parameters (..),
}

QS_PING Frame {
  Type (i) = 0xTBD..0xTBD+1,
  Sequence Number (i),
}

5. Transport Parameters

QUIC on Streams uses a subset of Transport Parameters defined in QUIC version 1. Also, one new Transport Parameter specific to QUIC on Streams is defined.¶

6. Closing the Connection

As is with QUIC version 1, a connection can be closed either by a CONNECTION_CLOSE frame or by an idle timeout.¶

Unlike QUIC version 1, there is no draining period; once an endpoint sends or receives the CONNECTION_CLOSE frame or reaches the idle timeout, all the resources allocated for the Service are freed and the underlying transport is closed immediately.¶

7. Using 0-RTT

TLS 1.3 introduced the concept of early data (also knows as 0-RTT data).¶

When using QUIC on Streams on top of TLS that supports early data, clients MAY use early data when resuming a connection, by reusing certain Transport Parameters as defined in Section 7.4.1 of [QUIC].¶

Similarly, when accepting early data, the servers MUST send Transport Parameters that obey to the restrictions defined in Section 7.4.1 of [QUIC].¶

8. Extensions

Not all the extensions of QUIC version 1 can be used. Each extension have to define its mapping for QUIC on Streams, or explicitly allow the use; see Section 5.1.¶

As is the case with QUIC version 1, use of extension frames have to be negotiated before use; see Section 19.21 of [QUIC].¶

This specification defines the mapping of the Unreliable Datagram Extension.¶

9. Version Agility

Unlike QUIC, QUIC on Streams does not define a mechanism for version negotiation.¶

In large-scale deployments requiring service and protocol version discovery, QUIC on Streams can and is likely to be implemented over TLS. The Application-Layer Protocol Negotiation Extension of TLS [ALPN] is the favored mechanism to negotiate between an application protocol based on this specification and others.¶

When ALPN is unavailable, first 8 bytes exchanged on the transport (i.e., the type field of the QS_TRANSPORT_PARAMETERS frame in the encoded form) can be used to identify if QUIC on Streams is in use.¶

10. Implementation Considerations

Similar to HTTP/3 with Extensible Priorities [HTTP_PRIORITY], application protocols using QUIC may employ stream multiplexing along with a system to tune the delivery sequence of QUIC streams.¶

To alternate between QUIC streams of varying priorities in a timely manner, it is advisable for QUIC on Streams implementations to avoid creating deep buffers holding QUIC frames. Instead, endpoints should wait for the transport layer to be ready for writing. Upon becoming writable, they should write QUIC frames according to the latest prioritization signals.¶

Additionally, implementations may consider monitoring or adjusting the flow and congestion control parameters of the underlying transport. This approach aims to minimize data buffering within the transport layer before transmission. However, improper adjustment of these parameters could potentially lead to lower throughput.¶

11. Security Considerations

TODO Security¶

12. IANA Considerations

TODO¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses