<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Being able to measure a network well *is* potentially useful.  The papers and articles you've linked so far do *not* disclose anything useful.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>