Re: [quicwg/base-drafts] loss recovery of crypto packets is less aggressive, not more aggressive (#2435)

[ianswett <[e-mail]>]

@marten-seemann I'll reopen this issue while we discuss this.

I believe the original core of this issue was that when early retransmit was at play, crypto retransmission was substantially less aggressive than other packets.  As you noted, that clearly was not the intent and I believe that's been fixed.

The case you outline is interesting, because even if Initial 3 is acked, the only mechanism we have to recover from the loss of Handshake 1 is the crypto timer.  If we'd like to avoid always spuriously retransmitting Handshake 1 in this scenario, we have to wait until Initial 3 is acked, because otherwise the peer likely doesn't have keys to decrypt Handshake 1.

In practice, when Initial 3 is acked, the server can likely assume the client has the handshake keys and if it doesn't receive an ACK for Handshake 1 in a relatively short period of time(maybe 1/8 RTT), then retransmit Handshake 1.  But that's making assumptions about key availability from recovery information, which seems like a very questionable optimization to save 7/8 RTT in an edge case where two packets from two different packet number spaces are lost in short sequence.

TLDR: I think the current algorithms are good, and only if we were ok with spuriously retransmitting all handshake data in the majority of cases when a single Initial packet was lost could we adopt a more aggressive approach.

-- 
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/2435#issuecomment-466024061