Re: [quicwg/base-drafts] Proposal for adding ECN support to QUIC. (#1372)

[Magnus Westerlund <[e-mail]>]

gloinul commented on this pull request.



> +This capability check thus has verified that one direction of the path between
+the peers is free from issues with ECN bleaching and that the application does
+not experience problems with access to the ECN field in the IP header. In this
+case the marking of the generated packets with ECT continues.
+
+If an ACK frame (not the ACK_ECN frame) is used to acknowledge reception of
+packets that was marked as ECT in the sender, or if the comparision of the
+counters with the total of acknolwedged packets indicates that not all packets
+arrive as ECT(0), ECT(1) or ECN-CE, then the path is determined as not ECN
+Capable.  If the endpoint determine the path as currently not ECN capable it
+SHALL stop marking the packets as ECT, and instead mark them as Not-ECT. If the
+connection is migrated then the ECN capability check is rerun as specified in
+{{ecn-connection-migration}}.
+
+
+### Continuous Verification of ECN {#ecn-continuous-verification}

It also requires one to send one ACK_ECN frame for any marked, and one ACK for any Not-ECT marked IP packets. That was not my original intention, but I think works fine. So, yes I think changing the ACK_ECN frame to use this proposal would improve efficiency when it works. 

When it comes to ACK loss there will be no effect if the lost ACKs only acknowledged ECT(0) pakets. If there was ACKs lost that incremented the CE or ECT(1) counters then it would be in the same situation. The sender can detect the event and record a new comparison point so that it doesn't effect the future bleaching detections. 

-- 
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/1372#discussion_r196400399