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

From: Marten Seemann <[email-masked]>
Date: Wed, 06 Feb 2019 17:15:37 -0800

We claim that 
> Data in CRYPTO frames is critical to QUIC transport and crypto negotiation, so a more aggressive timeout is used to retransmit it.

As pointed out in #2417, the only mechanisms we have for retransmitting crypto packets is Fast Retransmit (i.e. when an ACK declares a packet lost) and the Crypto Retransmission timer. Specifically, we don't have an Early Retransmit timer for crypto packets. This means that if a tail packet in one packet number space is lost, we wait 2 RTTs before retransmitting it, whereas with Early Retransmit the retransmission would have happened after 9/8 RTT.

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

---

From: ianswett <[email-masked]>
Date: Thu, 07 Feb 2019 10:21:21 -0800

Good point, I think this is really a bug and the time threshold loss detection should trump retransmitting handshake data.

This may be a good argument for adding a second timer just for time threshold loss detection.  I can make it work without that, but would that make it clearer?

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 11 Feb 2019 03:26:05 -0800

Why do we need a second timer? Wouldn't it be sufficient to have another `loss_time` variable for crypto packets?

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

---

From: ianswett <[email-masked]>
Date: Mon, 11 Feb 2019 07:01:28 -0800

I don't believe we need a second timer, and in implementation, I don't think it's necessary.

However, others have previously suggested it may make the pseudocode easier to read.

I'll try a minimal fix first, and we can add a second alarm if it ends up being clearer.

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 11 Feb 2019 07:33:43 -0800

I just tried to sketch the algorithm using a packet-number-space dependent `loss_time`, i.e. `loss_time[kPacketNumberSpace]`. In `SetLossDetectionTimer()`, you'd then use the smallest (non-zero) `loss_time` for your timer, and only arm the crypto retransmission timeout if all 3 `loss_time`s are 0.
This seems to work fine, and is generally (a lot) more aggressive than what we currently have, however, there's one corner case where it's less aggressive. Consider the following sequence of packets being sent:
```
t=1: Initial 1
t=2: Initial 2
t=3: Handshake 1
```
Now we receive an ACK for Initial 2, and arm the early retransmit timer at `t=1+1.125x`, where `x` is the RTT. When this timer fires, we retransmit Initial 1 as Initial 3. The crypto retransmission timeout will now be set this time plus 2 RTT, i.e. `t=1+3.125x`. This is then the first time we retransmit Handshake 1.
Without the early retransmit timer, we would have retransmitted Handshake 1 2 RTTs after sending it, i.e. at `t=3+2x`, which for all realistic RTTs would be earlier.

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

---

From: ianswett <[email-masked]>
Date: Mon, 11 Feb 2019 16:09:22 +0000 (UTC)

Good point, that is a case when the new approach is slightly less aggressive.

If we wanted to favor aggressiveness during the handshake, we could arm the crypto timer based on the left edge(earliest unacked ack-eliciting packet) rather than the right(latest unacked).  That's a larger change than I'd like to make in this CL/issue, though.

I believe the example you outlined above is fairly unlikely, because for most connections, if multiple initials are sent, they're likely to be re-transmissions, not new data.  In that case, when Initial 2 is acked, Initial 1 is immediately lost and Handshake 1 is still the only outstanding ack-eliciting packet.  That being said, I can probably construct other situations that are somewhat similar.

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 11 Feb 2019 18:04:08 -0800

> If we wanted to favor aggressiveness during the handshake, we could arm the crypto timer based on the left edge(earliest unacked ack-eliciting packet) rather than the right(latest unacked). That's…

I'm not sure if it would work. The main reason is the 3x amplification limit, which can delay the sending of crypto packets on the server side. You could then run into the situation where the timer based on the oldest packet already expires, just after sending another crypto packet. It wouldn't make a lot of sense to immediately retransmit that packet.

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 20 Feb 2019 15:53:30 -0800

Closed #2435 via #2451.

-- 
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#event-2153532088

---

From: Marten Seemann <[email-masked]>
Date: Wed, 20 Feb 2019 19:28:39 -0800

@janaiyengar I saw you closed this issue already, but I don't think my concerns in https://github.com/quicwg/base-drafts/issues/2435#issuecomment-462371300 are fully addressed by #2451. Do you think it's ok to just ignore that corner case?

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

---

From: ianswett <[email-masked]>
Date: Thu, 21 Feb 2019 06:41:04 -0800

@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

---

From: ianswett <[email-masked]>
Date: Thu, 21 Feb 2019 14:41:07 +0000 (UTC)

Reopened #2435.

-- 
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#event-2155157518