Re: [quicwg/base-drafts] Rework Retry packet (#1498)

[Kazuho Oku <[e-mail]>]

> Open Question: would it make sense to normalize the encoding of Retry and Initial? The former includes a token without a length (because it's the last piece of the packet), whereas the latter includes a length-prefixed token. It might be easier to invert the ODCID and token on Retry. That would make the token processing more consistent.

My preference goes to keeping the current format as-is, because IMO it is better to have fields that identify the connection at the top. Having ODCID above token allows implementations to bail out before dealing with the token, if ODCID does not match the expected value.

>  I'm not sure if we want to consider adding a token to 0-RTT and Handshake packets, but that would fully normalize things.

I think that we should limit the existence of the token field to Initial packets.

Having the field in Handshake packet does not make sense at all, because it is sent by the client after the path is validated using the token. Note also that we are trying hard to cram the certificate chain into the Handshake packets that can be sent in the first flight. Having an unnecessary field (even if it is empty) goes against that.

Having the field in 0-RTT packet _might_ make some sense, but I oppose, because it allows two ways of implementing buffering of potentially reordered 0-RTT packets on the server side. One way (the only way which is possible now) is to buffer such packets without validating the paths. The other way that will be opened up by having the field is to buffer such packets after validating the paths.

This flexibility will incentivize the clients to include token for every 0-RTT packets even though it reduces the space that can be used to carry application data. And that in turn disincentivises the server to buffer potentially reordered 0-RTT packets.

To summarize, having a token field in 0-RTT packet will force us to end up in an suboptimal implementation, even though 0-RTT is about optimization. I do not think that we want to see such an outcome.

-- 
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/pull/1498#issuecomment-401224459