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

From: janaiyengar <[email-masked]>
Date: Tue, 26 Jun 2018 14:01:10 -0700

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Jun 2018 11:31:38 +0000 (UTC)

I think the general approach of handling this is correct. I don't think the MAY in the fourth paragraph is appropriate. The counters can increase due to their markings, not something that is specified by a RFC 2119 MAY. 

"It can then reset both the largest acknowledged and the values it tracks for each counter." I don't think reset is the appropriate word for something that is in practice baseline offsets to the comparison.

-- 
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#issuecomment-400640246

---

From: janaiyengar <[email-masked]>
Date: Thu, 28 Jun 2018 16:16:54 -0700

I don't think this is adequate. @ianswett pointed out that a sender may choose to not retain state about a packet that is not yet acknowledged because, for example, the contents were retransmitted in a new packet. When an ack for such a "forgotten" packet arrives, the endpoint won't know it to be an as yet unacknowledged packet, since there's no state for the packet. At the same time, the ECN counters would have increased.

-- 
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#issuecomment-401200988

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Jun 2018 00:26:45 -0700

Right now the text requires an exact match - the number of markings on newly acknowledged packets need to exactly match the increase in counters.  If you forgot a packet (and so don't know if it's newly acknowledged), then add one to the upper limit of the number.  If there is a gap between the lowest acknowledged packet number in this ACK and the largest packet number previously acknowledged, increase the upper limit by the same amount.

-- 
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#issuecomment-401271903