diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 599939cdbf..e5a45646b0 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -38,11 +38,11 @@ normative: org: Mozilla role: editor - QCRAM: - title: "Header Compression for HTTP over QUIC" + QPACK: + title: "QPACK: Header Compression for HTTP over QUIC" date: {DATE} seriesinfo: - Internet-Draft: draft-ietf-quic-qcram-latest + Internet-Draft: draft-ietf-quic-qpack-latest author: - ins: C. Krasic @@ -344,7 +344,7 @@ abort a response in progress as a result of receiving a solicited RST_STREAM. ### Header Compression -HTTP/QUIC uses QCRAM header compression as described in [QCRAM], a variation of +HTTP/QUIC uses QPACK header compression as described in [QPACK], a variation of HPACK which allows the flexibility to avoid header-compression-induced head-of-line blocking. See that document for additional details. @@ -554,7 +554,7 @@ with a payload length of zero, the recipient MUST respond with a stream error ### HEADERS {#frame-headers} The HEADERS frame (type=0x1) is used to carry a header block, compressed using -QCRAM. See [QCRAM] for more details. +QPACK. See [QPACK] for more details. The HEADERS frame defines a single flag: @@ -844,7 +844,7 @@ Push ID: ({{frame-cancel-push}}), and PRIORITY frames ({{frame-priority}}). Header Block: -: QCRAM-compressed request headers for the promised response. See [QCRAM] for +: QPACK-compressed request headers for the promised response. See [QPACK] for more details. A server MUST NOT use a Push ID that is larger than the client has provided in a @@ -976,16 +976,16 @@ HTTP_NO_ERROR code. ### HEADER_ACK {#frame-header-ack} The HEADER_ACK frame (type=0x8) is used by header compression to ensure -consistency. The frames are sent from the QCRAM decoder to the QCRAM encoder; +consistency. The frames are sent from the QPACK decoder to the QPACK encoder; that is, the server sends them to the client to acknowledge processing of the client's header blocks, and the client sends them to the server to acknowledge processing of the server's header blocks. -The HEADER_ACK frame is sent on the Control Stream when the QCRAM decoder has -fully processed a header block. It is used by the peer's QCRAM encoder to +The HEADER_ACK frame is sent on the Control Stream when the QPACK decoder has +fully processed a header block. It is used by the peer's QPACK encoder to determine whether subsequent indexed representations that might reference that block are vulnerable to head-of-line blocking, and to prevent eviction races. -See [QCRAM] for more details on the use of this information. +See [QPACK] for more details on the use of this information. The HEADER_ACK frame indicates the stream on which the header block was processed by encoding the Stream ID as a variable-length integer. The same @@ -1190,7 +1190,7 @@ Likewise, HPACK was designed with the assumption of in-order delivery. A sequence of encoded header blocks must arrive (and be decoded) at an endpoint in the same order in which they were encoded. This ensures that the dynamic state at the two endpoints remains in sync. As a result, HTTP/QUIC uses a modified -version of HPACK, described in [QCRAM]. +version of HPACK, described in [QPACK]. Frame type definitions in HTTP/QUIC often use the QUIC variable-length integer encoding. In particular, Stream IDs use this encoding, which allow for a larger diff --git a/draft-ietf-quic-qcram.md b/draft-ietf-quic-qpack.md similarity index 94% rename from draft-ietf-quic-qcram.md rename to draft-ietf-quic-qpack.md index 99dbdda347..59c82bd6d7 100644 --- a/draft-ietf-quic-qcram.md +++ b/draft-ietf-quic-qpack.md @@ -1,7 +1,7 @@ --- -title: Header Compression for HTTP over QUIC -abbrev: QCRAM -docname: draft-ietf-quic-qcram-latest +title: "QPACK: Header Compression for HTTP over QUIC" +abbrev: QPACK +docname: draft-ietf-quic-qpack-latest date: {DATE} category: std ipr: trust200902 @@ -32,7 +32,7 @@ author: --- abstract -This specification defines QCRAM, a compression format for efficiently +This specification defines QPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP over QUIC. This is a variation of HPACK header compression that seeks to reduce head-of-line blocking. @@ -45,7 +45,7 @@ Discussion of this draft takes place on the QUIC working group mailing list Working Group information can be found at ; source code and issues list for this draft can be found at -. +. --- middle @@ -70,13 +70,13 @@ mapping is described in {{!QUIC-HTTP=I-D.ietf-quic-http}}. For a full description of HTTP/2, see {{?RFC7540}}. The description of HPACK is {{!RFC7541}}, with important terminology in Section 1.3. -QCRAM modifies HPACK to allow correctness in the presence of out-of-order +QPACK modifies HPACK to allow correctness in the presence of out-of-order delivery, with flexibility for implementations to balance between resilience against HoL blocking and optimal compression ratio. The design goals are to closely approach the compression ratio of HPACK with substantially less head-of-line blocking under the same loss conditions. -QCRAM is intended to be a relatively non-intrusive extension to HPACK; an +QPACK is intended to be a relatively non-intrusive extension to HPACK; an implementation should be easily shared within stacks supporting both HTTP/2 over (TLS+)TCP and HTTP/QUIC. @@ -188,7 +188,7 @@ change (implicitly). Implicit index updates are acceptable for HTTP/2 because TCP is totally ordered, but are problematic in the out-of-order context of QUIC. -QCRAM uses a hybrid absolute-relative indexing approach. +QPACK uses a hybrid absolute-relative indexing approach. When the encoder adds a new entry to its header table, it can compute an absolute index: @@ -209,7 +209,7 @@ indices: Header blocks on request and push streams do not modify the dynamic table state, so they never change the `baseIndex`. However, since ordering between streams is not guaranteed, the value of `baseIndex` can not be synchronized implicitly. -Instead then, QCRAM sends encoder's `Base Index` explicitly as part of the +Instead then, QPACK sends encoder's `Base Index` explicitly as part of the prefix (see {{absolute-index}}), so that the decoder can compute the same absolute indices that the encoder used: @@ -225,9 +225,9 @@ with the `HTTP_HPACK_DECOMPRESSION_FAILED` error code. ## Preventing Eviction Races {#evictions} -Due to out-of-order arrival, QCRAM's eviction algorithm requires changes +Due to out-of-order arrival, QPACK's eviction algorithm requires changes (relative to HPACK) to avoid the possibility that an indexed representation is -decoded after the referenced entry has already been evicted. QCRAM employs a +decoded after the referenced entry has already been evicted. QPACK employs a two-phase eviction algorithm, in which the encoder will not evict entries that have outstanding (unacknowledged) references. @@ -291,7 +291,7 @@ space efficient. ### Safe evictions -Section {{evictions}} describes how QCRAM avoids invalid references that might +Section {{evictions}} describes how QPACK avoids invalid references that might result from out-of-order delivery. When the encoder processes a HEADER_ACK, it dereferences table entries that were indexed in the acknowledged header. To track which entries must be dereferenced, it can maintain a map from @@ -326,9 +326,9 @@ the number of concurrently blocked streams. ### Fixed overhead. HPACK defines overhead as 32 bytes ({{!RFC7541}}, Section 4.1). As described -above, QCRAM adds some per-connection state, and possibly some per-entry state +above, QPACK adds some per-connection state, and possibly some per-entry state to track acknowledgment status and eviction reference count. A larger value -than 32 might be more accurate for QCRAM. +than 32 might be more accurate for QPACK. # Security Considerations