Re: [quicwg/base-drafts] RESET_STREAM should be allowed in 0-RTT packets (#2344)

[Marten Seemann <[e-mail]>]

> @marten-seemann I'm not sure if that's true. A client can always use transport parameters to specify it's limits; I doubt if there's a benefit in updating the limits using a 0-RTT packet.

There's generally good reason to keep the initial window small, since we don't have any mechanism to update the transport parameters.

> And in case of anticipating a large response, the anticipation would be that the transmission of the response would span across multiple round-trips (because of congestion control). Everything would work fine if the client's initial limit is large enough to cover what can be sent in the first round-trip (or several round-trips).

That depends very much on the concrete values used.

> Asking for permission to send _BLOCKED frames in 0-RTT packets might make sense, though I am not sure if we'd need that in practice. I think we can expect a server allowing 0-RTT to provide enough window to let the client actually use 0-RTT.

Right, I hadn't even thought about BLOCKED. I think it proves my point here: If we don't allow those frame types in 0-RTT, we'll need *a lot* of special code just for keeping those frames out of 0-RTT packets (and to delay transmission until you have 1-RTT keys). Equivalently, on the receiver side, you'd need to implement checks that the payload of 0-RTT packets only contain valid frames. I don't see any reason for special casing anything here, so we should just allow all frame types in 0-RTT packets.

-- 
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/2344#issuecomment-455435788