Hi, So being part of the ECN design team and driver behind the current text it is a result of quite some discussion. Something like what you proposed was discussed but I think the overhead was considered to be a bit high compared to unclear motivations for detailed per packet information. There are some motivation details in the ECN-in-QUIC wiki page: https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC but I would note that also indicates unclarity about what the needs for detailed reporting (see Requirement R.2).
If I remember correctly we where also expecting the SHOULD immediate acking of a CE packet be applied, thus at least the onset of any burst of CE marking should be provided timely, even if you don’t know exactly which packets. You will know within which set of packets this CE could have arrived in. And I guess that will still be true even if one after than aggregate, you will have a proportion of packets marked within the range acked. I would think the main issue would be related to those cases when also older packets are acked so the set of possible packets that could be marked are increased. As your ACK frequency issue https://github.com/quicwg/ack-frequency/issues/244 identifies it might be quite good to have some control for how much group reporting of CE marks the CC implementation deems acceptable. If you would ack every CE mark immediately you would likely assume that the CE marks applies to the highest PN received and it would be correct in most cases. That is however potentially expensive when it comes to the number of ACKs. I think on this issue we should look into adding some functionality to allow suppression of immediate ACK of CE when the receiver is continuously reporting CE marks in each ACK. I think the idea you mentioned of having a simple Boolean flag for suppressing sub-sequent CE marks is a good one. I think one can define suppression so that one immedietly ACK the first CE mark, then uses the other ACK frequency settings. And the suppression ends as soon as one have one ACK that doesn’t report additional CE marks received. So not having dive deep into Prague CC how important is the exact pattern of the CE marks in regards to packet numbers? Cheers Magnus From: QUIC <[email protected]> on behalf of Marten Seemann <[email protected]> Date: Wednesday, 1 November 2023 at 11:38 To: QUIC WG <[email protected]> Subject: more accurate ECN feedback in ACK frames While looking at Prague CC / L4S, I noticed that it might be useful if the sender could know which packet was CE-marked. This is currently not possible with the ACK frame defined in RFC 9000, as it only contains cumulative ECN counts. Instead of including cumulative counters at the end of the ACK frame, we could have encoded the ECN markings alongside the ACK ranges. This would lead to ACK frames with more ACK ranges when a lot of packets are received alternating ECN markings. However, in the steady state of L4S, 2 packets per RTT are expected to be CE-marked, so the overhead would be negligible. I wrote up an alternative encoding scheme in https://github.com/marten-seemann/draft-seemann-quic-accurate-ack-ecn<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-8c7ec7d2b94f75e8&q=1&e=6910a457-e43e-4e9a-8848-a23b1a51b019&u=https%3A%2F%2Fgithub.com%2Fmarten-seemann%2Fdraft-seemann-quic-accurate-ack-ecn> (I currently can't submit it as a draft, since the datatracker doesn’t allow new submissions past the deadline for 118). ECN counts were introduced in https://github.com/quicwg/base-drafts/pull/1372<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-7290d9e512b4d252&q=1&e=6910a457-e43e-4e9a-8848-a23b1a51b019&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F1372>, based on the output of a design team. Why did we decide to introduce these counters, instead of explicitly encoding the ECN marking for every packet? Is it because that's all we needed back then for classic ECN support?
