From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A4D9021F5D3 for ; Thu, 25 Jun 2015 11:53:31 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t5PIqvjU018872; Thu, 25 Jun 2015 11:52:57 -0700 Date: Thu, 25 Jun 2015 11:52:57 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Jonathan Morton In-Reply-To: <40204878-C1F4-4AFE-8FD8-72D0B83144FE@gmail.com> Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA34B30B4C@ESESSMB205.ericsson.se> <04ED8D23-53C3-4F12-9647-3A07FFB43352@tik.ee.ethz.ch> <40204878-C1F4-4AFE-8FD8-72D0B83144FE@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1766480597-1435258383=:21895" Cc: "cheshire@apple.com" , "iccrg@irtf.org" , "Bob Briscoe \(bob.briscoe@bt.com\)" , Ingemar Johansson S , =?ISO-8859-15?Q?Mirja_K=FChlewind?= , "bloat@lists.bufferbloat.net" , "ietf@trammell.ch" Subject: Re: [Bloat] ECN issues X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 18:53:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1766480597-1435258383=:21895 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT 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 --680960-1766480597-1435258383=:21895--