Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #1

Bob Briscoe <bob.briscoe@bt.com> Fri, 12 July 2013 17:29 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF811E811E for <aqm@ietfa.amsl.com>; Fri, 12 Jul 2013 10:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level:
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 EDpefhAWAiSs for <aqm@ietfa.amsl.com>; Fri, 12 Jul 2013 10:28:58 -0700 (PDT)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id A625C11E80FE for <aqm@ietf.org>; Fri, 12 Jul 2013 10:28:57 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 18:28:53 +0100
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 18:28:55 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 18:28:44 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.109.38.68]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6CHSgvq029224; Fri, 12 Jul 2013 18:28:42 +0100
Message-ID: <201307121728.r6CHSgvq029224@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Jul 2013 18:28:42 +0100
To: Dave Taht <dave.taht@gmail.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <CAA93jw7SkQQ=0X57wkbPY3Hiwgx_8ySs7ocjA6emcgNA6Uy+6w@mail.g mail.com>
References: <8C48B86A895913448548E6D15DA7553B81F454@xmb-rcd-x09.cisco.com> <201307120128.r6C1Save026348@bagheera.jungle.bt.co.uk> <CAA93jw7SkQQ=0X57wkbPY3Hiwgx_8ySs7ocjA6emcgNA6Uy+6w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: "Fred Baker (fred)" <fred@cisco.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #1
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 12 Jul 2013 17:29:04 -0000

Dave,

At 02:49 12/07/2013, Dave Taht wrote:
>Since this is a rollup email, this is a rollup in response.
>
>On Thu, Jul 11, 2013 at 6:28 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:
> > #3 Active Queue Management algorithms deployed SHOULD NOT require
> > operational tuning
> > Agree
>
>Agree, but I'd capitalize the REQUIRE bit, in that everything in this
>world can benefit from a little tuning here and there...
>
>as one major example, which is in conflict with your byte-congest
>draft, using a smaller quantum than the default helps on asymmetric
>links in fq_codel (and pie uses a probalistic drop mechanism also
>based on packet size). The smaller quantum thing has been well proven
>to work on multiple shapers/schedulers going back to wondershaper.

Pls elucidate or cite. INsufficient detail to understand. I thought I 
knew what a quantum was in a scheduler, but in these sentences I'm 
wondering whether you're talking about something else.


> > (and see same note to Dave Taht wherein I said time as a queue threshold is
> > not sufficient to get a tick in the auto-tuning box - responsiveness of the
> > algo also needs to depend on how bad the queue is getting)
>
>The sqrt->linear drop approach is tcp friendly and currently works
>well on a wide range of RTTs. It certainly seems like a worthwhile
>research effort to measure and act on the slope of the curve, both up
>and down, in a codel variant, in order to get better results faster.

I've transferred this response over to the separate thread 
specifically about this (rec #2), as I think my points have been missed.


>And the results of the hybrid fq_codel are interesting in that
>perspective as flows do affect one another, particularly in steady
>state. Right now a drop in one queue can be followed quickly by a drop
>in another queue (at steady state), and that could be randomized
>somewhat or fed into a feedback mechanism also.
>
>I do show this behavior on the rrul vs web traffic benchmark on the
>slidesets I've been showing. Note that steady state is something of a
>rarity outside of benchmarks.
>
>another thought is to periodically perturb the flow list. sigh. more research.

Bob


________________________________________________________________
Bob Briscoe,                                                  BT