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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> -experiencing congestion.
+It is possible for faulty network devices on path to corrupt or erroneously drop
+all IP packets with ECN Capable Transport (ECT) codepoints set.  To provide
+robust connectivity in the presence of such devices, each endpoint independently
+verifies and enables use of ECN.  Even if not setting ECT codepoints on packets
+it transmits, the endpoint SHOULD provide feedback about ECN markings received
+if they are accessible.
+
+To verify both that a path supports ECN and that the peer can provide ECN
+feedback, an endpoint initially sets the ECT(0) codepoint in the IP header of
+all outgoing packets {{!RFC8311}}.
+
+If all packets with ECT codepoints are dropped by a network device, endpoints
+can detect loss of the packets and MAY cease setting ECT codepoints in
+subsequent packets.  As one concrete strategy, an endpoint could disable setting
+of ECT codepoints if Initial packets with ECT codepoints set are deemed lost.

I think that it is going to need to be all.  But that leads to the question: do you let the handshake time out? Do you interleave ECT-marked and unmarked packets? Or do you start with ECT and switch the markings off after a few tries (and how many tries)?

Also, this needs to be all marked packets sent on a given path.  It is not just Initial packets, but also Handshake or 0-RTT and maybe those with short headers after a migration.

>  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

This paragraph doesn't really seem to say anything now.  You have deleted the timeout thing.  So it's not clear how you decide that a path *doesn't* support ECN now.

The point of having a timeout is to detect a black hole.  One nice thing about QUIC is that the idle timeout can be longer than any ECN validation timeout, so - at the risk of suggesting a design - maybe we could recommend that endpoints send the first packets it sends on any path marked, then they might stop marking until ECN support is confirmed.  We don't need to set a fixed rule, but it probably makes sense to recommend something.  The first N packets (where N of 10 produces pretty high confidence) or one round trip (which will be estimated based on the previous path, but that is OK) might work.  If you don't get a positive result, which might happen if the first few packets are lost for other reasons, we'll disable ECN more than is ideal, but we can allow the test to be retried.

(Maybe you could add this above the bullet list above, where I can't comment:
"A path is verified if ECT markings are either forwarded without change or the network changes the marking to Congestion Experience (ECN-CE)."
)

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

This is not a permanent condition.  If only one packet was marked, you might consider the path ECN-capable based on an acknowledgement of that packet.  However, that could be the result of random corruption.

I think that we can just say "until validation of ECN counts fails".  So we have the following algorithm:

For each path:

0. set ECN state to "testing"
1. after N packets or M round trips, set ECN state to "unknown"
2. on every ACK, check ECN counts
3. if ECN validation fails set ECN state to "failed".
4. if ECN validation passes and ECN state is "uncertain", set it to "capable".
5. when sending packets, mark with ECT(0) if state is "testing" or "capable"

(I know that this is unchanged text, but I just realized that we could be clearer.)

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