unclear definition of persistent congestion

[marten-seemann]

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.

[kazuho]

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.

[kazuho]

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.

[larseggert]

#3939 seems also related

[goelvidhi]

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.

[janaiyengar]

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