Proposal for adding ECN support to QUIC.

draft-ietf-quic-transport.md

@@ -1783,11 +1783,10 @@ IP packets continue to be transmitted with the applicable ECT code point. One po
 
 #### Case 2, ECN capability had previously failed
 
-The applicable ECT codepoint is set in the IP packets sent on the new path during and after the path migration and the ECN capability check as defined in {{ecn-capability-check}} is performed. However, some special considerations are needed due to the in mid connection check. The packet number for the first packet sent after the connection migration occured and the latest received, if ever, ECT(0), ECT(1) and ECN-CE counters need to be stored for later comparision. If no ECN counters have been received, then they are assumed to be zero. The ECN related counters may be non-zero if the connection had a ECN capable path for a period that then was migrated or stopped working. 
+The applicable ECT codepoint is set in the IP packets sent on the new path during and after the path migration, and then the ECN capability check as defined in {{ecn-capability-check}} is performed. However, some special considerations are needed due to the in mid connection check. The packet number for the first packet sent after the connection migration occured is stored. For the latest received ACK_ECN the ECT(0), ECT(1) and ECN-CE counters (ECN counters) need to be stored for later comparision. If no ACK_ECN has ever been received, then the all of the ECN counters are assumed to be zero. The ECN counters may be non-zero if the connection had a ECN capable path for a period that then was migrated or stopped working. 
 
-In the sub-sequent ACK or ACK_ECN received, the endpoint needs to track which packets that are acknowledged. Only packets sent after connection migration are included in the number of ACKed packets and compared to the difference in the ECN counters received in the ACK compared to the locally stored state. 
+If an ACK_ECN is received after a connection migration, but it contains acknowledgements for packets prior to the migration, then the stored ECN counters are updated with the values in the received ACK_ECN, also the value of the Largest Acknowledged, and a list of outstanding packet prior in sequence number to Largest Acknowledged are stored, but no further back then connection migration. If an ACK_ECN acknowleging only packets sent after connection migration is received, then then comparision is performed. First the number of ACKed packets are computed, by calculating how many packets with sequence number larger than Largest Acknowledged have been acknowledged, to that is added the number of packets of the outstanding that also have been acknolwedged. If the value of ACKed packets are non-zero, then the changes of the ECN counters between the stored and newely received are compared. If the sum of changes across the ECT(0), ECT(1) and ECN-CE are equal or larger than the number of ACKed packets, then ECN is confirmed to work. If an ACK frame is received, which acknowledge a non-zero number of packets that have a PN higher than the point of migration, it is concluded that ECN is not functional on the new path, and the ECT marking of any sent packets are stopped, and the packets will be marked as Non-ECT (00). 
 
-Note: This comparision is based on the assumption that no ECT packets where sent for at least the maximum packet life time in the network prior to the connection migration. This to avoid the risk that packets sent over the old path could result in a change of the ECN counters. 
 
 ### Loss Detection and Congestion Control {#migration-cc}