Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt

Andrew McGregor <andrewmcgr@gmail.com> Thu, 14 March 2013 13:38 UTC

Return-Path: <andrewmcgr@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FBA1F0D0B; Thu, 14 Mar 2013 06:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level:
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deYhrULpkY2q; Thu, 14 Mar 2013 06:38:11 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 34AEA1F0D09; Thu, 14 Mar 2013 06:38:11 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id er20so2431006lab.4 for <multiple recipients>; Thu, 14 Mar 2013 06:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wiXSmf5kU3abzlAbl2XIiSGQQDSiiVdMBqs3YRh3L4o=; b=ar2ixIyBZIESgZ1pkZnQdxlEC9AsrmDDKuvwDGsbS/KtbTpH3/xm0xbzssEsrmLcZk 5mJQ+N1qI5X85stadlcD9WmMq+KCzxfce5bP93ZjwyXI5rpICKfFxSQ1qtZ/sm3le4JT nrgSxanNTFPQN6ZTGkaNsUY+ulurdGDXTBn384yhV7DPUmrhBthAJ4OSbZ2er1PyRZnO x2iBsX+VPjVLEjewlK+vdPcaapqjxV6gBYfnIHvCTmJs4IZGWNUXuEXPNvZ9Z6MT+4oV u2cnAEqYa2ERCwg5PWx1Eyt7bDglsXRCo5Z8qxwkVEhN8sVJLLSnX+PcBkpQObJ630va zVOw==
MIME-Version: 1.0
X-Received: by 10.152.112.231 with SMTP id it7mr2242761lab.10.1363268290138; Thu, 14 Mar 2013 06:38:10 -0700 (PDT)
Received: by 10.112.21.7 with HTTP; Thu, 14 Mar 2013 06:38:09 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1303140540370.17716@uplift.swm.pp.se>
References: <20130313164833.27324.89314.idtracker@ietfa.amsl.com> <8C48B86A895913448548E6D15DA7553B7D045F@xmb-rcd-x09.cisco.com> <alpine.DEB.2.00.1303131810180.28820@uplift.swm.pp.se> <8C48B86A895913448548E6D15DA7553B7D0B1C@xmb-rcd-x09.cisco.com> <alpine.DEB.2.00.1303140402490.28820@uplift.swm.pp.se> <CAA_e5Z58nOzgsfCj=4O36P51NrK6jR8HCC0Zjvfz5jrCYpi46Q@mail.gmail.com> <alpine.DEB.2.00.1303140540370.17716@uplift.swm.pp.se>
Date: Thu, 14 Mar 2013 09:38:09 -0400
Message-ID: <CAA_e5Z6hXZ+9v+3vWBL1Qxh+i=wm_3WGwtefg+_cc=dT8VXfwA@mail.gmail.com>
From: Andrew McGregor <andrewmcgr@gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Content-Type: multipart/alternative; boundary="f46d040715332ad92904d7e2a279"
Cc: "tsv-area@ietf.org" <tsv-area@ietf.org>, tsvwg <tsvwg@ietf.org>
Subject: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 13:38:12 -0000

fq_codel achieves nearly all of what you're suggesting already, except that
it works on a flow basis rather than on a host basis.  You could add a DRR
layer hashing on IP address only to get host-level balancing.  An efficient
implementation of that would again add only a very little overhead.

fq_codel actually has a 'high volume' and 'low volume' flow rotation, which
are called 'old' and 'new' in the code, and commonly 'thick' and 'thin'
flows in mailing list discussions.  Flows arrive in the thin flow list, get
demoted to the thick flow list when they build queue, and are removed from
either list when they drain completely.  When a flow reappears it will be
introduced back in to the thin flow list, but it will keep its codel state.
 Flows are served from the thin list until it is empty, and then from the
thick list, in round-robin order, so it is very much like DRR.


On Thu, Mar 14, 2013 at 1:07 AM, Mikael Abrahamsson <swmike@swm.pp.se>wrote:

> On Wed, 13 Mar 2013, Andrew McGregor wrote:
>
>  A Netgear WNDR3800 (680MHz MIPS) can handle fq_codel on two flat out
>> 802.11n interfaces at the same time and still be very lightly loaded. CPU
>> is not a problem because fq_codel is a tiny fraction of the usage of the
>> firewall, connection tracking and 802.11 AP code, all of which are
>> necessary (in IPv4 the NAT also uses more CPU than fq_codel).
>>
>
> I'll have to look into what devices we're using and what CPUs they're
> using. The WNDR3800 seems to be a fairly high end device when I look at the
> price point.
>
> However, the other part of your reply sounds hopeful. I read
> draft-nichols-tsvwg-codel-01 and I now realise that yes, it shouldn't be
> too cpu intensive as the hashing into bins sounds efficient on a per-packet
> level.
>
> Would having multiple bin "trees" increase CPU usage a lot? I'm thinking
> of the use case where there are 10 computers in the home, of which one is
> doing 100 upload TCP sessions (bittorrent). If there was some mechanism
> that could identify a source IP address that caused most of the congestion
> and put them in a separate bin "tree" (basically each source IP would get
> its own set of bins, up to a maximum of perhaps 16 trees) and then these
> sets of bins would be emptied in a round-robin fashion (MDRR perhaps?). Or
> perhaps there would just be a "high volume speaker" tree and a "low volume
> speaker" tree, and it would be enough to just MDRR between these two trees.
> I realise we're now into "flow" territory which is exactly what Codel
> doesn't need to bother with currently, but just checking...
>
> I saw in ICCRG that some testing was done with LEDBAT which I would
> imagine would help for the bittorrent case, but what about trying to
> achieve some of that without needing LEDBAT by using the above technique?
>
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>