Should QPACK use the new layout?

[MikeBishop]

#3573 changed Transport and HTTP to use a different presentation format. QPACK still uses the ASCII art version, which is consistent with HPACK. We should explore what it would look like with the new format as well.

[martinthomson]

You can't use varints, but you could define (p) to indicate that the integer is prefixed. As far as I know, we don't need to indicate the size of the prefix and can rely on the prefixed integer ending on a byte boundary.

[MikeBishop]

I'm not sure we need that. Since variable-size fields are defined to end on byte boundaries, we could simply note them as (N..) for an N-bit prefix. The prefix is an artifact of how the field is encoded.

[dtikhonov]

I don't like this change. It will be more helpful to the future implementers if the QPACK spec looks similar to the HPACK spec.

[LPardue]

I find the traditional use of a "byte grid" a bit nonsensical when many fields span boundaries and the alignments are a falsity. I'd never implemented HPACK and so never realised this, I've only recently found it a minor nuisance while working on QPACK.

As a recent implementer of QPACK, I did find it useful to reference back and forth with HPACK and compare that to implementations of prefixed-integer handling. I don't find this new format particularly useful. While it might be consistent with the other documents, QPACK seems distinct with a very loose coupling to any other of the QUIC docs.

[MikeBishop]

So @LPardue, if you find the old format "nonsensical" and the new format "[not] particularly useful" for QPACK, do you have a third suggestion? 🙂

[LPardue]

Just update the ascii art to remove the little indices?

[afrind]

I'm not a fan of the new layout either, but I can't tell if that's just bias because I'm used to the old format. Do others agree with @LPardue's framing of the coupling with HPACK vs the other QUIC drafts?

[MikeBishop]

Personally, the "nonsense" of a byte grid doesn't bother me as much with H/QPACK as with others, and I think I've figured out why:

• Things are presented one byte at a time instead of four bytes at a time.
• Prefixed integers will take up the indicated portion of a byte if they fit, but might spill over to additional bytes which come before the next byte shown.
• QUIC fields were presented four bytes at a time, containing varints which messed with four-byte alignment, so the byte grid never made sense.

I kind of wish there were a better way of indicating visually where these possible extra bytes would fall (=== vs. ---?) but the + in the field length is a strong clue. If folks think the old format is better to stay in sync with HPACK, that's fine -- I just wanted to have the PR and make sure it was a decision instead of inertia.

[dtikhonov]

Do others agree with @LPardue's framing of the coupling with HPACK vs the other QUIC drafts?

I do.

[afrind]

Sounds like we have a preference for the existing layout over the new one. Closing this issue.