Internet-Draft | HTTP/3 and QPACK qlog event definitions | October 2022 |
Marx, et al. | Expires 27 April 2023 | [Page] |
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 [QLOG-MAIN].¶
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 27 April 2023.¶
Copyright (c) 2022 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.¶
This document describes the values of the qlog name ("category" + "event") and "data" fields and their semantics for HTTP/3 [HTTP/3] and QPACK [QPACK].¶
Note to RFC editor: Please remove the follow paragraphs in 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/.¶
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.¶
The event and data structure definitions in ths document are expressed in the Concise Data Definition Language [CDDL] and its extensions described in [QLOG-MAIN].¶
The following fields from [QLOG-MAIN] are imported and used: name, category, type, data, group_id, protocol_type, importance, RawInfo, and time-related fields.¶
This document describes how the HTTP/3 and QPACK can be expressed in qlog using the schema defined in [QLOG-MAIN]. 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".¶
The events described in this document can be used with or without logging the related QUIC events defined in [QLOG-QUIC]. 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).¶
This document re-uses the definition of the RawInfo data class from [QLOG-MAIN].¶
As HTTP/3 does not use trailers in frames, each HTTP/3 frame header_length can be calculated as header_length = RawInfo:length - RawInfo:payload_length¶
In some cases, the length fields are also explicitly reflected inside of frame headers. For example, all HTTP/3 frames include their explicit payload lengths in the frame header. In these cases, those fields are intentionally preserved in the event definitions. Even though this can lead to duplicate data when the full RawInfo is logged, it allows a more direct mapping of the HTTP/3 specifications to qlog, making it easier for users to interpret. In this case, both fields MUST have the same value.¶
This document defines events in two categories, written as lowercase to follow convention: http (Section 4) and qpack (Section 6).¶
As described in Section 3.4.2 of [QLOG-MAIN], the qlog "name" field is the concatenation of category and type.¶
Table 1 summarizes the name value of each event type that is defined in this specification.¶
Name value | Importance | Definition |
---|---|---|
http:parameters_set | Base | Section 4.1 |
http:parameters_restored | Base | Section 4.2 |
http:stream_type_set | Base | Section 4.3 |
http:frame_created | Core | Section 4.4 |
http:frame_parsed | Core | Section 4.5 |
http:push_resolved | Extra | Section 4.6 |
qpack:state_updated | Base | Section 6.1 |
qpack:stream_state_updated | Core | Section 6.2 |
qpack:dynamic_table_updated | Extra | Section 6.3 |
qpack:headers_encoded | Base | Section 6.4 |
qpack:headers_decoded | Base | Section 6.5 |
qpack:instruction_created | Base | Section 6.6 |
qpack:instruction_parsed | Base | Section 6.7 |
HTTP/3 events extend the $ProtocolEventBody
extension point defined in [QLOG-MAIN].¶
HTTPEvents = HTTPParametersSet / HTTPParametersRestored / HTTPStreamTypeSet / HTTPFrameCreated / HTTPFrameParsed / HTTPPushResolved $ProtocolEventBody /= HTTPEvents
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.¶
Note that some settings 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 settings included a single event instance. If you need to log settings from two sides, you MUST emit two separate event instances.¶
Note: we use the CDDL unwrap operator (~) here to make HTTPParameters into a re-usable list of fields. The unwrap operator copies the fields from the referenced type into the target type directly, extending the target with the unwrapped fields. TODO: explain this better + provide reference and maybe an example.¶
Definition:¶
HTTPParametersSet = { ? owner: Owner ~HTTPParameters ; qlog-specific ; indicates whether this implementation waits for a SETTINGS ; frame before processing requests ? waits_for_settings: bool } HTTPParameters = { ? max_header_list_size: uint64 ? max_table_capacity: uint64 ? blocked_streams_count: uint64 ; additional settings for grease and extensions * text => uint64 }
Note: enabling server push is not explicitly done in HTTP/3 by use of a setting or parameter. Instead, it is communicated by use of the MAX_PUSH_ID frame, which should be logged using the frame_created and frame_parsed events below.¶
Additionally, this event can contain any number of unspecified fields. This is to reflect setting of for example unknown (greased) settings or parameters of (proprietary) extensions.¶
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:¶
HTTPParametersRestored = { ~HTTPParameters }
Note that, like for parameters_set above, this event can contain any number of unspecified fields to allow for additional and custom settings.¶
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.¶
Note: most of this information can also be inferred by looking at a stream's id, since id's are strictly partitioned at the QUIC level. Even so, this event has a "Base" importance because it helps a lot in debugging to have this information clearly spelled out.¶
Definition:¶
HTTPStreamTypeSet = { ? owner: Owner stream_id: uint64 stream_type: HTTPStreamType ; only when stream_type === "unknown" ? raw_stream_type: uint64 ; only when stream_type === "push" ? associated_push_id: uint64 } HTTPStreamType = "request" / "control" / "push" / "reserved" / "unknown" / "qpack_encode" / "qpack_decode"
Importance: Core¶
HTTP equivalent to the packet_sent event. This event is emitted when the HTTP/3 framing actually happens. Note: this is not necessarily the same as when the HTTP/3 data is passed on to the QUIC layer. For that, see the "data_moved" event in [QLOG-QUIC].¶
Definition:¶
HTTPFrameCreated = { stream_id: uint64 ? length: uint64 frame: $HTTPFrame ? raw: RawInfo }
Note: in HTTP/3, DATA frames can have arbitrarily large lengths to reduce frame header overhead. As such, DATA frames can span many QUIC packets and can be created in a streaming fashion. In this case, the frame_created event is emitted once for the frame header, and further streamed data is indicated using the data_moved event.¶
Importance: Core¶
HTTP equivalent to the packet_received event. This event is emitted when we actually parse the HTTP/3 frame. Note: this is not necessarily the same as when the HTTP/3 data is actually received on the QUIC layer. For that, see the "data_moved" event in [QLOG-QUIC].¶
Definition:¶
HTTPFrameParsed = { stream_id: uint64 ? length: uint64 frame: $HTTPFrame ? raw: RawInfo }
Note: in HTTP/3, DATA frames can have arbitrarily large lengths to reduce frame header overhead. As such, DATA frames can span many QUIC packets and can be processed in a streaming fashion. In this case, the frame_parsed event is emitted once for the frame header, and further streamed data is indicated using the data_moved event.¶
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:¶
HTTPPushResolved = { ? push_id: uint64 ; in case this is logged from a place that does not have access ; to the push_id ? stream_id: uint64 decision: HTTPPushDecision } HTTPPushDecision = "claimed" / "abandoned"
The following data field definitions can be used in HTTP/3 events.¶
Owner = "local" / "remote"
The generic $HTTPFrame
is defined here as a CDDL extension point (a "socket"
or "plug"). It can be extended to support additional HTTP/3 frame types.¶
; The HTTPFrame is any key-value map (e.g., JSON object) $HTTPFrame /= { * text => any }
The HTTP/3 frame types defined in this document are as follows:¶
HTTPBaseFrames = HTTPDataFrame / HTTPHeadersFrame / HTTPCancelPushFrame / HTTPSettingsFrame / HTTPPushPromiseFrame / HTTPGoawayFrame / HTTPMaxPushIDFrame / HTTPReservedFrame / HTTPUnknownFrame $HTTPFrame /= HTTPBaseFrames
HTTPDataFrame = { frame_type: "data" ? raw: hexstring }
This represents an uncompressed, plaintext HTTP Headers frame (e.g., no QPACK compression is applied).¶
For example:¶
headers: [ { "name": ":path", "value": "/" }, { "name": ":method", "value": "GET" }, { "name": ":authority", "value": "127.0.0.1:4433" }, { "name": ":scheme", "value": "https" } ]
HTTPHeadersFrame = { frame_type: "headers" headers: [* HTTPField] }
HTTPField = { name: text value: text }
HTTPCancelPushFrame = { frame_type: "cancel_push" push_id: uint64 }
HTTPSettingsFrame = { frame_type: "settings" settings: [* HTTPSetting] } HTTPSetting = { name: text value: uint64 }
HTTPPushPromiseFrame = { frame_type: "push_promise" push_id: uint64 headers: [* HTTPField] }
HTTPGoawayFrame = { frame_type: "goaway" ; Either stream_id or push_id. ; This is implicit from the sender of the frame id: uint64 }
HTTPMaxPushIDFrame = { frame_type: "max_push_id" push_id: uint64 }
HTTPReservedFrame = { frame_type: "reserved" ? length: uint64 }
HTTPUnknownFrame = { frame_type: "unknown" raw_frame_type: uint64 ? raw_length: uint32 ? raw: hexstring }
HTTPApplicationError = "http_no_error" / "http_general_protocol_error" / "http_internal_error" / "http_stream_creation_error" / "http_closed_critical_stream" / "http_frame_unexpected" / "http_frame_error" / "http_excessive_load" / "http_id_error" / "http_settings_error" / "http_missing_settings" / "http_request_rejected" / "http_request_cancelled" / "http_request_incomplete" / "http_early_response" / "http_connect_error" / "http_version_fallback"
The HTTPApplicationError defines the general $ApplicationError definition in the qlog QUIC definition, see [QLOG-QUIC].¶
; ensure HTTP errors are properly validate in QUIC events as well ; e.g., QUIC's ConnectionClose Frame $ApplicationError /= HTTPApplicationError¶
QPACK events extend the $ProtocolEventBody
extension point defined in
[QLOG-MAIN].¶
QPACKEvents = QPACKStateUpdate / QPACKStreamStateUpdate / QPACKDynamicTableUpdate / QPACKHeadersEncoded / QPACKHeadersDecoded / QPACKInstructionCreated / QPACKInstructionParsed $ProtocolEventBody /= QPACKEvents
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).¶
Note: 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.¶
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 = { owner: Owner ? dynamic_table_capacity: uint64 ; effective current size, sum of all the entries ? dynamic_table_size: uint64 ? known_received_count: uint64 ? current_insert_count: uint64 }
Importance: Core¶
This event is emitted when a stream becomes blocked or unblocked by header decoding requests or QPACK instructions.¶
Note: This event is of "Core" importance, as it might have a large impact on HTTP/3's observed performance.¶
Definition:¶
QPACKStreamStateUpdate = { stream_id: uint64 ; streams are assumed to start "unblocked" ; until they become "blocked" state: QPACKStreamState } QPACKStreamState = "blocked" / "unblocked"
Importance: Extra¶
This event is emitted when one or more entries are inserted or evicted from QPACK's dynamic table.¶
Definition:¶
QPACKDynamicTableUpdate = { ; local = the encoder's dynamic table ; remote = the decoder's dynamic table owner: Owner update_type: QPACKDynamicTableUpdateType entries: [+ QPACKDynamicTableEntry] } QPACKDynamicTableUpdateType = "inserted" / "evicted" QPACKDynamicTableEntry = { index: uint64 ? name: text / hexstring ? value: text / hexstring }
Importance: Base¶
This event is emitted when an uncompressed header block is encoded successfully.¶
Note: 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 = { ? stream_id: uint64 ? headers: [+ HTTPField] block_prefix: QPACKHeaderBlockPrefix header_block: [+ QPACKHeaderBlockRepresentation] ? length: uint ? raw: hexstring }
Importance: Base¶
This event is emitted when a compressed header block is decoded successfully.¶
Note: 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 = { ? stream_id: uint64 ? headers: [+ HTTPField] block_prefix: QPACKHeaderBlockPrefix header_block: [+ QPACKHeaderBlockRepresentation] ? length: uint32 ? raw: hexstring }
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 = { ; see definition in appendix instruction: QPACKInstruction ? length: uint32 ? raw: hexstring }
Note: 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)¶
Importance: Base¶
This event is emitted when a QPACK instruction (both decoder and encoder) is read from the encoder/decoder stream.¶
Definition:¶
QPACKInstructionParsed = { ; see QPACKInstruction definition in appendix instruction: QPACKInstruction ? length: uint32 ? raw: hexstring }
Note: 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)¶
The following data field definitions can be used in QPACK events.¶
Note: 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 = SetDynamicTableCapacityInstruction / InsertWithNameReferenceInstruction / InsertWithoutNameReferenceInstruction / DuplicateInstruction / SectionAcknowledgementInstruction / StreamCancellationInstruction / InsertCountIncrementInstruction
SetDynamicTableCapacityInstruction = { instruction_type: "set_dynamic_table_capacity" capacity: uint32 }
InsertWithNameReferenceInstruction = { instruction_type: "insert_with_name_reference" table_type: QPACKTableType name_index: uint32 huffman_encoded_value: bool ? value_length: uint32 ? value: text }
InsertWithoutNameReferenceInstruction = { instruction_type: "insert_without_name_reference" huffman_encoded_name: bool ? name_length: uint32 ? name: text huffman_encoded_value: bool ? value_length: uint32 ? value: text }
DuplicateInstruction = { instruction_type: "duplicate" index: uint32 }
SectionAcknowledgementInstruction = { instruction_type: "section_acknowledgement" stream_id: uint64 }
StreamCancellationInstruction = { instruction_type: "stream_cancellation" stream_id: uint64 }
InsertCountIncrementInstruction = { instruction_type: "insert_count_increment" increment: uint32 }
QPACKHeaderBlockRepresentation = IndexedHeaderField / LiteralHeaderFieldWithName / LiteralHeaderFieldWithoutName
Note: also used for "indexed header field with post-base index"¶
IndexedHeaderField = { header_field_type: "indexed_header" ; MUST be "dynamic" if is_post_base is true table_type: QPACKTableType index: uint32 ; to represent the "indexed header field with post-base index" ; header field type is_post_base: bool .default false }
Note: also used for "Literal header field with post-base name reference"¶
LiteralHeaderFieldWithName = { header_field_type: "literal_with_name" ; the 3rd "N" bit preserve_literal: bool ; MUST be "dynamic" if is_post_base is true table_type: QPACKTableType name_index: uint32 huffman_encoded_value: bool ? value_length: uint32 ? value: text ; to represent the "indexed header field with post-base index" ; header field type is_post_base: bool .default false }
LiteralHeaderFieldWithoutName = { header_field_type: "literal_without_name" ; the 3rd "N" bit preserve_literal: bool huffman_encoded_name: bool ? name_length: uint32 ? name: text huffman_encoded_value: bool ? value_length: uint32 ? value: text }
QPACKHeaderBlockPrefix = { required_insert_count: uint32 sign_bit: bool delta_base: uint32 }
QPACKTableType = "static" / "dynamic"
The security and privacy considerations discussed in [QLOG-MAIN] apply to this document as well.¶
Major changes:¶
Smaller changes:¶
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.¶