Re: [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 28/02/16 13:39, Toke Høiland-Jørgensen wrote:
> Alan Jenkins <alan.christopher.jenkins@gmail.com> writes:
>
>> I wouldn't complain that I can't sustain 2056Kbps goodput when my fair
>> share of the shaped bandwidth is 2000Kbps.  The results might be
>> showing a significant degradation, or it could be a marginal one that
>> pushes over the boundary (between the 2056k and 1427k encodes).  Which
>> of those conclusions you start from might be influenced by whether
>> you're developing a different AQM, hmm.
> Exactly. And note how they just so happen to pick 11 total flows (10
> competing, one video) to share the bottleneck, putting the per-flow
> throughput just below the rate needed to go up one quality level. What a
> coincidence. At least it shows how difficult it is to design experiments
> that put fairness queueing in a bad light ;)
Ug. I try not to assume malice.  It does indeed come across as motivated 
absence of curiosity.

We ran a test where Product A scores better than Product B.  Buy Product 
A today!

* difference in presented results is within margin of error
** did you notice our "pass" threshold was literally over 100%? That the 
technology commonly assumed to provide fairness breaks down in this 
test?  No?  <simpsons character="Mr. Burns> _Excellent_.

> Oh, and of course HAS is in itself a hack to work around badly managed
> queues in the network. In a nicely fairness queued world, we could do
> away with HAS entirely and just, y'know, stream things at the desired
> rate...
>
> -Toke
Nah.  You do want to handle a variable number of users, without making 
them fiddle with rates when that number changes.