Re: [quicwg/base-drafts] Gorry's ECN rewrite (#4059)

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.



>  
 
 ### ECN Counts
 
-On receiving a QUIC packet with an ECT or CE codepoint, an ECN-enabled endpoint
-that can access the ECN codepoints from the enclosing IP packet increases the
-corresponding ECT(0), ECT(1), or CE count, and includes these counts in
-subsequent ACK frames; see {{generating-acks}} and {{frame-ack}}.
-
-An IP packet that results in no QUIC packets being processed does not increase
-ECN counts.  A QUIC packet detected by a receiver as a duplicate does not
-affect the receiver's local ECN codepoint counts; see {{security-ecn}} for
-relevant security concerns.
+Use of ECN requires the receiving endpoint to read the ECN codepoint from an IP

Perhaps the following makes it easier? "requires the sending endpoint to write an ECN codepoint to IP headers and the receiving endpoint to read the ECN ..."

> +packet are processed. A QUIC packet detected by a receiver as a duplicate also
+does not increase an ECN count; see {{security-ecn}} for relevant security

Do we define what "processed" means? We probably should.

>  
-* If all packets that were sent with the ECT(0) codepoint are eventually deemed
-  lost (Section 6 of {{QUIC-RECOVERY}}), validation is deemed to have failed.
+If an endpoint has cause to expect that IP packets with an ECT codepoint might

This isn't a departure from existing text -- see lines 3953-3956 in the old text.

>  
-ECN validation fails if the sum of the increase in ECT(0) and ECN-CE counts is
-less than the number of newly acknowledged packets that were originally sent
+ECN validation also fails if the sum of the increase in ECT(0) and ECN-CE counts

What are you undo'ing?

>  with an ECT(0) marking.  Similarly, ECN validation fails if the sum of the
 increases to ECT(1) and ECN-CE counts is less than the number of newly
 acknowledged packets sent with an ECT(1) marking.  These checks can detect
-removal of ECN markings in the network.
+remarking of ECN-CE markings by the network.

Remarking means that the network marks the bits to something else. The point here is that something in the  network marked the bits to CE, and now another element is remarking it to something else. Perhaps "erasing of ECN-CE markings"?

>  
-Processing ECN counts out of order can result in validation failure.  An
-endpoint SHOULD skip ECN validation on an ACK frame that does not increase the
-largest acknowledged packet number.
+ECN validation can fail if the received total count for either ECT(0) or ECT(1)

This is a reword of lines 3992-3996. I don't remember why this was written as a MAY earlier (as against a MUST, or just "fails"), but the new language is changing phrasing to "can" from "MAY". @martinthomson might remember why this isn't a failure requirement.

>  
-Processing ECN counts out of order can result in validation failure.  An
-endpoint SHOULD skip ECN validation on an ACK frame that does not increase the
-largest acknowledged packet number.
+ECN validation can fail if the received total count for either ECT(0) or ECT(1)
+exceeds the total number of packets sent with each corresponding ECT codepoint.
+In particular, validation will fail when an endpoint receives a non-zero ECN
+count corresponding to an ECT codepoint that it never applied.  This check
+detects when packets are remarked to ECT(0) or ECT(1) in the network.

"Remarked" is important here, since it means that the endpoint marked packets as ECT(0) or ECT(1), and the network remarked it to one of those.

-- 
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/pull/4059#discussion_r485991483