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

[Magnus Westerlund <[e-mail]>]

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

Yes, to prevent spurious ECN disablement one should have a number of packets spread over time so that a single burst loss can't be the cause for the loss so that probability is low. So, the downside of the above algorithm is that to get low probability you may have several retransmission of the handshake. From an ECN perspective an implementation could mark a single packet per RTT and not give up testing until 10 RTTs has past. That would have a low probability for spurious disablement. 

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