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

[mirjak <[e-mail]>]

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

Actually this is a bit weak. RFC3168 say
"Upon the receipt by an ECN-Capable transport of a single CE
packet, the congestion control algorithms followed at the end-
systems MUST be essentially the same as the congestion control
response to a single dropped packet."
(where RFC8311 adds a
"unless otherwise specified by an Experimental RFC in the IETF document stream"
to this last sentence, however, this is not really important here).

The text as currently written indicates that the congestion controller can choose to account for ECN information at all or not which is not the case.

-- 
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#pullrequestreview-142453295