[quicwg/base-drafts] Loss-detection happens after CC-increase, leading to higher congestion window (#3495)

[Christoph Paasch <[e-mail]>]

In the pseudo-code in appendix A.6, the call to ```DetectLostPackets``` is after ```OnPacketAcked```, while the call to ```ProcessECN``` is before that:

```
  // Process ECN information if present.
  if (ACK frame contains ECN information):
      ProcessECN(ack, pn_space)

  for acked_packet in newly_acked_packets:
    OnPacketAcked(acked_packet.packet_number, pn_space)

  DetectLostPackets(pn_space)
```

This means that if I get an ACK while in slow-start that indicates a packet-loss, the stack will first call ```OnPacketAcked``` (which ends up increasing the congestion-window) and only later enter recovery through ```DetectLostPackets```. Meaning, the congestion-window will actually be bigger than the flight-size that caused the packet-loss.

E.g., if cwnd is 10 while in slow-start and 10 packets were sent. If I get an ACK for 9 packets, indicating a hole, the congestion-window will first increase to 19 and then enter congestion-avoidance and reduce the congestion-window to 13 (assuming Cubic). Thus, the congestion-window is effectively bigger than 10 while it should be smaller than 10 (the flight-size that caused the packet-loss).

Shouldn't we process the loss before ```OnPacketAcked```, the same way ECN is being processed before that?

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