Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-04.txt

[[e-mail]]

Thanks Dave,

To keep people informed, we have taken the Chairs' advice and kept the
current format in the new upcoming revision (will be -05), but we have
also tried hard to address concerns over the what is recommended, fix
inconsistencies where noted, and above all tried to make the document more
accessible to others.

Specifically on David's comments below.

This will clearly state that ToS field usage is deprecated, and explain
why this is bad for ECN.

We try to "describe" things that need to be done to support ECN, rather
than develop a requirements list, similarly we tried to avoid describing
pitfalls in this document. While neither should be forgotten, they did not
seem to us to be the things to record in this particular ID.

We did add text in the new version to a section "3.4 Co-existance of ECN
and non-ECN flows" that will not say how to handle multiple queues or how
to do things better, but it does say that AQM designers need to think
about the latency of queueing CE-marked packets, and that better
algorithms could be made.

We'll send this shortly to the list.

Gorry

> for many positive bullet points in the present document I can think of
> a negative counter-example in the real world that needs to be defeated
> in detail. Just off the top of my head:
>
> 3.2 tinc, when carrying tos, encapsulates the ecn markings also and
> does not apply them properly according to the various rfcs.
> 3.3 recently: one large providers equal cost multipath implementation
> used the full 8 bit tos field as part of the tuple. This worked fine,
> until CE started getting exerted by new aqms in the path, which led to
> massive packet re-ordering. Fixing it required fixing a ton of pretty
> modern vendor gear.
> 3.4: thus far, even with multiple queues, on the aqms I have, ECN
> marked traffic causes extra loss and delay in non ecn marked traffic.
> I agree that we should ecn mark sooner than drop, work is progressing.
>
> I would like it if non-traditional (ab)uses of ecn were covered - 1)
> attacks using ecn marked packets on dns servers, for example - and 2)
> future protocols that could use it (say, Quic).
> 3) as an example of something I've been fiddling with for a long time,
> coupling a routing protocol's metrics to something other than packet
> loss, and getting better "signal strength" by using ecn marked packets
> for more reliable communications under congestion.
>
> the draft touches upon voip uses (where I kind of think ecn is not the
> best idea), but does not touch upon videoconferencing well, where I
> think ecn protection of iframes would be a very good idea. So the
> guidance in sec 2.4 is a bit vague.
>
> aggregating transports with retries (e.g. wifi) could use ecn
> basically "for free" when experiencing trouble at the lowest layers of
> the stack.
>
> I know I have a tendency to accumulate the negatives (I do LIKE ecn),
> but would certainly like to have a fora, or a living document or wiki
> for potential sysadmins, vendors, and deployers to have a clear grip
> on what can go wrong when attempting to roll out ecn stuff.
>
> So I am mostly in favor of this document getting published, so long as
> someone steps up to also be an "ecn news central", chock full of user
> generated content on the pitfalls, tips, and tricks - and benefits! -,
> to guiding ecn deployment further along.
>
> ecn is inevitable. finally.
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>