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

[Christian Huitema <[e-mail]>]

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

RFC3168 does say that the response to an ECN mark must be the same as to a dropped packet. However, different congestion control algorithms may well respond to dropped packets differently. Receivers may detect that the sender's algorithm does not respond as TCP-Reno would, but then so what? It just means that the sender's congestion control algorithm is different from TCP-Reno.

-- 
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_r206985670