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 (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, 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?
