]> Akamai

rmarx@akamai.com

Meta

lniccolini@meta.com

Protocol Labs

marten@protocol.ai

Cloudflare

lucaspardue.24.7@gmail.com

Transport QUIC Internet-Draft This document describes concrete qlog event definitions and their metadata for HTTP/3 and QPACK-related events. These events can then be embedded in the higher level schema defined in . Note to Readers

• Note to RFC editor: Please remove this section before publication.

Feedback and discussion are welcome at https://github.com/quicwg/qlog. Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/qlog/.

Introduction This document describes the values of the qlog name ("category" + "event") and "data" fields and their semantics for the HTTP/3 protocol , QPACK , and some of their extensions (see , and ).

Notational 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 when, and only when, they appear in all capitals, as shown here. The event and data structure definitions in ths document are expressed in the Concise Data Definition Language and its extensions described in . The following fields from are imported and used: name, category, type, data, group_id, protocol_type, importance, RawInfo, and time-related fields.

Overview This document describes how the HTTP/3 and QPACK can be expressed in qlog using the schema defined in . HTTP/3 and QPACK events are defined with a category, a name (the concatenation of "category" and "event"), an "importance", an optional "trigger", and "data" fields. Some data fields use complex datastructures. These are represented as enums or re-usable definitions, which are grouped together on the bottom of this document for clarity. When any event from this document is included in a qlog trace, the "protocol_type" qlog array field MUST contain an entry with the value "HTTP3".

Usage with QUIC The events described in this document can be used with or without logging the related QUIC events defined in . If used with QUIC events, the QUIC document takes precedence in terms of recommended filenames and trace separation setups. If used without QUIC events, it is recommended that the implementation assign a globally unique identifier to each HTTP/3 connection. This ID can then be used as the value of the qlog "group_id" field, as well as the qlog filename or file identifier, potentially suffixed by the vantagepoint type (For example, abcd1234_server.qlog would contain the server-side trace of the connection with GUID abcd1234).

HTTP/3 and QPACK Event Overview This document defines events in two categories, written as lowercase to follow convention: h3 () and qpack (). As described in , the qlog "name" field is the concatenation of category and type. summarizes the name value of each event type that is defined in this specification. HTTP/3 and QPACK Events

Name value	Importance	Definition
h3:parameters_set	Base
h3:parameters_restored	Base
h3:stream_type_set	Base
h3:priority_updated	Base
h3:frame_created	Core
h3:frame_parsed	Core
h3:datagram_created	Base
h3:datagram_parsed	Base
h3:push_resolved	Extra
qpack:state_updated	Base
qpack:stream_state_updated	Core
qpack:dynamic_table_updated	Extra
qpack:headers_encoded	Base
qpack:headers_decoded	Base
qpack:instruction_created	Base
qpack:instruction_parsed	Base

HTTP/3 Events HTTP/3 events extend the $ProtocolEventBody extension point defined in .

H3Events definition and ProtocolEventBody extension

HTTP events are logged when a certain condition happens at the application layer, and there isn't always a one to one mapping between HTTP and QUIC events. The exchange of data between the HTTP and QUIC layer is logged via the "stream_data_moved" and "datagram_data_moved" events in .

parameters_set Importance: Base This event contains HTTP/3 and QPACK-level settings, mostly those received from the HTTP/3 SETTINGS frame. All these parameters are typically set once and never change. However, they are typically set at different times during the connection, so there can be several instances of this event with different fields set. The "owner" field reflects how Settings are exchanged on a connection. Sent settings have the value "local" and received settings have the value "received". A qlog can have multiple instances of this event. As a reminder the CDDL unwrap operator (~), see ), copies the fields from the referenced type (H3Parameters) into the target type directly, extending the target with the unwrapped fields. Definition:

H3ParametersSet definition uint64 } ]]>

This event can contain any number of unspecified fields. This allows for representation of reserved settings (aka GREASE) or ad-hoc support for extension settings that do not have a related qlog schema definition.

parameters_restored Importance: Base When using QUIC 0-RTT, HTTP/3 clients are expected to remember and reuse the server's SETTINGs from the previous connection. This event is used to indicate which HTTP/3 settings were restored and to which values when utilizing 0-RTT. Definition:

H3ParametersRestored definition

Similar to H3ParametersSet this event can contain any number of unspecified fields to allow for reserved or extension settings.

stream_type_set Importance: Base Emitted when a stream's type becomes known. This is typically when a stream is opened and the stream's type indicator is sent or received. The stream_type_value field is the numerical value without VLIE encoding. Definition:

H3StreamTypeSet definition

priority_updated Importance: Base Emitted when the priority of a request stream or push stream is initialized or updated through mechanisms defined in . For example, the priority can be updated through signals received from client and/or server (e.g., in HTTP/3 HEADERS or PRIORITY_UPDATE frames) or it can be changed or overridden due to local policies. Definition:

H3PriorityUpdated definition

frame_created Importance: Core This event is emitted when the HTTP/3 framing actually happens. This does not necessarily coincide with HTTP/3 data getting passed to the QUIC layer. For that, see the "stream_data_moved" event in . Definition:

H3FrameCreated definition

frame_parsed Importance: Core This event is emitted when the HTTP/3 frame is parsed. This is not necessarily the same as when the HTTP/3 data is actually received on the QUIC layer. For that, see the "stream_data_moved" event in . Definition:

H3FrameParsed definition

HTTP/3 DATA frames can have arbitrarily large lengths to reduce frame header overhead. As such, DATA frames can span multiple QUIC packets. In this case, the frame_parsed event is emitted once for the frame header, and further streamed data is indicated using the stream_data_moved event.

datagram_created Importance: Base This event is emitted when an HTTP/3 Datagram is created (see ). This does not necessarily coincide with the HTTP/3 Datagram getting passed to the QUIC layer. For that, see the "datagram_data_moved" event in . Definition:

H3DatagramCreated definition

datagram_parsed Importance: Base This event is emitted when the HTTP/3 Datagram is parsed (see ). This is not necessarily the same as when the HTTP/3 Datagram is actually received on the QUIC layer. For that, see the "datagram_data_moved" event in . Definition:

H3DatagramParsed definition

push_resolved Importance: Extra This event is emitted when a pushed resource is successfully claimed (used) or, conversely, abandoned (rejected) by the application on top of HTTP/3 (e.g., the web browser). This event is added to help debug problems with unexpected PUSH behaviour, which is commonplace with HTTP/2. Definition:

H3PushResolved definition

HTTP/3 Data Field Definitions The following data field definitions can be used in HTTP/3 events.

Owner

Owner definition

H3Frame The generic $H3Frame is defined here as a CDDL extension point (a "socket" or "plug"). It can be extended to support additional HTTP/3 frame types.

H3Frame plug definition any } ]]>

The HTTP/3 frame types defined in this document are as follows:

H3BaseFrames definition

H3Datagram The generic $H3Datagram is defined here as a CDDL extension point (a "socket" or "plug"). It can be extended to support additional HTTP/3 datagram types. This document intentionally does not define any specific HTTP/3 Datagram types.

H3Datagram plug definition any } ]]>

H3DataFrame

H3DataFrame definition

H3HeadersFrame This represents an uncompressed, plaintext HTTP Headers frame (e.g., no QPACK compression is applied). For example:

H3HeadersFrame example

H3HeadersFrame definition

H3HTTPField definition

H3CancelPushFrame

H3CancelPushFrame definition

H3SettingsFrame

H3SettingsFrame definition

H3PushPromiseFrame

H3PushPromiseFrame definition

H3GoAwayFrame

H3GoawayFrame definition

H3MaxPushIDFrame

H3MaxPushIDFrame definition

H3PriorityUpdateFrame The PRIORITY_UPDATE frame is defined in .

h3priorityupdateframe definition

H3ReservedFrame

H3ReservedFrame definition

H3UnknownFrame The frame_type_value field is the numerical value without VLIE encoding.

UnknownFrame definition

H3ApplicationError

H3ApplicationError definition

The H3ApplicationError defines the general $ApplicationError definition in the qlog QUIC definition, see .

QPACK Events QPACK events extend the $ProtocolEventBody extension point defined in .

QPACKEvents definition and ProtocolEventBody extension

QPACK events mainly serve as an aid to debug low-level QPACK issues.The higher-level, plaintext header values SHOULD (also) be logged in the http.frame_created and http.frame_parsed event data (instead). QPACK does not have its own parameters_set event. This was merged with http.parameters_set for brevity, since qpack is a required extension for HTTP/3 anyway. Other HTTP/3 extensions MAY also log their SETTINGS fields in http.parameters_set or MAY define their own events.

state_updated Importance: Base This event is emitted when one or more of the internal QPACK variables changes value. Note that some variables have two variations (one set locally, one requested by the remote peer). This is reflected in the "owner" field. As such, this field MUST be correct for all variables included a single event instance. If you need to log settings from two sides, you MUST emit two separate event instances. Definition:

QPACKStateUpdate definition

stream_state_updated Importance: Core This event is emitted when a stream becomes blocked or unblocked by header decoding requests or QPACK instructions. This event is of "Core" importance, as it might have a large impact on HTTP/3's observed performance. Definition:

QPACKStreamStateUpdate definition

dynamic_table_updated Importance: Extra This event is emitted when one or more entries are inserted or evicted from QPACK's dynamic table. Definition:

QPACKDynamicTableUpdate definition

headers_encoded Importance: Base This event is emitted when an uncompressed header block is encoded successfully. This event has overlap with http.frame_created for the HeadersFrame type. When outputting both events, implementers MAY omit the "headers" field in this event. Definition:

QPACKHeadersEncoded definition

headers_decoded Importance: Base This event is emitted when a compressed header block is decoded successfully. This event has overlap with http.frame_parsed for the HeadersFrame type. When outputting both events, implementers MAY omit the "headers" field in this event. Definition:

QPACKHeadersDecoded definition

instruction_created Importance: Base This event is emitted when a QPACK instruction (both decoder and encoder) is created and added to the encoder/decoder stream. Definition:

QPACKInstructionCreated definition

Encoder/decoder semantics and stream_id's are implicit in either the instruction types or can be logged via other events (e.g., http.stream_type_set)

instruction_parsed Importance: Base This event is emitted when a QPACK instruction (both decoder and encoder) is read from the encoder/decoder stream. Definition:

QPACKInstructionParsed definition

Encoder/decoder semantics and stream_id's are implicit in either the instruction types or can be logged via other events (e.g., http.stream_type_set)

QPACK Data Field Definitions The following data field definitions can be used in QPACK events.

QPACKInstruction The instructions do not have explicit encoder/decoder types, since there is no overlap between the instructions of both types in neither name nor function.

QPACKInstruction definition

SetDynamicTableCapacityInstruction

SetDynamicTableCapacityInstruction definition

InsertWithNameReferenceInstruction

InsertWithNameReferenceInstruction definition

InsertWithoutNameReferenceInstruction

InsertWithoutNameReferenceInstruction definition

DuplicateInstruction

DuplicateInstruction definition

SectionAcknowledgementInstruction

SectionAcknowledgementInstruction definition

StreamCancellationInstruction

StreamCancellationInstruction definition

InsertCountIncrementInstruction

InsertCountIncrementInstruction definition

QPACKHeaderBlockRepresentation

QPACKHeaderBlockRepresentation definition

IndexedHeaderField This is also used for "indexed header field with post-base index"

IndexedHeaderField definition

LiteralHeaderFieldWithName This is also used for "Literal header field with post-base name reference".

LiteralHeaderFieldWithName definition

LiteralHeaderFieldWithoutName

LiteralHeaderFieldWithoutName definition

QPACKHeaderBlockPrefix

QPACKHeaderBlockPrefix definition

QPACKTableType

QPACKTableType definition

Security and Privacy Considerations The security and privacy considerations discussed in apply to this document as well.

IANA Considerations TBD

References Normative References The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. Akamai Meta Protocol Labs Cloudflare This document describes a high-level schema for a standardized logging format called qlog. This format allows easy sharing of data and the creation of reusable visualization and debugging tools. The high-level schema in this document is intended to be protocol- agnostic. Separate documents specify how the format should be used for specific protocol data. The schema is also format-agnostic, and can be represented in for example JSON, csv or protobuf. Akamai Meta Protocol Labs Cloudflare This document describes concrete qlog event definitions and their metadata for QUIC events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. Informative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.

Change Log

Since draft-ietf-quic-qlog-h3-events-04:

• Renamed 'http' category to 'h3' (#300)
• H3HTTPField.value is now optional (#296)
• Added definitions for RFC9297 (HTTP/3 Datagram extension) (#310)
• Added definitions for RFC9218 (HTTP Extensible Prioritizations extension) (#312)
• Added definitions for RFC9220 (Extended Connect extension) (#325)
• Editorial and formatting changes (#298, #258, #299, #304, #327)

Since draft-ietf-quic-qlog-h3-events-03:

• Ensured consistent use of RawInfo to indicate raw wire bytes (#243)
• Changed HTTPStreamTypeSet:raw_stream_type to stream_type_value (#54)
• Changed HTTPUnknownFrame:raw_frame_type to frame_type_value (#54)
• Renamed max_header_list_size to max_field_section_size (#282)

Since draft-ietf-quic-qlog-h3-events-02:

• Renamed HTTPStreamType data to request (#222)
• Added HTTPStreamType value unknown (#227)
• Added HTTPUnknownFrame (#224)
• Replaced old and new fields with stream_type in HTTPStreamTypeSet (#240)
• Changed HTTPFrame to a CDDL plug type (#257)
• Moved data definitions out of the appendix into separate sections
• Added overview Table of Contents

Since draft-ietf-quic-qlog-h3-events-01:

• No changes - new draft to prevent expiration

Since draft-ietf-quic-qlog-h3-events-00:

• Change the data definition language from TypeScript to CDDL (#143)

Since draft-marx-qlog-event-definitions-quic-h3-02:

• These changes were done in preparation of the adoption of the drafts by the QUIC working group (#137)
• Split QUIC and HTTP/3 events into two separate documents
• Moved RawInfo, Importance, Generic events and Simulation events to the main schema document.

Since draft-marx-qlog-event-definitions-quic-h3-01: Major changes:

• Moved data_moved from http to transport. Also made the "from" and "to" fields flexible strings instead of an enum (#111,#65)
• Moved packet_type fields to PacketHeader. Moved packet_size field out of PacketHeader to RawInfo:length (#40)
• Made events that need to log packet_type and packet_number use a header field instead of logging these fields individually
• Added support for logging retry, stateless reset and initial tokens (#94,#86,#117)
• Moved separate general event categories into a single category "generic" (#47)
• Added "transport:connection_closed" event (#43,#85,#78,#49)
• Added version_information and alpn_information events (#85,#75,#28)
• Added parameters_restored events to help clarify 0-RTT behaviour (#88)

Smaller changes:

• Merged loss_timer events into one loss_timer_updated event
• Field data types are now strongly defined (#10,#39,#36,#115)
• Renamed qpack instruction_received and instruction_sent to instruction_created and instruction_parsed (#114)
• Updated qpack:dynamic_table_updated.update_type. It now has the value "inserted" instead of "added" (#113)
• Updated qpack:dynamic_table_updated. It now has an "owner" field to differentiate encoder vs decoder state (#112)
• Removed push_allowed from http:parameters_set (#110)
• Removed explicit trigger field indications from events, since this was moved to be a generic property of the "data" field (#80)
• Updated transport:connection_id_updated to be more in line with other similar events. Also dropped importance from Core to Base (#45)
• Added length property to PaddingFrame (#34)
• Added packet_number field to transport:frames_processed (#74)
• Added a way to generically log packet header flags (first 8 bits) to PacketHeader
• Added additional guidance on which events to log in which situations (#53)
• Added "simulation:scenario" event to help indicate simulation details
• Added "packets_acked" event (#107)
• Added "datagram_ids" to the datagram_X and packet_X events to allow tracking of coalesced QUIC packets (#91)
• Extended connection_state_updated with more fine-grained states (#49)

Since draft-marx-qlog-event-definitions-quic-h3-00:

• Event and category names are now all lowercase
• Added many new events and their definitions
• "type" fields have been made more specific (especially important for PacketType fields, which are now called packet_type instead of type)
• Events are given an importance indicator (issue #22)
• Event names are more consistent and use past tense (issue #21)
• Triggers have been redefined as properties of the "data" field and updated for most events (issue #23)

Acknowledgements Much of the initial work by Robin Marx was done at the Hasselt and KU Leuven Universities. Thanks to Jana Iyengar, Brian Trammell, Dmitri Tikhonov, Stephen Petrides, Jari Arkko, Marcus Ihlar, Victor Vasiliev, Mirja Kuehlewind, Jeremy Laine, Kazu Yamamoto, and Christian Huitema for their feedback and suggestions.