Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)

[Nick Harper <[e-mail]>]

We discussed this in Tokyo ([minutes](https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.md#flow-control-for-post-handshake-crypto-messages-1834)), and there are basically 3 options here:

- Implement proper flow control for CRYPTO frames
- Specify a buffer size (50k is the example from the Tokyo discussion)
- Drop CRYPTO frames if an endpoint has to buffer too many

My sense of the room was that the 3rd option was the preferred option for now.

When we have TLS extensions where we care about reliable delivery of post-handshake messages, that sounds like a good time to add proper flow control. I don't like picking a fixed buffer size for the same reason as using timers for discarding keys. If we pick a buffer size now, how do we know that it will be big enough for whatever future TLS extensions might get used with QUIC (or future key exchanges)?

I don't think that this breaks a rule of acknowledging packets means that the peer has processed all frames in that packet. For example, if an endpoint receives a packet containing stream data that is a retransmission of previously received data, that endpoint in effect is dropping that STREAM frame. Here, the CRYPTO frame is being processed (and the endpoint is immediately choosing to do nothing based on it).

-- 
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/2524#issuecomment-474210701