[Cerowrt-devel] Testing Queue models

[Dave Taht]

Now that I have BQL and the new SFQ, ARED, and SFQRED working in
cerowrt, I have been working on modeling the behavior of existing
shapers (wshaper, openwrt, sfqred, and something more torrent-proof
that doesn't have a name yet)

There are several things that will get in the way of doing it well at
the present time, and I hope to evolve towards something that works
well in nearly all cases. For purposes of this discussion I'll use a
few abbreviations.

"u" = user
"d" = device
"f" = flow

Some general notes:

Accurately determining uplink bandwidth is something that no tool does
quite right today, and even then uplink bandwidth can be dynamic
(notably on cable). Van and Kathie are working on something that can
figure it out better, dynamically, but that code's not ready yet.
Instead I'm trying to pull together a shaperprobe that detects modern
conditions better, statically, at least.

Uplink speed is the principal bottleneck problem that users deal with.

I'm running SFQ on all interfaces. This helps break up streams into
more manageable chunks. It can be really NICE, on ethernet. In fact,
most of my network bottlenecks have moved to my desktops and laptops
in the general case, and to get best results I have to run the debloat
script and enable SFQ everywhere, in this wack-a-mole game.

SFQ has positive effects on wireless as sparse streams move forward in
the queue, and are thus shipped as an aggregate at the earliest
opportunity. Regrettably there is so much rate-insensitive fixed
buffering at present in the Linux wireless stack as to incur huge
penalties at variable rates.

It can have negative side effects on wireless, as it mucks with packet
aggregation across devices. That said, in home use (rather than with
dozens of wireless devices) it should help somewhat. I'm not worrying
about wireless behavior all that much right now, I'm mostly trying to
exercise the new code... as fixing the aggregation problems really
needs to have a per-destination queue somehow.

Developing correct configuration for RED and ARED is something of a dark art.

The new SFQ prioritizes new streams very well. Perhaps overly well.
Eric has a patch in progress
to make it have more of an idea of 'how new' a stream is. It otherwise
is very effective in reducing latency for short, sparse, streams.

SFQRED's mental model is closer to what an ISP would use on it's
downstream link. It is not (quite) right for what a site would use as
an uplink.

QFQ, which is what I was using to get 1/d level behavior in the
prototype I did several months back, still is hanging under load on
cerowrt. It's working on x86.  :( Might try working with classful SFQ
stuff instead, or I may give DRR a shot instead.

Even getting 1/d is hard because the filters can only use IP and IPv6
addresses, so a device issuing traffic on both ipv4 and ipv6 can get
twice what it deserves in terms of bandwidth, or more if it has
multiple ipv6 addresses.

My preferred solution to this (and part of the wireless problem) is to
sort things out by source mac address. How to do that, remains a
mystery. The way I'm leaning is to invent some sort of "src mac-to-id"
filter that is global router-wide.

I tend to view (in the home) as having 1/u network performance as the
ideal. There are exceptions to this, notably video vs. say,
bittorrent. A clever way of getting closer to 1/u might be to sense
for more recent DNS queries and move that to a more interactive class.

I got 1/d level performance, vs bittorrent, several months back, using
a combination of HTB, and a
two tier QFQ, then red model. I was happy with this, but QFQ was
required. Perhaps I can make
SFQRED do this with the right filters, or switch to a combination of
DRR and SFQRED....

Anyway, at the present time, I'm trying a few approaches, the most
promising one is a two or three tier model using SFQRED, with a very
limited number of things prio 1 (dns), 2 (mostly everything), 3
classified and background traffic and torrent, where classifiable.
Classification is a rathole however, and I'd rather be aiming for 1/d
than 1/f.

Regardless openwrt's default AQM does lousy queue depth management at
present, and I expect to
improve it tremendously over the coming week.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net