QPACK: Field Compression for HTTP/3
draft-ietf-quic-qpack-21
Yes
(Magnus Westerlund)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
Note: This ballot was opened for revision 20 and is now closed.
Murray Kucherawy
Yes
Comment
(2021-01-20 for -20)
Sent
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?
Erik Kline
No Objection
Comment
(2021-01-19 for -20)
Sent
[[ nits ]] [ Appendix B ] * s/as wells as/as well as/
Roman Danyliw
No Objection
Comment
(2021-01-19 for -20)
Not sent
Thanks to Magnus Nystrom for the SECDIR review.
Éric Vyncke
No Objection
Comment
(2021-01-20 for -20)
Sent
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
Barry Leiba Former IESG member
Yes
Yes
(2021-01-20 for -20)
Sent
Thanks for another fine, well-written QUIC document.
Magnus Westerlund Former IESG member
Yes
Yes
(for -20)
Unknown
Martin Duke Former IESG member
Yes
Yes
(2021-01-12 for -20)
Sent
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
Alissa Cooper Former IESG member
No Objection
No Objection
(for -20)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -20)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2021-01-20 for -20)
Sent
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).
Deborah Brungard Former IESG member
No Objection
No Objection
(for -20)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -20)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2021-01-21 for -20)
Sent
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.