QUIC Over Reliable Transport

1.1. Conventions

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

1.2. Terminology

This document uses the following terminology:¶

QUIC:

the protocol defined by the streams, connections, packets and frames specified in [RFC9000]. Within the context of this document, the term "QUIC" does not include the cryptographic protection described in [RFC9001] nor the loss detection and congestion control procedures of [RFC9002].¶

QORT:

QUIC over a reliable transport (as defined in this document).¶

RPT:

reliable and protected transport offering both cryptographic protection and error-free, in-order application data delivery (e.g. TLS/TCP, TLS/SCTP).¶

RT:

reliable transport offering error-free, in-order application data delivery but not offering cryptographic protection (e.g. SCTP).¶

session:

a collection of QUIC connections and paths used to exchange QUIC packets between two endpoints.¶

1.3. Notation

This document uses the field notation defined in [RFC9000] and quoted below:¶

Individual fields use the following notational conventions, with all lengths in bits:¶

x (A): Indicates that x is A bits long¶

x (i): Indicates that x holds an integer value using the variable length encoding described in [RFC9000], Section 16¶

x (A..B): Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits, and B can be omitted to indicate no set upper limit; values in this format always end on a byte boundary¶

x (L) = C: Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above¶

x (L) = C..D: Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above¶

x (L)...: Indicates that x is repeated zero or more times and that each instance has a length of L¶

3.1. Delimiting Messages

Some reliable transports provide message delimitation (aka. "framing"), allowing a sequence of bytes conveyed by the reliable transport to be identified and treated as a self-contained message. For example, in [SCTP] message delimitation is provided by the SCTP packet protocol and in [NR-RLP] message delimitation is provided by the packet data convergence protocol (PDCP). When message delimitation is provided by the reliable transport, each transmitted QUIC packet MUST be treated as a separate message.¶

Some reliable transports (e.g. TCP) only convey byte streams and do not (natively) provide message delimitation. When message delimitation is not provided by the reliable transport, each transmitted QUIC packet MUST be terminated by a QORT end-of-packet frame (Section 7).¶

3.2. In-Order Delivery

A reliable transport MUST provide in-order delivery of messages, ensuring that messages are presented to a receiving QORT entity in the same order that they sent by a transmitting QORT entity.¶

3.3. Guaranteed Delivery

A reliable transport MUST provide guaranteed delivery, ensuring that any bytes of a message lost in transmission between two endpoints are recovered, normally through retransmission. The reliable transport MUST buffer any bytes received out-of-order and MUST reorder any recovered bytes to ensure in-order delivery of the messages.¶

3.4. Congestion Control

A reliable transport MUST provide congestion control that is applied to the aggregate of packets transmitted by an endpoint.¶

3.5. Cryptographic Protection

A reliable transport MAY also provide integrity protection (e.g. a cryptographic hash of packet contents) and privacy protection (i.e. encryption). The ability of a reliable transport to provide cryptographic protection may influence the QORT mode of operation selected by a client (Section 4).¶

4.1. Mode Selection

The QORT mode of operation selected by the client is indicated by the Version field in the long packet header of the QUIC INITIAL packet sent from the client to a server.¶

If the server is able to support the QORT mode selected by the client, the server MUST respond with a QUIC INITIAL packet where the Version field in the long packet header is the same as the version indicated by the client.¶

If the server is not able to support the QORT mode selected by the client, the server MUST close the connection with an Error_qortNotSupported (Section 10).¶

Because the reliable transport has been established between the client and server before the start of QORT operations, there is no mode of operation negotiation -- the server either accepts the mode selected by the client or it closes the connection. Similarly, QORT does not support negotiation of the QUIC protocol version using a VERSION NEGOTIATION packet.¶

In this document, the mode of operation Version dictates compatibility with Version 0x00000001 of QUIC; compatibility with other versions of QUIC are beyond the scope of this document.¶

4.2. CRYPTO-QORT mode of operation

The CRYPTO-QORT mode of operation is initiated using a cryptographic handshake sequence similar to that described in Section 7 of [RFC9000].¶

The CRYPTO-QORT mode of operation differs from [RFC9000] in the following ways:¶

• the Version field in a QUIC long header packet MUST be set to Version01_qortCrypto (Section 13.1).¶

• deprecated QUIC frames listed in Section 5 and in Section 5.1 MUST NOT be included in any QUIC packets.¶

In the CRYPTO-QORT mode of operation, a receiving endpoint must be able to detect the end of a QUIC packet before attempting to decrypt the packet. Therefore CRYPTO-QORT mode of operation can only be used with a reliable transport that provides message delimitation (Section 3.1).¶

An exemplary CRYPTO-QORT handshake sequence is illustrated in Figure 2.¶

4.3. BASIC-QORT mode of operation

The BASIC-QORT mode of operation assumes that cryptographic protection (if needed) has been established by the reliable transport before the QORT handshake between client and server begins. As a consequence, the BASIC-QORT mode of operation involves an initial exchange of transport parameters between the endpoints but does not include a cryptographic handshake.¶

The BASIC-QORT mode of operation differs from [RFC9000] in the following ways:¶

• the Version field in a QUIC long header packet MUST be set to Version01_qortBasic (Section 13.1).¶

• the QUIC INITIAL packets exchanged between endpoints MUST include a QORT_CONFIGURATION frame (Section 8.1).¶

• QUIC HANDSHAKE packets MUST NOT be exchanged between endpoints.¶

• deprecated QUIC frames listed in Section 5 and in Section 5.2 MUST NOT be included in any QUIC packets.¶

The BASIC-QORT handshake sequence is illustrated in Figure 3.¶

5.1. Deprecated QUIC Frames in CRYPTO-QORT Mode

When CRYPTO-QORT mode is selected, the following additional QUIC frame types defined by [RFC9000] MUST NOT be transmitted by either endpoint in a connection:¶

• (TBD)¶

If an endpoint receives one of these frame types when operating in CRYPTO-QORT mode, it MUST close the connection with an error of type Error_qortInvalidFrame (Section 13).¶

5.2. Deprecated QUIC Frames in BASIC-QORT Mode

When BASIC-QORT mode is selected, the following additional QUIC frame types defined by [RFC9000] MUST NOT be transmitted by either endpoint in a connection:¶

• CRYPTO frames

  are not needed because cryptographic protection is provided by the reliable transport.¶

If an endpoint receives one of these frame types when operating in BASIC-QORT mode, it MUST close the connection with an error of type Error_qortInvalidFrame (Section 13).¶

8.1. QORT_CONFIGURATION frame

A QORT_CONFIGURATION frame contains transport parameters defined by the sending endpoint. As such, a QORT_CONFIGURATION frame is a direct replacement for the TLS quic_transport_parameters extension described in Section 8.2 of [RFC9001].¶

When a client initiates the BASIC-QORT mode of operation, the client MUST include a QORT_CONFIGURATION frame in its QUIC INITIAL packet. See example in Appendix A.2.¶

When a server agrees to use the BASIC-QORT mode of operation, the server MUST include a QORT_CONFIGURATION frame in its responding QUIC INITIAL packet.¶

A QORT_CONFIGURATION frame (Figure 4) includes the following fields:¶

   QORT_CONFIGURATION Frame {
     Type (i) = Type_qortConfiguration,
     Transport_Parameter_List_Length (i)
     Transport_Parameter_List (..) ...,
   }

• Type

  is set to Type_qortConfiguration (Section 13.3).¶

• Transport_Parameter_List_Length

  is set to the length of the Transport_Parameter_List, in number of octets.¶

• Transport_Parameter_List

  is a list of transport parameters.¶

As defined in Section 18 of [RFC9000], each transport parameter in the list of transport parameters is encoded as an (identifier, length, value) tuple -- i.e.¶

   Transport Parameter {
     Transport Parameter ID (i),
     Transport Parameter Length (i),
     Transport Parameter Value (..),
   }

The set of valid QORC transport parameters is described in Section 9.¶

8.2. QORT_ENDOFPACKET frame

A QORT_ENDOFPACKET frame is used to identify the end of a QUIC packet (Section 7). A QORT_ENDOFPACKET frame (Figure 6) includes the following fields:¶

   QORT_ENDOFPACKET Frame {
     Type (i) = Type_qortEndOfPacket,
   }

• Type

  is set to Type_qortEndOfPacket (Section 13.3).¶

9.1. RFC9000 Transport Parameters

Not all transport parameters defined in [RFC9000] are valid for use with QUIC over a reliable transport. When either QORT mode is enabled, a QUIC transport parameter with an 'x' in the "not allowed?" column of Table 1 MUST NOT be transmitted by either endpoint.¶

If an endpoint receives one of the "not allowed?" transport parameters, it MUST close the connection with an error of type Error_qortInvalidParameter (Section 13).¶

13.1. QUIC version numbers

This document defines two new (preliminary) QUIC version numbers that are bound to Version 0x00000001 of QUIC (Section 4):¶

• Version01_qortBasic (0x54e51e9e)¶

• Version01_qortCrypto (0x147214bd)¶

13.2. QORT transport error codes

This document extends the QUIC Transport Error Codes of [RFC9000], Section 22.5 with the following (preliminary) values:¶

• Error_qortInvalidFrame (0x2fc2ed12e1295ab1)¶

• Error_qortInvalidParameter (0x0b244a578d7dc6c4)¶

• Error_qortNotSupported (0x341b50c67a845ff4)¶

• Error_qortProtocolViolation (0x0ed79e3b4c52d445)¶

13.3. New QUIC frame types

This document defines two new (preliminary) QUIC frame types:¶

• Type_qortConfiguration (0x27f72376051c5308) -- Section 8.1¶

• Type_qortEndOfPacket (0x3b5690c1243618cd) -- Section 8.2¶

14.1. Normative References

[IANA]

Internet Assigned Numbers Authority, "QUIC Protocol Registry", <https://www.iana.org/assignments/quic/>.

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

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

[RFC9002]

Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

14.2. Informative References

[DATAGRAM]

Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/rfc/rfc9221>.

[NR-RLP]

3rd Generation Partnership Project (3GPP), "Technical Specification 38.300; NR and NG-RAN Overall Description; Stage 2", <https://www.3gpp.org/DynaReport/38300.htm>.

[QMUX-DRAFT]

Oku, K., Pardue, L., Iyengar, J., and E. Kinnear, "QMux", Work in Progress, Internet-Draft, draft-opik-quic-qmux-00, 23 July 2025, <https://datatracker.ietf.org/doc/html/draft-opik-quic-qmux-00>.

[RFC9312]

Kühlewind, M. and B. Trammell, "Manageability of the QUIC Transport Protocol", RFC 9312, DOI 10.17487/RFC9312, September 2022, <https://www.rfc-editor.org/rfc/rfc9312>.

[SCTP]

Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, June 2022, <https://www.rfc-editor.org/rfc/rfc9260>.

[TCP]

Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/rfc/rfc9293>.

[TLS]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

A.1. QUIC Packet with QORT_ENDOFPACKET Frame

When message delimitation is not provided by the reliable transport, each transmitted QUIC packet must be terminated by a QORT_ENDOFPACKET frame. This is illustrated in Figure 7.¶

{
  "name": "transport:packet_received",
  "data": {
    "header": {
      "packet_number": 1,
      "packet_type": "1RTT",
      "dcid": "faee8572bad88622",
      "spin_bit": 0
    },
    "frames": [
      {
        "frame_type": "ack",
        "ack_delay": 2.888,
        "acked_ranges": [
          [
            0,
            0
          ]
        ]
      },
      {
        "frame_type": "stream",
        "fin": false,
        "length": 21,
        "offset": 0,
        "stream_id": 3
      },
      {
        "frame_type": "stream",
        "fin": false,
        "length": 4,
        "offset": 0,
        "stream_id": 7
      },
      {
        "frame_type": "stream",
        "fin": false,
        "length": 1,
        "offset": 0,
        "stream_id": 11
      },
      {
        "frame_type": "rt end_of_packet"
      }
    ],
    "raw": {
      "length": 63
    }
  }
}

A.2. QUIC Initial Packet with QORT_CONFIGURATION Frame

In BASIC-QORT mode of operation, the INITIAL QUIC packet must include a QORT_CONFIGURATION frame. This is illustrated in Figure 8.¶

{
  "name": "transport:packet_sent",
  "data": {
    "header": {
      "packet_number": 0,
      "packet_type": "initial",
      "dcid": "48dc009224099b2c",
      "scid": "18657c1acd3e0c5e"
    },
    "frames": [
      {
        "frame_type": "rt configuration",
        "transport_parameters": {
          "max_idle_timeout": 10000,
          "max_udp_payload_size": 1200,
          "initial_max_data": 1048576,
          "initial_max_stream_data_bidi_local": 1048576,
          "initial_max_stream_data_bidi_remote": 1048576,
          "initial_max_stream_data_uni": 1048576,
          "initial_max_streams_bidi": 128,
          "initial_max_streams_uni": 128,
          "ack_delay_exponent": 3,
          "max_ack_delay": 25,
          "disable_active_migration": false,
          "active_connection_id_limit": 8,
          "initial_source_connection_id": "18657c1acd3e0c5e",
          "max_datagram_frame_size": 65536
        }
      },
      {
        "frame_type": "padding",
        "length": 1089
      },
      {
        "frame_type": "rt end_of_packet"
      }
    ],
    "raw": {
      "length": 1200
    }
  }
}

C.1. Use of QUIC packets

[QMUX-DRAFT] does not use QUIC packets for encapsulating QUIC frames. Instead, [QMUX-DRAFT] sends QUIC frames directly over the reliable transport.¶

By contrast, QORT retains the use of QUIC packets to support QUIC operations that are dependent on information in the QUIC packet header as described in Section 17 of [RFC9000] -- e.g. packet numbering, coalescence, cryptographic protection, connection identification and migration.¶

C.2. Connections and connection identifiers

[QMUX-DRAFT] does not include mechanisms for identifying QUIC connections, for managing QUIC connection identifiers, or for path migration. Essentially, all QUIC frames are associated with a zero-length connection identifier.¶

By contrast, QORT retains the concept of QUIC connections and associated connection identifiers to support connection management, path migration and multipath operations.¶

C.3. Cryptographic protection

[QMUX-DRAFT] requires an underlying transport that provides cryptographic protection. As a consequence, [QMUX-DRAFT] offers no cryptographic capabilities.¶

By contrast, QORT offers a CRYPTO-QORT mode of operation that reuses [RFC9000] cryptographic protection mechanisms such as a cryptographic handshake using QUIC CRYPTO frames and key rotation using the key phase bit of a QUIC packet header.¶

C.4. Stream processing

While [QMUX-DRAFT] reuses QUIC STREAM frames for exchanging application data, Section 4.1 of [QMUX-DRAFT] introduces some restrictions on STREAM frame use.¶

By contrast, QORT does not change any [RFC9000] procedures related to stream processing.¶