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

[ianswett <[e-mail]>]

I'm trying to fully digest everything above, so I apologize if I missed something important.

The idea that you wouldn't acknowledge packets that can be processed while waiting for keys for queued packets is clearly unrealistic for a variety of reasons, so we should definitely remove any text that assumes otherwise.

I'm unclear about why moving from handshake complete to confirmed is an improvement, given the example you cite seems to imply the server is retransmitting unnecessary data due to client delays, and for the server complete and confirmed happen at almost identical times.  Prior to CFIN or 1-RTT being acknowledged, the client knows the server has only one of the two keys.  PTO will retransmit the CFIN on the first PTO and the 1-RTT data on a subsequent PTO(assuming the first PTO doesn't send both).  I agree we expect HANDSHAKE_DONE to make this irrelevant in practice, but I can't reason about why this change is an improvement based on the problem description.  Can someone lay that out for me?

I believe we should make normative changes to transport along the lines of S2.  Specifically, I think we should say receivers SHOULD include the delay from the time an undecryptable packet is buffered to the time it's acknowledged in the ack_delay, as well as processing all buffered packets for a given encryption level before sending an ACK.  Ideally, a receiver would process buffered packets after the full datagram being processed as well, since that allows senders to fully mitigate this issue, but we could leave that to a description, rather than normative text if people prefer.  This provides more information to the sender, which it can ignore if it wants, and is much better than sending an Ack Delay of 0us in that case.  It's a bit odd that we say a receiver SHOULD set the ack delay field to 0 for Initial and Handshake packets today.

-- 
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-667619027