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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



>  
-* Set the ECT(0) codepoint in the IP header of early outgoing packets sent on a
-  new path to the peer ({{!RFC8311}}).
+* The endpoint sets an ECT(0) or ECT(1) codepoint in the IP header of early

To Lars' point below, adding ECT(1) probably isn't a good idea here.  This is probably the critical point at which we mention only ECT(0).  So I've struck ECT(1) from this.

> +frame.  This is why ECN counts are permitted to be larger than the value
+corresponding to the largest acknowledged packet number.

I agree with Jana here.  The original text is better.  The only tweak I might make is to say "counts to be greater than the number of packets *that are newly* acknowledged *by* an ACK frame."

I've reverted and made that change.

> +To reduce the chances of misinterpreting loss of packets dropped by a faulty
+network element, an endpoint could set an ECT codepoint for only the first ten
+outgoing packets on a path, or for a period of three RTTs, whichever occurs
+first.

I've reworded this; let me know if this works.

> +{{?RFC8311}}. Implementations that use the ECT(1) codepoint need to
+perform ECN validation using the reported ECT(1) counts.

This should be the only place that ECT(1) is mentioned, aside from the requirement to count and report the count.

>  
-ECN validation MAY fail if the total count for an ECT(0) or ECT(1) marking
-exceeds the total number of packets sent with the corresponding marking.   In
-particular, an endpoint that never applies a particular marking can fail
-validation when a non-zero count for the corresponding marking is received.
-This check can detect when packets are marked ECT(0) or ECT(1) in the network.
+Out of order processing of the ECN counts can result in a validation failure.
+An endpoint SHOULD skip ECN validation for an ACK frame that does not increase

I've tried to reword this to be clearer.  Let me know if this makes more sense now.

>  
-It is possible for faulty network devices to corrupt or erroneously drop packets
-with ECN markings.  To provide robust connectivity in the presence of such
-devices, each endpoint independently validates ECN counts and disables ECN if
-errors are detected.
+For example, if one each of an Initial, 0-RTT, Handshake, and 1-RTT QUIC packet
+are coalesced, the corresponding counts for the Initial and Handshake packet
+number space will be incremented by one and the counts for the application data
+packet number space will be increased by two.

This is how the protocol works.  The expectation is that a sender will correct for any double-counting.  That is, it will map newly acknowledged packets to the expected increase in counts and the number of *IP* packets that were sent.

>  
-#### Sending ECN Markings
+It is possible for faulty network devices to corrupt or erroneously drop packets
+that set an ECN codepoint.  To provide robust connectivity in the presence of
+such devices, an endpoint validates the ECN counts for each network path  and

This is introduction.  The explanation you seek follows.

-- 
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#pullrequestreview-483728655