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

[Lars Eggert <[e-mail]>]

@larseggert requested changes on this pull request.



> -rate in response, as described in {{QUIC-RECOVERY}}.
-
-To use ECN, QUIC endpoints first determine whether a path supports ECN marking
-and the peer is able to access the ECN codepoint in the IP header.  A network
-path does not support ECN if ECN marked packets get dropped or ECN markings are
-rewritten on the path. An endpoint validates the use of ECN on the path, both
-during connection establishment and when migrating to a new path
-({{migration}}).
+detect and respond to network congestion.  ECN allows an endpoint to set an ECT
+codepoint in the ECN field of an IP packet. A network node can then indicate
+congestion by setting the CE codepoint in the ECN field instead of dropping the
+packet {{?RFC8087}}.  Endpoints react to reported congestion by reducing their
+sending rate in response, as described in {{QUIC-RECOVERY}}.
+
+To enable ECN, a sending QUIC endpoint first determines whether a path supports
+ECN marking and whether reports the ECN value in received IP headers; see

```suggestion
ECN marking and whether the peer reports the ECN values in received IP headers; see
```

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

```suggestion
number spaces will be incremented by one each and the counts for the application data
```

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

```suggestion
that carry an ECN codepoint.  To provide robust connectivity in the presence of
```

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

```suggestion
* The endpoint MUST set the ECT(0) codepoint in the IP header of early
```
Can't validate if you don't set it.

>  
-* 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.
+* The endpoint SHOULD monitor whether all packets sent with an ECT codepoint are

```suggestion
* The endpoint MUST monitor whether all packets sent with an ECT codepoint are
```
Can't validate if you don't monitor.

> +  eventually deemed lost (Section 6 of {{QUIC-RECOVERY}}), deeming this as an
+  indication that ECN validation has failed.

```suggestion
  eventually deemed lost (Section 6 of {{QUIC-RECOVERY}}), indicating
  that ECN validation has failed.
```

> +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.

More needs to be said here about why this might be beneficial.

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

This whole ECN text needs to make up its mind on whether it wants to specify that ECT(0) should be used, or if it wants to allow ECT(0) or ECT(1). At the moment, it's a mix. And if it wants to allow both, some words need to be added whether an implementation should pick one statically or randomly or whatnot.

>  
-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.

What does "out of order processing of the ECN counts" mean? 

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

Why is this not a MUST?

-- 
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-481826612