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 protected]> wrote: > > > > On Fri, Nov 27, 2020 at 3:23 AM Timo Völker <[email protected]> > 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
smime.p7s
Description: S/MIME cryptographic signature
