Re: [Bloat] ECN issues

[Jonathan Morton <chromatix99@gmail.com>]

> On 25 Jun, 2015, at 20:49, Dave Taht <dave.taht@gmail.com> wrote:
> 
> In my case I just managed to show that congestive (rather than path)
> loss can be a factor in the reliability of even a low rate, CS6
> prioritized, link local multicast routing protocol (babel), over
> present day linux wifi, even using a modern fq+aqm+ecn system.

The conventional wisdom certainly is that ECN should be left off simple 1-RTT request-response protocols, where there is presumed to be no way to convey and act on the congestion information in the future.

DNS is such a protocol, at least for simple queries that fit into UDP.  Ergo, DNS generally doesn’t use ECN at present.

But in practice, a DNS resolver makes several queries in rapid succession, and often the resolver itself has sufficient persistence to be able to relay congestion state from one query to the next (especially if it’s a proxy in a CPE router).  DNS is also a critical latency factor in many practical Internet applications, especially Web traffic.  ECN capability effectively increases reliability of delivery when the bottleneck has AQM, and DNS should respond well to that, since upon loss (of either request or response) it has to wait for a exponential-backoff timeout.

I think that’s a concept worth pursuing.

- Jonathan Morton