Re: [Bloat] ECN issues

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1659 bytes --]

On Thu, 25 Jun 2015, Jonathan Morton wrote:

>> 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.

From a purely pragmatic point of view, if a router will mark a packet as ECN 
instead of dropping it, DNS packets should be marked with ECN because other 
requests are serialized on the DNS lookup, so a dropped packet/timeout results 
in a very user-visible delay.

David Lang