[Cerowrt-devel] Comparison against cablelabs test setup

[Dave Taht <dave.taht@gmail.com>]

Aaron, all:

I am curious as to what happens in rrul and other tests when fq_codel
is configured for the values that cablelabs used for their
simulations, compared to how you have it configured now. e.g.

Try:

target 50ms interval 150ms quantum 300 flows 32

Instead of the defaults...

I have some data too, but nothing at 120Mbit with only the upstream
managed, as aaron has, as one example, and my real world 50/10 mbit
data is suspect at the moment.

---------- Forwarded message ----------
From: Greg White <g.white@cablelabs.com>
Date: Mon, Sep 22, 2014 at 2:44 PM
Subject: Re: [aqm] adoption call: algorithm drafts
To: Dave Taht <dave.taht@gmail.com>
Cc: "Fred Baker (fred)" <fred@cisco.com>, Wesley Eddy
<wes@mti-systems.com>, "aqm@ietf.org" <aqm@ietf.org>


On 9/19/14, 3:04 PM, "Dave Taht" <dave.taht@gmail.com> wrote:

>On Fri, Sep 19, 2014 at 11:18 PM, Greg White <g.white@cablelabs.com>
>wrote:
>> Fred,
>>
>> I know you, Rong and Bill VS have seen it, but in case others haven't,
>> there is an apples-to-apples comparison of fq-codel and fq-pie in my
>>paper
>> from May (along with some design notes, since the merge of fq and pie is
>> not as straightforward as one might think).
>
>Please don't declare fq_codel (in the real world) equal to your setup
>of ns2 sfq_codel.

Yes, YMMV depending on a lot of things. Our comparison was specific to
DOCSIS upstreams, and used some optimized parameters to get the best
feasible mix of performance that we could.  It was apples-to-apples, but
I'm not claiming that the results should be interpreted to hold across all
possible implementations and configurations of *fq(-|_)(pie|codel).


>It is something of a wild extrapolation to compare sfq_codel target
>50ms interval 150ms flows 32
>
>to what we have deployed in the real world against cablemodems as
>fq_codel quantum 300 target 5ms interval 100ms flows 1024

Different for sure, but I wouldn't characterize it as a wild
extrapolation.  We used quantum 300 as well.  For the other parameters, we
tested with the lower target values and lower interval values and saw
better performance by boosting them to the values we reported.  With *fq
in the mix, CoDel or PIE really become the second line of defense and
primarily impact latency performance when you have a hash collision.  With
1024 queues, I would expect that is somewhat rare (certainly more rare
than we saw with 32 queues), so opening up some more burst/buffer
tolerance for TCP could get you better short term TCP results in a range
of conditions (keep in mind that RRUL is a nice test, but not the only
one) with very little downside.

32 queues vs 1024 ... yes we would have seen more frequent hash collisions
in our results. But, 32 queues per Service Flow (1024 queues total) was
about the limit of plausibility for our MAC.  Also, we've already shared
our concerns about potential exacerbations of the horizontal queuing
problem, VPN tunnels, etc.

In any case, I'm not trying to say that I have a monopoly on comparisons
between *fq-codel and *fq-pie, just that we did one (and so far it's the
only one).


>as we show here:
>
>http://burntchrome.blogspot.gr/2014_05_01_archive.html


I guess I missed the comparison to *fq-pie on that page.  ?

Also, please don't declare your PIE implementation equal to the one that
is defined in DOCSIS ;-)


>the two level DRR in fq_codel has a bit less complexity than the ns2
>SFQ_codel code and I've never felt it matched the linux code well
>enough.

How so?


>I otherwise mostly agree that the issues with applying fq on top of
>pie induce below.
>
>Now that the cablelabs ns2 code is mainlined, and GSOC bufferbloat
>summer of code for ns3 is done, and most of that code headed for
>mainline, (codel and some asymmetric network tests landed, (including
>a partial CMTS emulation), fq_codel is waiting on some improvements of
>packet header processing) I hope to find the time to do a real
>fq_codel implemention for ns2, and maybe get netperf-wrapper up to
>where it could duplicate more of your tests.
>
>I am curious, do any of your tests assume ack prioritization is in play?

No, the contrary.  We assume it is not present.

>>
>>http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pd
>>f
>>
>> Best Regards,
>> Greg
>>
>>
>>
>>
>> On 9/18/14, 12:20 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
>>
>>>
>>>On Sep 16, 2014, at 6:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>>> If a fq_pie were produced, how would that work?
>>>
>>>We are doing an fq_pie implementation, at least as a prototype. It
>>>merges
>>>the fq part of your existing fq_codel code RP¹s PIE algorithm. There is
>>>a
>>>part of me that would want to revisit the design of fq to make it a
>>>calendar queue, but that is down the road. What we¹re interested in
>>>right
>>>now is an apples/apples comparison with fq_codel. Further reports when
>>>we¹re ready to report, which isn¹t yet.
>>
>
>
>
>--
>Dave Täht
>
>https://www.bufferbloat.net/projects/make-wifi-fast



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast