Re: [quicwg/base-drafts] loss of only two packets can lead to an unrecoverable situation (#2267)

[Kazuho Oku <[e-mail]>]

@marten-seemann 
> Both endpoints have the 1-RTT keys, but the client doesn't know that the server has them, since the ACK for the CFIN was lost. For the client, this situation is indistinguishable from the CFIN itself being lost, so it has to keep retransmitting it.

That's true, however I am not sure if introducing a new frame (that needs to be delivered reliably) is the correct solution. At least for my implementation, consulting if an ACK for 1-RTT packet has been received each time a Handshake packet is deemed lost is easier than reliably transmitting a HANDSHAKE_DONE frame and using it's receipt as a signal.

Having that said, _if_ we are going to depart from the current approach, possibly by introducing a HANDSHAKE_DONE frame, I think it's worth reconsidering when we drop the Initial keys.

Current text requires endpoints to drop Initial packets as soon as they know that the peer knows the Handshake keys. The downside of this approach is delivery of Initial packets and their RTT is sometimes lost.

If we are to have an explicit signal for indicating the end of the handshake, we could delay dropping not only the Handshake keys but also the Initial keys until that signal is being emitted.

The design would be:
* each endpoint emits HANDSHAKE_DONE packet when all the CRYPTO data sent using Initial and Handshake packets are acknowledged
* an endpoint would retain it's Initial and Handshake keys until it sends HANDSHAKE_DONE frame and also receives HANDSHAKE_DONE frame

This is simpler than the current design. There's no fear of key being dropped having negative impact on loss recovery / congestion control. There's only one event for dropping the keys (instead of two). And the logic can be exactly the same on the server and the client.

-- 
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/2267#issuecomment-458441125