Subject: [quicwg/base-drafts] QUIC timers would be simpler if the Handshake timer was unified with the PTO timer (#2650)

From: ianswett <[email-masked]>
Date: Wed, 24 Apr 2019 06:51:41 -0700

The main optimization the handshake timer makes is the assumption that max_ack_delay does not need to be waited for before firing.  However, it also uses a completely different equation for a timeout (2 * SRTT vs SRTT + 4*RTTVar).  We could fix the max_ack_delay difference by defaulting max_ack_delay to 0(#2646), like almost all other transport parameters.

If there are no RTT measurements or estimates, we could use 1 second.  If there are no RTT measurements, but there is an estimate, we could either use the PTO formula and assume RTTVar is 1/2 RTT(=> 3*RTT), or we could recommend estimating RTTVar as well as RTT.  The first approach seems more practical.

Another notable difference is the advice to retransmit all the handshake packets instead of 1 or 2, but given the current 3x amplification limit, if a server sends 2 packets in response to a ClientHello, they can't even retransmit both packets, so advising that they retransmit all handshake packets is not indicative of real-world behavior.  If the server only has 1 handshake packet, then there's no change.  The client should always be able to fit its CRYPTO data into a single packet, unless there are large client certs.  If there are large client certs, one would expect time or packet threshold loss recovery to be faster and more effective than timer based retransmissions.  And at that point, the client should have at least one RTT sample.

The goal of this issue is to make the recovery mechanisms simpler, as well as including RTTVar in the handshake timer, as #2648 suggests.

-- 
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/2650

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 24 Apr 2019 23:20:38 -0700

Yes -- I was heading in this direction with #2648, and it is how we're implementing recovery in quicly. I realized that we have a false separation between the crypto retransmission timer and the PTO timers. Using _only_ the PTO timer basically is the most sensible approach.

We need to ensure that max_ack_delay is used only after handshake, and there's some care required there, but that's still much better than what we have now.

-- 
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/2650#issuecomment-486534895