Subject: Persistent Congestion and in-flight

From: Timo Völker <[email-masked]>
Date: Fri, 27 Nov 2020 08:23:06 +0000

Hi all,

Section 7.6. starts the explanation of Persistent Congestion with

> When a sender establishes loss of all in-flight packets...

Does this mean that packets that do not count as in-flight (e.g. a packet that contains only an ACK frame) are ignored here?

To refer to the example in section 7.6.3. What if at t=4.5 a packet were send with only an ACK frame, which gets acknowledged along with the last sent ack-eliciting packet with the ack received at t=12.2? Would this be still a persistent congestion or not?

Timo

---

From: Kevin <[email-masked]>
Date: Fri, 27 Nov 2020 11:33:16 -0500

I attempt to solve these problems with my own fork of datagram. I think 
you are talking about possible data loss do to anomalies. Take a look:

https://www.github.com/kjsisco/datagram

Kevin

http://kclive.buzzsprout.com

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Ian Swett <[email-masked]>
Date: Sat, 28 Nov 2020 08:07:29 -0500

On Fri, Nov 27, 2020 at 3:23 AM Timo Völker <[email-masked]>
wrote:

> Does this mean that packets that do not count as in-flight (e.g. a packet
> that contains only an ACK frame) are ignored here?
>

Yes.

>
> To refer to the example in section 7.6.3. What if at t=4.5 a packet were
> send with only an ACK frame, which gets acknowledged along with the last
> sent ack-eliciting packet with the ack received at t=12.2? Would this be
> still a persistent congestion or not?
>

That would still be persistent congestion because you'd be establishing
loss of all in-flight packets.  The ACK-only packet was never in-flight.

---

From: Timo Völker <[email-masked]>
Date: Sun, 29 Nov 2020 12:26:47 +0000

Ian,

Thanks again for your help.

Is there a reason why packets that do not count as in-flight are irrelevant for persistent congestion?

I find section 7.6.2. very helpful. It gave me a better idea how to implement a persistent congestion detection. However, there are two points where I scratch my head.

The section starts with: 

> A sender establishes persistent congestion on receiving an acknowledgement...

The pseudo code tell me that that I have to check for persistent congestion also if the loss detection timer fires and earliest_loss_time is not zero. Do I miss something?

The first bullet point in the section starts with

> all packets...

Based on what I have learned, it should be "all in-flight packets...", right?

Timo

> On 28. Nov 2020, at 14:07, Ian Swett <[email-masked]> wrote:
> 
> 
> 
> On Fri, Nov 27, 2020 at 3:23 AM Timo Völker <[email-masked]> wrote:
> Hi all,
> 
> That would still be persistent congestion because you'd be establishing loss of all in-flight packets.  The ACK-only packet was never in-flight.
> 
> Timo

---

From: Ian Swett <[email-masked]>
Date: Sun, 29 Nov 2020 20:01:59 -0500

> irrelevant for persistent congestion?

The reason is that the packets need to elicit acknowledgements to reliably
establish persistent congestion.  However, I realize you've stumbled upon a
subtle error, which is that I believe this should be ack-eliciting packets
must establish persistent congestion, not in-flight packets.  The only
packet that is in-flight and not ack-eliciting is one with PADDING or
PADDING + an ACK frame, so the error is unlikely to manifest in practice,
but I think it's worth fixing so I filed Issue #4413
<https://github.com/quicwg/base-drafts/issues/4413>.

>
> I find section 7.6.2. very helpful. It gave me a better idea how to
> implement a persistent congestion detection. However, there are two points
> where I scratch my head.
>
> The section starts with:
>
> The pseudo code tell me that that I have to check for persistent
> congestion also if the loss detection timer fires and earliest_loss_time is
> not zero. Do I miss something?
>

Sorry, I don't think I have enough context on this question.

> Based on what I have learned, it should be "all in-flight packets...",

Probably all ack-eliciting packets per my comment above, but yes.

> > Does this mean that packets that do not count as in-flight (e.g. a
> packet that contains only an ACK frame) are ignored here?
> >
> > Yes.
> >