From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A9CBC21F41B; Wed, 3 Sep 2014 04:04:11 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id w7so9343202lbi.15 for ; Wed, 03 Sep 2014 04:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h9R6oLpb+7cC+4HH0zLUmzLYzbn/4zVS9fqyGiMNbVM=; b=ucpuQ+EaNBBojopcEuES2Geb1+4ckTRXNPpgGcAjjaVhxSm2uJY1o3xSd3WyJnYc8u ocM+ig0G+fRXwrF2HrTyk4IuzQN4tinzQgnl/d07/ndj9SL8cIq9A7dSG56UpI6uMDR7 r0uzLeo+D9GF51tXMYeAfR+OehnhGd3YH92sn17x2+jTbEjNA3/1+/nhVhr6t1BhG1sf V2c+VhvTFlVWelWSjQHxVJhR/Ng2HdqJeymg8zCQC0bcb6OT/8fkbWN9HNkHism/H+Na jg70jg97Ty8smC/fRwk3bpeJM/StWam9Vwr8SumVDGj3N7IHFjp9cGhXdsp0GIHIYb+S 7lQw== X-Received: by 10.112.54.135 with SMTP id j7mr14220415lbp.51.1409742248892; Wed, 03 Sep 2014 04:04:08 -0700 (PDT) Received: from bass.home.chromatix.fi (178-55-226-0.bb.dnainternet.fi. [178.55.226.0]) by mx.google.com with ESMTPSA id b1sm1021414lah.34.2014.09.03.04.04.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 04:04:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Wed, 3 Sep 2014 14:04:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87ppfijfjc.fsf@toke.dk> <4FF4917C-1B6D-4D5F-81B6-5FC177F12BFC@gmail.com> <4DA71387-6720-4A2F-B462-2E1295604C21@gmail.com> <0DB9E121-7073-4DE9-B7E2-73A41BCBA1D1@gmail.com> <7D8C9C42-43E7-431E-B237-84B0937C81A0@gmail.com> To: Dave Taht X-Mailer: Apple Mail (2.1085) Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Bloat] Comcast upped service levels -> WNDR3800 can't cope... X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 11:04:12 -0000 On 2 Sep, 2014, at 6:37 pm, Dave Taht wrote: > > > tc qdisc add dev eth0 cake bandwidth 50mbit diffservmap std > > > > Or even having the "diffservmap std" part be in the defaults. I try = not to spend too much mental effort understanding diffserv - it's widely = misunderstood, and most end-user applications ignore it. Supporting the = basic eight precedences, and maybe some userspace effort to introduce = marking, should be enough. >=20 > The various ietf wgs seem to think AFxx is a useful concept. I'm sure they do. And I'm sure that certain networks make use of it = internally. But the Internet does not support such fine distinctions in = practice - at least, not at the moment. We have enough difficulty = getting SQM of *any* colour deployed where it's needed. A good default handling of Precedence would already be an improvement = over the status quo, and I've worked out a CPU-efficient way of doing = so. It takes explicit advantage of the fact that the overall shaping = bandwidth is known, but degrades gracefully in case the actual bandwidth = temporarily falls below that value. As I suggested previously, it gives = weighted priority to higher-precedence packets, but limits their = permitted bandwidth to prevent abuse. As it happens, simply following the Precedence field, and ignoring the = low-order bits of the Diffserv codepoint, satisfies the letter of the AF = spec. The Class field is encoded as a Precedence value, and the = drop-precedence subclasses then have equal drop probability, which the = inequality equations permit. The same equations say nothing obvious = about how a packet marked *only* with Precedence 1-4 should be treated = relative to AF-marked packets in the same Precedence band, which is part = of what gives me a headache about the whole idea. EF is also neatly handled by ignoring the low-order bits, since its = encoding has a high Precedence value. So, at the very least, more = refined AF/EF handling can be deferred to a "version 2" implementation. Reading the HTB code also gives me a headache. I have so far been = unable to distinguish any fundamental timing differences in its = single-class behaviour relative to TBF. The only clues I have so far = are: 1) HTB uses a different timer call to schedule a future wakeup than TBF = or FQ do. 2) FQ doesn't use a bucket of tokens, and explicitly avoids producing a = "burst" of packets, but HTB and TBF both do and explicitly can. 3) TBF is the only one of the three to exhibit unusually high softirq = load on egress. But this varies over time, even with constant bandwidth = and packet size. > > I like the name, though. :-) >=20 > It is partially a reference to a scene in the 2010 sequel to 2001. I need to re-watch that. - Jonathan Morton