Re: [aqm] adoption call: algorithm drafts
Greg White <g.white@CableLabs.com> Mon, 22 September 2014 21:44 UTC
Return-Path: <g.white@CableLabs.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4A11A1B1E for <aqm@ietfa.amsl.com>; Mon, 22 Sep 2014 14:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.15
X-Spam-Level: **
X-Spam-Status: No, score=2.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.786] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYcIJ-sYIhjv for <aqm@ietfa.amsl.com>; Mon, 22 Sep 2014 14:44:18 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D02B71A1AD5 for <aqm@ietf.org>; Mon, 22 Sep 2014 14:44:18 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s8MLiALN029481; Mon, 22 Sep 2014 15:44:10 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 22 Sep 2014 15:44:09 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 15:44:10 -0600
From: Greg White <g.white@CableLabs.com>
To: Dave Taht <dave.taht@gmail.com>
Thread-Topic: [aqm] adoption call: algorithm drafts
Thread-Index: AQHP0bOVmCA4fSjuq0imIzHnYfjFUJwELcwAgANtwwCAAU7MgIAAcX6AgARda4A=
Date: Mon, 22 Sep 2014 21:44:09 +0000
Message-ID: <D045DE63.3D58C%g.white@cablelabs.com>
References: <54183D58.3090503@mti-systems.com> <CAA93jw7O_jCEGfZoZEqJCMS9A+SfC2d2OO+SqTJxG_P+aJcRYg@mail.gmail.com> <61041020-F1D4-4300-8D90-0BF5173CAB1A@cisco.com> <D041EA48.3D475%g.white@cablelabs.com> <CAA93jw7b9C5FRcEv2Pp+bZio61uQ5cKw+n6vbuPzh6_tOdh1Bg@mail.gmail.com>
In-Reply-To: <CAA93jw7b9C5FRcEv2Pp+bZio61uQ5cKw+n6vbuPzh6_tOdh1Bg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [10.5.0.27]
Content-Type: text/plain; charset="windows-1254"
Content-ID: <75EC2DB995160A4E9AD2F3D3BD5CD05F@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/ouG8x23TIE6srfsTnO5glHYB6M8
Cc: Wesley Eddy <wes@mti-systems.com>, "Fred Baker (fred)" <fred@cisco.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] adoption call: algorithm drafts
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 21:44:20 -0000
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
- Re: [aqm] adoption call: algorithm drafts Wesley Eddy
- [aqm] adoption call: algorithm drafts Wesley Eddy
- Re: [aqm] adoption call: algorithm drafts Dave Taht
- Re: [aqm] adoption call: algorithm drafts Dave Taht
- Re: [aqm] adoption call: algorithm drafts Greg White
- Re: [aqm] adoption call: algorithm drafts Rong Pan (ropan)
- Re: [aqm] adoption call: algorithm drafts Toke Høiland-Jørgensen
- Re: [aqm] adoption call: algorithm drafts Michael Welzl
- Re: [aqm] adoption call: algorithm drafts Fred Baker (fred)
- Re: [aqm] adoption call: algorithm drafts Fred Baker (fred)
- Re: [aqm] adoption call: algorithm drafts Greg White
- Re: [aqm] adoption call: algorithm drafts Dave Taht
- Re: [aqm] adoption call: algorithm drafts Fred Baker (fred)
- Re: [aqm] adoption call: algorithm drafts Greg White