Re: [quicwg/base-drafts] Improve ACK_ECN frame encoding (e.g., use bit-vector) (#1439)

[Magnus Westerlund <[e-mail]>]

@kazuho 

> By using ACK frames to carry the PNs along with their CE bits, it is possible for the sender to find and reject duplicate signals. The information that reaches the sender first is adopted (in contrast to the approach of #1372 that adopts the information that reaches the receiver first). That is the principle.

Okay, if that is the general principle to make this work, you can't only provide CE to PN mappings. You need to indicate which packets get ECT or not-ECT marks also. i.e. you need to provide the ECN field value for all the packets included in the ACK. Then the other mechanisms needed for ECN than congestion event detection also will work. 

Yes, as long as we have any counters in the ECN encoding, the receiver will need to either suppress the duplicates from being counted, or include a counter for how many duplicate packets it has included in the counters for the various ECN field values received. 

So in regards to duplicated packets, what is your policy for handling that truly when a receiver don't suppress the duplicate prior to ECN processing? [Additional required for counter handling when have CE vector and counters for ECT] 
A) The receiver reports what was first received for a PN, i.e. a duplicate is not allowed to overwrite any already stored ECN field value. [Any duplicate ECN field value is not added to counters]
B) The receiver reports what is stored in receiver when generating the ACK, i.e. the latest received information. Thus duplicates may overwrite ECN field values of the first, if ACK hasn't been sent yet. [Added to counter in the interest of simplicity] 
C) Reception of an ECN field value that is different from what already exists forces an ACK, then the field value is overwritten and reported in the next ACK packet. [Counter values added for all packets]
D) The ACK reports the ECN Field values explicit for first received and then any duplicates making it clear that this is multiple received packets for the PN? [Using counters this require a counter for duplicates]

My comment on these policies are the following:
A) Works and is an ECN level suppression of duplicate packets
B) Sensitive to on-the-side ECN field value attacks. [Duplication causes slack in detection] 
C) Forces a more complex handling of packets and triggering of ACKs and in cases of ACK loss an on-the-side attack may get its information in. [Duplication causes slack in detection when subject to ACK loss]
D) Full capability for sender to interpret information, more complex encoding the ECN information to enable multiple copies of a PN to be correctly represented. [Works when counting duplicates]

So beyond the primary purpose of ECN to detect congestion events, the mechanism needs to have capability also to:
* Detect working paths
* Detect bleaching in mid-connection
* Detect working path after connection migration
* Mitigate attacks, at least off-path or on-side attacks. On path attackers can cause the same response as well as additional issues by dropping packets for a connection. 

I hope this clarifies my view why I don't think CE vectors are sufficient. For a solution that doesn't suppress duplicates prior to ECN processing, one either need explicit counting of number of duplicates if using counters, or a per packet information that that includes both bits of the ECN field as well as indicating any duplicates not suppressed by the receiver. I think a efficiency comparison both in regards to size of ACKs as well as implementation complexity between these two are fine and should be done. 

-- 
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/issues/1439#issuecomment-397998222