Re: [quicwg/base-drafts] Desirable behavior when it takes time to derive the traffic keys for the next PN space (#3821)

[Martin Thomson <[e-mail]>]

FWIW, I was *really* concerned about that last change.  Aside from it making this a non-editorial change, the way that we avoid handshake deadlock depends very much on HANDSHAKE_DONE being followed by probes.  But as the server confirms and completes the handshake at the same time, I've convinced myself that this is OK.  

(That this is what our stack did, largely by accident, is vindication of sorts...)

I would encourage people to sit down and run the analysis on that change to convince themselves that this is not reintroducing the handshake deadlock.

The other part of the proposed solution needs to be slightly different.  @janaiyengar proposes that we ignore `max_ack_delay` prior to confirming the handshake.  I think that's good, but it is not completely correct, and nor would it be sufficient.

We need to ignore `max_ack_delay` for acknowledgements of packets that were sent prior to handshake confirmation.  Those are the ones that might have been buffered until keys were ready.

In order for that to work, we have two new requirements on packet processing for buffered packets:

1. endpoints MUST process and acknowledge (or discard) any packets that they might have buffered during the handshake within `max_ack_delay` of completing the handshake

2. endpoints MUST report an ACK Delay that is based on when a packet is received, not when it was processed

-- 
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/3821#issuecomment-658599289