Re: [quicwg/base-drafts] loss recovery of crypto packets is less aggressive, not more aggressive (#2435)

[Marten Seemann <[e-mail]>]

I just tried to sketch the algorithm using a packet-number-space dependent `loss_time`, i.e. `loss_time[kPacketNumberSpace]`. In `SetLossDetectionTimer()`, you'd then use the smallest (non-zero) `loss_time` for your timer, and only arm the crypto retransmission timeout if all 3 `loss_time`s are 0.
This seems to work fine, and is generally (a lot) more aggressive than what we currently have, however, there's one corner case where it's less aggressive. Consider the following sequence of packets being sent:
```
t=1: Initial 1
t=2: Initial 2
t=3: Handshake 1
```
Now we receive an ACK for Initial 2, and arm the early retransmit timer at `t=1+1.125x`, where `x` is the RTT. When this timer fires, we retransmit Initial 1 as Initial 3. The crypto retransmission timeout will now be set this time plus 2 RTT, i.e. `t=1+3.125x`. This is then the first time we retransmit Handshake 1.
Without the early retransmit timer, we would have retransmitted Handshake 1 2 RTTs after sending it, i.e. at `t=3+2x`, which for all realistic RTTs would be earlier.

-- 
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/2435#issuecomment-462371300