Re: [Bloat] Bufferbloat in high resolution + non-stationarity

[Jonathan Morton <chromatix99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]

A central assumption in all of your references so far is that the relevant
traffic classes can be distinguished reliably in realtime and sent to
appropriate queues.  There is no fallback mechanism given for any cases
where this assumption is false - the queue within each class is a FIFO,
which as each paper notes is utterly incapable of providing the required
quality, or even an approximation to it, by itself.

In practice, we have found traffic classification to be a major problem in
terms of deployment.  Although some classes are easy to identify by layer-4
protocol and port, some important traffic (from a quality management point
of view) deliberately obscures its identity to avoid censorship, while
other types are simply difficult to distinguish from best-effort web
traffic because they piggy-back on the HTTP port and protocol.  The
TOS/DSCP field, which could theoretically be useful here, is rarely used in
practice by applications, and is frequently mangled by ISPs as part of
their own traffic management.

I submit that to provide *deployable* QoS schemes, you must either solve
the classification problem elegantly (which is a Hard Problem), or else
show that your scheme works adequately in the absence of classification.
I'm taking the latter approach with Cake, even though it *also* supports
Diffserv awareness to enhance its performance where classification is
straightforward.

My earlier point was that the scenario given in your 2003 paper could be
satisfied with *no* a-priori knowledge, classification or configuration,
merely a good flow-isolation algorithm operating on the 5-tuple.  In 2003,
you may not have known about DRR++, but it is widely deployed today as part
of fq_codel and meets those criteria by default.

In your 2005 paper, I find you in the curious position of assuming that an
"ad hoc" network can have a sophisticated QoS scheme, dynamically
configured to match the offered load (which for the experiment required
manual trial and error), in a way that supports *safety critical* levels of
service.  You then establish the frankly unsurprising results that strictly
prioritising critical traffic over the rest improves its quality of
service, and that it is possible to adequately service all traffic if the
network is not driven into saturation.  I stopped reading at that point; I
have little patience for laborious proof of the obvious.

Being able to measure a network well *is* potentially useful.  The papers
and articles you've linked so far do *not* disclose anything useful.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 2709 bytes --]