Re: [quicwg/base-drafts] ECN verification text (#2752)

[mirjak <[e-mail]>]

mirjak commented on this pull request.



>  If verification fails, then the endpoint ceases setting ECT codepoints in
 subsequent IP packets with the expectation that either the network path or the
 peer does not support ECN.
 
-If an endpoint sets ECT codepoints on outgoing IP packets and encounters a
-retransmission timeout due to the absence of acknowledgments from the peer (see
-{{QUIC-RECOVERY}}), or if an endpoint has reason to believe that an element on
-the network path might be corrupting ECN codepoints, the endpoint MAY cease
-setting ECT codepoints in subsequent packets.  Doing so allows the connection to
-be resilient to network elements that corrupt ECN codepoints in the IP header or
-drop packets with ECT or CE codepoints in the IP header.
+If an ECT codepoint set is not dropped or corrupted by a network device, then a
+received packet contains either the codepoint sent by the peer or the Congestion
+Experienced (CE) codepoint set by a network device that is experiencing
+congestion.
+
+Upon successful verification, an endpoint continues to set ECT codepoints in
+subsequent packets with the expectation that the path is ECN-capable.

Under the assumption that ECN-based black holing basically doesn't exists anymore or at at least was not measurable anymore, I would like to propose to enable ECN-marking from the beginning and simply disable ECN on time-out or if acks without ECN feedback are received. Of course ECN could be enabled anytime again if you want to try again, however, no matter if in "testing" or not if you don't receive ECN feedback (anymore) for whatever reason, you should stop using ECN no matter what.

-- 
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/2752#discussion_r310056524