Re: [quicwg/base-drafts] Consequences of bad ECN markings (#1626)

[ianswett <[e-mail]>]

ianswett commented on this pull request.



> +peer.  Suppressing reports of ECN-CE markings could cause a peer to increase
+their send rate.  This increase could result in congestion and loss.
+
+An endpoint MAY attempt to detect suppression of reports by marking occasional
+packets that they send with ECN-CE.  If a packet marked with ECN-CE is not
+reported as having been marked when the packet is acknowledged, the endpoint
+SHOULD then disable ECN for that path.
+
+Reporting additional ECN-CE markings will cause a peer to reduce their sending
+rate, which is similar in effect to advertising reduced connection flow control
+limits and so no advantage is gained by doing so.
+
+Endpoints choose the congestion controller that they use.  Though congestion
+controllers ideally use reports of ECN markings as input, the exact response for
+each controller could be different.  Failure to correctly respond to information
+about ECN markings is therefore difficult to detect.

Clearly there are congestion controllers which don't support ECN, particularly not 3168 style ECN.

As an example, DCTCP (RFC8257) specifies a mechanism which is different from 3168.

Maybe we don't need this paragraph at all?

-- 
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/1626#discussion_r206945335