CANCEL_PUSH, MAX_PUSH_ID and GOAWAY specify the length of the ID twice

[afrind]

From #1556:

CANCEL_PUSH, MAX_PUSH_ID and GOAWAY have a variable length frame length but the frame contains only a single variable length integer, so its length is effectively specified twice.

[martinthomson]

The advantage of having that redundancy is consistency. All frame types have a length, which allows us to send frames of unknown types.

It seems that QUIC-the-transport leans more heavily toward the schema-aware grammar than hq or TLS, which both have redundant lengths. The transport therefore needs prior agreement for every extension - which is fitting for something at that layer.

hq has just two instances of this sort of redundancy that I can identify: frames and settings. I don't think that either is particularly problematic, especially in light of existing needs. That is, you need to be able to send either without knowing that your peer will understand it.

I don't think that this needs to change.

[afrind]

I think what I'm asking about, for both frames and SETTINGS in the linked issue, is whether QUIC varints are the best choice for representing integers in HQ.

[MikeBishop]

I think that's a fair question, and I'm coming around to the idea of length-prefixed non-varint values for SETTINGS. It's a level of complexity that seemed like we might need it coming out of HTTP/2, and a few years later that need hasn't proven itself out.

For these frames, we're referencing Stream IDs / Push IDs. Stream IDs are a transport layer concept and I'm reluctant to introduce an alternative encoding. We already have at least one place (PRIORITY) where Push and Stream IDs are encoded in the same field, which argues for using the same encoding for both. If not varint, what?

[mnot]

Discussed in NYC; comfort with closing with no action.