Subject: [quicwg/base-drafts] Clarify use of the term "supports ECN" (#1631)

From: mirjak <[email-masked]>
Date: Wed, 01 Aug 2018 08:07:51 -0700

See issue #158: "support" should only be used for the path. I have left two occasions where it is used for both the path and the peer but I think that is okay because it only addresses the case where there is no support.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Clarify use of the term "supports ECN" 

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 16:57:44 -0700

martinthomson commented on this pull request.

> @@ -1834,26 +1834,31 @@ congestion in the network by setting a codepoint in the IP header of a packet
 instead of dropping it.  Endpoints react to congestion by reducing their sending
 rate in response, as described in {{QUIC-RECOVERY}}.
 
-To use ECN, QUIC endpoints first determine whether a path and peer support ECN
-marking. Verifying the path occurs at the beginning of a connection and when the
+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 regarded as not supporting ECN, if ECN marked packets get dropped

remove the comma

>  connection migrates to a new path (see {{migration}}).
 
-Each endpoint independently verifies and enables ECN for the path from it to the
-peer.
+Each endpoint independently verifies and enables use of ECN by setting the IP
+header ECN codepoint to ECN Capable Transport (ECT) for the path from it to the

Which one?

-To verify that both a path and the peer support ECN, an endpoint MUST set one of
-the ECN Capable Transport (ECT) codepoints -- ECT(0) or ECT(1) -- in the IP
-header {{!RFC8311}} of all outgoing packets.
+To verify both that a path supports ECN and the peer can provide ECN feedback, 
+an endpoint MUST set the ECT(0) codepoint in the IP header of all outgoing packets
+{{!RFC8311}}. 

Trailing space.

> @@ -1834,26 +1834,31 @@ congestion in the network by setting a codepoint in the IP header of a packet
 instead of dropping it.  Endpoints react to congestion by reducing their sending
 rate in response, as described in {{QUIC-RECOVERY}}.
 
-To use ECN, QUIC endpoints first determine whether a path and peer support ECN
-marking. Verifying the path occurs at the beginning of a connection and when the
+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 regarded as not supporting ECN, if ECN marked packets get dropped
+or ECN marking are rewritten on the path.
+Verifying the path occurs at the beginning of a connection and when the

Passive voice.  "An endpoint verifies every path, both during connection establishment and when migrating to a new path (see {{migration}})."

-- 
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/1631#pullrequestreview-142604617

---

From: mirjak <[email-masked]>
Date: Thu, 02 Aug 2018 02:03:39 -0700

@mirjak pushed 1 commit.

722b8b5  comments by martinthomson

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1631/files/9f1cab9361e12cc0780d97239c2833f86a8cfc3b..722b8b5304efb2e34a84111ad9595fc03aeb9948

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Aug 2018 10:01:05 +0000 (UTC)

> -
-To verify that both a path and the peer support ECN, an endpoint MUST set one of
-the ECN Capable Transport (ECT) codepoints -- ECT(0) or ECT(1) -- in the IP
-header {{!RFC8311}} of all outgoing packets.
+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 regarded as not supporting ECN if ECN marked packets get dropped
+or ECN marking are rewritten on the path.
+An endpoint verifies the path, both during connection establishment 
+and when migrating to a new path (see {{migration}}).
+
+Each endpoint independently verifies and enables use of ECN by setting the IP
+header ECN codepoint to ECN Capable Transport (ECT) for the path from it to the
+other peer. Even if ECN is not used on the path to the peer, the endpoint MUST
+provide ECN feedback information if the receive of a non-zero ECN IP codepoint
+is observed.

Grammar here could be improved: "an endpoint MUST provide ECN feedback information if it receives packets with non-zero 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/1631#pullrequestreview-142724553

---

From: mirjak <[email-masked]>
Date: Thu, 02 Aug 2018 14:28:56 +0000 (UTC)

mirjak commented on this pull request.

Maybe just "the endpoint MUST provide feedback about ECN markings received (if accessible)." Is that better?

-- 
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/1631#discussion_r207247316

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Aug 2018 22:25:27 +0000 (UTC)

Yeah, concise and correct.  You can just drop the parenthetical: if the markings aren't accessible, the endpoint didn't get them.

-- 
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/1631#discussion_r207393504

---

From: mirjak <[email-masked]>
Date: Mon, 06 Aug 2018 09:02:13 +0000 (UTC)

@mirjak pushed 1 commit.

7f405f8  Another wording comment by @martinthomson + remove trailing whitespace

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1631/files/722b8b5304efb2e34a84111ad9595fc03aeb9948..7f405f8cbc2aee2bbfcd7dc3e61b60f4bb247153

---

From: janaiyengar <[email-masked]>
Date: Tue, 07 Aug 2018 19:10:15 +0000 (UTC)

I don't think this distinction is useful, and I don't understand it. An endpoint can choose to not support ECN, for whatever reason, one of them being that the ECN codepoints are not accessible. If it helps to clarify this, I'm happy to write something that clarifies what "endpoint support of ECN" means... I don't think we need more than a sentence.

-- 
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/1631#issuecomment-411167771

---

From: Mike Bishop <[email-masked]>
Date: Tue, 07 Aug 2018 21:04:59 +0000 (UTC)

MikeBishop commented on this pull request.

-connection migrates to a new path (see {{migration}}).
+or ECN marking are rewritten on the path. An endpoint verifies the path, both

"marking**s** are"; "An endpoint verifies **each** path"

-peer.
-
-To verify that both a path and the peer support ECN, an endpoint MUST set one of
-the ECN Capable Transport (ECT) codepoints -- ECT(0) or ECT(1) -- in the IP
-header {{!RFC8311}} of all outgoing packets.
+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 regarded as not supporting ECN if ECN marked packets get dropped
+or ECN marking are rewritten on the path. An endpoint verifies the path, both
+during connection establishment and when migrating to a new path (see
+{{migration}}).
+
+Each endpoint independently verifies and enables use of ECN by setting the IP
+header ECN codepoint to ECN Capable Transport (ECT) for the path from it to the
+other peer. Even if ECN is not used on the path to the peer,the endpoint MUST

space

> @@ -1862,7 +1867,7 @@ concerns.
 If an endpoint receives a packet without an ECT or CE codepoint, it responds per
 {{processing-and-ack}} with an ACK frame.
 
-If an endpoint does not support ECN or does not have access to received ECN
+If an endpoint does not have access to received ECN
 codepoints, it acknowledges received packets per {{processing-and-ack}} with an
 ACK frame.

Rewrap.

-- 
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/1631#pullrequestreview-144183486

---

From: mirjak <[email-masked]>
Date: Thu, 09 Aug 2018 09:40:55 -0700

Actually the endpoint only verifies the forward path (the path from that endpoint to the other endpoint). Use of ECN of the "backward" path is verified by the other endpoint (given it's its forward path). Do we need to clarify this?

-- 
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/1631#discussion_r208999802

---

From: mirjak <[email-masked]>
Date: Thu, 09 Aug 2018 09:41:55 -0700

@mirjak pushed 1 commit.

f560aef  comments @MikeBishop

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1631/files/7f405f8cbc2aee2bbfcd7dc3e61b60f4bb247153..f560aefac6325b8dabd7581594bb50cb86306d02

---

From: Mike Bishop <[email-masked]>
Date: Thu, 09 Aug 2018 10:13:35 -0700

> @@ -1862,9 +1867,8 @@ concerns.
 
-If an endpoint does not support ECN or does not have access to received ECN
-codepoints, it acknowledges received packets per {{processing-and-ack}} with an
-ACK frame.
+If an endpoint does not have access to received ECN codepoints, it acknowledges 

Rewrap, but without making the line long enough to produce a build break.

-- 
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/1631#pullrequestreview-144939922

---

From: mirjak <[email-masked]>
Date: Fri, 10 Aug 2018 02:24:18 -0700

@mirjak pushed 1 commit.

adfd8fa  tailing space :-(

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1631/files/f560aefac6325b8dabd7581594bb50cb86306d02..adfd8fab5ae6671414456e02b377a90412552812

---

From: mirjak <[email-masked]>
Date: Fri, 10 Aug 2018 02:27:38 -0700

@mirjak pushed 1 commit.

e145873  line break

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1631/files/adfd8fab5ae6671414456e02b377a90412552812..e1458737054dc23ca1dc899fce1333cfba3bf3dd

---

From: mirjak <[email-masked]>
Date: Fri, 10 Aug 2018 02:31:40 -0700

@mirjak pushed 1 commit.

d102652  tailing space agian

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1631/files/e1458737054dc23ca1dc899fce1333cfba3bf3dd..d1026527f33d091842738e5b901ae2cc14c2c2cf

---

From: mirjak <[email-masked]>
Date: Tue, 14 Aug 2018 07:37:48 -0700

@mirjak pushed 1 commit.

dcc9418  one more "support" in the ACK_ECN Frame section

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1631/files/d1026527f33d091842738e5b901ae2cc14c2c2cf..dcc941812e5b357f32824ecae49efc70141e316f

---

From: Martin Thomson <[email-masked]>
Date: Sun, 26 Aug 2018 22:19:08 -0700

Merged #1631 into master.

-- 
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/1631#event-1809783236