Subject: [quicwg/base-drafts] Add handling of all packets marked as CE (#3455)

From: mirjak <[email-masked]>
Date: Thu, 13 Feb 2020 07:12:21 -0800

This is actually a behaviour that has been observed a few time on the Internet. In TCP this case is encounter as ECN will be disabled if the SYN is CE marked (as the SYN should always be Not-ECT these days). I just realised that this validation is rather easy to detect if any Not-ECT have been sent, I think it would be good to mention is explicitly.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Add handling of all packets marked as CE

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3455.patch
https://github.com/quicwg/base-drafts/pull/3455.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/3455

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Feb 2020 15:55:53 -0800

martinthomson commented on this pull request.

Thanks for doing this.  

This is a design change and needs a corresponding issue.

A few typos and suggestions below.

> @@ -3517,6 +3517,13 @@ use the following steps on receiving an ACK frame to validate ECN.
   corresponding ECT codepoint that are newly acknowledged in this ACK frame.
   This step detects any erroneous network remarking from ECT(0) to ECT(1) (or
   vice versa).
+  
+Another special case is when all packets are indicatd as CE marked,

```suggestion
Another special case is when all packets are marked ECN-CE,
```

> @@ -3517,6 +3517,13 @@ use the following steps on receiving an ACK frame to validate ECN.
   corresponding ECT codepoint that are newly acknowledged in this ACK frame.
   This step detects any erroneous network remarking from ECT(0) to ECT(1) (or
   vice versa).
+  
+Another special case is when all packets are indicatd as CE marked,
+independtly of the initial codepode used, including Not-ECT. In this case

```suggestion
independent of the marking used, including Not-ECT. In this case
```

> @@ -3517,6 +3517,13 @@ use the following steps on receiving an ACK frame to validate ECN.
   corresponding ECT codepoint that are newly acknowledged in this ACK frame.
   This step detects any erroneous network remarking from ECT(0) to ECT(1) (or
   vice versa).
+  
+Another special case is when all packets are indicatd as CE marked,
+independtly of the initial codepode used, including Not-ECT. In this case
+it could be a network element overwriting the ECN field of all packets and

Let's not say why we think this is happening and go straight to the action:

> If a peer indicates that all received packets are ECN-CE marked, endpoints MAY treat this as an ECN validation failure and ignore any ECN-CE counts in acknowledgments.

-- 
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/3455#pullrequestreview-358633335

---

From: mirjak <[email-masked]>
Date: Fri, 14 Feb 2020 02:36:11 -0800

@mirjak pushed 1 commit.

4112f50a3c530a47bfded1eeaaf71943be2ed204  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3455/files/a5241b69840374b9aa510061dc2a06f02575101c..4112f50a3c530a47bfded1eeaaf71943be2ed204

---

From: mirjak <[email-masked]>
Date: Fri, 14 Feb 2020 02:36:23 -0800

@mirjak pushed 1 commit.

d6ca8a869a454d1cc434904f5bf93cd69195c341  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3455/files/4112f50a3c530a47bfded1eeaaf71943be2ed204..d6ca8a869a454d1cc434904f5bf93cd69195c341

---

From: mirjak <[email-masked]>
Date: Fri, 14 Feb 2020 02:45:53 -0800

mirjak commented on this pull request.

I theory this could also be a valid congestion signal. Even if packets were marked Not-ECT there could one element that overwrite it to ECT and another later on that is actually congested and marks validly all packets as CE (I know it's rathe unlikely, just saying...). I found it kind of important to say that this is problematic as it could also conceal valid signals. How about:

"If this is caused by a network element erroneously overwriting the ECN code point field, it will also conceals actual congestion information. Therefore, if a peer indicates that all received packets are ECN-CE marked, endpoints MAY treat this as an ECN validation failure and ignore any ECN-CE counts in acknowledgments."

-- 
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/3455#discussion_r379364866

---

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Feb 2020 15:08:30 -0800

WFM s/conceals/conceal/

-- 
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/3455#discussion_r379941823

---

From: mirjak <[email-masked]>
Date: Mon, 17 Feb 2020 03:30:23 -0800

@mirjak pushed 1 commit.

4886482ddea3d3fc25269f1731f3d0e1d2afdaff  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3455/files/d6ca8a869a454d1cc434904f5bf93cd69195c341..4886482ddea3d3fc25269f1731f3d0e1d2afdaff