On Thu, 25 Jun 2015, Jonathan Morton wrote: >> On 25 Jun, 2015, at 20:49, Dave Taht 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