Re: [Bloat] Comcast upped service levels -> WNDR3800 can't cope...

[Jonathan Morton <chromatix99@gmail.com>]

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.
> 
> 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.  :-)
> 
> It is partially a reference to a scene in the 2010 sequel to 2001.


I need to re-watch that.

 - Jonathan Morton