Subject: [quicwg/base-drafts] unclear definition of persistent congestion (#3937)

From: Marten Seemann <[email-masked]>
Date: Tue, 21 Jul 2020 19:06:43 -0700

A sender sends a tail of 10 packets, packet number 1 to 10. It now receives an acknowledgement for packets 5 and 10, which establishes the loss of all other packets.

It's not clear how to perform the check for persistent congestion now. Several options come to mind:

1. check if the period between 6 and 9 is longer than 3*PTO
2. check if either the period between packet 1 and 4 or the period between packet 6 and 9 is longer than 3*PTO
3. The ACK doesn't establish loss of *all* tail packets, so there's no persistent congestion.

In an offline discussion, both @mjoras and @goelvidhi expressed preferences for different options here. I'm not sure what the right thing to do is here, but at least the draft should be clearer on what exactly establishes persistent congestion and what doesn't.

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 21 Jul 2020 21:04:26 -0700

Consider the case where the sender receives an acknowledgement for packets from 5 to 10, and the period between 1 and 4 was longer than 3*PTO. IIUC, this is clearly a persistent congestion.

The original example is strictly worse than that, and I think it would make sense to declare persistent congestion in the case too. In other words, I think that 3 is incorrect.

That said, I do not have a strong opinion regarding if we should specifically recommend either of 1 or 2, considering that the logic (or the time threshold) being used to detect persistent congestion is merely a recommendation.

-- 
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/3937#issuecomment-662228692

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 21 Jul 2020 22:06:20 -0700

FWIW, we had some discussion regarding the design rationale behind persistent congestion in #3875, and it seemed to me that it was mostly about the amount of time the sender cannot make any progress.

-- 
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/3937#issuecomment-662243363

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Jul 2020 22:33:42 -0700

#3939 seems also related

-- 
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/3937#issuecomment-662250818

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 22 Jul 2020 04:37:52 -0700

I think we should keep it simple, which IMO is do nothing.
Or if we want to add a recommendation, we can say that you start with the largest lost packet and try to detect Persistent congestion until either you have found 1 occurrence or reached the end of list.

-- 
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/3937#issuecomment-662403980

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 28 Jul 2020 11:18:28 -0700

This is fixed in #3961, and is an editorial fix.

-- 
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/3937#issuecomment-665197984