Re: Persistent Congestion and in-flight

[Timo Völker <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> On Fri, Nov 27, 2020 at 3:23 AM Timo Völker <[e-mail]> wrote:
> 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?
> 
> 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.
> 
> Timo