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

[mirjak <[e-mail]>]

mirjak 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
-connection migrates to a new path (see {{migration}}).
-
-Each endpoint independently verifies and enables ECN for the path from it to the
-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

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