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

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2020 02:40:00 -0700

This contains a lot of changes, but these seem to all be editorial.

@gorryfair is unable to engage here for a little while, but we should take that opportunity to provide feedback.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4059

-- Commit Summary --

  * Gorry&#39;s ECN rewrite, verbatim
  * fix nits; reorder

-- File Changes --

    M draft-ietf-quic-transport.md (194)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4059.patch
https://github.com/quicwg/base-drafts/pull/4059.diff

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Aug 2020 00:03:21 -0700

@martinthomson commented on this pull request.

This is a pretty disruptive and difficult to review.  I will need to take another pass at this.

> +ECN counts.  Coalesced packets (see {{packet-coalesce}}) carry several QUIC
+packets that share the same IP header.  The ECN count for the ECN codepoint

```suggestion
ECN counts.  Coalesced packets (see {{packet-coalesce}}) share the same IP header.
The ECN count for the ECN codepoint
```

Avoid a tautology.

> +received in the associated IP header are incremented once for each QUIC packet,
+not for the enclosing IP packet.

```suggestion
received in the associated IP header are incremented once for each QUIC packet.
```

> +An ECN count is not incremented when the received IP packet does not results in
+a QUIC packets being processed.  A QUIC packet detected by a receiver as a

```suggestion
An ECN count is not incremented when no QUIC packets from the received IP
packet are processed.  A QUIC packet detected by a receiver as a
```

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

I know that "remarking" is likely a term of art, but it is also a word with a completely different meaning.  I think we should avoid it.

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

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 28 Aug 2020 18:49:53 -0700

@janaiyengar commented on this pull request.

A few comments, but this seems to reduce text and is largely useful. Thank you, @gorryfair !

-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 CE-marks by the network can result in degraded

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

```suggestion
remarking of ECN-CE markings by the network.
```

-If an ACK frame newly acknowledges a packet that the endpoint sent with either
-ECT(0) or ECT(1) codepoints set, ECN validation fails if ECN counts are not
-present in the ACK frame.  This check detects a network element that zeroes out
-ECN bits or a peer that is unable to access ECN markings.
+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 ECN counts

```suggestion
either the ECT(0) or ECT(1) codepoint, ECN validation fails if the corresponding ECN counts
```

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

The old text makes sense to me, but I don't understand this proposed text. What value corresponding to the largest acknowledged PN is this text talking about? 

Perhaps "coalesced QUIC packets". Also "ECN counts" (plural, since different PN spaces).

"These checks can detect network elements that overwrite ECN-CE markings with an ECT(0) or ECT(1) codepoint."

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 30 Aug 2020 00:57:13 -0700

@gorryfair commented on this pull request.

(I couldn't clearly understand the old text in the old context... but expect the intention was fine.) Could someone propose a new sentence following the structure of the old one?

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