On 02/11/2023 02:06, Martin Thomson wrote:
We knew that L4S was likely to come around and use markings more. What we
didn't know was exactly how that would end up looking, so I believe that the
idea was to do exactly what you are proposing: deal with it in an extension,
later. What we have works with what you call classic ECN, OGECN, but just like
fine-grained timing information, we decided to defer.
(That's my memory only, I don't think that I was involved in the design team
directly.)
On Wed, Nov 1, 2023, at 21:38, Marten Seemann wrote:
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?
On the history: The group of people who went away and thought about
this, used AccECN (draft-ietf-tcpm-accurate-ecn-26) as the starting
point, for what was then introduced into QUIC, it might be helpful to
compare with that.
Gorry
