Having a draft is good, but we are obviously facing a tradeoff: more
precise ECN feedback may improve the performance of the L4S congestion
control, but increasing the fidelity of ECN reporting increases the size
of the ACKs and thus affects performance overall.
In fact, I am not sure that there is much of a performance gain if the
node is using L4S. L4S tracks the state of the path by computing a
rolling ratio "alpha" of packets marked with CE vs total number of
packets acknowledged. Without the "ECN fidelity" improvement, that ratio
is computed with a weight of 1 per packet. With the improvement, the
weight of a packet is set to the number of bytes sent in the packet. The
theoretical foundations for that are weak, because it is unclear whether
the CE marking strategy of routers is based on bytes or packets. It is
also unclear whether the two ways of computing that ratio provide
significant differences in practice.
Then there is the fact that many CC algorithms do not actually use L4S
strategy of making CWIN increases proportional to the number of CE
marking. BBR, for example, will tune the sending rate based on observed
data rates, and will just use the arrival of "more than usual" CE marks
as a signal to slow down.
And finally there is the issue that ECN is not an "honest signal", in
the sense that it is pretty easy for networks to "fake it", either in
some misguided effort at traffic engineering, or simply because of bugs.
That much easier than faking transmission delays or transmission rates,
and less costly for the network's reputation than just dropping packets.
But if you want to experiment with variations of ECN, then yes having a
draft and an extension code point is a very good idea.
-- Christian Huitema
On 11/17/2023 9:16 PM, Marten Seemann wrote:
Quick update: I just published the draft (
https://datatracker.ietf.org/doc/draft-seemann-quic-accurate-ack-ecn/).
Thanks to Vidhi for a lot of clarifying text and an encoding example!
On Sat, 4 Nov 2023 at 10:08, Kazuho Oku <[email protected]> wrote:
2023年11月4日(土) 4:06 Kazuho Oku <[email protected]>:
2023年11月2日(木) 3:07 Martin Thomson <[email protected]>:
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.
FYI we discussed alternative encoding schemes at the interim in Sep 2018:
* slides: file:///Users/kazuho/Downloads/ack-ecn.pdf
Agh. Only I can see this URL, the correct one is
https://github.com/quicwg/wg-materials/blob/master/interim-18-09/ack-ecn.pdf
* notes:
https://github.com/quicwg/wg-materials/blob/main/interim-18-09/minutes.md#ack-ecn---ian
(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?
--
Kazuho Oku
--
Kazuho Oku
