From nobody Fri Oct 3 08:46:17 2014 Return-Path: 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 B12001A0369 for ; Fri, 3 Oct 2014 08:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 QxQUcuBjO4si for ; Fri, 3 Oct 2014 08:46:09 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BC11A0387 for ; Fri, 3 Oct 2014 08:46:05 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id va2so1033797obc.25 for ; Fri, 03 Oct 2014 08:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MA1QamYRnW8NBvdP+4LNiTbkY1Q/LAWVSwdB8AsmwXg=; b=fjBW7kXJesAKxhGIwns1mwmlA2zKca3GuLzE3XHND1BZxzrVVjz7q44ENlXJt3ym0B SjoGHo+3udhGVWZvJAOwxbpRDqVSACpFCgyDcWjrk+qIIBkwjZLex8SiULNMW6+RcBKp yCEPaH5MtMRunT/fSuhyx5tH8T7sJ9ba7SJCsWa5+Z+J65fLBqK7oEy/LdKN/gnvGRUE YnmEwWLqBmKtbgb2it1SCeqgaj8G+zUNHEoG0MJtrsXnuFwBzS3x6tDBsYxRBNxSoC3V tukcojTM5aMUxTeAaASd2pI77rDPPlJE7pSt98lyKgsfQz2ojAAGGermg7zsh77qlrz0 IJ4A== MIME-Version: 1.0 X-Received: by 10.60.51.71 with SMTP id i7mr7971102oeo.41.1412351163777; Fri, 03 Oct 2014 08:46:03 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Fri, 3 Oct 2014 08:46:03 -0700 (PDT) In-Reply-To: <542D05B9.1040601@redhat.com> References: <542D05B9.1040601@redhat.com> Date: Fri, 3 Oct 2014 08:46:03 -0700 Message-ID: From: Dave Taht To: Daniel Borkmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/drZijh2nVXteGdG_J49Us8u75V4 Cc: fwestpha@redhat.com, "aqm@ietf.org" , dclc@irtf.org, bloat Subject: Re: [aqm] DCTCP in linux net-next X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:46:15 -0000 The testing on this DCTCP implementation is documented at: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id= =3De3118e8359bb7c59555aca60c725106e6d78c5ce Very Impressive! The use of classification to run this on the same data plane as other traffic was clever, also... Me being me, I'd wanted to test it against fq_codel, codel and pie (all of which support ECN) instead of RED, test it against competing cc algorithms (what harm could a cubic sender do in an otherwise dctcp environment?), all of which were impossible given the age of the patch prior set. I had no faith in the prior (pre-bql-era) results for DCTCP. I am also interested in what effects, if any, sch_fq had on the hosts vs a vs DCTCP. It looks like the code currently falls back to reno, not cubic, if ecn is not enabled, also... There are several tests in netperf-wrapper that could be easily modified to invoke dctcp instead to very rapidly get that sort of data. (the tests are things like cubic_reno reno_cubic_westwood_lp and the various tcp_square_wave tests, the 50 flow test, etc) Regrettably I'm not in a DC environment, I'm still out here, trying to fix the edge. Hopefully someone(s) else here will re-run their tests in with this modernized version of dctcp.... On Thu, Oct 2, 2014 at 12:58 AM, Daniel Borkmann wrot= e: > Hi Dave, > > [ also Cc'ing Florian as co-author ] > > On 10/02/2014 05:20 AM, Dave Taht wrote: >> >> I was surprised and delighted to see that DCTCP has now entered the >> linux net-next kernel (which means it will end up in linux 3.18 if it >> pans out)... >> >> http://thread.gmane.org/gmane.linux.network/332259 >> >> Benchmarkers fire up yer engines! The last benchmarks of DCTCP were >> all from the pre-bql era.... > > > Indeed, please do. ;) We did longer term measurements in a data center > environment as attached to the commit message, mostly to provoke incast > collapse. Results were looking quite promising. > >> In similar news, some patches are tightening up BQL. The improvements >> here are measured in >> 10s to 100s of us, and in cpu savings... >> >> https://patchwork.ozlabs.org/patch/394810/ > > > Thanks, > Daniel --=20 Dave T=C3=A4ht https://www.bufferbloat.net/projects/make-wifi-fast From nobody Thu Oct 16 18:09:15 2014 Return-Path: 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 B6C2A1A89C6 for ; Thu, 16 Oct 2014 18:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N9ycZBjeYBm2 for ; Thu, 16 Oct 2014 18:09:10 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38B51A9028 for ; Thu, 16 Oct 2014 18:09:10 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so3613075vcb.38 for ; Thu, 16 Oct 2014 18:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S8KIwDEsCWyaeBAMvK373eaKvJgD1th6tzWhpypawaw=; b=kQpW6HgP3agAdgm6FLw8Ne+nOMDZaQhnagv9qodgJEIOVPEts7SUMfeR2YjZXkM2P/ eLhlBHJ4clMCkUYCxqn4WHkm5vUOkvsJfpldTSvQY4O1Ndwt07fjn02JZhV2EXzsM6fa 4jKrWaOzAdT8GPK9AM1L3970qQ954x5wMCTKrW8tvFpMSG5nQ9f9zSvmoBrramc8BDJq PWUDmGEWpYk3fri4Kx1k8UMewoqRoLoy8eQBwb1sqEv0vg6L1U5osdjuFoO+3ghcVH3U t2XLE0NY/7p8FrSuFye0HdQXXebnEo8+JGpPIHi00EtLveK9uChtLytL2dtXDifzULUG MK6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=S8KIwDEsCWyaeBAMvK373eaKvJgD1th6tzWhpypawaw=; b=ZVNBSQRi4NP9LBoN/ygJph/C/QDF1u8ESoyn5UrAqwel//LrFDrdhb5tzFRUeipUm3 125cIZkur1PkhOWdOt6mW9D8p2Kmdn5rskziFaquqNV8o3h+SqT34IoeA898dShzpaSp B2DN5vt/+RIB1qMjt8xz0jWUK+8K1EhmeHZY66LYTUXTXD64HRyPi9urZLm0PrDadUFs FpfEB3IxNPq2DgjBrozDhzQ05/h+8bhZIA8opmPUQ6Ipvf5UkKomIe49mBG147G+oNRN v4XxX6MDeUCIG66wG7Ix4dqnotDqPFKtFBRK1mBDwvM4wx/XXBqR8SZFahgVwMOy7w+S WlVQ== X-Gm-Message-State: ALoCoQk0yUTNj3ymwr7ohNjZWOBH58Lwm9pU0+5lgwMgFw2dFkgLKhfgElkgAcKbObaa+cl/yrTr MIME-Version: 1.0 X-Received: by 10.221.4.73 with SMTP id ob9mr4751386vcb.13.1413508149781; Thu, 16 Oct 2014 18:09:09 -0700 (PDT) Received: by 10.52.243.73 with HTTP; Thu, 16 Oct 2014 18:09:09 -0700 (PDT) In-Reply-To: <20141017005520.7110.8373.idtracker@ietfa.amsl.com> References: <20141017005520.7110.8373.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 18:09:09 -0700 Message-ID: From: Jana Iyengar To: aqm@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/XYvZnpY8zc_n0c4GkoYSbT2zLAU Cc: Andrew McGregor , "Dr. Kathleen M. Nichols" , Van Jacobson Subject: Re: [aqm] New Version Notification for draft-aqm-codel-00.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:09:12 -0000 Dear all, A new draft on CoDel is now available in the drafts repository; see below for details. Thanks, - jana On Thu, Oct 16, 2014 at 5:55 PM, wrote: > > A new version of I-D, draft-aqm-codel-00.txt > has been successfully submitted by Jana Iyengar and posted to the > IETF repository. > > Name: draft-aqm-codel > Revision: 00 > Title: Controlled Delay Active Queue Management > Document date: 2014-10-16 > Group: Individual Submission > Pages: 28 > URL: http://www.ietf.org/internet-drafts/draft-aqm-codel-00.txt > Status: https://datatracker.ietf.org/doc/draft-aqm-codel/ > Htmlized: http://tools.ietf.org/html/draft-aqm-codel-00 > > > Abstract: > The "persistently full buffer" problem has been discussed in the IETF > community since the early 80's [RFC896]. The IRTF's End-to-End > Working Group called for the deployment of active queue management > (AQM) to solve the problem in 1998 [RFC2309]. Despite the awareness, > the problem has only gotten worse as Moore's Law growth in memory > density fueled an exponential increase in buffer pool size. Efforts > to deploy AQM have been frustrated by difficult configuration and > negative impact on network utilization. This problem, recently > christened "bufferbloat", [TSVBB2011] [BB2011] has become > increasingly important throughout the Internet but particularly at > the consumer edge. > > This document describes a general framework called CoDel (Controlled > Delay) [CODEL2012] that controls bufferbloat-generated excess delay > in modern networking environments. CoDel consists of an estimator, a > setpoint, and a control loop. It requires no configuration in normal > Internet deployments. CoDel comprises some major technical > innovations and has been made available as open source so that the > framework can be applied by the community to a range of problems. It > has been implemented in Linux (and available in the Linux > distribution) and deployed in some networks at the consumer edge. In > addition, the framework has been successfully applied in other ways. > > Note: Code Components extracted from this document must include the > license as included with the code in Section 5. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Fri Oct 17 04:53:35 2014 Return-Path: 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 8654E1AC443 for ; Fri, 17 Oct 2014 04:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ehVFOpi13oQS for ; Fri, 17 Oct 2014 04:53:31 -0700 (PDT) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8578B1AC3C6 for ; Fri, 17 Oct 2014 04:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 5DB1D301E6; Fri, 17 Oct 2014 13:53:29 +0200 (CEST) Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id itGL8lNE59TA; Fri, 17 Oct 2014 13:53:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id D2C67301E7; Fri, 17 Oct 2014 13:53:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5M0FNfHflGHy; Fri, 17 Oct 2014 13:53:27 +0200 (CEST) Received: from [IPv6:2001:660:7301:3728:1c5c:97cf:ae3c:da3c] (passerellev6v4.enst-bretagne.fr [192.108.117.5]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id A283730021; Fri, 17 Oct 2014 13:53:27 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6EDFE6F-6945-4848-8D85-F301D9614FCD" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicolas KUHN In-Reply-To: Date: Fri, 17 Oct 2014 13:53:26 +0200 Message-Id: <2A85824A-3D1C-48F2-A649-286AA02D74BB@telecom-bretagne.eu> References: <20141017005520.7110.8373.idtracker@ietfa.amsl.com> To: Jana Iyengar X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/A0XaOTfmL_hhHSu2TA-LmlA_asE Cc: Andrew McGregor , "Dr. Kathleen M. Nichols" , aqm@ietf.org, Van Jacobson Subject: Re: [aqm] New Version Notification for draft-aqm-codel-00.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 11:53:34 -0000 --Apple-Mail=_B6EDFE6F-6945-4848-8D85-F301D9614FCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all,=20 I have some comments regarding the new version of = draft-aqm-codel-00.txt. Also, we would like to have some reviews of the = draft-ietf-aqm-eval-guidelines-00.txt document [ = https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/ ]: we = have set up a github repository, if you want to have a access to it, = please send us an email. Comments on draft-aqm-codel-00.txt: 1- Introduction: - "Many approaches to active queue management (AQM) have been = developed over the past two decades but none has been widely deployed due to performance problems." -> "performance problems" is not clear IMO and not accurately = true - the problem is that AQM might be difficult to tweak, but we can = not say that there are performance problems when correctly = parameterised. -> AFAIK, RED have also been widely implemented in some network = devices, but RED is reported to be usually turned off.=20 - "The CoDel approach is designed to meet the following goals: = is [=85]; treats [=85] "=20 -> The CoDel approach is designed to meet the following goals: = be [=85]; treat [=85] - "With no changes to parameters, we have found CoDel to work = across a wide range of conditions, with varying links and the full range = of terrestrial round trip times." -> do you have any reference that justifies this point ?=20 - "CoDel has been implemented in Linux very efficiently" -> [non-native speaker alert] I would rephrase this sentence.=20 4- Putting it together: queue management for the network edge - "The only setting CoDel requires is its interval value, and as = 100ms satisfies that definition for normal internet usage, CoDel can be = parameter-free for consumer use." -> IMO the target value can also be another setting parameter, = as it triggers the maximum "allowed" queuing delay. I think that the = "normal internet usage" should be clearly defined. I believe that the = "That is, target SHOULD NOT be adjusted but interval MAY need to be = adjusted." (in section 4.3) is enough to say that the target value could = be adjusted, but is disadvised. Changing both the target and interval = would enable to achieve different tradeoffs than the default one, as you = say in Section 4.7.=20 - "CoDel was released to the open source community where it has = been widely promulgated and adapted to many problems. " -> what 'many' problems was CoDel adapted to ? 4.1- Overview of CoDel AQM - "In the open Internet, in particular the consumer edge, we can = use the "usual maximum" terrestrial RTT of 100 ms" -> I think that a reference is needed=20 - "Additional logic prevents re-entering the dropping state too = soon after exiting it and resumes the dropping state at a recent control = level, if one exists." -> what is this additional logic ? if this is explain later in = the document, this sentence should point to that part of the draft. 4.3 Using the interval=09 - " A setting of 100ms works well across a range of RTTs from = 10ms to 1 second (excellent performance is achieved in the range from 10 = ms to 300ms). For devices intended for the normal terrestrial Internet = interval SHOULD have the value of 100ms. This will only cause = overcropping where a long-lived TCP has an RTT longer than 100ms and = there is little or no mixing with other connections through the link." -> what do you mean by "works well" ? -> what are the differences between "working well" and = "excellent performance"=20 -> as you say, if the RTT is higher than 100ms, there will be = "overcropping": IMO, this discussion is enough to say that CoDel is not = "non-sensitive to RTT" - this statement should be alleviated (or = numbered in terms of bottleneck utilisation / queuing delay) in the = whole document. 4.6 Use of stochastic bins or sub-queues to improve performance - "Our code, intended for simulation experiments, is available = at http://pollere.net/CoDel.html and being integrated into the ns-2 = distribution." -> the link seems to be broken. - " Implementers SHOULD use the fq_codel multiple queue approach = if possible as it deals with many problems beyond the reach of an AQM on = a single queue." -> following F. Bakers talks at IETF 90 [ = http://www.ietf.org/proceedings/90/slides/slides-90-aqm-5.pdf ], I am = not sure if we can make such statement. Supplementary results should be = pointed at in this section to legitimate the "SHOULD".=20 4.7 Setting up CoDel AQM - "An interval of 100ms is used, target is set to 5% of = interval" - "A CoDel configured for this environment (target and interval = in the microsecond rather than millisecond range)" -> IMO, this is in contradiction with what is said in section 4 = about "That is, target SHOULD NOT be adjusted but interval MAY need to = be adjusted". In section 4.4, it is said that the target has been set to 5ms = based on experiments that consider various RTT and link capacity - but = this section says the target is set depending on the interval. IMO, = there should be more consistency in the determination of the target or = the interval. 6.2 CoDel in the datacenter - "a target of 5% of the RTT or CoDel interval was used here." -> I understand that the interval is set to RTT and target to 5% = of the interval -> sometimes in the document, it is said that target is set to = 5% of RTT - I think it should be said everywhere that target is 5% of = interval and the interval depends on the RTT. Kind regards,=20 Nicolas KUHN On Oct 17, 2014, at 3:09 AM, Jana Iyengar wrote: > Dear all, >=20 > A new draft on CoDel is now available in the drafts repository; see > below for details. >=20 > Thanks, > - jana >=20 > On Thu, Oct 16, 2014 at 5:55 PM, wrote: >>=20 >> A new version of I-D, draft-aqm-codel-00.txt >> has been successfully submitted by Jana Iyengar and posted to the >> IETF repository. >>=20 >> Name: draft-aqm-codel >> Revision: 00 >> Title: Controlled Delay Active Queue Management >> Document date: 2014-10-16 >> Group: Individual Submission >> Pages: 28 >> URL: = http://www.ietf.org/internet-drafts/draft-aqm-codel-00.txt >> Status: https://datatracker.ietf.org/doc/draft-aqm-codel/ >> Htmlized: http://tools.ietf.org/html/draft-aqm-codel-00 >>=20 >>=20 >> Abstract: >> The "persistently full buffer" problem has been discussed in the = IETF >> community since the early 80's [RFC896]. The IRTF's End-to-End >> Working Group called for the deployment of active queue management >> (AQM) to solve the problem in 1998 [RFC2309]. Despite the = awareness, >> the problem has only gotten worse as Moore's Law growth in memory >> density fueled an exponential increase in buffer pool size. = Efforts >> to deploy AQM have been frustrated by difficult configuration and >> negative impact on network utilization. This problem, recently >> christened "bufferbloat", [TSVBB2011] [BB2011] has become >> increasingly important throughout the Internet but particularly at >> the consumer edge. >>=20 >> This document describes a general framework called CoDel = (Controlled >> Delay) [CODEL2012] that controls bufferbloat-generated excess delay >> in modern networking environments. CoDel consists of an estimator, = a >> setpoint, and a control loop. It requires no configuration in = normal >> Internet deployments. CoDel comprises some major technical >> innovations and has been made available as open source so that the >> framework can be applied by the community to a range of problems. = It >> has been implemented in Linux (and available in the Linux >> distribution) and deployed in some networks at the consumer edge. = In >> addition, the framework has been successfully applied in other = ways. >>=20 >> Note: Code Components extracted from this document must include the >> license as included with the code in Section 5. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --Apple-Mail=_B6EDFE6F-6945-4848-8D85-F301D9614FCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = all, 

I have some comments regarding the new = version of draft-aqm-codel-00.txt.

Also, = we would like to have some reviews of the = draft-ietf-aqm-eval-guidelines-00.txt document [ = https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/ = ]: we have set up a github repository, if you want to have a access = to it, please send us an email.

Comments = on draft-aqm-codel-00.txt:
1- = Introduction:
- "Many approaches to active = queue management (AQM) have been developed
   over = the past two decades but none has been widely deployed due = to
   performance problems."
-> = "performance problems" is not clear IMO and not accurately true - the = problem is that AQM might be difficult to tweak, but we can not say that = there are performance problems when correctly = parameterised.
-> AFAIK, RED  have = also been widely implemented in some network devices, but RED is = reported to be usually turned off. 

- "The = CoDel approach is designed to meet the following goals: is [=85]; = treats [=85] " 
-> The CoDel approach is = designed to meet the following goals: be [=85]; treat = [=85]

- "With no changes to = parameters, we have found CoDel to work across a wide range of = conditions, with varying links and the full range of terrestrial = round trip times."
-> do you have any reference = that justifies this point ? 

- "CoDel = has been implemented in Linux very efficiently"
-> = [non-native speaker alert] I would rephrase this = sentence. 

4- Putting it together: = queue management for the network edge
- "The = only setting CoDel requires is its interval value, and as 100ms = satisfies that definition for normal internet usage, CoDel can be = parameter-free for consumer use."
-> IMO the target value can = also be another setting parameter, as it triggers the maximum "allowed" = queuing delay. I think that the "normal internet usage" should be = clearly defined. I believe that the "That is, target SHOULD NOT be = adjusted but interval MAY need to be adjusted." (in section 4.3) is = enough to say that the target value could be adjusted, but is = disadvised. Changing both the target and interval would enable to = achieve different tradeoffs than the default one, as you say in Section = 4.7. 

- "CoDel was released to the = open source community where it has been widely promulgated and = adapted to many problems. "
-> what 'many' problems was = CoDel adapted to ?

4.1- Overview of CoDel = AQM
= - "In the open Internet, in particular the consumer edge, we = can use the "usual maximum" terrestrial RTT of 100 = ms"
= -> I think that a reference is = needed 

- "Additional logic prevents = re-entering the dropping state too soon after exiting it = and resumes the dropping state at a recent control level, if one = exists."
-> what is this additional = logic ? if this is explain later in the document, this sentence should = point to that part of the draft.

4.3 Using the = interval =
- " A setting of 100ms = works well across a range of RTTs from 10ms to 1 second (excellent = performance is achieved in the range from 10 ms to 300ms). For = devices intended for the normal terrestrial Internet = interval SHOULD have the value of 100ms.  This will only cause = overcropping where a long-lived TCP has an RTT longer than 100ms = and there is little or no mixing with other connections through the = link."
= -> what do you mean by "works well" ?
-> = what are the differences between "working well" and "excellent = performance" 
-> as you say, if the RTT is = higher than 100ms, there will be "overcropping": IMO, this discussion is = enough to say that CoDel is not "non-sensitive to RTT" - this statement = should be alleviated (or numbered in terms of bottleneck utilisation / = queuing delay) in the whole = document.

4.6 Use of stochastic bins or = sub-queues to improve performance
- "Our code, intended = for simulation experiments, is available at http://pollere.net/CoDel.html&n= bsp;and being integrated into the ns-2 distribution."
-> the = link seems to be broken.

- = " Implementers SHOULD use the fq_codel multiple queue approach = if possible as it deals with many problems beyond the reach of an = AQM on a single queue."
-> following F. Bakers talks = at IETF 90 [ htt= p://www.ietf.org/proceedings/90/slides/slides-90-aqm-5.pdf ], I = am not sure if we can make such statement. Supplementary results should = be pointed at in this section to legitimate the = "SHOULD". 

4.7 Setting up CoDel = AQM
= - "An interval of 100ms is used, target is set to 5% of = interval"
- "A CoDel configured for = this environment (target and interval in the microsecond rather = than millisecond range)"
-> IMO, this is in = contradiction with what is said in section 4 about "That is, = target SHOULD NOT be adjusted but interval MAY need to be = adjusted".
In section 4.4, it is said that = the target has been set to 5ms based on experiments that consider = various RTT and link capacity - but this section says the target is set = depending on the interval. IMO, there should be more consistency in the = determination of the target or the = interval.

6.2 CoDel in the = datacenter
- "a target of 5% of the RTT = or CoDel interval was used here."
-> I understand that the = interval is set to RTT and target to 5% of the interval
-> = sometimes in the document, it is said that target is set to 5% of RTT - = I think it should be said everywhere that target is 5% of interval and = the interval depends on the RTT.

Kind = regards, 

Nicolas = KUHN

On Oct 17, 2014, at 3:09 AM, Jana Iyengar = <jri@google.com> = wrote:

Dear all,

A new draft on CoDel  is now = available in the drafts repository; see
below for = details.

Thanks,
- jana

On Thu, Oct 16, 2014 at 5:55 = PM,  <internet-drafts@ietf.org> = wrote:

A new version of I-D, = draft-aqm-codel-00.txt
has been successfully submitted by Jana = Iyengar and posted to the
IETF repository.

Name: =           draft-aqm-code= l
Revision:       00
Title: =          Controlled Delay = Active Queue Management
Document date:  2014-10-16
Group: =          Individual = Submission
Pages: =          28
URL: =            http:/= /www.ietf.org/internet-drafts/draft-aqm-codel-00.txt
Status: =         https://datatra= cker.ietf.org/doc/draft-aqm-codel/
Htmlized: =       http://tools.ietf.o= rg/html/draft-aqm-codel-00


Abstract:
  The = "persistently full buffer" problem has been discussed in the IETF
=   community since the early 80's [RFC896].  The IRTF's = End-to-End
  Working Group called for the deployment of = active queue management
  (AQM) to solve the problem in = 1998 [RFC2309].  Despite the awareness,
  the problem = has only gotten worse as Moore's Law growth in memory
=   density fueled an exponential increase in buffer pool size. =  Efforts
  to deploy AQM have been frustrated by = difficult configuration and
  negative impact on network = utilization.  This problem, recently
  christened = "bufferbloat", [TSVBB2011] [BB2011] has become
=   increasingly important throughout the Internet but = particularly at
  the consumer edge.

=   This document describes a general framework called CoDel = (Controlled
  Delay) [CODEL2012] that controls = bufferbloat-generated excess delay
  in modern networking = environments.  CoDel consists of an estimator, a
=   setpoint, and a control loop.  It requires no = configuration in normal
  Internet deployments. =  CoDel comprises some major technical
  innovations = and has been made available as open source so that the
=   framework can be applied by the community to a range of = problems.  It
  has been implemented in Linux (and = available in the Linux
  distribution) and deployed in = some networks at the consumer edge.  In
  addition, = the framework has been successfully applied in other ways.

=   Note: Code Components extracted from this document must = include the
  license as included with the code in Section = 5.




Please note that it may take a couple of minutes = from the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


______________________________________= _________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mail= man/listinfo/aqm

= --Apple-Mail=_B6EDFE6F-6945-4848-8D85-F301D9614FCD-- From nobody Mon Oct 20 07:08:52 2014 Return-Path: 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 AFD951A88B8 for ; Mon, 20 Oct 2014 07:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 DTdu8FuXAK1k for ; Mon, 20 Oct 2014 07:08:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD481A88B9 for ; Mon, 20 Oct 2014 07:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141020140013.1342.79916.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 07:00:13 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/YVW1jygi7P4vGvQgf30I2-4esio Subject: [aqm] Milestones changed for aqm WG X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:08:46 -0000 Changed milestone "Submit AQM algorithm evaluation guidelines to IESG for publication as Informational", added draft-ietf-aqm-eval-guidelines to milestone. URL: http://datatracker.ietf.org/wg/aqm/charter/ From nobody Fri Oct 24 02:29:53 2014 Return-Path: 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 6C4D91A898E; Fri, 24 Oct 2014 02:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ZCgWzfCn-q6e; Fri, 24 Oct 2014 02:29:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 081E11A8923; Fri, 24 Oct 2014 02:29:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024092948.9876.61739.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 02:29:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/XS78O7v2WKJCsIS7qWcLevgbEjA Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-00.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:29:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. Title : The Benefits and Pitfalls of using Explicit Congestion Notification (ECN) Authors : Michael Welzl Godred Fairhurst Filename : draft-ietf-aqm-ecn-benefits-00.txt Pages : 11 Date : 2014-10-24 Abstract: This document describes the potential benefits and pitfalls when applications enable Explicit Congestion Notification (ECN). It outlines the principal gains in terms of increased throughput, reduced delay and other benefits when ECN is used over network paths that include equipment that supports ECN-marking. It also lists potential problems that might occur when ECN is used. The document does not propose new algorithms that may be able to use ECN or describe the details of implementation of ECN in endpoint devices, routers and other network devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-aqm-ecn-benefits-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 12:32:37 2014 Return-Path: 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 1F2511A86F2; Fri, 24 Oct 2014 12:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7Z5a-RcGR-Se; Fri, 24 Oct 2014 12:32:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A541A1ACC; Fri, 24 Oct 2014 12:32:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024193232.20292.96858.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 12:32:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/n50vRFELkhHY9ZNM9MFm2EDbHs4 Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-codel-00.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 19:32:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. Title : Controlled Delay Active Queue Management Authors : Kathleen Nichols Van Jacobson Andrew McGregor Jana Iyengar Filename : draft-ietf-aqm-codel-00.txt Pages : 28 Date : 2014-10-24 Abstract: The "persistently full buffer" problem has been discussed in the IETF community since the early 80's [RFC896]. The IRTF's End-to-End Working Group called for the deployment of active queue management (AQM) to solve the problem in 1998 [RFC2309]. Despite the awareness, the problem has only gotten worse as Moore's Law growth in memory density fueled an exponential increase in buffer pool size. Efforts to deploy AQM have been frustrated by difficult configuration and negative impact on network utilization. This problem, recently christened "bufferbloat", [TSVBB2011] [BB2011] has become increasingly important throughout the Internet but particularly at the consumer edge. This document describes a general framework called CoDel (Controlled Delay) [CODEL2012] that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. CoDel comprises some major technical innovations and has been made available as open source so that the framework can be applied by the community to a range of problems. It has been implemented in Linux (and available in the Linux distribution) and deployed in some networks at the consumer edge. In addition, the framework has been successfully applied in other ways. Note: Code Components extracted from this document must include the license as included with the code in Section 5. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-aqm-codel-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 26 15:05:54 2014 Return-Path: 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 E7D451A1AB7 for ; Sun, 26 Oct 2014 15:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zKcun6An_BZa for ; Sun, 26 Oct 2014 15:05:48 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4AF1A1AB0 for ; Sun, 26 Oct 2014 15:05:48 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id a3so2477799oib.22 for ; Sun, 26 Oct 2014 15:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+IlBTnbB3D1J+BGhmQ92nn1k8mfSYCfYSnQE1NqKXCs=; b=KU8oNUiNpW63wFSnI3CpHo3UX5qjGyZUDXU9JP7qfkXBkJBYMJWTYyQltqE2lwEWep stvg2F695E7cgysJ5+V/w9cvhlysdLrmvMxZZyIm7GfxUEGOOmTEol5box5p3vBa7EFw Be7NTHpIutcpq+RhoMnqsiLcc+hxw1B8RmcJzREmwNtt+h8RIAgCqGkBf451mFKmzboR HNqMzhF24ZIMdcSBdbXFPttHiLRVKIwtNFtp70MmQISzgtuNiHFBWJ6d09t34hkaCEuA 5iu4ui1b6DFkKwJYvtLfVf7fgvoBmphFFrKRBi5tMjVQvEK/ITP07jycl57T3oAKmOTv K65Q== MIME-Version: 1.0 X-Received: by 10.182.24.166 with SMTP id v6mr16858867obf.30.1414361147637; Sun, 26 Oct 2014 15:05:47 -0700 (PDT) Received: by 10.202.227.211 with HTTP; Sun, 26 Oct 2014 15:05:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Oct 2014 15:05:47 -0700 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/rf06S9EIXFCxcCVDEcf_T6O2Oi4 Cc: "aqm@ietf.org" Subject: Re: [aqm] Review of draft-hoeiland-joergensen-aqm-fq-codel-00 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 22:05:52 -0000 We are working on revising the draft today, if anyone else has comments, please let us know soonest. On Tue, Sep 30, 2014 at 2:24 PM, Jim Gettys wrote: > Looks pretty good to me. I took a pretty good read on the airplane west > yesterday, and comments are below. > - Jim > 1. > > "The rest of this document" is immediately followed by "The rest of this > section". That repetition is unfortunate, and the second is capitalized. k. > 1.2 > > You should note again that fq_codel is not limited to hashing on f-tuples= ; > just that the current implementation defaults to hashing those. k. > > Noting that fq_codel gets really good performance is nice and usually bet= ter > than most deployed ad-hoc classification schemes, but you should > also note that if you want hard "guarantees" of performance, packet > classification still has a role to play. For example, multiplexing a > control plane for a network over that network would be something that > requires > explicit classification to provide such guarantees. I have thought about publishing something as to how this stuff has mostly deployed, which is with a 3 or 4 level classification system, as per the SQM, qos-scripts, and free.fr'd DRR + fq_codel system. As well as what's currently in "cake". I documented some of that here: http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices= -00.html But as there is another working group entirely working on nailing down the definitions of the diffserv codepoints and the expected behavior (not that I agree that an insane level of detail is needed), and there hasn't been much interest here in what I've been calling "comprehensive queue management", I'm not going to bother polishing that up before codel, fq-codel, and pie go standards track. There are even more complex classification schemes in play in "streamboost", and I haven't torn apart the netgear X4's "dynamic QoS" scheme. > > 4.1.2 Target > > Should the target be tuned to at least the transmission time of an aggreg= ate > on aggregating media (e.g. Cable, 802.11n, etc)? I think so.... > but we can/should check with Kathy and Van.... No. We really don't have a good handle on what to be doing in the case of aggregation, and it's not really the limiting factor on how codel or fq_cod= el behave in cable and 802.11n. In the case of wireless in particular, it's no= t the aggregation that kills you so much as the "taxi stand topology". fq_codel, pie and codel work ok with a minimally buffered p2p wireless netw= ork today, but could be much better. > 4.1.3 > > This default of 10240 packets bothers me. That's of order 15,306,000 byt= es. It's potentally worse than that in the case of TSO/GSO, as the actual range= of packet size is 64 - 64k, not 64-1500 bytes. Thankfully TSO/GSO offloads have not made it to the wifi stacks I'm aware of yet, and there has been some work towards reducing the size of these to sane values for the link rate. > It should be computed on link speed, or maybe observed transmission rate. > And should it be in bytes? Given the 2+ years of experience we have with it now, I would definately ar= gue for a do-over that was purely byte limited. This restricts the in-use dynam= ic range of the limit to the overhead of the skb (256 bytes usually) + the pay= load. The limit is rather hard to hit, though, as usually the aqm algorithms kick= in long before it is hit. openwrt patches the limit to 1000 packets. (and again, offloads are not com= monly in use on routers) > How does one compute the "suitable size"? So it's wrong by at least an > order > of magnitude for *most* current devices. > > We really don't want to discourage naive people on IoT devices to think > that it will eat them out of house and home and therefore not to use > fq_codel. > > At a minimum, we should note that this is an artifact of the current > implementation, and note the shortcoming of the current implementation. > > Sigh. > > Where did our "no knobs" mantra get lost? I guess Eric is too used to > machines with 10G and faster ethernet interfaces. Well, if the actual link speed were available to the qdisc layer (it isn't)= the limit could be sized appropriately. > > 5.3 > > The "Jenkins" hash should be referenced. Which one is used? It appears to be a lookup3 from that suite, but I'd have to go look at the code again... > > Possibly worth noting that some other hash could also be used (I presume > it can be?), and why was the Jenkins hash chosen? It was there. I have seen a few other hash variants, (like spookyhash), but I'd like to try them on a typical dataset rather than an artificial one= . There is very little entropy in the protocol portion of the tuple, for example. I liked arris's 4 way set associative hash idea, btw. And then of course, sch_fq uses a red/black tree and gets away from hashing entirely, with spectacular results. (on a server) > 5.2 > > "This is because otherwise the queue can" -> "Otherwise the queue could" > > The last paragraph does probability computations; IIRC, this was work > done by Paul McKenney for SFQ. It should be referenced. > > 6.2 > > There are indenting problems in this section. > > 6.3 > > "it cannot be easily retrofitted to devices". > > Cannot is a bit strong; some silicon may also have modifyable firmware. > > I'd say instead: > > "it may be impossible to retrofit devices that do most of their > processing in silicon and lack space for timestamping" > > You say: > Also, timestamping functions in the core OS need to be very > efficient. > > Somehow we should make clear that perfection is not required. > Timestamping to of order a millisecond is fine; certainly getting time > at that resolution is sufficient, so long as the overhead to get the time= at > that resolution is very low. Well, I'd have actually preferred that the full timestamp was preserved. (the 64bit timestamp is presently shifted right 10 bits) and turned into a 32 bit one.... It would make throwing a drop notification to userspace more "interesting" Secondly, while a millisecond may well be enough at low rates, at least one variant of codel will throw away a bunch of packets with very similar timestamps at high rates when a high drop rate is needed. > > > 6.5 > > You say: > Finally, FQ-CoDel drops packets from the largest flows sooner and > more accurately than CoDel alone, and it is more responsive to > changes in bandwidth, and in number of flows, than CoDel alone. > > Why is this true? It's an assertion without explanation. I'd be happier > if there is a one/two sentence explanation. I labored over that sentence for ages. A more complicated explanation would not fit into the margins of this draft, and worthy of a paper all by itself. Let me stare into space on that for a while. > > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks From nobody Sun Oct 26 15:14:49 2014 Return-Path: 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 314281A1AB3 for ; Sun, 26 Oct 2014 15:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 nJsUohSZBkPi for ; Sun, 26 Oct 2014 15:14:44 -0700 (PDT) Received: from nm1-vm6.access.bullet.mail.gq1.yahoo.com (nm1-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4F51A1A2F for ; Sun, 26 Oct 2014 15:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1414361684; bh=5L3P1Hi+A7IBPjXC3ZNjR1xJWczxJGkXWqnPybvcff4=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To:From:Subject; b=WTVq6vHmEj5dJd5T+biVDKwlLI/Z2EGGMYw6Sxuj5usaE36Ah6io4RZQWUhf5oBrOSsefJ8VrTDm5vdfTG+b6J1XqGc93TMN0arWWJuO4vvjjyRRtF2wlzgTcINw+xPqm4Nlf3Kfyy9R17ptV+pmoUBWgywxw8wU9tjODI+gZko= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; b=ghFjX3zU+DLQvOroV7N2NVkzMarzuXVAWec0QC8QoEZ494kbc85YE1E2If0iYOo72v5wtaadfJ7YwDrkinOlye4tBl+Pc+MBTf6OD9ypTljtfVRJkccTvovWanTssrUqtfAKWFv963Ar5XSEFHh2Xduac+k8X97sAvF9IR3C2LM=; Received: from [216.39.60.176] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Oct 2014 22:14:44 -0000 Received: from [98.138.104.100] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Oct 2014 22:14:43 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 26 Oct 2014 22:14:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1414361683; bh=5L3P1Hi+A7IBPjXC3ZNjR1xJWczxJGkXWqnPybvcff4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GEzsgKZvCuXyYcPk4yBh/dt47+LXJQ1If8/+l2HEGrCcl/d9Lt0YsjE8YTK5uTgMjXCy2/FkRyrQnbzd3CL80rOu+AjqXN1Bridmauumevci81NreisEFNmbZyDq6TVgcmjspD3WHzGzWDA9rdkgVzNQzXbDwbtpV/9waEK+o4s= X-Yahoo-Newman-Id: 776503.90916.bm@smtp120.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cfgfcgAVM1lsHCFn_TSYn1hvndNoBcHs0TQeFe6untSYkeG ctjxJp22e5CoImLmiSltCqCqGcTp04J7E.XBawZXGZDZi5KrqvD8dqnayPKt YJ6RG7NYeO5e5wft5kVyuWGtdsZVO_UU56mClGcrbpJ8Vge9p2vkDHSUHthU IGY0xeMr6Q.grW7SyQfS_NF01hOGn3CgOLekE0lspRhPRTuzVFldGCjCljNb cGihGP5QRYo6blUHPBMb3UxIymSNW7XIdeo_inQ71qmML6j1Pw5u3rNMIZlo SKQaPVSKpXRiFIkJiVwUtDXcyKY0q_o2khPem0_j5nDoJgNUo5hl2Ops0TmV 4PKioNHPDlDhHNltLtJzgmUg31GbMOcIqm4H2DEAhCjcDwDarg2ua4RQyuuT Mv6F7d3XmfYgdz59kQvcfXYcPMfOlG32XV7itOYFa3Hjd.IgPeu7D58wWKdm hd6BxKIA43ioW8uFVjfhE44n3im.m_K_1TuySgmEeUredKFHqLVqalwipSqD 1zgtmdwp48MDIATNt_I5JIEsGipetIg82SSnfzIXhkr.oQ1qCA.FI8OFuORa O_1mMtnhHV1TsVUORPvWX.DmBSklg9f.2xDxVfDEmmfOxKUy7PzD15vTQ9OB zweSc7u_GIRDwm4CWCfwz7SCARzq7aLft1l6_1Sc4HT_LFG0NzFcutKLIs_x b0zgjRubc.lHmTGHT051lip2jcBk1GRfZshnMOk_GH63j.jAM84bPYqQFaTk 8FH265A-- X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Message-ID: <544D7251.3030200@rogers.com> Date: Sun, 26 Oct 2014 18:14:41 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: aqm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/12nCeB5EsDTC1rKokalt5pqqwpE Subject: Re: [aqm] Review of draft-hoeiland-joergensen-aqm-fq-codel-00 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: davecb@spamcop.net List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 22:14:47 -0000 Hey guys, are we trying too hard? This has more detail than one of my IAHC drafts (:-() --dave On 10/26/2014 06:05 PM, Dave Taht wrote: > We are working on revising the draft today, if anyone else has comments, > please let us know soonest. > > On Tue, Sep 30, 2014 at 2:24 PM, Jim Gettys wrote: >> Looks pretty good to me. I took a pretty good read on the airplane west >> yesterday, and comments are below. >> - Jim >> 1. >> >> "The rest of this document" is immediately followed by "The rest of this >> section". That repetition is unfortunate, and the second is capitalized. > k. > >> 1.2 >> >> You should note again that fq_codel is not limited to hashing on f-tuples; >> just that the current implementation defaults to hashing those. > k. > >> Noting that fq_codel gets really good performance is nice and usually better >> than most deployed ad-hoc classification schemes, but you should >> also note that if you want hard "guarantees" of performance, packet >> classification still has a role to play. For example, multiplexing a >> control plane for a network over that network would be something that >> requires >> explicit classification to provide such guarantees. > I have thought about publishing something as to how this stuff has > mostly deployed, which is with a 3 or 4 level classification system, as > per the SQM, qos-scripts, and free.fr'd DRR + fq_codel system. As > well as what's currently in "cake". > > I documented some of that here: > > http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html > > But as there is another working group entirely working on nailing down the > definitions of the diffserv codepoints and the expected behavior (not that > I agree that an insane level of detail is needed), and there hasn't > been much interest > here in what I've been calling "comprehensive queue management", I'm not > going to bother polishing that up before codel, fq-codel, and pie go > standards track. > > There are even more complex classification schemes in play in > "streamboost", and I haven't torn apart the netgear X4's "dynamic QoS" > scheme. > >> 4.1.2 Target >> >> Should the target be tuned to at least the transmission time of an aggregate >> on aggregating media (e.g. Cable, 802.11n, etc)? I think so.... >> but we can/should check with Kathy and Van.... > No. We really don't have a good handle on what to be doing in the case of > aggregation, and it's not really the limiting factor on how codel or fq_codel > behave in cable and 802.11n. In the case of wireless in particular, it's not > the aggregation that kills you so much as the "taxi stand topology". > > fq_codel, pie and codel work ok with a minimally buffered p2p wireless network > today, but could be much better. > >> 4.1.3 >> >> This default of 10240 packets bothers me. That's of order 15,306,000 bytes. > It's potentally worse than that in the case of TSO/GSO, as the actual range of > packet size is 64 - 64k, not 64-1500 bytes. > > Thankfully TSO/GSO offloads have not made it to the wifi stacks I'm aware > of yet, and there has been some work towards reducing the size of these > to sane values for the link rate. > >> It should be computed on link speed, or maybe observed transmission rate. >> And should it be in bytes? > Given the 2+ years of experience we have with it now, I would definately argue > for a do-over that was purely byte limited. This restricts the in-use dynamic > range of the limit to the overhead of the skb (256 bytes usually) + the payload. > > The limit is rather hard to hit, though, as usually the aqm algorithms kick in > long before it is hit. > > openwrt patches the limit to 1000 packets. (and again, offloads are not commonly > in use on routers) > >> How does one compute the "suitable size"? So it's wrong by at least an >> order >> of magnitude for *most* current devices. >> >> We really don't want to discourage naive people on IoT devices to think >> that it will eat them out of house and home and therefore not to use >> fq_codel. >> >> At a minimum, we should note that this is an artifact of the current >> implementation, and note the shortcoming of the current implementation. >> >> Sigh. >> >> Where did our "no knobs" mantra get lost? I guess Eric is too used to >> machines with 10G and faster ethernet interfaces. > Well, if the actual link speed were available to the qdisc layer (it isn't) the > limit could be sized appropriately. > >> 5.3 >> >> The "Jenkins" hash should be referenced. Which one is used? > It appears to be a lookup3 from that suite, but I'd have to go look at the > code again... > >> Possibly worth noting that some other hash could also be used (I presume >> it can be?), and why was the Jenkins hash chosen? > It was there. I have seen a few other hash variants, (like spookyhash), > but I'd like to try them on a typical dataset rather than an artificial one. > > There is very little entropy in > the protocol portion of the tuple, for example. > > I liked arris's 4 way set associative hash idea, btw. > > And then of course, sch_fq uses a red/black tree and gets away from > hashing entirely, > with spectacular results. (on a server) > >> 5.2 >> >> "This is because otherwise the queue can" -> "Otherwise the queue could" >> >> The last paragraph does probability computations; IIRC, this was work >> done by Paul McKenney for SFQ. It should be referenced. >> >> 6.2 >> >> There are indenting problems in this section. >> >> 6.3 >> >> "it cannot be easily retrofitted to devices". >> >> Cannot is a bit strong; some silicon may also have modifyable firmware. >> >> I'd say instead: >> >> "it may be impossible to retrofit devices that do most of their >> processing in silicon and lack space for timestamping" >> >> You say: >> Also, timestamping functions in the core OS need to be very >> efficient. >> >> Somehow we should make clear that perfection is not required. >> Timestamping to of order a millisecond is fine; certainly getting time >> at that resolution is sufficient, so long as the overhead to get the time at >> that resolution is very low. > Well, I'd have actually preferred that the full timestamp was preserved. > (the 64bit timestamp is presently shifted right 10 bits) and turned into > a 32 bit one.... > > It would make throwing a drop notification to userspace more "interesting" > > Secondly, while a millisecond may well be enough at low rates, > at least one variant of codel will throw away a bunch of packets > with very similar timestamps at high rates when a high drop rate is > needed. > >> >> 6.5 >> >> You say: >> Finally, FQ-CoDel drops packets from the largest flows sooner and >> more accurately than CoDel alone, and it is more responsive to >> changes in bandwidth, and in number of flows, than CoDel alone. >> >> Why is this true? It's an assertion without explanation. I'd be happier >> if there is a one/two sentence explanation. > I labored over that sentence for ages. A more complicated explanation > would not fit into the margins of this draft, and worthy of a paper all > by itself. > > Let me stare into space on that for a while. >> >> >> >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >> > > -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain From nobody Mon Oct 27 22:00:22 2014 Return-Path: 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 93FFB1A19EB; Mon, 27 Oct 2014 22:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 hR8MwyC8-g_V; Mon, 27 Oct 2014 22:00:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 210E61A03A4; Mon, 27 Oct 2014 22:00:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028050017.14999.32425.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 22:00:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/4otTo0KD5dLVh6cUgSnnurD8rCs Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-pie-00.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 05:00:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. Title : PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem Authors : Rong Pan Preethi Natarajan Fred Baker Greg White Filename : draft-ietf-aqm-pie-00.txt Pages : 19 Date : 2014-10-27 Abstract: Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. We present here a lightweight design, PIE (Proportional Integral controller Enhanced) that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-aqm-pie-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 22:03:16 2014 Return-Path: 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 1E84C1A07BC for ; Mon, 27 Oct 2014 22:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 uz-BI22aFRzR for ; Mon, 27 Oct 2014 22:03:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8301A1A04 for ; Mon, 27 Oct 2014 22:03:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028050313.14999.47981.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 22:03:13 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/_mXoq0DcIRP2OOgRXa3LHzViFrI Subject: [aqm] Milestones changed for aqm WG X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 05:03:15 -0000 Changed milestone "Submit first algorithm specification to IESG for publication as Proposed Standard", added draft-ietf-aqm-codel, draft-ietf-aqm-pie to milestone. URL: http://datatracker.ietf.org/wg/aqm/charter/ From nobody Tue Oct 28 10:12:59 2014 Return-Path: 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 C67D91A9084 for ; Tue, 28 Oct 2014 10:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G7WzFrDuSp6Z for ; Tue, 28 Oct 2014 10:12:56 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913F91A8F3A for ; Tue, 28 Oct 2014 10:12:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,803,1406617200"; d="scan'208";a="206463224" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx12-out.netapp.com with ESMTP; 28 Oct 2014 10:12:55 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 28 Oct 2014 10:12:54 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::f046:41c2:b062:3ccd%21]) with mapi id 15.00.0995.031; Tue, 28 Oct 2014 10:12:54 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: Draft Agenda for IETF91 Thread-Index: Ac/y0cSDj5hhB2j9QgiNlALOo0o2DA== Date: Tue, 28 Oct 2014 17:12:54 +0000 Message-ID: <5c65c172515e4f22bbc69f6b229927d3@hioexcmbx05-prd.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/G-DoT4QhKX4Y8IPmKlFWdBmOWBg Subject: [aqm] Draft Agenda for IETF91 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:12:58 -0000 Hi, please review the current draft agenda. If I have missed anyone who expecte= d to have a slot, or surprised some author to have assigned a slot, please = let me know. As usual, at this stage it's easy to shuffle around and adjust this agenda. Also, I am already looking for volunteers to support me in the meeting by t= aking notes, and playing jabber scribe. As it seems right now, my Co-Chair = can't help me out with his very eloquent and professional way of running th= e meeting, thus I would also be happy for a native speaker to help me in th= e front. Thanks a lot! ****************************************************** AQM Agenda IETF 91 in Honolulu, HI, USA Monday, November 10, 2014, 13:00-15:00 HAST=20 ****************************************************** WG status --------- 13:00 Agenda bashing AQM status Process for adopting algorithms=20 Chairs 15 min =20 WG items -------- 13:15 draft-ietf-aqm-eval-guidelines Naeem Khademi et. al. 45 min 14:00 draft-ietf-aqm-pie Rong Pan 20 min =20 14:20 draft-ietf-aqm-codel Jana Iyengar 20 min =20 =20 Algorithm Proposals ------------------- =20 14:40 draft-hoeiland-joergensen-aqm-fq-codel Toke Hoeiland-Joergensen=20 20 min Richard Scheffenegger From nobody Tue Oct 28 13:36:15 2014 Return-Path: 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 D82841ACE83 for ; Tue, 28 Oct 2014 13:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 TEM-WezkXxnn for ; Tue, 28 Oct 2014 13:36:10 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F14A1ACE80 for ; Tue, 28 Oct 2014 13:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Sender: toke@toke.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1414528189; bh=RIQZ1ldJbic5r74TpPUiWioJ4jAhajxOhB1g29K2mkM=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=BcjWQ9XCd7hLKWG+1ORmbLwRUq/hcGZpN2fhoJInKuzea3u5lWumFQMZFtUbarm3d 9Jpelw347UO4k8GHfovEF8S3079sok77YcRFZqHR5YUhVv+NYBGF386/CrFmY+Dyn8 X3cmvDXnjaJGIxcj0iRyhoKBvVLbkJ0lyG0fCA/Y= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 4EDD230326; Tue, 28 Oct 2014 13:35:52 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: "Scheffenegger\, Richard" References: <5c65c172515e4f22bbc69f6b229927d3@hioexcmbx05-prd.hq.netapp.com> Date: Tue, 28 Oct 2014 13:35:52 -0700 In-Reply-To: <5c65c172515e4f22bbc69f6b229927d3@hioexcmbx05-prd.hq.netapp.com> (Richard Scheffenegger's message of "Tue, 28 Oct 2014 17:12:54 +0000") Message-ID: <87bnowlyon.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/O17EG7YbXm6ZQ9sT66uxTpmRDNc Cc: "aqm@ietf.org" Subject: Re: [aqm] Draft Agenda for IETF91 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:36:12 -0000 "Scheffenegger, Richard" writes: > 14:40 > draft-hoeiland-joergensen-aqm-fq-codel > Toke Hoeiland-Joergensen > 20 min I managed to botch the submission process for the update to this, and now the ietf web site is closed for submissions. So until it reopens during the meeting, here is the -01 for this draft for perusal: https://kau.toke.dk/ietf/draft-hoeiland-joergensen-aqm-fq-codel-01.html or https://kau.toke.dk/ietf/draft-hoeiland-joergensen-aqm-fq-codel-01.txt Compared to the previous version this version had minor wording changes throughout, as well as some new references added. In addition, a new section on the algorithm limitations (section 7 in this version) has been added. -Toke From nobody Thu Oct 30 05:12:45 2014 Return-Path: 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 11BF01A0007 for ; Thu, 30 Oct 2014 05:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 vkPLUDek_41G for ; Thu, 30 Oct 2014 05:12:42 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EEC1A0015 for ; Thu, 30 Oct 2014 05:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=786; q=dns/txt; s=iport; t=1414671162; x=1415880762; h=from:to:subject:date:message-id:mime-version; bh=sDMcz63JL6N1jttuNf7TLYv2CILbQLv0mKC9zcFWzj0=; b=ev0LPf6r6DhxZF/60/J9IyUF0LZ5WRqvggfxNKOHwDMw69/itD/UXeUC kLv6Jov+1GBH1eQTeyKfGa9aj8IZesr83xmA/vhCQ7rq/pdsIYFAd+TgW pA55vtCMTBUa/Q8nWM75tsueu94H0WAP4FWsxYFv3gtYr4JKszk+L1Wq3 c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAGsqUlStJA2L/2dsb2JhbABcgw6BMI1iyGoWAQEBAQFyC4QJgQsBgQAnBCGIM6QkpDsBAQEBAQUBAQEBAQEBARqURIEeBZINghKBUId7lj+DeII0gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,285,1413244800"; d="asc'?scan'208";a="91730797" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 30 Oct 2014 12:12:42 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9UCCfox012352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 30 Oct 2014 12:12:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 07:12:41 -0500 From: "Fred Baker (fred)" To: "aqm@ietf.org" Thread-Topic: draft-ksubram-lmap-router-buffer-sizes Thread-Index: AQHP9DrNCm0hwBdD+kiyg93jq1VAMg== Date: Thu, 30 Oct 2014 12:12:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_1E7B37D0-209E-4423-84E0-B9FBF2E4748C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/uA3i5qZ0GrrAdZV4MHCSZyvLbxo Subject: [aqm] draft-ksubram-lmap-router-buffer-sizes X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:12:44 -0000 --Apple-Mail=_1E7B37D0-209E-4423-84E0-B9FBF2E4748C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks from AQM may be interested to comment on = draft-ksubram-lmap-router-buffer-sizes on the lmap list. --Apple-Mail=_1E7B37D0-209E-4423-84E0-B9FBF2E4748C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUUisrbjEdbHIsm0MRAvheAJ9ac/fm7V/EPF9iWZKDCpUl158wyACg5w4q i7/7kGGC1cLwwKXEUAA9cuA= =+zi3 -----END PGP SIGNATURE----- --Apple-Mail=_1E7B37D0-209E-4423-84E0-B9FBF2E4748C-- From nobody Thu Oct 30 06:49:21 2014 Return-Path: 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 E26061AD382 for ; Thu, 30 Oct 2014 06:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 QZGBKv88VdCo for ; Thu, 30 Oct 2014 06:49:10 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845A61AD37E for ; Thu, 30 Oct 2014 06:49:09 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id nt9so4592959obb.15 for ; Thu, 30 Oct 2014 06:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hplEFhW0IkobSkWBkyJNnQ9bSnSMaGo18D+5dL43dkY=; b=x6A8N5naMqRcXcGJjyP6MXH1FaJLe15+T5BXLG+ydjkPeyUWgXlSEJGpwTQOqTVP7D N2I7xojwToyVwTFbwUyTp8HgIZTK54FPE0UDWXre5ZiCsNqI/Y6hUJL1G5lClUTRqVIH bVlDIdkd9Du2rjaRXJJsCMZw/pqFkzmdYHdnYWFQCIqohNOlEPIA0PtIZRGZD7d33b96 JTTBw9Cqscee8gG+rAsBIrn0laCCJxmlMqeKGoKTLnn8EOzp2ZTK2ZnZVp8OhpvqWmu8 M9UsRPYh85PL8R34MDCi/mUcRtewCH3gI3dCASkdZIukcIhft7q5DtCDc8+REwnh1DkG 0R3A== MIME-Version: 1.0 X-Received: by 10.60.55.200 with SMTP id u8mr14085705oep.43.1414676949000; Thu, 30 Oct 2014 06:49:09 -0700 (PDT) Received: by 10.202.227.211 with HTTP; Thu, 30 Oct 2014 06:49:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Oct 2014 06:49:08 -0700 Message-ID: From: Dave Taht To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/9GEgLrSRSYAZ8e34ecMXsB70KfA Cc: "aqm@ietf.org" Subject: Re: [aqm] draft-ksubram-lmap-router-buffer-sizes X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:49:15 -0000 I didn't get past the first sentence. "The question boils down to quantify buffer sizes and yet achieve 100% utilization on links with maximum throughput at a feasible cost. " My goal has always been to have minimal induced latency and reasonable utilization, and also to keep my blood pressure low. Reading further strikes me as damaging to both goals. On Thu, Oct 30, 2014 at 5:12 AM, Fred Baker (fred) wrote: > Folks from AQM may be interested to comment on draft-ksubram-lmap-router-= buffer-sizes on the lmap list. > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks From nobody Thu Oct 30 08:41:34 2014 Return-Path: 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 2954A1AD530 for ; Thu, 30 Oct 2014 08:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 GM27X-a_bHk9 for ; Thu, 30 Oct 2014 08:41:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7CC1AD531 for ; Thu, 30 Oct 2014 08:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1646; q=dns/txt; s=iport; t=1414683663; x=1415893263; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=erd0aOUYHzs8aJGAxE2QsiaviGF/VrHSPkOE1LmSAy8=; b=eZ9xiFi6Lp7yPrbGM2GFuu4fjqL/GLKbcOqV17SxviJpnQfjirTCkokk tEVI2EiQXbXBMg7y6kyyMWUJ4pPyYCUoDdyzPHZylGRnSiQyvf9rbnkDX 0ncsOAodhAVO/OWkHhyQGjoUplLaC6yWwUX+22bqRQoji5xHNNoF0okwX 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEMAK1bUlStJA2G/2dsb2JhbABcgw5UWAS6ApNMCodNAoEkFgEBAQEBfYQCAQEBAwEBAQFrCwULAgEIGC4hBgslAgQOBQ6IHgMJCQ3DQA2EYgEBAQEBAQEBAQEBAQEBAQEBAQEBAReOVieCEweDLYEeBZINghKBUIVqghGPV4Zog3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,286,1413244800"; d="asc'?scan'208";a="91801607" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 30 Oct 2014 15:40:58 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9UFewAn025054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 15:40:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 10:40:58 -0500 From: "Fred Baker (fred)" To: Dave Taht Thread-Topic: [aqm] draft-ksubram-lmap-router-buffer-sizes Thread-Index: AQHP9Ffm0b0dc/eLSEmxH8d//x8pog== Date: Thu, 30 Oct 2014 15:40:58 +0000 Message-ID: <0D4BA625-7720-41F7-BB28-594DAF855A86@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_FF74A183-F9B9-41E4-B8E5-F375AAAFCCB1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/GMd7NYPooTiJbBsKlL47SynHoDM Cc: "aqm@ietf.org" Subject: Re: [aqm] draft-ksubram-lmap-router-buffer-sizes X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:41:32 -0000 --Apple-Mail=_FF74A183-F9B9-41E4-B8E5-F375AAAFCCB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 That might be a comment to make. On Oct 30, 2014, at 6:49 AM, Dave Taht wrote: > I didn't get past the first sentence. >=20 > "The question boils down to quantify buffer sizes and yet achieve 100% > utilization on links with maximum > throughput at a feasible cost. " >=20 > My goal has always been to have minimal induced latency and reasonable > utilization, and also to keep my blood pressure low. Reading further > strikes me as damaging to both goals. >=20 >=20 > On Thu, Oct 30, 2014 at 5:12 AM, Fred Baker (fred) = wrote: >> Folks from AQM may be interested to comment on = draft-ksubram-lmap-router-buffer-sizes on the lmap list. >>=20 >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks --Apple-Mail=_FF74A183-F9B9-41E4-B8E5-F375AAAFCCB1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUUlv7bjEdbHIsm0MRAhYxAJ0cCq0P5TnXFEO+D3xPSBsDwk1mCwCfSAJI 9tz7Qppq8gjWSl6x2g76Cw8= =A4g9 -----END PGP SIGNATURE----- --Apple-Mail=_FF74A183-F9B9-41E4-B8E5-F375AAAFCCB1-- From nobody Thu Oct 30 19:00:34 2014 Return-Path: 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 41D6B1A8A59 for ; Thu, 30 Oct 2014 19:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 Sun3NoZ_jW5l for ; Thu, 30 Oct 2014 19:00:31 -0700 (PDT) Received: from nm18-vm10.access.bullet.mail.bf1.yahoo.com (nm18-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.89]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF5F1A8A52 for ; Thu, 30 Oct 2014 19:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1414720830; bh=avnN2CcnMOWvb3/7WtEu5V2qrfmx9Rbh2zy8Rk4bOqI=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To:From:Subject; b=ObUAfwlM0Ca7P4nd9xddcI5Gh1MmLTdSt3vJG463FaEY+SQQOF/4Vwwf7TksJrR+TD2ujhGJdTBcdsK+PV7sQwe/BLVf698LI+ISB6DlB4l/PWLeSbg7onAeQ43F16Oy3Rhw0bZ6A/IWnWyiERIwELyEY9qq0/MZYE5wyw3DoZg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; b=I2jA1h6v2+dDXPH7iCBz6P32CEUUmXMlyHL16WSiPKJPCkx4MHndy9LZ7vjY5bQi9/2GzDh8kwWHS4nZhvrnYH5KB4WEvvYstWTTjsGyF29TPTTeAaFeKPEzD68taFTN+eoKlbk5MAmrwT/f61bTt9aVTZ53RjANDgSyax5zbDM=; Received: from [66.196.81.165] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 02:00:30 -0000 Received: from [98.138.226.243] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 02:00:29 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 31 Oct 2014 02:00:29 -0000 X-Yahoo-Newman-Id: 708051.51946.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0R2A2s8VM1lLD_UpV6NtrJQ6t8W9zMDKh_BwdDpjsZSh0pd mtZe0TDk_.NQoydP.473xnfZNw8hbSN0ZBUxwE86omEG2BV7LLUcz5gr6R2F NKETFP5WJBqXxC6j8alpK.Lde5y9Eiv6xR5kMYG3UWRYLtSLQgKOFvhDE2Td VXC72m9d5UxAqLPXpH74AFd6zJGTsFwJfVds.zakUeYOJfMP54TsZnFVPK_5 4Kn0cLa4LiGzfZJvckV1.F5L2s4uRHJq6_qgbCzyg.nQqMRnI_9yXx.JZ.ge 106xRTuEXSD4UlJsbHyRur8FXyntcHEbG7zN9fbqvkRxdlTlvjsbUxln6f8C jz8r_ys5CRMe.vCPaXWl8rFVC8.NuP48DJ9wA9Iv3eywhaA9OhbLLL9CjuBe M3S8OPFhMOBN1yXjxXwuVODDmfdfuEBybMnl5G0ZNSF2C_2Ct_vZ7MPytxKw G_IOGkidGnUXW347Cc_AC_3DlZiET9k48uBvp_3oDnZss8kkUzT_54vs6wAI OGgnVl_RnkZXxPEJBq0iWyDiKr3mqEboGmg-- X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Message-ID: <5452ED3C.1060601@rogers.com> Date: Thu, 30 Oct 2014 22:00:28 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: aqm@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010407090600010200090306" Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/bC3ib2wA_C2vKOHMgMY3YGJYumc Subject: Re: [aqm] draft-ksubram-lmap-router-buffer-sizes X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: davecb@spamcop.net List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:00:33 -0000 This is a multi-part message in MIME format. --------------010407090600010200090306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Yup: author makes a classic, and I fear common, wrong assumption about tradeoffs in queuing systems. Latency is minimized /throughout/ the operating range if a queue is not allowed to form. TCP consciously sees a queue as congestion and avoids having it. Bufferboat causes queuing, and degrades both (low) latency and throughput, trying to drive the link toward congestive collapse. The worst of all possible worlds! In this case it also tries to drive Dave Taht's circulation system into collapse, which is doubly ungood. --dave On 10/30/2014 09:49 AM, Dave Taht wrote: > I didn't get past the first sentence. > > "The question boils down to quantify buffer sizes and yet achieve 100% > utilization on links with maximum > throughput at a feasible cost. " > > My goal has always been to have minimal induced latency and reasonable > utilization, and also to keep my blood pressure low. Reading further > strikes me as damaging to both goals. > > > On Thu, Oct 30, 2014 at 5:12 AM, Fred Baker (fred) wrote: >> Folks from AQM may be interested to comment on draft-ksubram-lmap-router-buffer-sizes on the lmap list. >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >> > > -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain --------------010407090600010200090306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Yup: author makes a classic, and I fear common, wrong assumption about tradeoffs in queuing systems. 

Latency is minimized throughout the operating range if a queue is not allowed to form. TCP consciously sees a queue as congestion and avoids having it. 

Bufferboat causes queuing, and degrades both (low) latency and throughput, trying to  drive the link toward congestive collapse.  The worst of all possible worlds!

In this case it also tries to drive Dave Taht's circulation system into collapse, which is doubly ungood.

--dave


On 10/30/2014 09:49 AM, Dave Taht wrote:
I didn't get past the first sentence.

"The question boils down to quantify buffer sizes and yet achieve 100%
utilization on links with maximum
   throughput at a feasible cost. "

My goal has always been to have minimal induced latency and reasonable
utilization, and also to keep my blood pressure low. Reading further
strikes me as damaging to both goals.


On Thu, Oct 30, 2014 at 5:12 AM, Fred Baker (fred) <fred@cisco.com> wrote:

Folks from AQM may be interested to comment on draft-ksubram-lmap-router-buffer-sizes on the lmap list.

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm







-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain
--------------010407090600010200090306-- From nobody Fri Oct 31 07:58:58 2014 Return-Path: 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 262981A90A3 for ; Fri, 31 Oct 2014 07:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 B3v3Rv75Y4mf for ; Fri, 31 Oct 2014 07:58:48 -0700 (PDT) Received: from nm39-vm9.bullet.mail.bf1.yahoo.com (nm39-vm9.bullet.mail.bf1.yahoo.com [72.30.239.153]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675B11A0111 for ; Fri, 31 Oct 2014 07:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414767526; bh=aAkGpyA1oZi9OpaMbyRJ07cHDHmZdicC756hgYfpq3g=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=VsEIFHBRKHJNc/lliyD92OdOKXeNEqvny7iTouGCq6SfzghYL+E4nxbbOZf6o+l/ibUGIRAH9Ln4DXuJ1QsyAXSLxH3+mi3B6Nqaa7U4gDL3Q9gECejxNKRdWGXpaFYGGXmU0nelmKfnh90XRSxhFGPVr7U/fdwLUMa4aS/btYJ3mHDJCUE1og7wi2OXZNSH4lVDYUlKo9jGJ24XplWRlPVA5nIiMNxDy7nsGrlHlexvSrRUtRdGeitAMjNBg7zK8E2LAxWTrfaxMLFy2c2UlOzQUxmYmQk8uZGayb/59ydVOvHMDUML53vbKo8SH9yqSZhJ0uZ7FEbbJ6u0e14z/A== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=UtVuQH6oLe3ROKYAM5VhLxK7+ldzm3Xbu4bbK6sIMnydaHf/NthkbqN/rcP/pqSYpvg7Q6mVtSe7l/HQJGWogF6fWs/8vzm6OVIHTXv3wLXu2M2bacSk1rr9g+HHS90W+npXb+WIO3iWs6IZjqbjeEwYPj2vBZBlKckOn8N9mFkEmym3qZk6R3nZ5Bd61y4BZHxOJWOh6PY4SesZlnxryMJk0cmJSbJFoihRtKLdorEYqCiftcv94/Qn57WTVoaZo3l7hH9auZiIlk+ceHQZ9Hig9cURhe4Z+v6Gv/9ei9Vs+MYONJHzkjLFhTLdiNQZ6tgVKXEjVqEBs2MgnMv/ZQ==; Received: from [66.196.81.173] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 14:58:46 -0000 Received: from [98.139.212.197] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 14:58:46 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 14:58:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 604707.80174.bm@omp1006.mail.bf1.yahoo.com Received: by 66.196.81.104; Fri, 31 Oct 2014 14:58:46 +0000 Date: Fri, 31 Oct 2014 14:58:44 +0000 (UTC) From: Daniel Havey To: "aqm@ietf.org" Message-ID: <1810074792.117895.1414767524846.JavaMail.yahoo@jws10699.mail.bf1.yahoo.com> In-Reply-To: <5452ED3C.1060601@rogers.com> References: <5452ED3C.1060601@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/YQ1GGimOnHHfNzCcf5NANSvofgI Subject: Re: [aqm] draft-ksubram-lmap-router-buffer-sizes X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Daniel Havey List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:58:54 -0000 Yeah, I have encountered this type of problem in many forms. It seems that there are fundamental misunderstandings of the problem. This seems prevalent in expert networking communities from people who have the knowledge, but, perhaps have not thought the problem through thoroughly. I guess we are just working at cross-purposes with other communities. Perhaps there is no cure for this problem and maybe we just have to accept and embrace it. ...Daniel On Thursday, October 30, 2014 7:00 PM, David Collier-Brown wrote: Yup: author makes a classic, and I fear common, wrong assumption about tradeoffs in queuing systems. Latency is minimized throughout the operating range if a queue is not allowed to form. TCP consciously sees a queue as congestion and avoids having it. Bufferboat causes queuing, and degrades both (low) latency and throughput, trying to drive the link toward congestive collapse. The worst of all possible worlds! In this case it also tries to drive Dave Taht's circulation system into collapse, which is doubly ungood. --dave On 10/30/2014 09:49 AM, Dave Taht wrote: I didn't get past the first sentence. "The question boils down to quantify buffer sizes and yet achieve 100% utilization on links with maximum throughput at a feasible cost. " My goal has always been to have minimal induced latency and reasonable utilization, and also to keep my blood pressure low. Reading further strikes me as damaging to both goals. On Thu, Oct 30, 2014 at 5:12 AM, Fred Baker (fred) wrote: >Folks from AQM may be interested to comment on draft-ksubram-lmap-router-buffer-sizes on the lmap list. _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm From nobody Fri Oct 31 11:03:46 2014 Return-Path: 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 C0B3A1A037F for ; Fri, 31 Oct 2014 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 hP6fvwHWBiP8 for ; Fri, 31 Oct 2014 11:03:42 -0700 (PDT) Received: from nm26-vm6.access.bullet.mail.gq1.yahoo.com (nm26-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81A61A0101 for ; Fri, 31 Oct 2014 11:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1414778621; bh=SPlP85N6dYqiuKVVwNbnQ1v8ptJwWchJxG9aXhnBqnc=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To:From:Subject; b=B/GAlF5zXl+fLzV5exvmZyg/nEZpdahTzii0kLWW4QdGy2vv1gpTcR0u2FUeMUDlhHo9V6qDoYer+Bq+LNXD8ilS1c7koPQj76Y2ezn7mM1xoLERqB1bZPC5/CmZJt+kH13kItSpYdj5RBBT0ZMvrRiPXkYIhX1eCf93fUwKVGw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; b=gqYE3OrNVAB72nE/6ZDaXhB6qE+SKTTHImB6bbgcs6ihwc62UZpCEhmQWY5GtRtm2kvxspICeosWsHNZClzwIKqlgXumD0c5VYsXV7qysU8JZGXRmoPTldHeH/LoDba0FZGRoPmh2eRbomB8UwuDKFr4Ll5nwRxr7IJkxkaq1To=; Received: from [216.39.60.166] by nm26.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Oct 2014 18:03:41 -0000 Received: from [98.138.226.241] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Oct 2014 18:03:41 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 31 Oct 2014 18:03:41 -0000 X-Yahoo-Newman-Id: 272630.52649.bm@smtp112.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: F.dQPggVM1l5XJ5QdWWyCZAiUsZsjSDLBoRExbC7wqsOPHx R.5d0NvuIfXrINtqaAq020aWolSPNtJHQqQ.liohy9fMT4UP.CE_vro4lhLN owi60yA9JLTO97iyQ1EfFq.9WINnhhK17vPcUp3IiRDI__hIzdc3UZQf7IOV 5oVa5.GJXYRMHKAktJRGupC.X7HKCYxpPYbNu1uS1e7hodRHsFWO_6wauyRW w6vnweZVqFMScAPfTDsoF4YoFKPYxzcF5P_lnzosPwlp1Tx1MqyQ0o6Yl9p5 MGKEyWK6KbEd3U5uX7Mv3OA3tye1rclLkxYMD.BSXS8.jNoNf2JenBqs9kZA ORNhiahhoeOEXYHh8Rqzr8iBG2GzRurd7CUhlSGX8oTapSE_UuH4QdVX0tya EzobGDQAVRSPuPBkYCVcpGnEyiaX3qV.zgHeb10k2eggUk3RK1oYWaTL6Qit xwMmPFt2bMUV50I54.fJPTekn8h69dJH1DXzlnWJI9qHFebnRGpQEPH1Fp8S elJ0EMy_yiijtIilkTbkj_y_9Fk4yP9SjIzXq X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Message-ID: <5453CEFB.8090203@rogers.com> Date: Fri, 31 Oct 2014 14:03:39 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: aqm@ietf.org References: <5452ED3C.1060601@rogers.com> <1810074792.117895.1414767524846.JavaMail.yahoo@jws10699.mail.bf1.yahoo.com> In-Reply-To: <1810074792.117895.1414767524846.JavaMail.yahoo@jws10699.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/IEfaOUEmKStfaHbUtENzet3YBDc Subject: Re: [aqm] draft-ksubram-lmap-router-buffer-sizes X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: davecb@spamcop.net List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:03:45 -0000 It's OK, we just need to write it up as informational material and cite it a lot. Maybe as an appendix to a congestion-related rfc, maybe as a little bitty one on it's own. Having said that, I guess I've just volunteered to write it. Therefor: If someone says where it should go, so people will find it when looking for the expected behaviour, I'll compose a draft and help make it fit. --dave On 10/31/2014 10:58 AM, Daniel Havey wrote: > Yeah, I have encountered this type of problem in many forms. It seems that there are fundamental misunderstandings of the problem. This seems prevalent in expert networking communities from people who have the knowledge, but, perhaps have not thought the problem through thoroughly. > > I guess we are just working at cross-purposes with other communities. Perhaps there is no cure for this problem and maybe we just have to accept and embrace it. > > > ...Daniel > > On Thursday, October 30, 2014 7:00 PM, David Collier-Brown wrote: > > > > Yup: author makes a classic, and I fear common, wrong assumption about tradeoffs in queuing systems. > > Latency is minimized throughout the operating range if a queue is not allowed to form. TCP consciously sees a queue as congestion and avoids having it. > > Bufferboat causes queuing, and degrades both (low) latency and > throughput, trying to drive the link toward congestive collapse. > The worst of all possible worlds! > > In this case it also tries to drive Dave Taht's circulation system > into collapse, which is doubly ungood. > > --dave > > > > On 10/30/2014 09:49 AM, Dave Taht wrote: > > I didn't get past the first sentence. "The question boils down to quantify buffer sizes and yet achieve 100% > utilization on links with maximum throughput at a feasible cost. " My goal has always been to have minimal induced latency and reasonable > utilization, and also to keep my blood pressure low. Reading further > strikes me as damaging to both goals. On Thu, Oct 30, 2014 at 5:12 AM, Fred Baker (fred) wrote: >> Folks from AQM may be interested to comment on draft-ksubram-lmap-router-buffer-sizes on the lmap list. _______________________________________________ > aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm > > -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain