Subject: [quicwg/base-drafts] Suggest endpoints may recognize acks after loss is declared (#3956)

From: Kazuho Oku <[email-masked]>
Date: Thu, 23 Jul 2020 18:33:27 -0700

By design, TCP is capable of handling late-arriving acks. If a TCP endpoint receives an ack for a byte range after declaring loss of that byte range, retransmission of that byte range is cancelled.

In contrast, QUIC uses monotonically increasing packet numbers. That is definitely an improvement, but does have a downside. If loss detection is too sensitive, and if endpoints drop information regarding what had been sent in a packet at the moment that packet is declared lost, then it would not recognize the late acks.

I think that we should suggest (even if not recommend) QUIC endpoints to recognize late-arriving acks, so that our loss detection can be as aggressive and as effective as TCP, if not better.

(Please let me know if such text already exists. I am opening the issue because I could not find one)

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jul 2020 19:07:12 -0700

I have to agree.  We had to implement late acknowledgment by marking "lost" packets and retaining them.  I believe that this was very helpful in reducing the amount of redundant information we send.

Failing to retain packets that were marked as lost was also the cause of a bug. As the lost packet was removed from our outstanding calculation (a different value to the "in-flight" counter we use for congestion control), we believed that there were no packets outstanding and we didn't try to send anything when the next PTO fired.  As the loss detection timer is shorter than the PTO timer, we believed that there was nothing to send often (and we don't check all sources of frames, which would have told us otherwise).

-- 
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/3956#issuecomment-663316576

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 23 Jul 2020 19:34:10 -0700

Agreed.

-- 
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/3956#issuecomment-663321709

---

From: ianswett <[email-masked]>
Date: Fri, 24 Jul 2020 11:36:54 -0700

Yeah, we should have text on this if we don't already.

-- 
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/3956#issuecomment-663676917

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 24 Jul 2020 16:00:20 -0700

The resolution in #3957 introduces a new recommendation for senders, so this ought to be considered a design issue if we're happy with that resolution.

-- 
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/3956#issuecomment-663766057

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sun, 26 Jul 2020 18:38:33 -0700

https://tools.ietf.org/html/draft-ietf-quic-recovery-29#appendix-A.1

we have this text:

```
   After a packet is declared lost, the endpoint can track it for an
   amount of time comparable to the maximum expected packet reordering,
   such as 1 RTT.  This allows for detection of spurious
   retransmissions.
```

-- 
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/3956#issuecomment-664075123

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 26 Jul 2020 18:52:10 -0700

@tatsuhiro-t Thank you for pointing that out. I missed that.

I tend to think that we should adopt #3957. As stated in my original comment, handling of late acks is the prerequisite of many of the normative requirements that exist in the recovery draft. Therefore, it is better to have a normative requirement for handling of late acks.

-- 
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/3956#issuecomment-664077868

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sun, 26 Jul 2020 19:08:29 -0700

I'm not opposing adding new normative text.  If new text is added, I think that the existing text should be aligned to it.  In the PR, it recommends 3PTO, but the recovery draft A.1 says 1RTT.

-- 
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/3956#issuecomment-664081346

---

From: Martin Thomson <[email-masked]>
Date: Sun, 26 Jul 2020 21:11:18 -0700

FWIW, our implementation, as of a little while ago, tracks for `>` the current PTO.  If everything is working nicely, that limits our commitment.  As we are sending probes, the time lengthens so that we send a probe before discarding state.  If it takes two probes to get an ACK, we won't recognize that, but we will always catch an ACK for the last set of probes.  And the state commitment is minimal unless we're forced to probe.

-- 
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/3956#issuecomment-664108552

---

From: ianswett <[email-masked]>
Date: Mon, 27 Jul 2020 07:46:19 -0700

I'll note that the PR is against transport, but this issue is tagged as recovery.

-- 
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/3956#issuecomment-664440871

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 27 Jul 2020 08:52:07 -0700

Thanks for pointing out this inconsistency, @tatsuhiro-t. I would argue that this should be a PTO, since that allows for including the  RTT variance in the waiting period. Using a PTO includes the maximum ack delay as well -- which may not be necessary -- but it's convenient to use the PTO period.

-- 
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/3956#issuecomment-664478743

---

From: ianswett <[email-masked]>
Date: Mon, 27 Jul 2020 08:54:40 -0700

I wanted to clarify my comment on the PR about believing that 1 RTT is a preferable recommendation to 3*PTO.

We definitely don't want to discard this information BEFORE the packet is lost or acknowledged.  But after it's been declared lost, there's no need to wait longer than the reordering window to receive an acknowledgement, because an immediate ACK will be sent when the out of order packet arrives.  I tend to think an RTT is a plenty long reordering window in practice.

If nothing is inflight before and nothing sent after the packet is lost AND the late immediate ACK for the reordered packet is lost, then it could take longer than the reordering window to receive an ACK, but that seems like an edge case that's not very interesting.

-- 
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/3956#issuecomment-664480525

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 27 Jul 2020 09:52:23 -0700

@ianswett : I've changed it to 1 PTO. We've commonly used PTO as a time period for everything else in the transport, and so it's convenient to use PTO here too. Ultimately, this is the amount of time you're holding on to packets marked as lost, so the extra time waiting for a PTO (over an RTT) really shouldn't make any measurable difference. 

If you still think we should say RTT, I'm fine with that.

-- 
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/3956#issuecomment-664513327

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 27 Jul 2020 09:58:40 -0700

I'm fine with PTO, and I prefer PTO above RTT.

There could be reasons where there are some packet reordering due to multiple paths being used (e.g., ECMP, clustered endpoint). In such case, the variance of latency becomes more like a constant independent of RTT.

I think it is a good idea to recommend a value (i.e. PTO) that can cover such constant even if RTT is very small. PTO has `max_ack_delay` that would cover that constant.

-- 
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/3956#issuecomment-664516741

---

From: ianswett <[email-masked]>
Date: Mon, 27 Jul 2020 12:20:36 -0700

I'm not convinced I understand the rationale completely, but I'm ok with 1 PTO.  I believe we should update the recovery draft in the same PR.

-- 
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/3956#issuecomment-664589096

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jul 2020 22:30:39 -0700

So, design?

-- 
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/3956#issuecomment-664786182

---

From: ianswett <[email-masked]>
Date: Tue, 28 Jul 2020 07:45:17 -0700

We have text about this in recovery, but it's there was no normative text and it's in the appendix, so I think this is design.

-- 
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/3956#issuecomment-665083249