Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)

[Kazuho Oku <[e-mail]>]

@MikeBishop 
> Fundamentally, this seems to be a case of design reflecting a coding pattern. If your pattern is that the QUIC layer generates a binary structure, hands the opaque blob to TLS and says "this is the payload of extension foo," then it makes total sense to varint everything, because it's part of QUIC.
> 
> If your coding pattern is that the transport parameters are a known structure and TLS is handed a key-value store that it knows how to serialize, then it makes total sense to TLSPL everything, because it's part of TLS.

I think that this is a good summary of the trade-off that we have here.

FWIW, the latter approach (using a helper provided by TLS) can use something other than a key-value store.

As an example, picotls does not provide an API for encoding / decoding extensions, but provides a closure-based API<sup>1</sup> for encoding decoding TLS blocks instead, which is used by quicly. The code that encodes TP is at [quicly.c line 1389-1435](https://github.com/h2o/quicly/blob/0b0ba909eb502ae9db300f75819e3d207ba503c8/lib/quicly.c#L1389-L1435), the code that decodes TPs is at [line 1459-1546](https://github.com/h2o/quicly/blob/0b0ba909eb502ae9db300f75819e3d207ba503c8/lib/quicly.c#L1459-L1546). Because the encoding / decoding process are defined as callbacks of the TLS stack, they directly read from / append to the buffer built by the TLS stack.

As stated in [my previous comment](https://github.com/quicwg/base-drafts/issues/3294#issuecomment-564442061), encoding / decoding TPs is a complicated task that happens as part of the TLS handshake message processing, it would be helpful to allow these kinds of code reuse.

If we are to switch to varints for both TP ID and length, there would be much much less chance of such code reuse, because the structures of the TLV encoding would depend on the varint encoding of QUIC. In case of quicly, we would be copy-pasting the helper functions provided by picotls, changing the code that handles uint16 to varints.

That's certainly possible, but the additional complexity is far more than the cost of using uint16 instead of varints here.

1: With the caveat that something that looks like a closure (or a block of code) is actually a macro in case of C though :-)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3294#issuecomment-564750434