[quicwg/base-drafts] persistent congestion is more aggressive than RTO verified (#2255)

[Marten Seemann <[e-mail]>]

Consider the following sequence of packets being sent

|  | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| -- | -- | -- | -- | -- | -- | -- | -- | -- |
| old: | packet | packet | TLP 1 | TLP 1 | TLP 2 | TLP 2 | RTO | RTO |
| new: | packet | packet | PTO 1 | PTO 1 | PTO 2 | PTO 2 | PTO 3 | PTO 3 |

In our old loss recovery code (before unifying TLP and RTO, #2114), we used the following logic for determining if an RTO was not spurious, which would then lead to collapse of the congestion window:
```
if (rto_count > 0 && smallest_newly_acked > largest_sent_before_rto):
  OnRetransmissionTimeoutVerified(smallest_newly_acked)
```
In the example above `largest_sent_before_rto` would be packet 14. This means that to count as a verified RTO, an ACK must acknowledge 15 or 16, but not *any* packets smaller or equal than 14.

With #2114, we now collapse the congestion window when `pto_count` is larger than 2 and we receive an ACK which leads us to declare *any* packet lost. In the example above this means any ACK received after sending packet 15 which declares a packet lost would suffice. Even worse, this logic already triggers if we receive the ACK *immediately after* sending 15, i.e. when the peer didn't even have a chance to receive it.

This seems  **a lot more aggressive** than what we had before before. Is this intentional?

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