]> Akamai

rmarx@akamai.com

Meta

lniccolini@meta.com

martenseemann@gmail.com

Cloudflare

lucas@lucaspardue.com

Transport QUIC Internet-Draft This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions. 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 defines a qlog event schema () containing concrete events for the core HTTP/3 protocol and selected extensions (, , and ). The event namespace with identifier http3 is defined; see . In this namespace multiple events derive from the qlog abstract Event class (), each extending the "data" field and defining their "name" field values and semantics. summarizes the name value of each event type that is defined in this specification. Some event data fields use complex data types. These are represented as enums or re-usable definitions, which are grouped together on the bottom of this document for clarity. HTTP/3 Events

Name value	Importance	Definition
http3:parameters_set	Base
http3:parameters_restored	Base
http3:stream_type_set	Base
http3:priority_updated	Base
http3:frame_created	Core
http3:frame_parsed	Core
http3:datagram_created	Base
http3:datagram_parsed	Base
http3:push_resolved	Extra

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

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, namespace, type, data, group_id, importance, RawInfo, and time-related fields. As is the case for , the qlog schema definitions in this document are intentionally agnostic to serialization formats. The choice of format is an implementation decision.

Event Schema Definition This document describes how the core HTTP/3 protocol and selected extensions can be expressed in qlog using a newly defined event schema. Per the requirements in , this document registers the http3 namespace. The event schema URI is urn:ietf:params:qlog:events:http3.

Draft Event Schema Identification Only implementations of the final, published RFC can use the events belonging to the event schema with the URI urn:ietf:params:qlog:events:http3. Until such an RFC exists, implementations MUST NOT identify themselves using this URI. Implementations of draft versions of the event schema MUST append the string "-" and the corresponding draft number to the URI. For example, draft 07 of this document is identified using the URI urn:ietf:params:qlog:events:http3-07. The namespace identifier itself is not affected by this requirement.

HTTP/3 Events HTTP/3 events extend the $ProtocolEventData extension point defined in . Additionally, they allow for direct extensibility by their use of per-event extension points via the $$ CDDL "group socket" syntax, as also described in .

HTTP3EventData definition and ProtocolEventData 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 . HTTP/3 frames are transmitted on QUIC streams, which allows them to span multiple QUIC packets. Some implementations might send a single large frame, rather than a sequence of smaller frames, in order to amortize frame header overhead. HTTP/3 frame headers are represented by the frame_created () and frame_parsed () events. Subsequent frame payload data transfer is indicated by stream_data_moved events. Furthermore, stream_data_moved events can appear before frame_parsed events because implementations need to read data from a stream in order to parse the frame header. The concrete HTTP/3 event types are further defined below, their type identifier is the heading name.

parameters_set The parameters_set event contains HTTP/3 and QPACK-level settings, mostly those received from the HTTP/3 SETTINGS frame. It has Base importance level; see . All these parameters are typically set once and never change. However, they might be set at different times during the connection, therefore a qlog can have multiple instances of parameters_set 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".

HTTP3ParametersSet definition

The parameters_set 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 When using QUIC 0-RTT, HTTP/3 clients are expected to remember and reuse the server's SETTINGs from the previous connection. The parameters_restored event is used to indicate which HTTP/3 settings were restored and to which values when utilizing 0-RTT. It has Base importance level; see .

HTTP3ParametersRestored definition

stream_type_set The stream_type_set event conveys when a HTTP/3 stream type becomes known; see Sections and of . It has Base importance level; see . Client bidirectional streams always have a stream_type value of "request". Server bidirectional streams have no defined use, although extensions could change that. Unidirectional streams in either direction begin with with a variable-length integer type. Where the type is not known, the stream_type value of "unknown" type can be used and the value captured in the stream_type_bytes field; a numerical value without variable-length integer encoding. The generic $HTTP3StreamType is defined here as a CDDL "type socket" extension point. It can be extended to support additional HTTP/3 stream types.

HTTP3StreamTypeSet definition

priority_updated The priority_updated event is emitted when the priority of a request stream or push stream is initialized or updated through mechanisms defined in . It has Base importance level; see . There can be several reasons why a priority_updated occurs, and why a particular value was chosen. 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. The trigger and reason fields can be used to optionally capture such details.

HTTP3PriorityUpdated definition

frame_created The frame_created event is emitted when the HTTP/3 framing actually happens. It has Core importance level; see . This event does not necessarily coincide with HTTP/3 data getting passed to the QUIC layer. For that, see the stream_data_moved event in .

HTTP3FrameCreated definition

frame_parsed The frame_parsed event is emitted when the HTTP/3 frame is parsed. It has Core importance level; see . This event 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 .

HTTP3FrameParsed definition

datagram_created The datagram_created event is emitted when an HTTP/3 Datagram is created (see ). It has Base importance level; see . This event does not necessarily coincide with the HTTP/3 Datagram getting passed to the QUIC layer. For that, see the datagram_data_moved event in .

HTTP3DatagramCreated definition

datagram_parsed The datagram_parsed event is emitted when the HTTP/3 Datagram is parsed (see ). It has Base importance level; see . This event 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 .

HTTP3DatagramParsed definition

push_resolved The push_resolved 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 provides additional context that can is aid debugging issues related to server push. It has Extra importance level; see .

HTTP3PushResolved definition

HTTP/3 Data Type Definitions The following data type definitions can be used in HTTP/3 events.

Owner

Owner definition

HTTP3Frame The generic $HTTP3Frame is defined here as a CDDL "type socket" extension point. It can be extended to support additional HTTP/3 frame types.

HTTP3Frame type socket definition any } ]]>

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

HTTP3BaseFrames definition

HTTP3Datagram The generic $HTTP3Datagram is defined here as a CDDL "type socket" extension point. It can be extended to support additional HTTP/3 datagram types. This document intentionally does not define any specific qlog schemas for specific HTTP/3 Datagram types.

HTTP3Datagram type socket definition any } ]]>

HTTP3DataFrame

HTTP3DataFrame definition

HTTP3HeadersFrame The payload of an HTTP/3 HEADERS frame is the QPACK-encoding of an HTTP field section; see . HTTP3HeaderFrame, in contrast, contains the HTTP field section without QPACK encoding.

HTTP3HTTPField definition

HTTP3HeadersFrame definition

For example, the HTTP field section would be represented in a JSON serialization as:

HTTP3HeadersFrame example

and define rules for the characters used in HTTP field sections names and values. Characters outside the range are invalid and result in the message being treated as malformed. It can however be useful to also log these invalid HTTP fields. Characters in the allowed range can be safely logged by the text type used in the name and value fields of HTTP3HTTPField. Characters outside the range are unsafe for the text type and need to be logged using the name_bytes and value_bytes field. An instance of HTTP3HTTPField MUST include either the name or name_bytes field and MAY include both. An HTTP3HTTPField MAY include a value or value_bytes field or neither.

HTTP3CancelPushFrame

HTTP3CancelPushFrame definition

HTTP3SettingsFrame The settings field can contain zero or more entries. Each setting has a name field, which corresponds to Setting Name as defined (or as would be defined if registered) in the "HTTP/3 Settings" registry maintained at https://www.iana.org/assignments/http3-parameters. An endpoint that receives unknown settings is not able to log a specific name. Instead, the name value of "unknown" can be used and the value captured in the name_bytes field; a numerical value without variable-length integer encoding.

HTTP3SettingsFrame definition

HTTP3PushPromiseFrame

HTTP3PushPromiseFrame definition

HTTP3GoAwayFrame

HTTP3GoawayFrame definition

HTTP3MaxPushIDFrame

HTTP3MaxPushIDFrame definition

HTTP3PriorityUpdateFrame The PRIORITY_UPDATE frame is defined in .

HTTP3PriorityUpdateFrame definition

HTTP3ReservedFrame The frame_type_bytes field is the numerical value without variable-length integer encoding.

HTTP3ReservedFrame definition

HTTP3UnknownFrame The frame_type_bytes field is the numerical value without variable-length integer encoding.

HTTP3UnknownFrame definition

HTTP3ApplicationError

HTTP3ApplicationError definition

The HTTP3ApplicationError extends the general $ApplicationError definition in the qlog QUIC document, see .

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

IANA Considerations This document registers a new entry in the "qlog event schema URIs" registry.

Event schema URI:

urn:ietf:params:qlog:events:http3

Namespace

http3

Event Types

parameters_set,parameters_restored,stream_type_set,priority_updated,frame_created,frame_parsed,datagram_created,datagram_parsed,push_resolved

Description:

Event definitions related to the HTTP/3 application protocol.

Reference:

This Document

Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 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 Cloudflare qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (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/ (https://github.com/quiclog/qlog/). Akamai Meta Cloudflare This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (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/ (https://github.com/quiclog/qlog/). 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.

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, Christian Huitema, Hugo Landau and Jonathan Lennox for their feedback and suggestions.

Change Log

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

• Several editorial changes
• Consistent use of RawInfo and _bytes fields to log raw data (#450)

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

• Removed individual categories and put every event in the single http3 event schema namespace. Major change (#439)
• Changed protocol id from HTTP3 to HTTP/3 (#428)

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

• TODO (we forgot...)

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

• ProtocolEventBody is now called ProtocolEventData (#352)
• Editorial changes (#402)

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

• Removed all qpack event definitions (#335)
• Various editorial changes

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)