[quicwg/base-drafts] Fragility in ECN counters with lost acks (#1481)

[janaiyengar <[e-mail]>]

The proposed text for ECN (in https://github.com/gloinul/base-drafts/pull/3) says: "The increase in ECT(0) and ECT(1) counters MUST be no greater than the number of packets newly acknowledged that were sent with the corresponding codepoint."

As @gloinul observed in his PR and @martinthomson noted in his review, this can cause ECN to be disabled when acks are lost. A sender may never receive an ack for a packet that was in fact acknowledged, and might see an increase in ECN counters without a corresponding packet being newly acked. This should be addressed.

@martinthomson writes: "Say a marked packet gets through and gets acknowledged, but the acknowledgment is lost. And the recipient abandons the ACK. The counters will increase, but the number of newly acknowledged packets will be lower than the increase to the counters. That suggests a tweak, though it complicates things a little:

If the acknowledgments cover a range of packet numbers that extend past (or adjacent to) the largest acknowledged packet number that was previously acknowledged, then the counters must match precisely. If the acknowledgments do not extend to the largest previously acknowledged packet number, then the numbers MAY increase by the number of unacknowledged packets between the previously largest acknowledged and the newly lowest acknowledged.

That is, if an endpoint has seen an ACK_ECN for packet 10, then receives a new ACK_ECN for packet 20-30, it needs to allow for an increase in the counters for packets 11 through 19 (inclusive). It can then reset both the largest acknowledged and the values it tracks for each counter."


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