QPACK: Field Compression for HTTP/3
draft-ietf-quic-qpack-21

[Ballot comment]
Thank you for this well written document, like Eric I found it interesting to read.

A few non blocking comments:

I didn't read the draft in complete detail, but I'm not sure that I came away with a good understanding of what the receiver data structure would actually look like in an implementation.  The first paragraph in section 3.2 suggests that this would be a list of field lines in FIFO order, but I would assume that a more performant representation would likely be used.  I appreciate that this is really an implementation detail, but possibly the introduction in section 3.2 might benefit with text giving a bit more overview of what the data structure is expected to look like.

A couple of places in the document have pseudo code, which I presume is written in Python.  Possibly, it might be helpful to readers to indicate that the pseudo code follows a Python style syntax, although it is pretty intuitive regardless.

Section 7.4 talks about implementation limits, but it wasn't obvious to me how a receiver is expected to behave if one of those limits is exceeded.  Further in the case of strings, there seems to be a simple upper bound on the maximum size of the string of the table size.

I note that the algorithm uses a static table.  Is there any consideration to be able to update or evolve that static table over time?  E.g., perhaps in 10 years time, the traffic will have changed sufficiently enough that a new version of the static table should be generated.

[Ballot comment]
Kudos on all the hard work that clearly went into this.  Makes our job easy, and this was also very educational.

Some minor suggestions:

In Section 2.1.3, I suggest "SHOULD avoid writing" ought to be "SHOULD NOT write". (For that matter, I don't know why this isn't a MUST NOT.)

In Section 2.2.1:

  While blocked, encoded field section data SHOULD remain in the
  blocked stream's flow control window.

Since SHOULD grants me a choice, why might I decide not to do what it says here?  Or should this be MUST?

[Ballot comment]
Thanks for another well-written document!

I put up some editorial suggestions at https://github.com/quicwg/base-drafts/pull/4789

Section 2.1.1.1

Figure 1 might benefit from an explicit indication of which direction is
higher (or lower) absolute index.

Section 7.1.2

The mitigation technique of segregating the dynamic table by entity
constructing the message seems to inherently require the encoder to have
direct knowledge of the entity on whose behalf it is constructing a
message.  For the other mitigation technique we present (of always using
string literals for sensitive values), we include the 'N' bit to allow
this attribute to be propagated through intermediaries.  However, I
think that in scenarios where multiple intermediaries are involved, in
the later steps in the intermediary chain the encoder will not
necessarily have knowledge of which entity created a given message, and
thus could inadvertently merge compression contexts that the original
encoder had specifically kept separate.  The preconditions necessary for
this to enable an attack seem rare, with one of the originating entities
having access to observe the transport layer in a location several hops
removed, so it doesn't really seem worth attempting to add a technical
mitigation.  It would probably be worth documenting the risk, though.

Section 8.1

(nit) In the prose we refer to the setting names with a "SETTINGS_" prefix.
Blindly adding that to the table looks like it would blow out the column
count for the plaintext output, though, so I didn't put that in my
editorial PR.

Appendix A

(nit) At least the plaintext output might benefit from a disclaimer
about line wraps in the 'Value' column being display artifacts.

Appendix B

I worked through the examples.  The presentation format is quite nice, and
I appreciate all the detailed breakdowns!

However, we show the dynamic table as being 1-indexed, but I'm pretty
sure the prose says it should be 0-indexed.  We do it consistently, at
least, and toss some extra '1's into the math to make the numbers work
out, but since the static table is by definition 0-indexed, it's a bit
weird to show the dynamic table as 1-indexed.

Additionally, I think that B.5 is an exception to the "we do it
consistently" -- while the 81... dynamic insert with relative index 1
does refer to the indicated custom-key field, that would be absolute
index 3 in the 1-indexed presentation we give (though it would be
absolute index 2 if 0-indexed, if I'm getting this right).

Appendix C

It might be worth a brief mention of the API contracts for (e.g.) the
encode*() functions.  The second argument of encodeInteger() as "the
byte value used to fill in the bits of the first byte that are not
consumed by the trailing N-prefix integer" is particularly hard to infer
(if it's even the correct inference).

[Ballot comment]
Thank you for the work put into this document. To be honest, I find it really interesting to read.

I have only one generic comment, did the WG look into the Static Context Header Compression out of the LPWAN WG ? As there are similarities.

Regards

-éric

[Ballot comment]
A couple of very minor points:

3.2 I think it would be more accurate to say that each HTTP/3 endpoint holds two dynamic tables, not one, one in each direction. I'm assuming that the dynamic tables are in fact distinct.

3.2.1. s/32/32 bytes

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-quic-qpack-19. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: draft-iana-quic-http

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the HTTP/3 Settings registry created upon approval of draft-iana-quic-http two new values are to be registered as follows:

+==========================+======+=============================+=========+
| Setting Name | Code | Specification | Default |
+==========================+======+=============================+=========+
| QPACK_MAX_TABLE_CAPACITY | 0x1 | [ RFC-to-be Section 5 ] | 0 |
+--------------------------+------+-----------------------------+---------+
| QPACK_BLOCKED_STREAMS | 0x7 | [ RFC-to-be Section 5 ] | 0 |
+--------------------------+------+-----------------------------+---------+

Second, in the HTTP/3 Stream Type registry created upon approval of draft-iana-quic-http two new values are to be registered as follows:

+======================+======+============================+========+
| Stream Type | Code | Specification | Sender |
+======================+======+============================+========+
| QPACK Encoder Stream | 0x02 | [ RFC-to-be Section 4.2 ] | Both |
+----------------------+------+----------------------------+--------+
| QPACK Decoder Stream | 0x03 | [ RFC-to-be ]Section 4.2 ] | Both |
+----------------------+------+----------------------------+--------+

Third, in the HTTP/3 Error Codes registry created upon approval of draft-iana-quic-http three new values are to be registered as follows:

+============================+=======+=============+============================+
| Name | Code | Description | Specification |
+============================+=======+=============+============================+
| QPACK_DECOMPRESSION_FAILED | 0x200 | Decoding of | [ RFC-to-be Section 6 ] |
| | | a field | |
| | | section | |
| | | failed | |
+----------------------------+-------+-------------+----------------------------+
| QPACK_ENCODER_STREAM_ERROR | 0x201 | Error on | [ RFC-to-be Section 6 ] |
| | | the encoder | |
| | | stream | |
+----------------------------+-------+-------------+----------------------------+
| QPACK_DECODER_STREAM_ERROR | 0x202 | Error on | [ RFC-to-be Section 6 ] |
| | | the decoder | |
| | | stream | |
+----------------------------+-------+-------------+----------------------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-11-16):

From: The IESG
To: IETF-Announce
CC: lucaspardue.24.7@gmail.com, draft-ietf-quic-qpack@ietf.org, magnus.westerlund@ericsson.com, quic@ietf.org, quic-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (QPACK: Header Compression for HTTP/3) to Proposed Standard


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'QPACK: Header Compression for HTTP/3'
  as Proposed Standard

This document is part of a combined 26-day last call for multiple
related documents that defines the QUIC protocol and the HTTP mapping
onto QUIC. The documents are:

  - draft-ietf-quic-transport
  - draft-ietf-quic-recovery
  - draft-ietf-quic-tls
  - draft-ietf-quic-invariants
  - draft-ietf-quic-http
  - draft-ietf-quic-qpack

Due to its GitHub-centric work style, the QUIC WG requests that LC review
comments are individually filed as issues in the WG repository at
https://github.com/quicwg/base-drafts if at all possible. A summary email may with
URLs to the individual issue should then also be sent to the relevant mailing list
(primarily last-call@ietf.org and quic@ietf.org).

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-11-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines QPACK, a compression format for
  efficiently representing HTTP fields, to be used in HTTP/3.  This is
  a variation of HPACK compression that seeks to reduce head-of-line
  blocking.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-qpack/



No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-httpbis-semantics: HTTP Semantics (None - IETF stream)

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.