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

[Lars Eggert <[e-mail]>]

@larseggert approved this pull request.

I flagged some minor nits, but otherwise good to go.

>  
 
-### ECN Validation {#ecn-validation}
+### Reporting ECN Counts
+
+Use of ECN requires the receiving endpoint to read the ECN field from an IP
+packet, which is not possible on all platforms. If an endpoint does not
+implement ECN support or does not have access to received ECN field, it

```suggestion
implement ECN support or does not have access to received ECN fields, it
```

>  
 
-### ECN Validation {#ecn-validation}
+### Reporting ECN Counts
+
+Use of ECN requires the receiving endpoint to read the ECN field from an IP
+packet, which is not possible on all platforms. If an endpoint does not
+implement ECN support or does not have access to received ECN field, it
+does not report ECN counts for packets it receives.
+
+Even if an endpoint does not set an ECT field on packets it sends, the endpoint
+MUST provide feedback about ECN markings it receives, if these are accessible.
+Failing to report the ECN counts will cause the sender to disable use of ECN
+for packets to this receiver.

```suggestion
for this connection.
```

>  
-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
-the path is not showing consistent support for ECN.
+Each packet number space maintains separate acknowledgement state and separate
+ECN counts.  Coalesced QUIC packets (see {{packet-coalesce}}) share the same IP
+header so the ECN counts are incremented once for each QUIC packet.

```suggestion
header so the ECN counts are incremented once for each coalesced QUIC packet.
```

>  
-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
-the path is not showing consistent support for ECN.
+Each packet number space maintains separate acknowledgement state and separate
+ECN counts.  Coalesced QUIC packets (see {{packet-coalesce}}) share the same IP
+header so the ECN counts are incremented once for each QUIC packet.
+
+For example, if one each of an Initial, Handshake, and 1-RTT QUIC packet are
+coalesced into a single UDP datagram, the ECN counts for all three packet
+number spaces will be incremented by one each.

```suggestion
number spaces will be incremented by one each, based on the ECN field of the single IP header.
```

>  
-To reduce the chances of misinterpreting congestive loss as packets dropped by a
-faulty network element, an endpoint could set the ECT(0) codepoint for only the
-first ten outgoing packets on a path, or for a period of three RTTs, whichever
-occurs first.
+If an endpoint has cause to expect that IP packets with an ECT codepoint might
+be dropped by faulty network element, the endpoint could set an ECT codepoint

```suggestion
be dropped by a faulty network element, the endpoint could set an ECT codepoint
```

>  
-Erroneous application of ECN marks in the network can result in degraded
-connection performance.  An endpoint that receives an ACK frame with ECN
-counts therefore validates the counts before using them. It performs this
-validation by comparing newly received counts against those from the last
-successfully processed ACK frame. Any increase in ECN counts is validated
-based on the markings that were applied to packets that are newly
-acknowledged in the ACK frame.
+Erroneous application of ECN-CE markings by the network can result in degraded

```suggestion
Erroneous application of CE markings by the network can result in degraded
```

> +If an ACK frame newly acknowledges a packet that the endpoint sent setting
+either the ECT(0) or ECT(1) codepoint, ECN validation fails if the

```suggestion
If an ACK frame newly acknowledges a packet that the endpoint sent with
either the ECT(0) or ECT(1) codepoint set, ECN validation fails if the
```

> +network element that zeroes the ECN field or a peer that is unable to access
+ECN the markings.

```suggestion
network element that zeroes the ECN field or a peer that does not report 
ECN markings.
```

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