From nicolas.kuhn@telecom-bretagne.eu Mon Feb 3 06:30:10 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 708B71A003B for ; Mon, 3 Feb 2014 06:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35, 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 YMnqlr-Mhlc3 for ; Mon, 3 Feb 2014 06:30:05 -0800 (PST) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4951A00E1 for ; Mon, 3 Feb 2014 06:30:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 9CC6F66009; Mon, 3 Feb 2014 15:30:04 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5JCtdL0UwGR; Mon, 3 Feb 2014 15:30:04 +0100 (CET) Received: from dhcp-salsa-i-129-163.rennes.enst-bretagne.fr (dhcp-salsa-i-129-163.rennes.enst-bretagne.fr [10.35.129.163]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 64C4366008; Mon, 3 Feb 2014 15:30:04 +0100 (CET) From: Nicolas KUHN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 3 Feb 2014 15:30:03 +0100 To: bloat-ietf@lists.bufferbloat.net, "aqm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [aqm] [FQ_CoDel] "Official" version 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: Mon, 03 Feb 2014 14:30:10 -0000 Dear all,=20 We would like to test FQ_CoDel and we wonder which version to evaluate.=20= Does anyone know where we could get the "official" version / source code = of FQ_CoDel ? (linux and/or NS2 if possible) Thanks a lot,=20 Kind regards,=20 Nicolas From gettysjim@gmail.com Mon Feb 3 07:57: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 184641A019E for ; Mon, 3 Feb 2014 07:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 Ygl9xB-ME8z8 for ; Mon, 3 Feb 2014 07:57:50 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B44061A0162 for ; Mon, 3 Feb 2014 07:57:45 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id g12so8373826oah.31 for ; Mon, 03 Feb 2014 07:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xGpld1SGhMccuW1s6vQsYFSwyXGHUnooz2vMkQOz90I=; b=ACb+wLbDkoXqaCh003AKgy/sUltCxP/Xc3nfVdKOrQJybb0Cs3pUT7AjoXUZY5Eimo rQDvJalrHZrgSeoBkzAbpOkrmC6m4A2DBRdAP7ytPx8BqFcAc6YBUt7tgzDqQ5UGnJBw SfrGAAvOPPxBtohl+tD6MTdH01lONswoMDLgiXUQ26iFF2cQ2ugmrrr9u1oeL+TxwLeD pwVkA9TZB70CcNRQeBhHQkaZ/r8n9jwVadp20NHdcQTMUgf+XOSEqRP5HlfYwCt2V5Fe dZBL8ivKfO0dGy2LoGGDBVU2W0BdrUI37rSjnhsZwW28tROFKng6GfkxZ+QKX/+ifmNP mZFw== MIME-Version: 1.0 X-Received: by 10.182.247.68 with SMTP id yc4mr1117115obc.67.1391443065542; Mon, 03 Feb 2014 07:57:45 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.76.84.162 with HTTP; Mon, 3 Feb 2014 07:57:45 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 10:57:45 -0500 X-Google-Sender-Auth: rrLhFK-4MsSeVH0YmSWyt9Mcdfw Message-ID: From: Jim Gettys To: Nicolas KUHN Content-Type: multipart/alternative; boundary=089e015384d6a6169e04f1829525 Cc: bloat-ietf@lists.bufferbloat.net, "aqm@ietf.org" Subject: Re: [aqm] [FQ_CoDel] "Official" version 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: Mon, 03 Feb 2014 15:57:53 -0000 --089e015384d6a6169e04f1829525 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 3, 2014 at 9:30 AM, Nicolas KUHN < nicolas.kuhn@telecom-bretagne.eu> wrote: > Dear all, > > We would like to test FQ_CoDel and we wonder which version to evaluate. fq_codel has been in Linux since about Linux 3.5, IIRC. For casual experiments, a current Linux distro will have it available at the invocation of the "tc" command. But... You should generally be testing the latest Linux release (not that I think there has been much change in fq_codel, as demonstrated in: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=refs%2Ftags%2Fv3.14-rc1&qt=grep&q=fq_codel For serious bench marking getting results from an old system can make your results easily invalid since there has been a large number of improvements in Linux for bufferbloat everywhere over the last three years, and the queue discipline is only part of the equation. For example, many ethernet drivers in SOC's found in home routers may still lack even BQL support. You should be testing the fq_codel queue discipline: while Dave Taht has played with a number of variants on that theme, nothing to date has shown itself (by testing) with enough better results to be worth merging upstream into kernel.org. Pie finally entered kernel.org Linux a month or so ago. Note that there a large number of "traps" for the unwary in this benchmarking/testing business, into which multiple groups have come to bad ends causing questionable results to confuse everyone. For example, the details of the underlying device driver can matter a lot (actually, hugely!), and netem has to be used with exquisite care just to name a couple of the big traps. Fundamentally, you need to realize that the queue discipline in Linux (where you can apply aqm) does *not* have control of all of the buffering in the system; device drivers and even the hardware itself can do "interesting" things to you. And a bunch of changes have taken place in the Linux TCP stack to remove unneeded buffering since around Linux 3.2. At one point I think the list was up to a dozen or more significant improvements in the Linux networking stack, independent of fq_codel. We've come to learn that WiFi in particular needs a serious rewrite, and before venturing far, you'd be wise to get in touch with us further. ATM, the ath9k driver is least problematic, but even there, aggregation causes large amounts of buffering (32 packets!). Dave Taht and I tried to outline what you should be thinking about when bench marking in: http://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel Pretty much all of these issues apply to anything you do, not just fq_codel. I think that page overs most of the problems though of course, Linux is a moving target so I'm sure there will be future problems :-(. > Does anyone know where we could get the "official" version / source code > of FQ_CoDel ? > (linux and/or NS2 if possible) > www.kernel.org for the source. You can use git to see the exact revision history of the code. I forget off hand where to find the simulation code... There is a link somewhere in the bufferbloat/codel wiki http://www.bufferbloat.net/projects/codel/wiki/Wiki Help from people to get the wiki up to date gratefully appreciated! Jim > Thanks a lot, > > Kind regards, > > Nicolas > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --089e015384d6a6169e04f1829525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 3, 2014 at 9:30 AM, Nicolas KUHN <nicolas.k= uhn@telecom-bretagne.eu> wrote:
Dear all,

We would like to test FQ_CoDel and we wonder which version to evaluate.

fq_codel has been in Linux since about Linux 3.5, IIRC. =A0For casual e= xperiments, a current Linux distro will have it available at the invocation= of the "tc" command. =A0But...

You s= hould generally be testing the latest Linux release (not that I think there= has been much change in fq_codel, as demonstrated in:=A0https://git.kernel.org/cgit= /linux/kernel/git/torvalds/linux.git/log/?id=3Drefs%2Ftags%2Fv3.14-rc1&= qt=3Dgrep&q=3Dfq_codel

For serious bench marking gett= ing results from an old system can make your results easily invalid since t= here has been a large number of improvements in Linux for bufferbloat every= where over the last three years, and the queue discipline is only part of t= he equation. =A0For example, many ethernet drivers in SOC's found in ho= me routers may still lack even BQL support.

You should be testing the fq_c= odel queue discipline: while Dave Taht has played with a number of variants= on that theme, nothing to date has shown itself (by testing) with enough b= etter results to be worth merging upstream into kernel.org. =A0Pie finally entered ker= nel.org Linux a month or so ago.

Note that there a large number= of "traps" for the unwary in this benchmarking/testing business,= into which multiple groups have come to bad ends causing questionable resu= lts to confuse everyone. For example, the details of the underlying device = driver can matter a lot (actually, hugely!), and netem has to be used with = exquisite care just to name a couple of the big traps.=A0

Fundamentally, you need to rea= lize that the queue discipline in Linux (where you can apply aqm) does *not= * have control of all of the buffering in the system; device drivers and ev= en the hardware itself can do "interesting" things to you. =A0And= a bunch of changes have taken place in the Linux TCP stack to remove unnee= ded buffering since around Linux 3.2. =A0At one point I think the list was = up to a dozen or more significant improvements =A0in the Linux networking s= tack, independent of fq_codel.

We've come to learn that W= iFi in particular needs a serious rewrite, and before venturing far, you= 9;d be wise to get in touch with us further. =A0ATM, the ath9k driver is le= ast problematic, but even there, aggregation causes large amounts of buffer= ing (32 packets!).

Dave Taht and I tried to outli= ne what you should be thinking about when bench marking in:

h= ttp://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarki= ng_Codel_and_FQ_Codel

Pretty = much all of these issues apply to anything you do, not just fq_codel.
=

I think that page overs most of the problems =A0though of course, Linux is = a moving target so I'm sure there will be future problems :-(.



Does anyone know where we could get the "official" version / sour= ce code of FQ_CoDel ?
(linux and/or NS2 if possible)

www.kernel.org for the source.

You can us= e git to see the exact revision history of the code.

I forget off hand where to find the simulation code... =A0There is a link s= omewhere in the bufferbloat/codel wiki

http://www.bufferbloat.= net/projects/codel/wiki/Wiki

H= elp from people to get the wiki up to date gratefully appreciated!

Jim
<= div class=3D"gmail_default">

=

Thanks a lot,

Kind regards,

Nicolas

_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

--089e015384d6a6169e04f1829525-- From dave.taht@gmail.com Mon Feb 3 12:52:08 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 028221A0225 for ; Mon, 3 Feb 2014 12:52:08 -0800 (PST) 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 ekR7J-K1FgPp for ; Mon, 3 Feb 2014 12:52:05 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB81A020C for ; Mon, 3 Feb 2014 12:52:04 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so12191450qcy.15 for ; Mon, 03 Feb 2014 12:52:04 -0800 (PST) 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=olQ80jv4cZq3xR/1e1mQLZHm+Q7UrCtZAnAormYp/lk=; b=tO9JSzLwTWn4uEAMdp13Drfnq7pwkhiGd4ftTdQO7y/PiXZVnaXwfAdqhqayhutEXI dnxA06xwg59H0OfxLVdqacEWcSw+MClRTyxE+v5NYzA0skGcItP379I7vt3f0YwrxrrZ 9an2wVZ30u9375ubLxwzhRNX/BRQjZip1XmF17+gQzaHVnybd0+syHb8gnei9h8dZKZM EPUOLjesPoD4frfmCPqJwS6a4lSbQroHCelTCRaJ/oFqjghTJEwrL5Svl/U4tFj0NZSa T/4Kn0GseYgN+8T7a+8HevUd2r8/qgzjf4fw1/IIk4jZysHpFJPtCBsQ+4YlthHHWdx9 R+Vw== MIME-Version: 1.0 X-Received: by 10.140.91.23 with SMTP id y23mr56903191qgd.3.1391460724687; Mon, 03 Feb 2014 12:52:04 -0800 (PST) Received: by 10.224.27.133 with HTTP; Mon, 3 Feb 2014 12:52:04 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 12:52:04 -0800 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat-ietf@lists.bufferbloat.net, Nicolas KUHN , "aqm@ietf.org" Subject: Re: [aqm] [FQ_CoDel] "Official" version 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: Mon, 03 Feb 2014 20:52:08 -0000 On Mon, Feb 3, 2014 at 7:57 AM, Jim Gettys wrote: > > > On Mon, Feb 3, 2014 at 9:30 AM, Nicolas KUHN > wrote: >> >> Dear all, >> >> We would like to test FQ_CoDel and we wonder which version to evaluate. > > > fq_codel has been in Linux since about Linux 3.5, IIRC. For casual > experiments, a current Linux distro will have it available at the invocat= ion > of the "tc" command. But... Improvements as of 3.12 is the ability to set a default qdisc across the entire system via a single sysctl.conf option. > You should generally be testing the latest Linux release (not that I thin= k > there has been much change in fq_codel, as demonstrated in: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id= =3Drefs%2Ftags%2Fv3.14-rc1&qt=3Dgrep&q=3Dfq_codel However there were some improvements to the jhash algorithm that landed in 3.8 and later to improve ipv6 hashing, and to more deeply inspect gre and 6in4 tunnels. > For serious bench marking getting results from an old system can make you= r > results easily invalid since there has been a large number of improvement= s > in Linux for bufferbloat everywhere over the last three years, and the qu= eue > discipline is only part of the equation. For example, many ethernet driv= ers > in SOC's found in home routers may still lack even BQL support. I note the sanest results are more consistently obtained using a SQM system like what's in cero, which leverages htb, thus moving control to htb and away from the drivers deeper in the stack. that said, htb also underwent improvements in 3.11 to make it faster, and there are some "dis-improvements" the current SQM system for cero that speed it up for the low powered hardware it's aimed at, above 20Mbit. Faster systems don't need those hacks... (and htb can be improved further, or replaced with hfsc.) > You should be testing the fq_codel queue discipline: while Dave Taht has > played with a number of variants on that theme, nothing to date has shown > itself (by testing) with enough better results to be worth merging upstre= am > into kernel.org. nfq_codel presently does mildly better at very low bandwidths (<2Mbit) as it is more sfq-like. Actually everything below 4Mbit is kind of finicy with everything (aqm, sfq, codel, fq_codel). I have been thinking of bringing back a patch from 3.5 in some form to make maxpacket handling saner at lower bandwidths (at a price in latency) > Pie finally entered kernel.org Linux a month or so ago. I have been backporting that as far back as 3.8. > > Note that there a large number of "traps" for the unwary in this > benchmarking/testing business, into which multiple groups have come to ba= d > ends causing questionable results to confuse everyone. For example, the > details of the underlying device driver can matter a lot (actually, > hugely!), and netem has to be used with exquisite care just to name a cou= ple > of the big traps. netem was hugely buggy prior to 3.11. I still only run it on a dedicated bo= x to insert delay and watch it carefully. > Fundamentally, you need to realize that the queue discipline in Linux (wh= ere > you can apply aqm) does *not* have control of all of the buffering in the > system; device drivers and even the hardware itself can do "interesting" > things to you. And a bunch of changes have taken place in the Linux TCP > stack to remove unneeded buffering since around Linux 3.2. At one point = I > think the list was up to a dozen or more significant improvements in the > Linux networking stack, independent of fq_codel. Yep. I look forward to hardware that can run this stuff directly. > We've come to learn that WiFi in particular needs a serious rewrite, and > before venturing far, you'd be wise to get in touch with us further. ATM= , > the ath9k driver is least problematic, but even there, aggregation causes > large amounts of buffering (32 packets!). > > Dave Taht and I tried to outline what you should be thinking about when > bench marking in: > > http://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchma= rking_Codel_and_FQ_Codel Don't be too scared... > Pretty much all of these issues apply to anything you do, not just fq_cod= el. > > I think that page overs most of the problems though of course, Linux is = a > moving target so I'm sure there will be future problems :-(. > > >> >> Does anyone know where we could get the "official" version / source code >> of FQ_CoDel ? >> (linux and/or NS2 if possible) > > > www.kernel.org for the source. patches and backports to older kernel versions are available as part of the kernel-backports package. (YMMV, as we note lots of other changes in the stack elsewhere matter quite a lot) > > You can use git to see the exact revision history of the code. > > I forget off hand where to find the simulation code... There is a link > somewhere in the bufferbloat/codel wiki > > http://www.bufferbloat.net/projects/codel/wiki/Wiki ns2 and ns3 versions of the patches have been rotting in a repo on github. Hope someone makes it a google summer of code project to get these mainline= d. > Help from people to get the wiki up to date gratefully appreciated! > > Jim > > >> >> Thanks a lot, >> >> Kind regards, >> >> Nicolas >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From rs@netapp.com Wed Feb 5 13:01:08 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 4DA8D1A0211 for ; Wed, 5 Feb 2014 13:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-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 7wcGwm4qCySa for ; Wed, 5 Feb 2014 13:01:06 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8F78A1A01FC for ; Wed, 5 Feb 2014 13:01:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,788,1384329600"; d="scan'208";a="100231174" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 05 Feb 2014 13:01:06 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 13:01:06 -0800 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: [aqm] WG status Thread-Index: AQHPDKpjfDc4O/iDH0qQCt7bybJXrpqnS6jA Date: Wed, 5 Feb 2014 21:01:04 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> References: <52CDAAF7.2060307@mti-systems.com> In-Reply-To: <52CDAAF7.2060307@mti-systems.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [aqm] WG status 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: Wed, 05 Feb 2014 21:01:08 -0000 Hi, a new month, a new status report. First of all, Wes and I as chairs would like to thank the editors who have = stepped forward to work on the AQM Evaluation Guideline draft. We are reall= y thankful for their burst of efforts in the last couple weeks! We expect that that a document will be ready for submission into the I-D re= pository well before cutoff, as an individual draft, so that the WG can see= what the state of thinking is currently. Also, once the document is publis= hed on datatracker we'd like to encourage active discussion on it. If the submitted -00 draft is felt to have a fairly complete outline of wha= t the current thinking in the WG is, we may be able to ask the WG for forma= l adoption during this IETF meeting, or shortly thereafter. =20 - WG Milestones: - Submit AQM recommendations to IESG for publication, obsoleting RFC 2309 (Goal: January 2014) - draft-ietf-aqm-recommendation is accepted towards this milestone - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ - the draft has been updated per comments received - if the authors are comfortable, a WGLC might be made on the next revision - we would like to hear from other authors of RFC 2309 on this document, if anyone has contacts to them. =20 - Submit AQM algorithm evaluation guidelines to IESG for publication as Informational (Goal: July 2014) - An editor team has come forth and is working on this - A draft should be available for discussion in the London IETF - We encourage discussion on the list and during the meeting, if this= =20 draft should be adopted by the working group. - Submit first algorithm specification to IESG for publication as Proposed Standard (Goal: December 2014) - Since any Proposed Standard algorithm should be in line with the recommendations and be passable versus the evaluation guidelines, this milestone is dependend on the progress of the two work items above. - Currently the only algorithm spec with a complete and active individual-submission draft is PIE =20 - Other items: - draft-pan-aqm-pie is under active work as a proposed algorithm: http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the draft has expired and should be refreshed. - draft-nichols-tsvwg-codel is expired; Dave Taht or others may revive i= t and/or describe pairing with FQ/SFQ algorithms: http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt - Other algorithm specifications are welcome! - Though, we are not planning on adopting algorithms until recommendations and evaluation guidelines are mostly stable Richard Scheffenegger From dave.taht@gmail.com Thu Feb 6 13:24:05 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 7F0C41A042A for ; Thu, 6 Feb 2014 13:24:05 -0800 (PST) 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 zzr0ZssTFjiC for ; Thu, 6 Feb 2014 13:24:03 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6D61A0427 for ; Thu, 6 Feb 2014 13:24:03 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id e16so4345554qcx.10 for ; Thu, 06 Feb 2014 13:24:01 -0800 (PST) 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=yqvVIp6uqzVRD1VXWi6atg0Jp0Pq5sQww7/g/1tE0ok=; b=K9BovjePhkg9qwcyoAYJ+gAZ71aoq+BmKxim9th2/q7N4kyEXIcjRwESDMKCCEZzhA 45/5/lPVMPFxpA3c4R3n0EK9vweau4z+dh467JgHdYABMuvTbuFsmD4bI6o3juvKLkLM aBSwQUoZQDP3SpWcEfIgxU3R+963EukKfnlm4UCMOQwMNj/dh3QzGh6ykUSKV9BhBJjj E9jIjsvSIHgXxGQ+YCMc+ZWWCurOCgLS6Yp/iRnmaRTQlmOpUy7sQjSysekBoMFAQsps plA3GhuwXcEQ5q+oJL0tW7vcRyDftA6WWbW7RwUSh96fJRUSl5aZtSMvMVNo4LbsHoX8 DiHA== MIME-Version: 1.0 X-Received: by 10.224.71.209 with SMTP id i17mr15607648qaj.29.1391721651705; Thu, 06 Feb 2014 13:20:51 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 6 Feb 2014 13:20:51 -0800 (PST) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 6 Feb 2014 16:20:51 -0500 Message-ID: From: Dave Taht To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "aqm@ietf.org" Subject: Re: [aqm] WG status 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, 06 Feb 2014 21:24:05 -0000 On Wed, Feb 5, 2014 at 4:01 PM, Scheffenegger, Richard wrot= e: > Hi, > > a new month, a new status report. > > First of all, Wes and I as chairs would like to thank the editors who hav= e stepped forward to work on the AQM Evaluation Guideline draft. We are rea= lly thankful for their burst of efforts in the last couple weeks! > > We expect that that a document will be ready for submission into the I-D = repository well before cutoff, as an individual draft, so that the WG can s= ee what the state of thinking is currently. Also, once the document is publ= ished on datatracker we'd like to encourage active discussion on it. > > If the submitted -00 draft is felt to have a fairly complete outline of w= hat the current thinking in the WG is, we may be able to ask the WG for for= mal adoption during this IETF meeting, or shortly thereafter. > > > > > - WG Milestones: > - Submit AQM recommendations to IESG for publication, obsoleting RFC > 2309 (Goal: January 2014) > - draft-ietf-aqm-recommendation is accepted towards this milestone > - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ > - the draft has been updated per comments received > - if the authors are comfortable, a WGLC might be made on the next > revision > - we would like to hear from other authors of RFC 2309 on this > document, if anyone has contacts to them. > > > - Submit AQM algorithm evaluation guidelines to IESG for publication a= s > Informational (Goal: July 2014) > - An editor team has come forth and is working on this > - A draft should be available for discussion in the London IETF > - We encourage discussion on the list and during the meeting, if thi= s > draft should be adopted by the working group. > > - Submit first algorithm specification to IESG for publication as > Proposed Standard (Goal: December 2014) > - Since any Proposed Standard algorithm should be in line with the > recommendations and be passable versus the evaluation guidelines, this > milestone is dependend on the progress of the two work items above. > - Currently the only algorithm spec with a complete and active > individual-submission draft is PIE > > - Other items: > - draft-pan-aqm-pie is under active work as a proposed algorithm: > http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the draft > has expired and should be refreshed. > - draft-nichols-tsvwg-codel is expired; Dave Taht or others may revive= it and/or > describe pairing with FQ/SFQ algorithms: > http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt > - Other algorithm specifications are welcome! > - Though, we are not planning on adopting algorithms until > recommendations and evaluation guidelines are mostly stable We are working on codel, fq_codel, and best current practices documents. Very, very, very drafty material is being kept in pandoc2rfc format in https://github.com/dtaht/bufferbloat-rfcs of these only the home_gateway_queue_management one is even halfway presentable, and it is anyone's guess as to whether we'll have any of these complete before ietf. More eyeballs and help would be nice to have. > > Richard Scheffenegger > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nicolas.kuhn@telecom-bretagne.eu Fri Feb 7 03:58:29 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 4B67B1A00ED for ; Fri, 7 Feb 2014 03:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 3MAGMjvM0OfX for ; Fri, 7 Feb 2014 03:58:27 -0800 (PST) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5D31A05FE for ; Fri, 7 Feb 2014 03:58:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 6B981B00CD; Fri, 7 Feb 2014 12:58:26 +0100 (CET) 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 10024) with ESMTP id nOWKhuS8uvhZ; Fri, 7 Feb 2014 12:58:25 +0100 (CET) Received: from dhcp-salsa-i-129-163.rennes.enst-bretagne.fr (dhcp-salsa-i-129-163.rennes.enst-bretagne.fr [10.35.129.163]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id BE266B00CB; Fri, 7 Feb 2014 12:58:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicolas KUHN In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 7 Feb 2014 12:58:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> To: Richard Scheffenegger X-Mailer: Apple Mail (2.1503) Cc: "aqm@ietf.org" Subject: [aqm] [AQM Evaluation Guidelines] 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, 07 Feb 2014 11:58:29 -0000 Dear all,=20 On the behalf of the contributors to the AQM Evaluation Guidelines, I = encourage active discussion on the draft that we have written.=20 I just submitted the draft as an individual draft to the I-D Submission = Tool [0]. Please let us know what you think of the current document.=20 Kind regards,=20 Nicolas KUHN [0] http://datatracker.ietf.org/doc/draft-kuhn-aqm-eval-guidelines/ On Feb 5, 2014, at 10:01 PM, "Scheffenegger, Richard" = wrote: > Hi, >=20 > a new month, a new status report. >=20 > First of all, Wes and I as chairs would like to thank the editors who = have stepped forward to work on the AQM Evaluation Guideline draft. We = are really thankful for their burst of efforts in the last couple weeks! >=20 > We expect that that a document will be ready for submission into the = I-D repository well before cutoff, as an individual draft, so that the = WG can see what the state of thinking is currently. Also, once the = document is published on datatracker we'd like to encourage active = discussion on it. >=20 > If the submitted -00 draft is felt to have a fairly complete outline = of what the current thinking in the WG is, we may be able to ask the WG = for formal adoption during this IETF meeting, or shortly thereafter. >=20 >=20 >=20 >=20 > - WG Milestones: > - Submit AQM recommendations to IESG for publication, obsoleting RFC > 2309 (Goal: January 2014) > - draft-ietf-aqm-recommendation is accepted towards this milestone > - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ > - the draft has been updated per comments received > - if the authors are comfortable, a WGLC might be made on the next > revision > - we would like to hear from other authors of RFC 2309 on this > document, if anyone has contacts to them. >=20 >=20 > - Submit AQM algorithm evaluation guidelines to IESG for publication = as > Informational (Goal: July 2014) > - An editor team has come forth and is working on this > - A draft should be available for discussion in the London IETF > - We encourage discussion on the list and during the meeting, if = this=20 > draft should be adopted by the working group. >=20 > - Submit first algorithm specification to IESG for publication as > Proposed Standard (Goal: December 2014) > - Since any Proposed Standard algorithm should be in line with the > recommendations and be passable versus the evaluation guidelines, this > milestone is dependend on the progress of the two work items above. > - Currently the only algorithm spec with a complete and active > individual-submission draft is PIE >=20 > - Other items: > - draft-pan-aqm-pie is under active work as a proposed algorithm: > http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the = draft > has expired and should be refreshed. > - draft-nichols-tsvwg-codel is expired; Dave Taht or others may = revive it and/or > describe pairing with FQ/SFQ algorithms: > http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt > - Other algorithm specifications are welcome! > - Though, we are not planning on adopting algorithms until > recommendations and evaluation guidelines are mostly stable >=20 >=20 > Richard Scheffenegger >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From rs@netapp.com Fri Feb 7 04:49:38 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 E1F1F1A03A8 for ; Fri, 7 Feb 2014 04:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-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 a5MNSQpSCy2w for ; Fri, 7 Feb 2014 04:49:36 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D7E881A0393 for ; Fri, 7 Feb 2014 04:49:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,800,1384329600"; d="scan'208";a="100629706" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 07 Feb 2014 04:49:37 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 04:47:24 -0800 From: "Scheffenegger, Richard" To: Nicolas KUHN Thread-Topic: [AQM Evaluation Guidelines] Thread-Index: AQHPI/v0w8+4TlXMnkOof2ZQu+1455qpvZQg Date: Fri, 7 Feb 2014 12:47:23 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F26039F3C@SACEXCMBX02-PRD.hq.netapp.com> References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> In-Reply-To: <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] [AQM Evaluation Guidelines] 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, 07 Feb 2014 12:49:39 -0000 Thank you Nicolas, and of course also all the other editors for preparing t= his document! We will dedicate a significant fraction of the meeting time in London on di= scussing this document, so I would like to encourage you all to review this= version! Best regards, Richard Scheffenegger > -----Original Message----- > From: Nicolas KUHN [mailto:nicolas.kuhn@telecom-bretagne.eu] > Sent: Freitag, 07. Februar 2014 12:58 > To: Scheffenegger, Richard > Cc: aqm@ietf.org > Subject: [AQM Evaluation Guidelines] >=20 > Dear all, >=20 > On the behalf of the contributors to the AQM Evaluation Guidelines, I > encourage active discussion on the draft that we have written. > I just submitted the draft as an individual draft to the I-D Submission > Tool [0]. >=20 > Please let us know what you think of the current document. >=20 > Kind regards, >=20 > Nicolas KUHN >=20 > [0] http://datatracker.ietf.org/doc/draft-kuhn-aqm-eval-guidelines/ >=20 >=20 > On Feb 5, 2014, at 10:01 PM, "Scheffenegger, Richard" > wrote: >=20 > > Hi, > > > > a new month, a new status report. > > > > First of all, Wes and I as chairs would like to thank the editors who > have stepped forward to work on the AQM Evaluation Guideline draft. We ar= e > really thankful for their burst of efforts in the last couple weeks! > > > > We expect that that a document will be ready for submission into the I-= D > repository well before cutoff, as an individual draft, so that the WG can > see what the state of thinking is currently. Also, once the document is > published on datatracker we'd like to encourage active discussion on it. > > > > If the submitted -00 draft is felt to have a fairly complete outline of > what the current thinking in the WG is, we may be able to ask the WG for > formal adoption during this IETF meeting, or shortly thereafter. > > > > > > > > > > - WG Milestones: > > - Submit AQM recommendations to IESG for publication, obsoleting RFC > > 2309 (Goal: January 2014) > > - draft-ietf-aqm-recommendation is accepted towards this milestone > > - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ > > - the draft has been updated per comments received > > - if the authors are comfortable, a WGLC might be made on the next > > revision > > - we would like to hear from other authors of RFC 2309 on this > > document, if anyone has contacts to them. > > > > > > - Submit AQM algorithm evaluation guidelines to IESG for publication > > as Informational (Goal: July 2014) > > - An editor team has come forth and is working on this > > - A draft should be available for discussion in the London IETF > > - We encourage discussion on the list and during the meeting, if > this > > draft should be adopted by the working group. > > > > - Submit first algorithm specification to IESG for publication as > > Proposed Standard (Goal: December 2014) > > - Since any Proposed Standard algorithm should be in line with the > > recommendations and be passable versus the evaluation guidelines, this > > milestone is dependend on the progress of the two work items above. > > - Currently the only algorithm spec with a complete and active > > individual-submission draft is PIE > > > > - Other items: > > - draft-pan-aqm-pie is under active work as a proposed algorithm: > > http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the draf= t > > has expired and should be refreshed. > > - draft-nichols-tsvwg-codel is expired; Dave Taht or others may > > revive it and/or describe pairing with FQ/SFQ algorithms: > > http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt > > - Other algorithm specifications are welcome! > > - Though, we are not planning on adopting algorithms until > > recommendations and evaluation guidelines are mostly stable > > > > > > Richard Scheffenegger > > > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm From toke@toke.dk Fri Feb 7 09:58: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 446131A0176 for ; Fri, 7 Feb 2014 09:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 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, MIME_HEADER_CTYPE_ONLY=0.717] 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 xPjvMBrHHUl7 for ; Fri, 7 Feb 2014 09:58:48 -0800 (PST) Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) by ietfa.amsl.com (Postfix) with ESMTP id B446F1A0128 for ; Fri, 7 Feb 2014 09:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-kau.localdomain (Postfix, from userid 1000) id 1295248064; Fri, 7 Feb 2014 18:58:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1391795919; bh=CBwiD3Z8S9iVzg2iJh9z4+Wda5JfyfXBOLeaBM+F9wo=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=qxprLWP8vUTaLAJbu+bZ/KGQjtF2hstZjF8lqhXpJL6gO6HCipoWZIbWyjQnPC/sH z4dJCck1rOGYL3V8SgUtroJaUvP0ck94Bi9v6RAwtx5u5M5guo2C5B0dnsGHEbya6W bW69o3FngEJTCTemxHtgwbP1JynyIQEYVqoBSGCw= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Nicolas KUHN References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> Date: Fri, 07 Feb 2014 18:58:35 +0100 In-Reply-To: <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> (Nicolas KUHN's message of "Fri, 7 Feb 2014 12:58:25 +0100") Message-ID: <87vbwqiz3o.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: Richard Scheffenegger , "aqm@ietf.org" Subject: Re: [aqm] [AQM Evaluation Guidelines] 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, 07 Feb 2014 17:58:49 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Nicolas KUHN writes: > Please let us know what you think of the current document. Hi Nicolas and others Thank you for the draft; here are some comments, mostly of a more general nature (as opposed to concrete proposals for rewording). 1. TESTING METHODOLOGY AND REPRODUCIBILITY I think it is important to encourage good testing methodology in a document like this; and from the current draft the actual proposed testing method is not clear. I realise it is also important to leave some room for people to do things in the way that suits their work-flow, however I believe some minimum standards for methodology would be appropriate. Reproducibility is a part of this that is especially important, but other areas that spring to mind are: =2D A sufficiently detailed description of the test setup to allow others to replicate it. Including software and hardware versions etc. =2D Availability of the data used for analysis to allow others to check the conclusions drawn. Requiring a reference implementation to be available could also be relevant to this general point; I would think it would be a reasonable requirement to have. 2. COMPETING VS LOAD-INDUCING TRAFFIC CHARACTERISTICS=20 Distinguishing between the effect an AQM has on the traffic that induces the congestion and traffic that competes with it is worthwhile, in my opinion. For some applications (e.g. background transfers), maximising goodput for the "offending" stream is less important than ensuring that other traffic is not experiencing added latency because of it, while for others (e.g. an adaptive video conference stream), the latency of the "offending" stream can be vital. Having this distinction in the measurements (by measuring both) makes it possible to evaluate this aspect of the AQM behaviour. 3. SOME COMMENTS ON THE SCENARIOS I have various comments on the proposed testing scenarios: =2D 10 Mbps is a fairly high bandwidth compared to the average connection to the internet. I believe it would be worthwhile to include lower bandwidth(s) in the "general" scenarios, and not just in the "optional" ones. =2D I don't believe the scenario dubbed "Wi-Fi" is a realistic representation of the behaviour of a wifi link. A comprehensive wifi test would include the presence of multiple hosts, bandwidth varying on very short time scales, and packet aggregation behaviour. I would suggest keeping the existing scenario, but calling it something else, and then adding a more comprehensive wifi scenario (which would probably need some hashing out). =2D I'm missing measurements of the behaviour of real-world traffic such as DNS lookups, HTTP requests, etc. Indeed, having bidirectional traffic included would be good. 4. SCHEDULING vs AQM In the first section(s) mention AQM and scheduling as though they are interchangeable, while a later section mentions AQM interaction with scheduling mechanisms. I believe it is worthwhile to both (a) distinguish clearly between what is mean by AQM resp scheduling, but also (b) make the recommendations apply equally to a "pure" AQM algorithm and to a combination scheme that includes both an AQM and a scheduler (which may or may not be intricately linked in their operation). 5. STABILITY ANALYSIS While I agree that it is important for an algorithm proposal to argue plausibly for its stability, I think it is wrong to *require* that argument to be made in the form of a control theoretic analysis. Such a requirement limits possible algorithms to those that can be described using that particular paradigm (loosely, things expressible and solvable by differential equations). For instance, the fluid dynamic TCP model commonly used for control theory stability analysis, discards a lot of the dynamics of TCP, most notably slow start and other transient behaviour, and focuses on the steady state. Since it is by no means clear that this is the only way to make the argument (and indeed focusing too much on the steady state can be counter-productive), I would suggest to at least reword the section to mention control theory as *a* way to make the argument, rather than the *only* way. Sorry if this got a bit long; I started with a much shorter list of notes, I swear! :) =2DToke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJS9R7LAAoJEENeEGz1+utPGbMH/j0j2u8X7zJqVzcbvMta4wdg FXq5YRhq1pzX/8q7hJuszBnOx5yaf/w6MeA35Rq/LSttvRuXJfhwJ6Hi+7/L68hN UsxyxnrCdLDbtfMDLmHcRn/lNECk5ROSD1vsBAyyU47ROLAfE+9odp6nG97pJWsT 5Zq4CSYVOcWNcbk8wxSPNSmasggf1eKLqrg25BbbZ+FX06cI2fxf4VKK73aDwLtN OhKcuUkRZwR4vSvPBC1oYFUWbhDFSVxih4ppvx0leUAuXDhtbQjvKO87RqRYLcZs VsVLSgLqarppzmhVCzPQNwzs9nRk4vQ2Fn6/pK/Mxt/9hJgQHgWgAFLrVmd7jcw= =a53E -----END PGP SIGNATURE----- --=-=-=-- From dave.taht@gmail.com Sun Feb 9 18:35:00 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 189F81A05D9 for ; Sun, 9 Feb 2014 18:35:00 -0800 (PST) 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 zUG6QT4FG5VE for ; Sun, 9 Feb 2014 18:34:55 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB911A0591 for ; Sun, 9 Feb 2014 18:34:55 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id n7so9651505qcx.2 for ; Sun, 09 Feb 2014 18:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=m+X5vaERsOSsof5KP+CFYQbi1a69LX30R4Xadc7+7SU=; b=Wk2ir/gnDFo5z6/Rf+FN3RlapSIJGOP668qpvZ9+xXmDAXANlfQUYGCy47eDQWFG9a qegWcI2bHwWaVLBMSEVPSDCt8vwGb35hnc7URnXf90hJjQ07tD7B383v6tDYqNAhvtZ7 rtPdWxGifY7Zal9WHnqjtPdats5pRRvPlDFnzLc8S0T+YxuqmGQVJe8Gyt3bmf08i4bd 6IOSXfzmJE9kOTDbTzMaW0NY/WkSnASJf80F/UAKLD32z+XjSsySw1t1gRtZLDB+2SB9 97SKpCJ6dJb8TvioW10cmQ8Esl7sg/nlf54AqkK7++Wu6a9WT6yFbRMrm8vmklxCCCoK RfEw== MIME-Version: 1.0 X-Received: by 10.224.28.197 with SMTP id n5mr43914408qac.43.1391999695288; Sun, 09 Feb 2014 18:34:55 -0800 (PST) Received: by 10.224.27.133 with HTTP; Sun, 9 Feb 2014 18:34:55 -0800 (PST) Date: Sun, 9 Feb 2014 18:34:55 -0800 Message-ID: From: Dave Taht To: "aqm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [aqm] some comments I'd made on the cablelabs study privately 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: Mon, 10 Feb 2014 02:35:00 -0000 Since that study and test design were highly influential on the AQM requirements draft, I am going to publish now here what my comments were at the time, with a couple updates here and there.... I am not sure if any of the ns2 code from the last round made it out to the public. ? * Executive summary The Cablelabs AQM paper was the best simulation study of the effects of the new bufferbloat-fighting AQMs verses the common Internet traffic types in the home that has been created to date... However, it is only a study of half the edge network. It assumes throughout that there are no excessive latencies to be had from the CMTS side. Field measurements show latencies in excess of 1.8 seconds from the CMTS side. 300ms on Verizon gpon. Buffer sizes in the range of 64k to 512k on DSL in general, with some RED, SFQ, and SQF actually deployed there. So... while the focus has been on what is perceived as the larger problem, the cable modems themselves, downstream behavior was not studied and the entire simulation set to "reasonable" values for ns2 modelers... and not seen in the real world. In the real world (RW) Flows are almost always bidirectional. What happens on the downstream side affects the upstream side and vice versa, as per Van Jacobson's "fountain" analogy. Correctly compensating for bidirectional TCP dynamics is incredibly important. The second largest problem with original cablelabs study is that it only analyzed traffic at one specific (although common) setting for cable operators, 20Mbits down, and 5 Mbits up. A common, lower setting should be analyzed, as well as more premier services. Some tweaking of codel derived technologies (flows and quantum), and of pie (alpha and beta) are indicated both at lower and higher bandwidths for optimum results. Additionally the effects of classification, notably of background traffic, has not been explored. There are numerous other difficulties in the simulations and models that need to be understood in order to make good decisions moving forward. This document goes into more detail on those later. All the AQMs tested performed vastly better than standard FIFO drop tail as well as buffercontrol. They all require minimal configuration to work. With some configuration they can be made to work better. * Recomendations I'd made at the time ** Study be repeated using at least two more bandwidth settings ** More exact emulation of current CMTS behavior Based on real world measurements ** Addition of more traffic types, notably VPN and Videoconferencing ** Improvements to the VOIP, web models ** Continued attempts at getting real world and simulated benchmarks to "line up". My approach has been to follow the simulation work and try to devise real world benchmarks that are similar, and feed back the results into the ongoing simulation process. There are multiple limitations in this method, too, notably getting repeatable results, and doing large scale tests on customer equipment, both of which are subject to heisenbugs. * Issues in the cablelabs study ** Downstream behavior Tests with actual cablemodems in actual configurations shows a significant amount of buffering on the downstream. At 20Mbits, DS buffering well in excess of 1 second has been observed. The effect of excessive buffering on this side has not been explored in these tests. Certain behaviors - TCP's "burstiness" as it opens it's window to account for what it is thinking as a long path - reflect interestingly on congestion avoidance, on the downstream, and the effects on the upstream side of the pair are interesting too. I note that my own RW statistics were often very skewed by some very bad ack behavior on TSO offloads that has been a bug in Linux for years and recently fixed. ** Web model *** The web model does not emulate DNS lookups. Caching DNS forwarders are typically located on a gateway box (not sure about cablemodems ??), and the ISP locates a full DNS server nearby, (within 10ms RTT). DNS traffic is particularly sensitive to delay, loss and head of line blocking, and slowed DNS traffic stalls subsequent tcp connections on sharded web traffic in particular. *** The web model does no caching A fairly large percentage (not high enough) of websites make use of various forms of caching, ranging from marking whole objects as cachable for a certain amount of time, or using the etags method to provide checksum-like value for an if-modified get request. Use of the former method eliminates a RTT entirely, the latter works inside of a http 1.1 pipeline well. *** The web model does not use https Establishing a secure http connection requires additional round trips. *** The web model doesn't emulate tons of tabs Web users, already highly interactive, now tend to have tons of tabs, all on individual web sites, many of which are doing some sort of polling or interaction in the background against the remote web server. These benchmarks do not emulate this highly common behavior. ** TCP Cubic in ns2 is not the same as modern TCP cubic in Linux Showing that these new AQMs work correctly with modern TCPs is essential. ** VOIP model The VOIP model measures *one-way* egress delays only, and does not track the burstiness of packet loss, or the burstiness of jitter. It uses an archaic codec emulation, as well. Something like opus should be looked at. ** The gaming model Treats gaming as equivalent to VOIP, with the same problems as the VOIP model. Gaming traffic is bidirectional, even more so than voip. Additionally, some of the traces I have access to use a 15ms, rather than 20ms period, to emitted packets. (I have collected a vast amount of gaming traffic data that I have not yet had time to analyze) ** Videoconferencing was not stuidied. ** Bittorrent model The torrent model is flawed in multiple ways. Notably it only tests phase III of the typical torrent cycle, not the download or down/up phases... **** The download saturation problem Torrent can and WILL saturate a downlink and not respond to congestion indicators until over 100ms of delay is observed. Most clients do have a ratelimit set for download. It is often turned off after-hours. **** The upload saturation problem shown in the study Bittorrent clients have evolved to where, out of the box, there is a very low rate limit set, typically in the range of 50-150KBytes/sec. This makes bittorrent uploads a non-problem for most people. Still, benchmarking each of these phases would be worthwhile. Torrent can be fixed. *** LEDBAT !=3D Bittorrent LEDBAT as defined and uTP as deployed remain significantly different. No implementation of bittorrent I've looked at (utorrent and transmission) behaves anything like the LEDBAT modules I have. *** TCP-LEDBAT kernel module is buggy In my RW tests this Linux congestion control module never gets out of SSTHRESH and into congestion avoidance. The behavior LOOKs like bittorrent (look! It's scavaging), when in reality, it's merely stuck at a low rate. However, it is possible this module works correctly under older linuxes under ns2. The RW behavior of bittorrent under RED and SFQ was explored in [[YIXI2012]] and under those two AQM systems, formerly scavaging flows are reprioritized to have roughly the same weight as non-scavaging flows until 100ms of delay is incurred. The simulated LEDBAT results do show that extraordinarily high numbers of persistent high rate flows interact badly with fq_codel, at this 20/4 bandwidth setting. Using another TCP that is not buggy will probably be even worse. However, bittorrent is a very special case. Dozens of full rate flows are extremely rare in the real world. (RW benchmarks show even fairly large numbers of flows (50+) show fq_codel still doing quite well) ** IP address Hashing ns2 does not have support for a full 5 tuple including the protocol (e.g. TCP, UDP, ARP, etc). This makes hashing multiple protocols together problematic and I'm unsure if this was compensated for correctly in all the models. ** Fq_codel and PIE configuration with 10ms target While I buy into (kathie doesn't) the idea that the delay target variable needs to be greater than the cable MAC media acquisition time (in this model), it does not need to be set to 10ms. 6.X should be sufficient to avoid MAC acquisition artifacts. There is a quadratic response time to delay in TCP, so the doubling of the default target to aim for of 5ms to 10ms results in much fuller queues. (Lest I be mis-interpreted, the quadratic behavior is end to end and I honestly don't know what differences we'd see between a 6.5ms target and a 10ms target) PIE has similar constraints, (but apparently ran fine on the cable MAC) so a target delay of 6.X or 7 being tried for both would be interesting. **I note that (2014) pie has now grown a target of 20ms in the Linux implementation, and a closer tie with the htb rate shaper in the as-yet-unpublished cablelabs model. ** At very, very low bandwidths (<4mbit) we have found it desireable to increase the fq_codel target to account for a single MTU at that bandwidth. The fq_codel interval estimation window in the cablelabs testing was set to 150ms, rather than the default 100ms. I note that most experimental variants of codel fiddle with the "drop resumption" portion of the algorithm which is very sensitive to the interval. It's an area of research... The estimation window in pie has grown to 10k bytes. * rate limiters have a cost. At higher rates, more fq_codel queues are of use, and the RW tests point to the rate limiter being the principal CPU hog and source of problems, the drop/mark/scheduler algorithm hardly enter into it. The PIE codel and fq_codel algorithms barely show upon a trace.... ** Back to back packet drop Gaming and VOIP traffic tolerate single, random packet drop with aplomb. It's bursty packet loss and sudden delays that cause audible artifacts, and gaming misbehavior. You can hear 3 packets lost in a row, (which is no different from a sudden delay of 60ms on a stream) So in addition to the packet loss figure, a good measurement would be a bursty packet loss, and a bursty delay graph. Hopefully in the aqm cases it follows a random distribution, but... (Similarly many tcps respond to bursty packet loss in a drastic fashion, but do not react too much to bursty delay) Another problem with VOIP is "creeping delay", where a voip queue builds and builds and then delivers or drops a full boatload of packets to catch up. I have experienced this on multiple wifi based voip sessions where I ended up with seconds of delay on the line over time... ** ns2 issues Many of the problems in this test series are due to using an obsolete and undermaintained network model system (ns2). Alternatives exist that are better (ns3, minitel, etc) in multiple aspects. While ns2 can certainly be improved the cost/benefit ratio of using ns3 seems better. (There is no harm in using other technologies as a cross-check too.) *** Ns2 doesn't support many modern networking features, like ECN. *** ns2 doesn't have TOS values (so it can't do diffserv) *** ns2 doesn't have port numbers fq_codel uses a 5 tuple of port, protocol, src and destination ips * Statistical notes Analyzing network queue, and network traffic behavior does not lend itself to many means of statistical analysis. In particular, throwing out the upper or lower percentiles of most results is a bad practice - with real time systems, it's the outliers that are interesting and important. This paper uses CDF plots throughout, which is a fine way to measure the full range of results, however the use of a log scale is difficult on the unpracticed eye. In it's summary form, the paper uses a method of averaging together the results of each separate subtest, and the weighting is unclear. This in particular gives the bittorrent result a lot more weight than one would expect. NOTE: RW =3D real world * Overall recommendations... ** Continue developing better models! ** Find a cable vendor willing to do the exploratory work It took me 24 hours to port the code from ns2 to Linux. Analysis of several other operating systems indicate that a week in conjunction with a local expert would be enough to make this code work on most other network OSes. ** Better models of media acquisition, (cable, wifi, lte), aggregation, or scheduling characteristics (wifi, lte, token ring) dissimilar to ethernet. * Nits ** fq_pie Given the probalistic dropping technique in PIE, it too can benefit from flow queuing, fair queueing or weighted fair queuing tecniques inserted before it in the chain, with only one PIE queue needed to do so. (This is unlike fq_codel, which due to the isochronous nature of the timestamping has to have one codel queue per fq in order to work, presently) The prospect of fq + pie seems quite promising. * Packet Trains * Next steps in the RW cerowrt tests ** pie and fq_pie improvements Cerowrt gained pie support back in august or so and has tracked revisions 1-4. Codel has had some tiny tweaks as well. ** Several new codel and fq_codel models based on the cablelabs testing, it is evident that number of queues could be dependent on the available bandwidth, which can be made automatic, there are also a few tweaks that can be made to pie and codel (ecn handling, notably) Also it seems possible to improve fq_codel's behavior by adopting slightly different strategies for nearly empty queues, under load. Like (original) PIE, favoring dropping big packets more, particularly when a queue is at 1 and the system is experiencing large delays, seems plausible to handle the bittorrent problem while not affecting most other traffic types. ** classification Under test are several shapers that use limited amounts of classification. In the RW, in the campground test site, Over 52% of all packets are marked CS1 on egress. Applications are obviously trying to deprioritize themselves, it seems logical to try to support that. * Side notes It should be clear that these AQMs and packet schedulers can apply not only to edge networks, but anywhere there is a fast to slow transition on a network. This includes within a machine itself! It may well be easier to apply these technogies to load balancers, high end Linux based routers, and vm root hardware, piecemeal, far faster than they can be deployed en-mass across the customer edge network. Linux based servers can also benefit, today. Deploying these AQM technologies on any scale will help gain needed operational experience with them before they have to be burned into hard to update edge customer network hardware. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From swmike@swm.pp.se Sun Feb 9 22:14:05 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 8D1D91A07B0 for ; Sun, 9 Feb 2014 22:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 XNu8azyKb1oX for ; Sun, 9 Feb 2014 22:14:02 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id B89851A0699 for ; Sun, 9 Feb 2014 22:14:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CF8CD9C; Mon, 10 Feb 2014 07:13:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C43819A; Mon, 10 Feb 2014 07:13:59 +0100 (CET) Date: Mon, 10 Feb 2014 07:13:59 +0100 (CET) From: Mikael Abrahamsson To: Dave Taht In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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: Mon, 10 Feb 2014 06:14:05 -0000 On Sun, 9 Feb 2014, Dave Taht wrote: > The second largest problem with original cablelabs study is that it > only analyzed traffic at one specific (although common) setting for > cable operators, 20Mbits down, and 5 Mbits up. A common, lower setting > should be analyzed, as well as more premier services. Some tweaking of > codel derived technologies (flows and quantum), and of pie (alpha and > beta) are indicated both at lower and higher bandwidths for optimum > results. Additionally the effects of classification, notably of > background traffic, has not been explored. Just as a data point, currently Comhem in Sweden offers a DOCSIS based cable-Internet service of up to 500/50 (500 down, 50 up). What would be of great interest would be to test this kind of service in several modes, including having 10 of those on the same CMTS port and congesting both up and downstream of the cable system itself (because there isn't 500 megabit/s total upstream capacity to support 10 subscribers all trying to use 50 megabit/s per user. Same thing downstream. Would be very interesting to see how these users interacted with each other combined with LEDBAT and having TCP flows that didn't incur too much latency for the individual user, whilst assuring that each subscribed line got its fair share of bandwidth from the system. > **** The upload saturation problem shown in the study > > Bittorrent clients have evolved to where, out of the box, there is > a very low rate limit set, typically in the range of 50-150KBytes/sec. > This makes bittorrent uploads a non-problem for most people. > > Still, benchmarking each of these phases would be worthwhile. > Torrent can be fixed. Well, users still would like to set the upload rate to something close to what they have purchased, and still have it yield to other traffic that happens to need the upstream bw, so further study would be great. > Another problem with VOIP is "creeping delay", where a voip queue builds > and builds and then delivers or drops a full boatload of packets to > catch up. I have experienced this on multiple wifi based voip sessions > where I ended up with seconds of delay on the line over time... This was a big problem 5+ years ago, where I think the PDV (jitter) buffer just grew, and never shrunk again even if network conditions improved. I haven't experienced this lately, so for instance Skype must have fixed this. -- Mikael Abrahamsson email: swmike@swm.pp.se From g.white@CableLabs.com Mon Feb 10 11:47:57 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 C406A1A0884 for ; Mon, 10 Feb 2014 11:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548] 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 YG6Cdxes1Iyz for ; Mon, 10 Feb 2014 11:47:55 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9321A0879 for ; Mon, 10 Feb 2014 11:47:55 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s1AJlpaH022869; Mon, 10 Feb 2014 12:47:52 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 10 Feb 2014 12:47:51 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 12:47:51 -0700 From: Greg White To: Mikael Abrahamsson , Dave Taht Thread-Topic: [aqm] some comments I'd made on the cablelabs study privately Thread-Index: AQHPJgi0fL9DpXCbg0ORb6qUDdr545qud9mAgABuCYA= Date: Mon, 10 Feb 2014 19:47:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.4.10.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <56A41E3A5779BC4C93F46DE5C724E481@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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: Mon, 10 Feb 2014 19:47:58 -0000 Dave,=20 Thanks for posting the helpful critique, and I hope that it helps shape the eval-guidelines draft. I think simulations are always a "work-in-progress" of sorts - there is always something you can do better next time. By their nature, simulations are simplifications of reality, and one of the challenges is to spend time developing fidelity where it is needed and not where it is not (we've tried to be very conscious of that, but it is always good to get another set of eyes on the problem), another is to try to avoid letting the combinatorics get out of hand. And, you are right that simulations can have bugs (but as you've noted, so does the RW). Some of the items in your list we've already addressed since publishing that white paper last spring, some we may address in future work, and some we may need to agree to disagree on the importance of. Also, we are in the process of getting a bunch of our tools made public (in ns-2.36) so that the research community can potentially tackle some areas that we're not able to get to. Once we have real systems to experiment with, we'll be doing some RW experiments too (both to validate implementations, and to validate the approach). I hope we can leverage some of the work you've been doing in your testbed (e.g. RRUL) when we get to that point. I responded to a couple of Mikael's points below. -Greg On 2/9/14, 11:13 PM, "Mikael Abrahamsson" wrote: >On Sun, 9 Feb 2014, Dave Taht wrote: > >> The second largest problem with original cablelabs study is that it >> only analyzed traffic at one specific (although common) setting for >> cable operators, 20Mbits down, and 5 Mbits up. A common, lower setting >> should be analyzed, as well as more premier services. Some tweaking of >> codel derived technologies (flows and quantum), and of pie (alpha and >> beta) are indicated both at lower and higher bandwidths for optimum >> results. Additionally the effects of classification, notably of >> background traffic, has not been explored. > >Just as a data point, currently Comhem in Sweden offers a DOCSIS based >cable-Internet service of up to 500/50 (500 down, 50 up). > >What would be of great interest would be to test this kind of service in >several modes, including having 10 of those on the same CMTS port and >congesting both up and downstream of the cable system itself (because >there isn't 500 megabit/s total upstream capacity to support 10 >subscribers all trying to use 50 megabit/s per user. Same thing >downstream. Would be very interesting to see how these users interacted >with each other combined with LEDBAT and having TCP flows that didn't >incur too much latency for the individual user, whilst assuring that each >subscribed line got its fair share of bandwidth from the system. In our recent simulation work (unpublished), we've been using the following configurations: 20/5 (the original cfg), 100/20, 1000/200. One finding for us was that the fq benefits diminished considerably as the data rates went up. Also, we model shared link congestion by modulating the capacity available to our tested user. This was described in our April 2013 paper. Since one user's queuing latency doesn't impact another user, the interaction between users is largely limited to how much capacity is available to our tested user at any point in time. Our model was, admittedly, a simple one, but I'm not aware of any better models at the moment. We did collect data on some real systems to validate the model, but had difficulty finding a real system that exhibited significant congestion (I'm sure several hands will go up to volunteer their own broadband connection as being the poster child for this ;-). > >> **** The upload saturation problem shown in the study >> >> Bittorrent clients have evolved to where, out of the box, there is >> a very low rate limit set, typically in the range of 50-150KBytes/sec. >> This makes bittorrent uploads a non-problem for most people. >> >> Still, benchmarking each of these phases would be worthwhile. >> Torrent can be fixed. > >Well, users still would like to set the upload rate to something close to >what they have purchased, and still have it yield to other traffic that >happens to need the upstream bw, so further study would be great. > >> Another problem with VOIP is "creeping delay", where a voip queue >>builds=20 >> and builds and then delivers or drops a full boatload of packets to >> catch up. I have experienced this on multiple wifi based voip sessions >> where I ended up with seconds of delay on the line over time... > >This was a big problem 5+ years ago, where I think the PDV (jitter) >buffer=20 >just grew, and never shrunk again even if network conditions improved. I >haven't experienced this lately, so for instance Skype must have fixed >this. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm From swmike@swm.pp.se Tue Feb 11 00:43: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 F3EE61A0906 for ; Tue, 11 Feb 2014 00:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, 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 Kqs-nhGj3DUb for ; Tue, 11 Feb 2014 00:43:50 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id AEA3A1A090F for ; Tue, 11 Feb 2014 00:43:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 07E3B9C; Tue, 11 Feb 2014 09:43:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 03DD59A; Tue, 11 Feb 2014 09:43:46 +0100 (CET) Date: Tue, 11 Feb 2014 09:43:45 +0100 (CET) From: Mikael Abrahamsson To: Greg White In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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, 11 Feb 2014 08:43:53 -0000 On Mon, 10 Feb 2014, Greg White wrote: > Also, we model shared link congestion by modulating the capacity > available to our tested user. This was described in our April 2013 > paper. Since one user's queuing latency doesn't impact another user, the > interaction between users is largely limited to how much capacity is > available to our tested user at any point in time. Our model was, Could you please elaborate on this. If we're 10 users all using our 50 megs up, now 5 of them stop sending, since now the upstream system capacity per actually sending user has doubled, how can the queueing delay not be affected? What happens when those 5 that now went silent started sending again? What I'm after is to measure the system as a whole, the CPE queueing algorithm together with the cable "system" interaction and how this would interact with TCP streams. The same use-case would be valid for PON. -- Mikael Abrahamsson email: swmike@swm.pp.se From g.white@CableLabs.com Tue Feb 11 08:18:01 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 4C7911A0620 for ; Tue, 11 Feb 2014 08:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548] 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 765Lc1KF4Zdk for ; Tue, 11 Feb 2014 08:17:59 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 799051A061A for ; Tue, 11 Feb 2014 08:17:58 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s1BGHuSW024055; Tue, 11 Feb 2014 09:17:56 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 11 Feb 2014 09:17:56 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 09:17:56 -0700 From: Greg White To: Mikael Abrahamsson Thread-Topic: [aqm] some comments I'd made on the cablelabs study privately Thread-Index: AQHPJgi0fL9DpXCbg0ORb6qUDdr545qud9mAgABuCYCAAU4kgIAACYqA Date: Tue, 11 Feb 2014 16:17:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.4.10.154] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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, 11 Feb 2014 16:18:01 -0000 On 2/11/14, 1:43 AM, "Mikael Abrahamsson" wrote: >On Mon, 10 Feb 2014, Greg White wrote: > >> Also, we model shared link congestion by modulating the capacity >> available to our tested user. This was described in our April 2013 >> paper. Since one user's queuing latency doesn't impact another user, >>the=20 >> interaction between users is largely limited to how much capacity is >> available to our tested user at any point in time. Our model was, > >Could you please elaborate on this. If we're 10 users all using our 50 >megs up, now 5 of them stop sending, since now the upstream system >capacity per actually sending user has doubled, how can the queueing >delay=20 >not be affected? What happens when those 5 that now went silent started >sending again? It is just as you think it is. When 10 users are placing equal, saturating load on the link, they will each get (on average) 10% of the link rate. When there are 5 users, they will each get (on average) 20% of the link rate. This is enforced by the CMTS. So when the active users undergoes a step change from 10 to 5, each of the 5 remaining active users will see a doubling of their link rate. The reverse will happen when the active users returns to 10. Step changes in link rate will result in step changes in queuing latency. This we model. What I was getting at is that the above is true for user #1 regardless of what applications and what AQM user #2 is using. So we don't need to simulate user #2 (it is sufficient to model him) if we're interested in user #1's performance. -Greg > >What I'm after is to measure the system as a whole, the CPE queueing >algorithm together with the cable "system" interaction and how this would >interact with TCP streams. > >The same use-case would be valid for PON. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Feb 12 00:15:26 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 89B9D1A08B3 for ; Wed, 12 Feb 2014 00:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, 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 ymL0LJ-oFIXv for ; Wed, 12 Feb 2014 00:15:24 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 30E241A0886 for ; Wed, 12 Feb 2014 00:15:23 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 926309C; Wed, 12 Feb 2014 09:15:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8AB339A; Wed, 12 Feb 2014 09:15:21 +0100 (CET) Date: Wed, 12 Feb 2014 09:15:21 +0100 (CET) From: Mikael Abrahamsson To: Greg White In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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: Wed, 12 Feb 2014 08:15:26 -0000 On Tue, 11 Feb 2014, Greg White wrote: > What I was getting at is that the above is true for user #1 regardless > of what applications and what AQM user #2 is using. So we don't need to > simulate user #2 (it is sufficient to model him) if we're interested in > user #1's performance. Are you sure? If AQM user #2 has 500 ms worth of packets in his upstream buffer (FIFO) vs 10 ms worth of packets with FQ_CODEL, wouldn't that make him adapt faster to increased upstream capacity? If nothing else, he has plenty of packets buffered that can be emptied out, whereas with FQ_CODEL you do not have this huge standing buffer with packets ready to send? -- Mikael Abrahamsson email: swmike@swm.pp.se From g.white@CableLabs.com Wed Feb 12 11:36:01 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 32E771A062C for ; Wed, 12 Feb 2014 11:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548] 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 h7HCYrXRh_K6 for ; Wed, 12 Feb 2014 11:35:59 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BB6651A06B7 for ; Wed, 12 Feb 2014 11:35:13 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s1CJZCsW011599; Wed, 12 Feb 2014 12:35:12 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 12 Feb 2014 12:35:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 12:35:11 -0700 From: Greg White To: Mikael Abrahamsson Thread-Topic: [aqm] some comments I'd made on the cablelabs study privately Thread-Index: AQHPJgi0fL9DpXCbg0ORb6qUDdr545qud9mAgABuCYCAAU4kgIAACYqAgAGA3ICAAEiXAA== Date: Wed, 12 Feb 2014 19:35:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.4.10.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D5E126EE4E08E40B96AEEAD8857C458@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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: Wed, 12 Feb 2014 19:36:01 -0000 What you've said is true, and we will see the first order effect of that in our model. At that rate increase transition, user 1 will have ~20% of the link rate *available* to him. If he cannot capitalize on it because he has a small queue, then that capacity can be used by user 2 (who has a large queue). But, still, this effect on user 1 is only caused by user 1 himself in this case, user 2 has no impact. Comparatively speaking, it is true that user 2 would temporarily see a larger amount of free capacity on the link (> 20% available). This we don't try to model. I may be wrong, but I think this is a small nuance of a synthetic scenario. Certainly, more complex models can be built to look into nuances of specific situations, and perhaps this is an area for other researchers to explore. But, at that point, I think you have to move away from simple synthetic usage models like we've been discussing in this thread (5 users simultaneously go immediately dark or simultaneously immediately saturate their link). TCP sessions (and other traffic loads) come and go across the user base asynchronously, so the available capacity fluctuates over time in a more random manner than we've used in this example. Similarly within each modem the traffic loads and TCP sessions will come and go and be in various states of congestion avoidance (hence differing amounts of queue), so the availability of a 500ms or 10ms of queued traffic isn't guaranteed in the FIFO vs FQ_CODEL cases. -Greg On 2/12/14, 1:15 AM, "Mikael Abrahamsson" wrote: >On Tue, 11 Feb 2014, Greg White wrote: > >> What I was getting at is that the above is true for user #1 regardless >> of what applications and what AQM user #2 is using. So we don't need >>to=20 >> simulate user #2 (it is sufficient to model him) if we're interested in >> user #1's performance. > >Are you sure? If AQM user #2 has 500 ms worth of packets in his upstream >buffer (FIFO) vs 10 ms worth of packets with FQ_CODEL, wouldn't that make >him adapt faster to increased upstream capacity? If nothing else, he has >plenty of packets buffered that can be emptied out, whereas with FQ_CODEL >you do not have this huge standing buffer with packets ready to send? > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Wed Feb 12 20:39: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 63DEB1A00EC for ; Wed, 12 Feb 2014 20:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 nQdTOHxiyAXs for ; Wed, 12 Feb 2014 20:39:14 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE41A00E3 for ; Wed, 12 Feb 2014 20:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7011; q=dns/txt; s=iport; t=1392266353; x=1393475953; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5pGRmr3PvujOEXqgJYKa8IomMKwjzhaV9yXjqAbeeg0=; b=Pe7y267ItC3BJ7yWxVtrmoxBEXtaJsC8UiGjxS+QyVXmxg+wl9vE+s9m pQTRUW24lFDKOj5TGLQgl7cVC8eU/KhAv3r+7ja6EZj6XcpCDz4uSJNDC xAsixrJK2/wI6HHorqa6o4ebBDUikBKwFnjW+my62vFY990CGO1i0oVU1 U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAK9L/FKtJV2c/2dsb2JhbABWA4JGRDhXqyqUD4EXFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQOBQ6HbwgNyCQTBI5pEAcRgxOBFASQP4EyhjqSIYFvgT6CKg X-IronPort-AV: E=Sophos;i="4.95,836,1384300800"; d="asc'?scan'208,217";a="20066990" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 13 Feb 2014 04:39:12 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1D4dCAo021914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 04:39:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.227]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 22:39:12 -0600 From: "Fred Baker (fred)" To: "" Thread-Topic: [aqm] Prefatory comments re draft-aqm-reccommendation and -evaluation, and a question Thread-Index: AQHPKHWK/xiOiaaWFES1g7TjvbtD9w== Date: Thu, 13 Feb 2014 04:39:11 +0000 Message-ID: <78F8B890-A075-4800-B7DB-CCADA1438EEA@cisco.com> References: <52D9C1F3.3070803@rogers.com> <52DA9A49.9040109@rogers.com> In-Reply-To: <52DA9A49.9040109@rogers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_61C7FCF0-2631-40BD-9972-38000F38CC8E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] Prefatory comments re draft-aqm-reccommendation and -evaluation, and a question 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, 13 Feb 2014 04:39:16 -0000 --Apple-Mail=_61C7FCF0-2631-40BD-9972-38000F38CC8E Content-Type: multipart/alternative; boundary="Apple-Mail=_46BDCD85-3B77-470C-92E6-6D974E3B72C2" --Apple-Mail=_46BDCD85-3B77-470C-92E6-6D974E3B72C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 18, 2014, at 7:14 AM, David Collier-Brown = wrote: > On 01/17/2014 06:51 PM, I wrote: >> I've been reading through the internet-drafts, and one paragraph = struck me as very illuminating. This is therefor a sanity-check before = I go full-hog down a particular path... >=20 > I have a longish set of comments for = draft-ietf-aqm-recommendations-00, is it best they go to the list as a = series, or to a smaller group as one big wodge? If you haven't sent them in yet, I personally think you should. We're = talking about finalizing the draft, and should get all known comments = out of the way before that review. Send them to the list. > --dave > --=20 > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > davecb@spamcop.net | -- Mark Twain > (416) 223-8968 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein --Apple-Mail=_46BDCD85-3B77-470C-92E6-6D974E3B72C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 davec-b@rogers.com> = wrote:
=20
On 01/17/2014 06:51 PM, I wrote:
=20 I've been reading through the internet-drafts, and one paragraph struck me as very illuminating.  This is therefor a = sanity-check before I go full-hog down a particular path...

I have a longish set of comments for draft-ietf-aqm-recommendations-00, is it best they go to the list as a series, or to a smaller group as one big = wodge?

If you haven't = sent them in yet, I personally think you should. We're talking about = finalizing the draft, and should get all known comments out of the way = before that review. Send them to the list.

--dave
--=20
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |    =
                  -- Mark Twain
(416) 223-8968
_______________________________________________
aqm mailing = list
aqm@ietf.org
https://www.ietf.org/mail= man/listinfo/aqm

If at first = the idea is not absurd, then there is no hope for it.  


= --Apple-Mail=_46BDCD85-3B77-470C-92E6-6D974E3B72C2-- --Apple-Mail=_61C7FCF0-2631-40BD-9972-38000F38CC8E 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 iD8DBQFS/ExsbjEdbHIsm0MRAvbvAKCDE/3lCK/UT3DkooH17A56xEK+IACePFq9 1X26wqbfRVJQZw2WoSfYynM= =Mi9E -----END PGP SIGNATURE----- --Apple-Mail=_61C7FCF0-2631-40BD-9972-38000F38CC8E-- From swmike@swm.pp.se Wed Feb 12 21:37: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 6D9DD1A00EC for ; Wed, 12 Feb 2014 21:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, 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 VjHY3d0rRUdc for ; Wed, 12 Feb 2014 21:37:18 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A64B81A00DF for ; Wed, 12 Feb 2014 21:37:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 40C979C; Thu, 13 Feb 2014 06:37:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 36E489A; Thu, 13 Feb 2014 06:37:16 +0100 (CET) Date: Thu, 13 Feb 2014 06:37:16 +0100 (CET) From: Mikael Abrahamsson To: Greg White In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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, 13 Feb 2014 05:37:22 -0000 On Wed, 12 Feb 2014, Greg White wrote: > Certainly, more complex models can be built to look into nuances of > specific situations, and perhaps this is an area for other researchers > to explore. But, at that point, I think you have to move away from > simple synthetic usage models like we've been discussing in this thread > (5 users simultaneously go immediately dark or simultaneously > immediately saturate their link). TCP sessions (and other traffic > loads) come and go across the user base asynchronously, so the available > capacity fluctuates over time in a more random manner than we've used in > this example. Similarly within each modem the traffic loads and TCP > sessions will come and go and be in various states of congestion > avoidance (hence differing amounts of queue), so the availability of a > 500ms or 10ms of queued traffic isn't guaranteed in the FIFO vs FQ_CODEL > cases. How quickly does the CMTS react to customer demand, is this done continously (basically down to millisecond)? I don't know how cable works, I just know how LTE works for instance, where it actually takes a little while to adapt to changes in customer rate requirements. If cable does this is more or less round robin fairness between users then I agree with you that the current model is sufficient. -- Mikael Abrahamsson email: swmike@swm.pp.se From nicolas.kuhn@telecom-bretagne.eu Thu Feb 13 02:25:08 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 776481A01C2 for ; Thu, 13 Feb 2014 02:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 zdWnHXNxinlm for ; Thu, 13 Feb 2014 02:25:05 -0800 (PST) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id B1A541A0159 for ; Thu, 13 Feb 2014 02:25:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 983106602E; Thu, 13 Feb 2014 11:25:02 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC7Y74py7B4H; Thu, 13 Feb 2014 11:25:02 +0100 (CET) Received: from dhcp-salsa-i-129-163.rennes.enst-bretagne.fr (dhcp-salsa-i-129-163.rennes.enst-bretagne.fr [10.35.129.163]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id F1C1166004; Thu, 13 Feb 2014 11:25:01 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicolas KUHN In-Reply-To: <87vbwqiz3o.fsf@toke.dk> Date: Thu, 13 Feb 2014 11:25:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92701763-5FA6-438F-98C1-E2E11EA366E7@telecom-bretagne.eu> References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> <87vbwqiz3o.fsf@toke.dk> To: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1503) Cc: Richard Scheffenegger , "aqm@ietf.org" Subject: Re: [aqm] [AQM Evaluation Guidelines] 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, 13 Feb 2014 10:25:08 -0000 On Feb 7, 2014, at 6:58 PM, Toke H=F8iland-J=F8rgensen = wrote: > Nicolas KUHN writes: >=20 >> Please let us know what you think of the current document. >=20 > Hi Nicolas and others >=20 > Thank you for the draft; here are some comments, mostly of a more > general nature (as opposed to concrete proposals for rewording). >=20 >=20 > 1. TESTING METHODOLOGY AND REPRODUCIBILITY > I think it is important to encourage good testing methodology in a > document like this; and from the current draft the actual proposed > testing method is not clear. >=20 We tried to be the clearer the possible.=20 If you have any comments or proposals, we would be glad to hear them.=20 > I realise it is also important to leave some room for people to do > things in the way that suits their work-flow, however I believe some > minimum standards for methodology would be appropriate. We mentioned in the draft that the metrics and scenarios can be used for = any AQM and context (that is the main idea of the draft).=20 The idea is to provide a metric section that can be exploited whatever = the context is.=20 Also, the first part of Evaluation section is dedicated to scenarios = that are "context-free".=20 I agree that methodology should be integrated in the draft. I will = include a dedicated section in the next version of the draft.=20 > Reproducibility > is a part of this that is especially important, but other areas that > spring to mind are: >=20 > - A sufficiently detailed description of the test setup to allow = others > to replicate it. Including software and hardware versions etc. > - Availability of the data used for analysis to allow others to check > the conclusions drawn. >=20 > Requiring a reference implementation to be available could also be > relevant to this general point; I would think it would be a reasonable > requirement to have. >=20 > 2. COMPETING VS LOAD-INDUCING TRAFFIC CHARACTERISTICS=20 > Distinguishing between the effect an AQM has on the traffic that = induces > the congestion and traffic that competes with it is worthwhile, in my > opinion. For some applications (e.g. background transfers), maximising > goodput for the "offending" stream is less important than ensuring = that > other traffic is not experiencing added latency because of it, while = for > others (e.g. an adaptive video conference stream), the latency of the > "offending" stream can be vital. Having this distinction in the > measurements (by measuring both) makes it possible to evaluate this > aspect of the AQM behaviour. >=20 I think this is dealt with in section 3.3.1.5.=20 The next version will be more specific with the expected output = (measuring the metrics separately for each class of traffic). The next = version will also detail that the TCp transfer can be operated with an = LBE congestion control.=20 > 3. SOME COMMENTS ON THE SCENARIOS > I have various comments on the proposed testing scenarios: >=20 > - 10 Mbps is a fairly high bandwidth compared to the average = connection > to the internet. I believe it would be worthwhile to include lower > bandwidth(s) in the "general" scenarios, and not just in the = "optional" > ones. ACK - next version will consider 1Mbps > - I don't believe the scenario dubbed "Wi-Fi" is a realistic > representation of the behaviour of a wifi link. A comprehensive wifi > test would include the presence of multiple hosts, bandwidth varying > on very short time scales, and packet aggregation behaviour. I would > suggest keeping the existing scenario, but calling it something else, > and then adding a more comprehensive wifi scenario (which would > probably need some hashing out). > - I'm missing measurements of the behaviour of real-world traffic such > as DNS lookups, HTTP requests, etc. Indeed, having bidirectional > traffic included would be good. >=20 The idea behind the draft was to be quite generic. Wi-Fi is a use case = for "Medium bandwidth, medium delay" scenario. We could go deeper into = details, but I am afraid that the draft will lose some of its = generically. This should be further discussed with the list.=20 > 4. SCHEDULING vs AQM > In the first section(s) mention AQM and scheduling as though they are > interchangeable, while a later section mentions AQM interaction with > scheduling mechanisms. I believe it is worthwhile to both (a) > distinguish clearly between what is mean by AQM resp scheduling, but > also (b) make the recommendations apply equally to a "pure" AQM > algorithm and to a combination scheme that includes both an AQM and a > scheduler (which may or may not be intricately linked in their > operation). >=20 I am not sure the current draft mention that AQM and scheduling are = interchangeable.=20 I think the draft mentions that they may both reduce the latency and the = distinction between the two is clear.=20 If some sections lack of clarity, please point them out.=20 > 5. STABILITY ANALYSIS > While I agree that it is important for an algorithm proposal to argue > plausibly for its stability, I think it is wrong to *require* that > argument to be made in the form of a control theoretic analysis. Such = a > requirement limits possible algorithms to those that can be described > using that particular paradigm (loosely, things expressible and = solvable > by differential equations). For instance, the fluid dynamic TCP model > commonly used for control theory stability analysis, discards a lot of > the dynamics of TCP, most notably slow start and other transient > behaviour, and focuses on the steady state. Since it is by no means > clear that this is the only way to make the argument (and indeed > focusing too much on the steady state can be counter-productive), I > would suggest to at least reword the section to mention control theory > as *a* way to make the argument, rather than the *only* way. >=20 >=20 The draft claims that the impact of every externally tuned parameter = MUST be discussed. The tester SHOULD provide background material showing = control theoretic analysis but COULD use other ways to discuss = stability.=20 Kind regards,=20 Nicolas >=20 > Sorry if this got a bit long; I started with a much shorter list of > notes, I swear! :) >=20 > -Toke From wolfram.lautenschlaeger@alcatel-lucent.com Thu Feb 13 07:16:25 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 080951A01F1 for ; Thu, 13 Feb 2014 07:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 9jbye0ftM2b1 for ; Thu, 13 Feb 2014 07:16:23 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0601A02C6 for ; Thu, 13 Feb 2014 07:16:11 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1DFG8Yt008925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Feb 2014 09:16:09 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1DFG7NR013667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Feb 2014 16:16:08 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.165]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 16:16:07 +0100 From: "LAUTENSCHLAEGER, WOLFRAM (WOLFRAM)" To: "aqm@ietf.org" Thread-Topic: new I-D on Global Synchronization Protection for Packet Queues Thread-Index: Ac8oznfOE3clBRJ3QHi1y5z9PwWdpA== Date: Thu, 13 Feb 2014 15:16:07 +0000 Message-ID: <0A452E1DADEF254C9A7AC1969B8781280502D6@FR712WXCHMBA13.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [aqm] new I-D on Global Synchronization Protection for Packet Queues 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, 13 Feb 2014 15:16:25 -0000 Dear all, I submitted an I-D with a proposal for a particularly light weight AQM sche= me that is solely focused on suppression of global synchronization. Despite= its simplicity it is able to reduce the queuing size, delay, and jitter by= an order of magnitude and more, if many flows are competing for a bottlene= ck. If possible I would like to present the theoretical rationale behind the pr= oposal and experimental results with a Linux qdisc implementation on the AQ= M WG meeting at IETF 89 in London. URL: https://datatracker.ietf.org/doc/draft-lauten-aqm-gsp/ Wolfram Lautenschlaeger From g.white@CableLabs.com Thu Feb 13 07:43: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 EE8FB1A02AC for ; Thu, 13 Feb 2014 07:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548] 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 HUx7FTzix9Eo for ; Thu, 13 Feb 2014 07:43:14 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 512651A0209 for ; Thu, 13 Feb 2014 07:43:14 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s1DFhCF1013863; Thu, 13 Feb 2014 08:43:12 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 13 Feb 2014 08:43:12 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 08:43:12 -0700 From: Greg White To: Mikael Abrahamsson Thread-Topic: [aqm] some comments I'd made on the cablelabs study privately Thread-Index: AQHPJgi0fL9DpXCbg0ORb6qUDdr545qud9mAgABuCYCAAU4kgIAACYqAgAGA3ICAAEiXAIABHZIAgAAz8oA= Date: Thu, 13 Feb 2014 15:43:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.4.10.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A7F01E55ADF184194689B36666215C6@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] some comments I'd made on the cablelabs study privately 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, 13 Feb 2014 15:43:16 -0000 On 2/12/14, 10:37 PM, "Mikael Abrahamsson" wrote: >On Wed, 12 Feb 2014, Greg White wrote: > >> Certainly, more complex models can be built to look into nuances of >> specific situations, and perhaps this is an area for other researchers >> to explore. But, at that point, I think you have to move away from >> simple synthetic usage models like we've been discussing in this thread >> (5 users simultaneously go immediately dark or simultaneously >> immediately saturate their link). TCP sessions (and other traffic >> loads) come and go across the user base asynchronously, so the >>available=20 >> capacity fluctuates over time in a more random manner than we've used >>in=20 >> this example. Similarly within each modem the traffic loads and TCP >> sessions will come and go and be in various states of congestion >> avoidance (hence differing amounts of queue), so the availability of a >> 500ms or 10ms of queued traffic isn't guaranteed in the FIFO vs >>FQ_CODEL=20 >> cases. > >How quickly does the CMTS react to customer demand, is this done >continously (basically down to millisecond)? I don't know how cable >works,=20 >I just know how LTE works for instance, where it actually takes a little >while to adapt to changes in customer rate requirements. If cable does >this is more or less round robin fairness between users then I agree with >you that the current model is sufficient. It is done continuously. There is about a 6ms lag between the CM sending a request for a transmission opportunity (e.g. "I currently have 3742 bytes in queue ready to transmit") and the actual transmission opportunity occurring (e.g. "Ok you can transmit 1768 bytes starting at time X"), but essentially* every data transmission is handled via this request-grant mechanism, i.e. the CMTS doesn't grant a tx opportunity for a CM unless it is explicitly requested for. *there are some special cases (not relevant here) that differ from this > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se From toke@toke.dk Thu Feb 13 08:09:26 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 864481A020D for ; Thu, 13 Feb 2014 08:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 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, MIME_HEADER_CTYPE_ONLY=0.717] 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 IBF-tlxEkwxE for ; Thu, 13 Feb 2014 08:09:24 -0800 (PST) Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) by ietfa.amsl.com (Postfix) with ESMTP id 96C891A030E for ; Thu, 13 Feb 2014 08:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-kau.localdomain (Postfix, from userid 1000) id A5216552A6; Thu, 13 Feb 2014 17:09:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1392307754; bh=ohdF844TdehscKNMGjrE5fJRj83AT6yGIZkv9S7nZpI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=I/Y98sxo8pbheLX6AcEwTIsBb7A0WsxUwKbfvsB6WOjWqJXqePaEETZHR2A5hWYDV I5BY9psip1tbVgnAqCpXneiXsX2tWRwnFyH5MYrju5PXjCcPCEZaNy+FzPzFMa/pFf RP70BKzTbYAUiWjFrhYxtviq1U0iEHQaIUuSQZEQ= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Nicolas KUHN References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> <87vbwqiz3o.fsf@toke.dk> <92701763-5FA6-438F-98C1-E2E11EA366E7@telecom-bretagne.eu> Date: Thu, 13 Feb 2014 17:09:11 +0100 In-Reply-To: <92701763-5FA6-438F-98C1-E2E11EA366E7@telecom-bretagne.eu> (Nicolas KUHN's message of "Thu, 13 Feb 2014 11:25:01 +0100") Message-ID: <87wqgz2dw8.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: Richard Scheffenegger , "aqm@ietf.org" Subject: Re: [aqm] [AQM Evaluation Guidelines] 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, 13 Feb 2014 16:09:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Nicolas KUHN writes: > We tried to be the clearer the possible.=20 > If you have any comments or proposals, we would be glad to hear them. Well, one thing I believe is worth addressing is the issue of simulation vs experiments on real systems. I would not consider an algorithm that has never been subjected to real-world testing to be sufficiently evaluated. Another issue is how to obtain the data: if the AQM itself is inspected while running that might affect its performance, whereas if packet traces or application level measurements at another point are inspected, they might be showing behaviour that has very little to do with the behaviour of the AQM algorithm. As an example of the latter, on Linux it is very easy to end up measuring buffers in the network driver, unless care is taken to avoid it. I would like to see the draft address these issues and provide some guidance on how the most obvious pitfalls can be avoided. I'll be happy to draft some text on it, if it's not part of the planned methodology section. > I agree that methodology should be integrated in the draft. I will > include a dedicated section in the next version of the draft. Great (also, comments above)! > I think this is dealt with in section 3.3.1.5. (I'm assuming you mean 3.2.1.5 here). I suppose that scenario could cover this; however, I was also alluding to the methodological issue of distinguishing between the case where latency is measured by a separate flow (such as a straight 'ping' alongside the test) vs directly measuring the queueing delay of the packets making up the traffic scenario; I believe both kinds of measurements provide valuable data, but about different aspects of the algorithm behaviour... > The next version will be more specific with the expected output > (measuring the metrics separately for each class of traffic). The next > version will also detail that the TCp transfer can be operated with an > LBE congestion control. ACK. What about IW4 vs IW10? > The idea behind the draft was to be quite generic. Wi-Fi is a use case > for "Medium bandwidth, medium delay" scenario. We could go deeper into > details, but I am afraid that the draft will lose some of its > generically. This should be further discussed with the list. I'm not saying "get rid of the scenario", I'm saying "Don't call it wifi, because that mischaracterises the behaviour of wifi". And perhaps also "add a scenario where bandwidth varies on very small time scales". > I am not sure the current draft mention that AQM and scheduling are > interchangeable. I think the draft mentions that they may both reduce > the latency and the distinction between the two is clear. If some > sections lack of clarity, please point them out. I think it could be made clearer whether or not his document is meant as only a way to evaluate AQM algorithms, or if hybrid AQM/scheduling algorithms should also be in scope (I would argue for the latter). In the first many sections, whenever scheduling is mentioned (sections 2, 2.2.3, 3.2.3), the wording suggests that indeed AQM and scheduling can be complimentary and an algorithm might feasibly be a tightly coupled hybrid. However, the section specifically dealing with scheduling (4.4), discussing adding scheduling "on top of" the algorithm is mentioned as a requirement, which might imply that an algorithm that already includes (say) a tightly coupled scheduler would not be liable for consideration? Also, this paragraph: Both schedulers and AQMs can be introduced when packet are either enqued or dequed. If both schedulers and AQM are implemented when packet are enqued, their interaction should not be a major issue. However, if one is introduced when packets are enqued and the others when they are dequed, there may be destructive interactions. seems a bit speculative to me. Has the fact that the algorithms' activation time is a predictor of adverse side effects actually been demonstrated? > The draft claims that the impact of every externally tuned parameter > MUST be discussed. The tester SHOULD provide background material > showing control theoretic analysis but COULD use other ways to discuss > stability. That formulation would be fine with me. However, the last part of the latter sentence (the COULD part) is missing from the draft... :) =2DToke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJS/O4nAAoJEENeEGz1+utPz4IH/j0lBO06U9NEGsTARpDHPyDO 2qV0Tva9uwxQsK4BVPJWtPsCrgn9Xl4a1RZD1vl5WBr+vWM5Zdj+iD/nn22JT4q0 cUiQ+a/7+2zn35pVO8qiD1HiR1ouO43ENGhgG/hwC+bPvNXtWwRROra7rXUIuGaL yqfdXSxxaHjvBbeGjNQY2qhGOaqx4qm4wMkOmH8j19KidiL6iZQdlRU/D9FnTG2O XxwNJ+ztl77gwxcrpoYM+tksdg3MS+eOqYrVStOMgHnPnidkxPy6QxKCKUOIpcWm uXb/BQd6vny+eLjtSBMnfp4hqzX4ueDVhD5ydSs5YDa0YEDY7aPRk5+aYAW/3R4= =K4mm -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 13 11:25:04 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 141921A0350 for ; Thu, 13 Feb 2014 11:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 IY_2Ko2T_zjU for ; Thu, 13 Feb 2014 11:24:56 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3361A0404 for ; Thu, 13 Feb 2014 11:24:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,840,1384329600"; d="scan'208,217";a="101967363" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 13 Feb 2014 11:24:55 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 11:24:55 -0800 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: Draft Agenda for IETF89 Thread-Index: Ac8o8PonjUL7l8fiSvyG5Yr+JT+XLQ== Date: Thu, 13 Feb 2014 19:24:54 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-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.104.60.118] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F2605812ESACEXCMBX02PRDh_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/JNu-0AxO0qkklWp_qep-T-0uAfE Subject: [aqm] Draft Agenda for IETF89 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, 13 Feb 2014 19:24:58 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F2605812ESACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The draft agenda for this IETF meeting in London has currently the followin= g points. Please let me know if you disagree with the ordering, length or anything el= se! Best regards, Richard Scheffenegger (aqm-chair) ***************************************************************************= ********** AQM Agenda IETF 89 in London, United Kingdom Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) ****************************************************** WG status --------- 14:20 Agenda bashing AQM status Chairs 10 min WG items -------- 14:30 draft-ietf-aqm-recommendation Fred Baker / Gorry Fairhurst 10 min Charter items ------------- 14:40 draft-fairhurst-ecn-motivation Gorry Fairhurst 15 min 14:55 draft-kuhn-aqm-eval-guidelines Nicolas Kuhn et. al. 45 min if time permits: Algorithm Proposals ------------------- 15:40 draft-lauten-aqm-gsp wolfram lautenschlaeger 10 min --_000_012C3117EDDB3C4781FD802A8C27DD4F2605812ESACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
The draft agenda for this IETF meeting in London has currently the fol= lowing points.
 
Please let me know if you disagree with the ordering, length or anythi= ng else!
 
Best regards,
 
Richard Scheffenegger (aqm-chair)
 
**********************************************************************= ***************
 
AQM Agenda
IETF 89 in London, United Kingdom
Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign)
******************************************************
 
WG status
---------
 
14:20
Agenda bashing
AQM status
Chairs
10 min
 
 
WG items
--------
 
14:30
draft-ietf-aqm-recommendation
Fred Baker / Gorry Fairhurst
10 min
 
 
Charter items
-------------
 
14:40
draft-fairhurst-ecn-motivation
Gorry Fairhurst
15 min
 
14:55
draft-kuhn-aqm-eval-guidelines
Nicolas Kuhn et. al.
45 min
 
 
if time permits:
 
Algorithm Proposals
-------------------
 
15:40
draft-lauten-aqm-gsp
wolfram lautenschlaeger
10 min
 
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F2605812ESACEXCMBX02PRDh_-- From nobody Thu Feb 13 11:40: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 3B6D61A0405 for ; Thu, 13 Feb 2014 11:40:19 -0800 (PST) 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 5y8kzZWj5EFB for ; Thu, 13 Feb 2014 11:40:17 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 22FE11A03D0 for ; Thu, 13 Feb 2014 11:40:17 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id o15so16741709qap.2 for ; Thu, 13 Feb 2014 11:40:15 -0800 (PST) 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=ZbRKDGvaGkiPeTuttn4y8npGRrPhbAYVc/+yG1ZIiCk=; b=eJj15T6iNEPJOL7oCS62OzFlalzMzbtXrhFtyeQBKDmzQALNly9O/cdTWrKcXkV9/p w92df408JekEPV0IOtnZU59RXjoaJdcxH04dH7auyCRraW1WBxoFReimb72tlPiq0Iou MSTLx1ea17T5UNIYPEg4wlOCVJG92JVXETkcK1iKQV8pVpFJsJwQYKSmSpmJUZ79ZyUS 2izpmdOo4m2ZvBoxN6L1mr52wuo9SQiX2ZYKc9gxe9R8Jn4usRq5DzuPC/1mcD50bh6Z vf94PWRMi3pgRKQbgGZelHXiMeWeap32oBgLsVFCz+TZPe/h2v0/tz0SRHrY3/4faUyx gByA== MIME-Version: 1.0 X-Received: by 10.224.30.16 with SMTP id s16mr5855697qac.74.1392320412325; Thu, 13 Feb 2014 11:40:12 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 11:40:12 -0800 (PST) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 13 Feb 2014 14:40:12 -0500 Message-ID: From: Dave Taht To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/LICu7yNoHx6YsmZm4ZLBAnbezQo Cc: "aqm@ietf.org" Subject: Re: [aqm] Draft Agenda for IETF89 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, 13 Feb 2014 19:40:19 -0000 On Thu, Feb 13, 2014 at 2:24 PM, Scheffenegger, Richard wro= te: > Hi, > > The draft agenda for this IETF meeting in London has currently the follow= ing > points. > > Please let me know if you disagree with the ordering, length or anything > else! > > Best regards, > > Richard Scheffenegger (aqm-chair) > > *************************************************************************= ************ > > AQM Agenda > IETF 89 in London, United Kingdom > Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) > ****************************************************** > > WG status > --------- > > 14:20 > Agenda bashing > AQM status > Chairs > 10 min > > > WG items > -------- > > 14:30 > draft-ietf-aqm-recommendation > Fred Baker / Gorry Fairhurst > 10 min > > > Charter items > ------------- > > 14:40 > draft-fairhurst-ecn-motivation > Gorry Fairhurst > 15 min This is apparently not a published draft yet. > > 14:55 > draft-kuhn-aqm-eval-guidelines > Nicolas Kuhn et. al. > 45 min I keep hoping for more discussion on the list. > > > if time permits: > > Algorithm Proposals > ------------------- > > 15:40 > draft-lauten-aqm-gsp > wolfram lautenschlaeger > 10 min Nifty, got code? > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Thu Feb 13 13:20:25 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 80AF31A0513; Thu, 13 Feb 2014 13:20:22 -0800 (PST) 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 NuX3ltL5ngBj; Thu, 13 Feb 2014 13:20:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC3C1A0516; Thu, 13 Feb 2014 13:20:19 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213212019.12484.97730.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 13:20:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/M1roXlTdxF8k62Az6ZmgiUUn4dQ Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-recommendation-02.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: Thu, 13 Feb 2014 21:20:22 -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 : IETF Recommendations Regarding Active Queue Management Authors : Fred Baker Godred Fairhurst Filename : draft-ietf-aqm-recommendation-02.txt Pages : 22 Date : 2014-02-13 Abstract: This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. The note largely repeats the recommendations of RFC 2309, updated after fifteen years of experience and new research. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-aqm-recommendation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-02 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 Thu Feb 13 13:30:47 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 64C4B1A04F7 for ; Thu, 13 Feb 2014 13:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 G0A4c5-Oi5k3 for ; Thu, 13 Feb 2014 13:30:43 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 756451A04ED for ; Thu, 13 Feb 2014 13:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3265; q=dns/txt; s=iport; t=1392327042; x=1393536642; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JfXFfkp6qVX8atf5BzR4HYJO8Md+I/yrU7KpE4uDqvs=; b=TApivbaItVmH6+QOrmfZrAli1roG0wo7O7V3Rjds47Fz6MsfGNh/XGQ6 R3nUADKwIC1bBLN62aj49q5L6yuSEt1yTJda7R1m00lxiCQw8nevzXV4N /mnVz9nRCGAmhN9HH3f4U7veWtcFeyM7VSHm9yw5X5I4mQvjjX5z786CX E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJ04/VKtJV2Z/2dsb2JhbABZgwY4UQa/ToEaFnSCJQEBAQMBAQEBaxsCAQhGJwslAgQTCQUGh2kICAXILBePAIMkgRQEkECBMoY6gTKLL4VCgy1xAYE4 X-IronPort-AV: E=Sophos;i="4.95,840,1384300800"; d="asc'?scan'208";a="20301483" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 13 Feb 2014 21:30:42 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1DLUfJv020338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Feb 2014 21:30:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.202]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 15:30:41 -0600 From: "Fred Baker (fred)" To: "aqm@ietf.org list" Thread-Topic: [aqm] I-D Action: draft-ietf-aqm-recommendation-02.txt Thread-Index: AQHPKQLYiC2ciN4A00CWSjjKuLZITg== Date: Thu, 13 Feb 2014 21:30:40 +0000 Message-ID: <0B51D150-B5D5-422D-A76C-DD9DFAE7A6F0@cisco.com> References: <20140213212019.12484.97730.idtracker@ietfa.amsl.com> In-Reply-To: <20140213212019.12484.97730.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_D076D697-8165-4315-9C18-A36BA62AAC01"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/otPXvf30d4-msz7xwmqnBiQpBM4 Subject: Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-02.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: Thu, 13 Feb 2014 21:30:45 -0000 --Apple-Mail=_D076D697-8165-4315-9C18-A36BA62AAC01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gorry and I have posted a second update to the AQM Recommendations draft = discussed at IETF 88. This update mostly picks up nit-level matters. We, of course, invite review, and would suggest that reviews look at = this version. A diff from IETF 88's version may be found at = http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-a= qm-recommendation-00.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-aqm-re= commendation-02.txt which is also http://tinyurl.com/k9tfufm On Feb 13, 2014, at 1:20 PM, wrote: >=20 > 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. >=20 > Title : IETF Recommendations Regarding Active Queue = Management > Authors : Fred Baker > Godred Fairhurst > Filename : draft-ietf-aqm-recommendation-02.txt > Pages : 22 > Date : 2014-02-13 >=20 > Abstract: > This memo presents recommendations to the Internet community > concerning measures to improve and preserve Internet performance. = It > presents a strong recommendation for testing, standardization, and > widespread deployment of active queue management (AQM) in network > devices, to improve the performance of today's Internet. It also > urges a concerted effort of research, measurement, and ultimate > deployment of AQM mechanisms to protect the Internet from flows that > are not sufficiently responsive to congestion notification. >=20 > The note largely repeats the recommendations of RFC 2309, updated > after fifteen years of experience and new research. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-aqm-recommendation-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-aqm-recommendation-02 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --Apple-Mail=_D076D697-8165-4315-9C18-A36BA62AAC01 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 iD8DBQFS/Tl9bjEdbHIsm0MRAnu5AJ4qK3RYwvcml+tDhq06AK7CVgY3PgCgtT+i X8O8EgKn+oZelhvdELo/hCk= =VYfb -----END PGP SIGNATURE----- --Apple-Mail=_D076D697-8165-4315-9C18-A36BA62AAC01-- From nobody Thu Feb 13 16:33: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 D62FA1A0021 for ; Thu, 13 Feb 2014 16:33:44 -0800 (PST) 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 ZEWMGICoCxef for ; Thu, 13 Feb 2014 16:33:42 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id DAD841A0020 for ; Thu, 13 Feb 2014 16:33:41 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id w8so17559995qac.0 for ; Thu, 13 Feb 2014 16:33:40 -0800 (PST) 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=2o2xREPoKXkO9dAOZ5Zmj/XWOJdHgZLhdKoqvqOWrWU=; b=DaoRoG8NoKENTJhdg6mrWnZOSgfkxz3NPDG15QbpS0hXJxTqy+7r3cD1gjTCSFsvSL SKwKMf42Xe/na6UbYY+NfOhKjLlQ/1A/yYow8xcNdvi9pqFoGGGVSsYKyjHblQhdlB+f HUQ/g9BLN74JCW1DUwabUcCp5OHgttwzcXPHmUTALro16ii3XwdQBvz5cdUytSbtwlvS 4PGHTi+vcK+NyUWXZqBnuz6RK9kNTHm5B2BghQsDWN1vAy2d0OHmqXsrVDSVH2l9ZnOT 9YluJSHEwLgPT5XhRbO3bSRxn584uVFNPTxmpm8KlYYmKsFVrDPpNowVY7lvzCOBtJNG +Fxg== MIME-Version: 1.0 X-Received: by 10.229.193.136 with SMTP id du8mr7885479qcb.11.1392338020281; Thu, 13 Feb 2014 16:33:40 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 16:33:40 -0800 (PST) In-Reply-To: <0B51D150-B5D5-422D-A76C-DD9DFAE7A6F0@cisco.com> References: <20140213212019.12484.97730.idtracker@ietfa.amsl.com> <0B51D150-B5D5-422D-A76C-DD9DFAE7A6F0@cisco.com> Date: Thu, 13 Feb 2014 19:33:40 -0500 Message-ID: From: Dave Taht To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/srC3c6kDX38tD850MGcABU2x3ds Cc: "aqm@ietf.org list" , bloat Subject: Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-02.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, 14 Feb 2014 00:33:45 -0000 On Thu, Feb 13, 2014 at 4:30 PM, Fred Baker (fred) wrote: > Gorry and I have posted a second update to the AQM Recommendations draft = discussed at IETF 88. This update mostly picks up nit-level matters. > > We, of course, invite review, and would suggest that reviews look at this= version. A few nits. A) I have not bought into byte-pkt. I don't want to go into it today. In particular, I'd like the original pie benchmarks rerun now that that code doesn't have a byte sensitive dropping mode, and the two compared. Perhaps that would shed some light on the issue. B) "Another topic requiring consideration is the appropriate granularity of a "flow" when considering a queue management method. There are a few "natural" answers: 1) a transport (e.g. TCP or UDP) flow (source address/port, destination address/port, Differentiated Services Code Point - DSCP); 2) a source/destination host pair (IP addresses, DSCP); 3) a given source host or a given destination host. add: 4) 5 tuple consisting of source ip/port, dest/port, proto. And we can hash it out later. C) " We suggest that the source/destination host pair gives the most appropriate granularity in many circumstances. " Back that up with measurements of real traffic from real homes and small businesses, and I'll believe you. Breaking up packet trains back into packets in sane ways is the only way to deal with the impact of iw10 at low bandwidths that I can think of, in particular. In the interim I would suggest language that waffles more as to appropriate methods. D) "Traffic classes may be differentiated based on an Access Control List (ACL), the packet DiffServ Code Point (DSCP) [RFC5559], setting of the ECN field[RFC3168] [RFC4774] or an equivalent codepoint at a lower layer." Are you ruling out port number? I have no problem with (for example) deprioritizing port 873 (rsync) somewhat relevant to other traffic. Same goes for some other well known ports... Are you ruling out protocol number? Destination address? (stuff inside my network gets treated differently than stuff egressing) These are all common methods of classifying traffic that has codepoints that cannot be trusted. And regrettably, on inbound from another domain, diffserv values cannot be trusted, period. I don't know how to fit that into this draft, bu= t a MUST regarding remarking inbound diffserv appropriately is needed. Right now I just quash everything inbound to BE. E) "A malfunctioning or non-conforming network device may similarly "hide" an ECN mark. In normal operation such cases should be very uncommon." I disagree with the last sentence. ECN unleashed will be ECN abused. If the recent ntp flooding attacks were ECN marked, and ECN widely deployed, what would have happened? (I still strongly support the notion of ECN, but don't want to deprecate the dangers) > A diff from IETF 88's version may be found at > > http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-= aqm-recommendation-00.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-aqm-re= commendation-02.txt > > which is also http://tinyurl.com/k9tfufm > > On Feb 13, 2014, at 1:20 PM, > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Active Queue Management and Packet Sche= duling Working Group of the IETF. >> >> Title : IETF Recommendations Regarding Active Queue Man= agement >> Authors : Fred Baker >> Godred Fairhurst >> Filename : draft-ietf-aqm-recommendation-02.txt >> Pages : 22 >> Date : 2014-02-13 >> >> Abstract: >> This memo presents recommendations to the Internet community >> concerning measures to improve and preserve Internet performance. It >> presents a strong recommendation for testing, standardization, and >> widespread deployment of active queue management (AQM) in network >> devices, to improve the performance of today's Internet. It also >> urges a concerted effort of research, measurement, and ultimate >> deployment of AQM mechanisms to protect the Internet from flows that >> are not sufficiently responsive to congestion notification. >> >> The note largely repeats the recommendations of RFC 2309, updated >> after fifteen years of experience and new research. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-aqm-recommendation-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-aqm-recommendation-02 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> 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/ >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Fri Feb 14 00:03:04 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 9B3821A013D for ; Fri, 14 Feb 2014 00:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 ly_ObyjL2QPj for ; Fri, 14 Feb 2014 00:03:00 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id DB47F1A0158 for ; Fri, 14 Feb 2014 00:02:59 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id F15632B41C8; Fri, 14 Feb 2014 08:02:57 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 14 Feb 2014 08:02:58 -0000 Message-ID: <27db50749ac8e30618c7f87f270a5745.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <20140213212019.12484.97730.idtracker@ietfa.amsl.com> <0B51D150-B5D5-422D-A76C-DD9DFAE7A6F0@cisco.com> Date: Fri, 14 Feb 2014 08:02:58 -0000 From: gorry@erg.abdn.ac.uk To: "Dave Taht" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/5JUvg2Xuzjf_usXuCh5-xNzZH-A Cc: bloat , "Fred Baker \(fred\)" , "aqm@ietf.org list" Subject: Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-02.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, 14 Feb 2014 08:03:02 -0000 > On Thu, Feb 13, 2014 at 4:30 PM, Fred Baker (fred) wrote: >> Gorry and I have posted a second update to the AQM Recommendations draft >> discussed at IETF 88. This update mostly picks up nit-level matters. >> >> We, of course, invite review, and would suggest that reviews look at >> this version. > > A few nits. > > A) I have not bought into byte-pkt. I don't want to go into it today. > > In particular, I'd like the original pie benchmarks rerun now that > that code doesn't have a byte sensitive dropping mode, and the two > compared. > > Perhaps that would shed some light on the issue. > I'm not sure I understand the comment, but new data is always good. > B) "Another topic requiring consideration is the appropriate granularity > of a "flow" when considering a queue management method. There are a > few "natural" answers: 1) a transport (e.g. TCP or UDP) flow (source > address/port, destination address/port, Differentiated Services Code > Point - DSCP); 2) a source/destination host pair (IP addresses, > DSCP); 3) a given source host or a given destination host. > > > add: > > 4) 5 tuple consisting of source ip/port, dest/port, proto. > We could add MF-Classifier - I personally would have no problems with that. > And we can hash it out later. > > C) " We > suggest that the source/destination host pair gives the most > appropriate granularity in many circumstances. " > > Back that up with measurements of real traffic from real homes and > small businesses, and I'll believe you. Breaking up packet trains back > into packets in sane ways is the only way to deal with the impact > of iw10 at low bandwidths that I can think of, in particular. > > In the interim I would suggest language that waffles more as to > appropriate methods. > Maybe this relates to your position in the Internet - edge device v. other places. We could say something on this? > D) "Traffic > classes may be differentiated based on an Access Control List (ACL), > the packet DiffServ Code Point (DSCP) [RFC5559], setting of the ECN > field[RFC3168] [RFC4774] or an equivalent codepoint at a lower layer." > > Are you ruling out port number? I have no problem with (for example) > deprioritizing port 873 (rsync) somewhat relevant to other traffic. Same > goes for some other well known ports... > > Are you ruling out protocol number? > > Destination address? (stuff inside my network gets treated > differently than stuff egressing) > > These are all common methods of classifying traffic that has > codepoints that cannot be trusted. > > And regrettably, on inbound from another domain, diffserv values > cannot be trusted, period. I don't know how to fit that into this draft, > but > a MUST regarding remarking inbound diffserv appropriately is > needed. Right now I just quash everything inbound to BE. > Ports and the rest would be covered by MF-Classifier? I don't think a tutorial of DS fits in this particular draft, although if the IETF adopts draft-geib-tsvwg-diffserv-intercon, it would relate to the topic you mention. > > E) "A malfunctioning or non-conforming > network device may similarly "hide" an ECN mark. In normal operation > such cases should be very uncommon." > > I disagree with the last sentence. ECN unleashed will be ECN abused. > > If the recent ntp flooding attacks were ECN marked, and ECN widely > deployed, what would have happened? > > (I still strongly support the notion of ECN, but don't want to > deprecate the dangers) > If I understand, you're suggesting that the group should unpick the last sentence, and explain more. Speaking only for myself, I'm tempted to agree - ECN also needs something to keep it sane. Do you have some suggested text here? Gorry >> A diff from IETF 88's version may be found at >> >> http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-aqm-recommendation-00.txt&url2=http://tools.ietf.org/id/draft-ietf-aqm-recommendation-02.txt >> >> which is also http://tinyurl.com/k9tfufm >> >> On Feb 13, 2014, at 1:20 PM, >> wrote: >> >>> >>> 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 : IETF Recommendations Regarding Active Queue >>> Management >>> Authors : Fred Baker >>> Godred Fairhurst >>> Filename : draft-ietf-aqm-recommendation-02.txt >>> Pages : 22 >>> Date : 2014-02-13 >>> >>> Abstract: >>> This memo presents recommendations to the Internet community >>> concerning measures to improve and preserve Internet performance. It >>> presents a strong recommendation for testing, standardization, and >>> widespread deployment of active queue management (AQM) in network >>> devices, to improve the performance of today's Internet. It also >>> urges a concerted effort of research, measurement, and ultimate >>> deployment of AQM mechanisms to protect the Internet from flows that >>> are not sufficiently responsive to congestion notification. >>> >>> The note largely repeats the recommendations of RFC 2309, updated >>> after fifteen years of experience and new research. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-aqm-recommendation-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-02 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >> >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >> > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From nobody Fri Feb 14 01:55:11 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 DD54B1A0125 for ; Fri, 14 Feb 2014 01:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 Tj91EUD4Q3ZI for ; Fri, 14 Feb 2014 01:55:07 -0800 (PST) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00F1A010C for ; Fri, 14 Feb 2014 01:55:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 5069566009; Fri, 14 Feb 2014 10:55:05 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPCrJeHPe0nF; Fri, 14 Feb 2014 10:55:04 +0100 (CET) Received: from [IPv6:2001:660:7301:3728:b053:3d14:df0f:865] (passerellev6v4.enst-bretagne.fr [192.108.117.5]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 941C766017; Fri, 14 Feb 2014 10:55:04 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicolas KUHN In-Reply-To: <87wqgz2dw8.fsf@toke.dk> Date: Fri, 14 Feb 2014 10:55:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> <87vbwqiz3o.fsf@toke.dk> <92701763-5FA6-438F-98C1-E2E11EA366E7@telecom-bretagne.eu> <87wqgz2dw8.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1503) Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/2jSLE0NRd-wKzcwPx9FkqbiteXo Cc: Richard Scheffenegger , "aqm@ietf.org" Subject: Re: [aqm] [AQM Evaluation Guidelines] 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, 14 Feb 2014 09:55:10 -0000 Dear Toke,=20 On Feb 13, 2014, at 5:09 PM, Toke H=F8iland-J=F8rgensen = wrote: > Nicolas KUHN writes: >=20 >> We tried to be the clearer the possible.=20 >> If you have any comments or proposals, we would be glad to hear them. >=20 > Well, one thing I believe is worth addressing is the issue of = simulation > vs experiments on real systems. I would not consider an algorithm that > has never been subjected to real-world testing to be sufficiently > evaluated. >=20 I believe the draft must be the most generic the possible. These = guidelines provide the tools and aspects that must be looked at, however = the AQM is tested. Even-driven simulations (such as in NS-2,OMNET) = enable to achieve an economical and fast protocol experimentation = [http://arxiv.org/pdf/1002.2827.pdf]. These guidelines cannot reject a = proposal because it has not been tested in the 'real' world.=20 I will add in the "methodology" section something about that issue, = saying that proposals SHOULD be evaluated in testbeds, and MAY be = evaluated with event-driven simulations to better understand their = internal behaviour.=20 > Another issue is how to obtain the data: if the AQM itself is = inspected > while running that might affect its performance, whereas if packet > traces or application level measurements at another point are = inspected, > they might be showing behaviour that has very little to do with the > behaviour of the AQM algorithm. As an example of the latter, on Linux = it > is very easy to end up measuring buffers in the network driver, unless > care is taken to avoid it. >=20 This is the kind of discussion that should be avoided in the draft. = Indeed, I am afraid we may open a "pandora's box" as we do not want to = list all the issues encountered by any evaluation tool set. We may end = discussing why choosing emulation, vs simulation, vs mathematical model, = vs real-workd experiment. =20 > I would like to see the draft address these issues and provide some > guidance on how the most obvious pitfalls can be avoided. I'll be = happy > to draft some text on it, if it's not part of the planned methodology > section. >=20 >> I agree that methodology should be integrated in the draft. I will >> include a dedicated section in the next version of the draft. >=20 > Great (also, comments above)! >=20 >> I think this is dealt with in section 3.3.1.5. >=20 > (I'm assuming you mean 3.2.1.5 here). >=20 Yes, I integrated the "Methodology" section and 3.2.1.5 became 3.3.1.5.=20= Sorry for that > I suppose that scenario could cover this; however, I was also alluding > to the methodological issue of distinguishing between the case where > latency is measured by a separate flow (such as a straight 'ping' > alongside the test) vs directly measuring the queueing delay of the > packets making up the traffic scenario; I believe both kinds of > measurements provide valuable data, but about different aspects of the > algorithm behaviour=85 >=20 I think that this is more a metric linked to the evaluation tool set.=20 If we want the guidelines to be "generic" and "evaluation tool set" = free, this should not be discussed. =20 >> The next version will be more specific with the expected output >> (measuring the metrics separately for each class of traffic). The = next >> version will also detail that the TCp transfer can be operated with = an >> LBE congestion control. >=20 > ACK. What about IW4 vs IW10? I am not sure that it makes sense here, that would be another pandora's = box: the guidelines should not consider every possible TCP improvements. = Otherwise, others would say "do you consider RENO? CUBIC? Delay based = CC?" or "what about MultiPath?". We must generic and speak generally = about TCP and UDP - without much more details.=20 >=20 >> The idea behind the draft was to be quite generic. Wi-Fi is a use = case >> for "Medium bandwidth, medium delay" scenario. We could go deeper = into >> details, but I am afraid that the draft will lose some of its >> generically. This should be further discussed with the list. >=20 > I'm not saying "get rid of the scenario", I'm saying "Don't call it > wifi, because that mischaracterises the behaviour of wifi". And = perhaps > also "add a scenario where bandwidth varies on very small time = scales". >=20 Yes I updated the Section "Medium bandwidth, medium delay: Wi-Fi" so = that the tester may include "small time scales varying bandwidth" >> I am not sure the current draft mention that AQM and scheduling are >> interchangeable. I think the draft mentions that they may both reduce >> the latency and the distinction between the two is clear. If some >> sections lack of clarity, please point them out. >=20 > I think it could be made clearer whether or not his document is meant = as > only a way to evaluate AQM algorithms, or if hybrid AQM/scheduling > algorithms should also be in scope (I would argue for the latter). >=20 I agree as well - the draft would then need some rewording I will add an entry in the glossary explaining that by AQM, the draft = consider hybrid AQM+scheduling > In the first many sections, whenever scheduling is mentioned (sections = 2, > 2.2.3, 3.2.3), the wording suggests that indeed AQM and scheduling can > be complimentary and an algorithm might feasibly be a tightly coupled > hybrid. However, the section specifically dealing with scheduling = (4.4), > discussing adding scheduling "on top of" the algorithm is mentioned as = a > requirement, which might imply that an algorithm that already includes > (say) a tightly coupled scheduler would not be liable for = consideration? >=20 I will update the Section (4.4) considering that scheduling is a feature = of an AQM, and is not introduced "on top" of it. >=20 > Also, this paragraph: >=20 > Both schedulers and AQMs can be introduced when packet are either > enqued or dequed. If both schedulers and AQM are implemented when > packet are enqued, their interaction should not be a major issue. > However, if one is introduced when packets are enqued and the others > when they are dequed, there may be destructive interactions. >=20 > seems a bit speculative to me. Has the fact that the algorithms' > activation time is a predictor of adverse side effects actually been > demonstrated? >=20 The guidelines just mention that this MAY be destructive and this issue = should be carefully discussed.=20 >> The draft claims that the impact of every externally tuned parameter >> MUST be discussed. The tester SHOULD provide background material >> showing control theoretic analysis but COULD use other ways to = discuss >> stability. >=20 > That formulation would be fine with me. However, the last part of the > latter sentence (the COULD part) is missing from the draft... :) >=20 ACK Cheers,=20 Nicolas > -Toke > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Fri Feb 14 03:55:32 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 CCCA11A021F for ; Fri, 14 Feb 2014 03:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 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, MIME_HEADER_CTYPE_ONLY=0.717] 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 DcPK0JsBNL6D for ; Fri, 14 Feb 2014 03:55:28 -0800 (PST) Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) by ietfa.amsl.com (Postfix) with ESMTP id 78F8B1A0203 for ; Fri, 14 Feb 2014 03:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-kau.localdomain (Postfix, from userid 1000) id 18DEA5B87C; Fri, 14 Feb 2014 12:55:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1392378917; bh=c8MHgvb3RbS0y1ORirfasoc7guwNFuyxmYUZhpNlosY=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=j8yuEcHCAgzbF8qEH9DqNoP0C0sKMkwMycm0zKwKOVT/eLslmfrM4KlgPnxSsaQ0f Sfk+8SJMh3KRvH2xRRqG3ltOMNkRm+Owbfswla4maokEe3R7ipSfvafSbyvJrCzwAh bFqTSaQpTyOVnR/T/5f41bJRDk4G4V2Iz5Z16z8o= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Nicolas KUHN References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> <87vbwqiz3o.fsf@toke.dk> <92701763-5FA6-438F-98C1-E2E11EA366E7@telecom-bretagne.eu> <87wqgz2dw8.fsf@toke.dk> Date: Fri, 14 Feb 2014 12:55:13 +0100 In-Reply-To: (Nicolas KUHN's message of "Fri, 14 Feb 2014 10:55:04 +0100") Message-ID: <87ob293o4e.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/zEORMU0yr_xCVyYH0lz34-lJcBw Cc: Richard Scheffenegger , "aqm@ietf.org" Subject: Re: [aqm] [AQM Evaluation Guidelines] 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, 14 Feb 2014 11:55:31 -0000 --=-=-= Content-Type: text/plain Nicolas KUHN writes: > I believe the draft must be the most generic the possible. These > guidelines provide the tools and aspects that must be looked at, > however the AQM is tested. Even-driven simulations (such as in > NS-2,OMNET) enable to achieve an economical and fast protocol > experimentation [http://arxiv.org/pdf/1002.2827.pdf]. These guidelines > cannot reject a proposal because it has not been tested in the 'real' > world. Sure, I'm not saying simulation is not useful. I'm just saying it should not be the only evaluation of an algorithm. > I will add in the "methodology" section something about that issue, > saying that proposals SHOULD be evaluated in testbeds, and MAY be > evaluated with event-driven simulations to better understand their > internal behaviour. Great. Would add "reference implementation available" to that. :) > This is the kind of discussion that should be avoided in the draft. > Indeed, I am afraid we may open a "pandora's box" as we do not want to > list all the issues encountered by any evaluation tool set. Not all of them perhaps, but the most common, and those that apply generally across tool sets. > We may end discussing why choosing emulation, vs simulation, vs > mathematical model, vs real-workd experiment. A discussion that is sorely lacking, IMO :) >> ...case where latency is measured by a separate flow (such as a straight >> 'ping' alongside the test) vs directly measuring the queueing delay >> of the packets making up the traffic scenario; > > I think that this is more a metric linked to the evaluation tool set. > If we want the guidelines to be "generic" and "evaluation tool set" > free, this should not be discussed. My interest here was more to avoid comparing apples to oranges: the two different kinds of measurements can give widely varying results. As an example, a strict priority queue would give very good latency for flows alongside the main "elephant", but could completely starve the elephant itself. Which may be desirable in some cases: but distinguishing between different types of behaviour is important if we want to compare different algorithms fairly. And I think it is worth specifying that in the draft somewhere. > I am not sure that it makes sense here, that would be another > pandora's box: the guidelines should not consider every possible TCP > improvements. Otherwise, others would say "do you consider RENO? > CUBIC? Delay based CC?" or "what about MultiPath?". We must generic > and speak generally about TCP and UDP - without much more details. Well, the draft does mention CUBIC under "aggressive" senders. But if you don't want to enumerate all the permutations, some generic language (along the lines of "SHOULD be evaluated against the most commonly seen TCP variants deployed on the internet (for example, CUBIC, IW4, IW10, etc"). > Yes I updated the Section "Medium bandwidth, medium delay: Wi-Fi" so > that the tester may include "small time scales varying bandwidth" Right, better. Still not entirely sure that it is a good representation of wifi, but I'm not going to argue the point vehemently... :) > I agree as well - the draft would then need some rewording > > I will add an entry in the glossary explaining that by AQM, the draft > consider hybrid AQM+scheduling > > I will update the Section (4.4) considering that scheduling is a > feature of an AQM, and is not introduced "on top" of it. Great! >> seems a bit speculative to me. Has the fact that the algorithms' >> activation time is a predictor of adverse side effects actually been >> demonstrated? > > The guidelines just mention that this MAY be destructive and this > issue should be carefully discussed. Yeah, I was just puzzled by why specifically one configuration of activation time interaction is mentioned as potentially problematic, instead of just saying "potentially destructive interactions between AQM and scheduling should be accounted for" or somesuch. -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJS/gQhAAoJEENeEGz1+utPAK4H+wUCc6E+xmaWvDhBExFOkujN gWeCPduJoxkOYBsJha0WifgtY9LvkKYHOJ2YWkP7oRi8u6buuOY2Vsec+c6/fQCr bnvhiSFLP6EpXQ41qnVCO3OyIh9CgzPfE2LheuoyWF9FqCeiQMa/KkgLyNntXp3e T0wYb4K0HPP0R8YKPaTQQeLINA8J5QL01ApHtpDQtwWg8UmTAL54VAeGv4KaSRpl qU2mF0WYgOlsVS+dS5kvuYFzYSy2H5U4p7CBdKA+MOtZd5NFx4DLTHajlM6axbg9 vwedYf+pLZLbv2X5cjMzwfBmBdYJ5wL5z1x1uxuTolOosF0tIj2ws2LUd+ZYkJw= =ENHr -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 14 14:05:29 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 224D91A0145; Fri, 14 Feb 2014 14:05:17 -0800 (PST) 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 An1IALNasLGe; Fri, 14 Feb 2014 14:05:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD861A00BB; Fri, 14 Feb 2014 14:05:14 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214220514.29000.18063.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:05:14 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/TVEPHoLw7JAt0VPCGXBR6n1Cymk Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-recommendation-03.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, 14 Feb 2014 22:05:17 -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 : IETF Recommendations Regarding Active Queue Management Authors : Fred Baker Godred Fairhurst Filename : draft-ietf-aqm-recommendation-03.txt Pages : 23 Date : 2014-02-14 Abstract: This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. The note largely repeats the recommendations of RFC 2309, updated after fifteen years of experience and new research. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-aqm-recommendation-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-03 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 Sat Feb 15 04:10:36 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 818151A00D5 for ; Sat, 15 Feb 2014 04:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 hWdvn7r5vGQT for ; Sat, 15 Feb 2014 04:10:29 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 911341A01AD for ; Sat, 15 Feb 2014 04:10:29 -0800 (PST) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WEe4g-0007X6-3w; Sat, 15 Feb 2014 13:10:26 +0100 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WEe4f-0007MN-Ey; Sat, 15 Feb 2014 13:10:26 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_ABF572CD-7E0F-4999-8EC7-397CE1F6F9F2" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sat, 15 Feb 2014 13:10:24 +0100 Message-Id: <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 6 sum msgs/h 3 total rcpts 12603 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6F7D6AD33D49572F749FC0E131395C3A5518C730 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 921 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/sQSb_qqvDnsUAwK7ADdFmC1Dox8 Cc: "Scheffenegger, Richard" , "aqm@ietf.org" Subject: Re: [aqm] Draft Agenda for IETF89 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: Sat, 15 Feb 2014 12:10:33 -0000 --Apple-Mail=_ABF572CD-7E0F-4999-8EC7-397CE1F6F9F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 13. feb. 2014, at 20:40, Dave Taht wrote: > On Thu, Feb 13, 2014 at 2:24 PM, Scheffenegger, Richard = wrote: >> Hi, >>=20 >> The draft agenda for this IETF meeting in London has currently the = following >> points. >>=20 >> Please let me know if you disagree with the ordering, length or = anything >> else! >>=20 >> Best regards, >>=20 >> Richard Scheffenegger (aqm-chair) >>=20 >> = **************************************************************************= *********** >>=20 >> AQM Agenda >> IETF 89 in London, United Kingdom >> Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) >> ****************************************************** >>=20 >> WG status >> --------- >>=20 >> 14:20 >> Agenda bashing >> AQM status >> Chairs >> 10 min >>=20 >>=20 >> WG items >> -------- >>=20 >> 14:30 >> draft-ietf-aqm-recommendation >> Fred Baker / Gorry Fairhurst >> 10 min >>=20 >>=20 >> Charter items >> ------------- >>=20 >> 14:40 >> draft-fairhurst-ecn-motivation >> Gorry Fairhurst >> 15 min >=20 > This is apparently not a published draft yet. It's draft-welzl-ecn-benefits, = http://tools.ietf.org/html/draft-welzl-ecn-benefits-00 Cheers, Michael --Apple-Mail=_ABF572CD-7E0F-4999-8EC7-397CE1F6F9F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 dave.taht@gmail.com> = wrote:

On Thu, Feb 13, 2014 at 2:24 PM, Scheffenegger, Richard = <rs@netapp.com> = wrote:
Hi,

The draft agenda for this = IETF meeting in London has currently the = following
points.

Please let me know if you disagree with the = ordering, length or anything
else!

Best = regards,

Richard Scheffenegger = (aqm-chair)

*******************************************************= ******************************

AQM Agenda
IETF 89 in London, = United Kingdom
Tuesday, March 4, 2013, 14:20-15:50 BST = (Sovereign)
******************************************************
<= br>WG status
---------

14:20
Agenda bashing
AQM = status
Chairs
10 min


WG = items
--------

14:30
draft-ietf-aqm-recommendation
Fred = Baker / Gorry Fairhurst
10 min


Charter = items
-------------

14:40
draft-fairhurst-ecn-motivation
G= orry Fairhurst
15 min

This is apparently not a = published draft = yet.

It's draft-welzl-ecn-benefits,&nb= sp; http://too= ls.ietf.org/html/draft-welzl-ecn-benefits-00

= Cheers,
Michael

= --Apple-Mail=_ABF572CD-7E0F-4999-8EC7-397CE1F6F9F2-- From nobody Sun Feb 16 11:36:04 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 462CD1A025C for ; Sun, 16 Feb 2014 11:36:02 -0800 (PST) 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 vRql-du2MBvG for ; Sun, 16 Feb 2014 11:36:00 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7571A0262 for ; Sun, 16 Feb 2014 11:36:00 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id w5so20558195qac.17 for ; Sun, 16 Feb 2014 11:35:57 -0800 (PST) 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=t2R+CxdafF1Kg5VQlwVvW6Iu/aiUqymcdok85xGG2ng=; b=gMjL8V/pDB0xviGjZoqRBgpCIA+mg26z2NkmHw+0msMFeuHpsGX07l/Nj6a+bpsafy t3q3cYsgA8+ByDL9Wlc0+9nipJIgN8Ucqiobhs8DrU2r+ZRSRoXr4Djeh2CVmCTTjau8 rPsOkz1fdpQ1amJAaGPh6vtF6Y848UWVRYakrezPoww+H5JQVtX1ZsS8vIvBHk26vcQX pKB3mQFHBnD4OW6YO8FjhnkgFYNHnoEWePqi/j85jFAD+v46kh3thaJIxxDQrTkDjMZn SkeMKWaQTb38WAFHnnOLGJ/vbSD2XdRPgwMbRcVwp+Nyze5Trqy+JJAcaXU3c9rLEeIS 1mcQ== MIME-Version: 1.0 X-Received: by 10.224.115.78 with SMTP id h14mr2686092qaq.94.1392579357804; Sun, 16 Feb 2014 11:35:57 -0800 (PST) Received: by 10.224.27.133 with HTTP; Sun, 16 Feb 2014 11:35:57 -0800 (PST) In-Reply-To: <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> Date: Sun, 16 Feb 2014 14:35:57 -0500 Message-ID: From: Dave Taht To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/vCCDlRQKwhUghU7oKAYwSbUDgy0 Cc: "Scheffenegger, Richard" , "aqm@ietf.org" Subject: Re: [aqm] Draft Agenda for IETF89 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, 16 Feb 2014 19:36:02 -0000 On Sat, Feb 15, 2014 at 7:10 AM, Michael Welzl wrote: > 14:40 > draft-fairhurst-ecn-motivation > Gorry Fairhurst > 15 min > > > This is apparently not a published draft yet. > > > It's draft-welzl-ecn-benefits, > http://tools.ietf.org/html/draft-welzl-ecn-benefits-00 It describes the benefits of ECN persuasively and well. I would rather like a section discussing the negatives. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Mon Feb 17 01:21:07 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 91BF31A00DD for ; Mon, 17 Feb 2014 01:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 7ok7txwkMuFW for ; Mon, 17 Feb 2014 01:21:03 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE81A0061 for ; Mon, 17 Feb 2014 01:21:02 -0800 (PST) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WFKNm-0006JI-IR; Mon, 17 Feb 2014 10:20:58 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WFKNl-0005H9-Sg; Mon, 17 Feb 2014 10:20:58 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: Date: Mon, 17 Feb 2014 10:20:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> To: Dave Taht X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 14 sum msgs/h 8 total rcpts 12636 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 464B8BD4E756F2D8F14AA95A40D2EAD02755CB40 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 4487 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/nzwk1QfXNybfkBemVoLT0EodiFM Cc: "Scheffenegger, Richard" , "aqm@ietf.org" Subject: Re: [aqm] Draft Agenda for IETF89 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: Mon, 17 Feb 2014 09:21:06 -0000 On 16. feb. 2014, at 20:35, Dave Taht wrote: > On Sat, Feb 15, 2014 at 7:10 AM, Michael Welzl = wrote: >=20 >> 14:40 >> draft-fairhurst-ecn-motivation >> Gorry Fairhurst >> 15 min >>=20 >>=20 >> This is apparently not a published draft yet. >>=20 >>=20 >> It's draft-welzl-ecn-benefits, >> http://tools.ietf.org/html/draft-welzl-ecn-benefits-00 >=20 > It describes the benefits of ECN persuasively and well. Thanks!! > I would rather like a section discussing the negatives. We point to one problem in the introduction: "Following a recommendation in [RFC3168], which says: "for a router, the CE codepoint of an ECN- Capable packet SHOULD only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes", it has often been assumed that routers mark packets at the same level of congestion at which they would otherwise drop them (e.g. in [RFC2884]), but there are indications that this configuration is not ideal [KH13]." With this configuration, which is a common default, e.g. also in Linux = AFAIK, one sometimes gets more queue growth than without ECN because the = very packets that an AQM mechanism marks with ECN don't free queue space = (which they would do if they were dropped instead). However, even this = disadvantage has to be put against the advantages that we tried to list, = some of which can't be measured by looking at the delay of packets on = the wire (e.g., head-of-line blocking delay occurs in the receiver = buffer). Do you know about any other disadvantages? Cheers, Michael From nobody Mon Feb 17 06:40: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 305091A0213 for ; Mon, 17 Feb 2014 06:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 zj13ldhAF7MY for ; Mon, 17 Feb 2014 06:40:50 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA31A0211 for ; Mon, 17 Feb 2014 06:40:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,861,1384329600"; d="scan'208";a="102729790" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 17 Feb 2014 06:40:28 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 06:40:28 -0800 From: "Scheffenegger, Richard" To: Michael Welzl , Dave Taht Thread-Topic: [aqm] Draft Agenda for IETF89 Thread-Index: Ac8o8PonjUL7l8fiSvyG5Yr+JT+XLQARXzsAAFTfrwAAQdohgAAcz3uAAAZGxWA= Date: Mon, 17 Feb 2014 14:40:28 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F26068204@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.30] 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/EhG0iW3nDgu8HmmMXaYlcn6-qlQ Cc: "aqm@ietf.org" Subject: Re: [aqm] Draft Agenda for IETF89 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: Mon, 17 Feb 2014 14:40:52 -0000 Hi Michael, Gorry, in section 3.2, you state that "it exposes the presence of congestion". But ECN (on the IP layer) goes beyond that, and=20 can expose not only the presence, but also the extent of congestion. (It's just that very few transports have ways to carry that=20 extent back to the sender - speaking as co-author of=20 draft-kuehlewind-tcpm-accecn-reqs and=20 draft-kuehlewind-tcpm-accurate-ecn). > Do you know about any other disadvantages? I think the biggest issue is the interaction between ECN and non-ECN flows = (and packets; for TCP, only data segments are specified to optionally be EC= N-enabled, not pure ACKs, and other control segments (some are allowed as e= xperimental, i.e. SYN/ACK). If ECN would have been seen as universally good (back in the day), it is od= d that one L4 flow (TCP session) is constituted from both ECN- and non-ECN = segments during it's lifetime. The natural conclusion would be to assume that ECN on pure ACK, FIN, RST is= detrimental in some way (personally I tend to disagree; there may not be a= ny significant benefit, but it wouldn't break anything either - just the op= posite, pure ACKs would serve as probes into the congestion state of the re= turn path, once the data direction within the TCP flow reverses). But these points are transport specific;=20 However, guidance to transport protocol designers on the use of ECN with co= ntrol segments etc seems like it could be in scope for this document? In any case, to hash out the obvious, the interaction between ECN and non-E= CN is complex and seen as potentially problematic. That may account for a r= eal or perceived (depending on the AQM's use of ECN) problem with ECN... Richard Scheffenegger (individual contributor) > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Montag, 17. Februar 2014 10:21 > To: Dave Taht > Cc: Scheffenegger, Richard; aqm@ietf.org > Subject: Re: [aqm] Draft Agenda for IETF89 >=20 >=20 > On 16. feb. 2014, at 20:35, Dave Taht wrote: >=20 > > On Sat, Feb 15, 2014 at 7:10 AM, Michael Welzl > wrote: > > > >> 14:40 > >> draft-fairhurst-ecn-motivation > >> Gorry Fairhurst > >> 15 min > >> > >> > >> This is apparently not a published draft yet. > >> > >> > >> It's draft-welzl-ecn-benefits, > >> http://tools.ietf.org/html/draft-welzl-ecn-benefits-00 > > > > It describes the benefits of ECN persuasively and well. >=20 > Thanks!! >=20 >=20 > > I would rather like a section discussing the negatives. >=20 > We point to one problem in the introduction: > "Following a recommendation in > [RFC3168], which says: "for a router, the CE codepoint of an ECN- > Capable packet SHOULD only be set if the router would otherwise have > dropped the packet as an indication of congestion to the end nodes", > it has often been assumed that routers mark packets at the same level > of congestion at which they would otherwise drop them (e.g. in > [RFC2884]), but there are indications that this configuration is not > ideal [KH13]." >=20 > With this configuration, which is a common default, e.g. also in Linux > AFAIK, one sometimes gets more queue growth than without ECN because the > very packets that an AQM mechanism marks with ECN don't free queue space > (which they would do if they were dropped instead). However, even this > disadvantage has to be put against the advantages that we tried to list, > some of which can't be measured by looking at the delay of packets on the > wire (e.g., head-of-line blocking delay occurs in the receiver buffer). >=20 > Do you know about any other disadvantages? >=20 > Cheers, > Michael From nobody Mon Feb 17 06:42:05 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 E5D8C1A04EF for ; Mon, 17 Feb 2014 06:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 VTa7R_n9p-zt for ; Mon, 17 Feb 2014 06:42:02 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 439AF1A0213 for ; Mon, 17 Feb 2014 06:42:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,861,1384329600"; d="scan'208,217";a="143389954" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 17 Feb 2014 06:41:59 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 06:42:00 -0800 From: "Scheffenegger, Richard" To: Michael Welzl Thread-Topic: [aqm] Draft Agenda for IETF89 Thread-Index: Ac8o8PonjUL7l8fiSvyG5Yr+JT+XLQARXzsAAFTfrwAAWRJLUA== Date: Mon, 17 Feb 2014 14:41:58 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F2606829C@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> In-Reply-To: <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.30] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F2606829CSACEXCMBX02PRDh_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/xhbGRIpIOY6AjfvccTxZbbkTCts Cc: "aqm@ietf.org" Subject: Re: [aqm] Draft Agenda for IETF89 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: Mon, 17 Feb 2014 14:42:04 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F2606829CSACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for providing the correct draft name; I updated the agenda according= ly. Richard Scheffenegger (co-chair). Charter items ------------- 14:40 draft-fairhurst-ecn-motivation Gorry Fairhurst 15 min This is apparently not a published draft yet. It's draft-welzl-ecn-benefits, http://tools.ietf.org/html/draft-welzl-ecn-= benefits-00 --_000_012C3117EDDB3C4781FD802A8C27DD4F2606829CSACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

Thanks for providing the correc= t draft name; I updated the agenda accordingly.

 

Richard Sc= heffenegger (co-chair).

 

 

Charter items
-------------

14:40
draft-fairhurst-ecn-motivation
Gorry Fairhurst
15 min


This is apparently not a published draft yet.

 

It's draft-welzl-ecn-benef= its,  http://tools.ietf.org/html/draft-welzl-= ecn-benefits-00

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F2606829CSACEXCMBX02PRDh_-- From nobody Mon Feb 17 09:46: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 5CFD81A04E5 for ; Mon, 17 Feb 2014 09:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 GminchCoNkfC for ; Mon, 17 Feb 2014 09:46:32 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D31A0418 for ; Mon, 17 Feb 2014 09:46:31 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8EFD5C94C0; Mon, 17 Feb 2014 12:46:26 -0500 (EST) Date: Mon, 17 Feb 2014 12:46:26 -0500 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20140217174626.GL54716@verdi> References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> <012C3117EDDB3C4781FD802A8C27DD4F26068204@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F26068204@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/tQ3HUnZvuUWMAAuwLifJskcaY_s Cc: Dave Taht , Michael Welzl , "aqm@ietf.org" Subject: [aqm] draft-welzl-ecn-benefits 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: Mon, 17 Feb 2014 17:46:35 -0000 Scheffenegger, Richard wrote: > [Michael Welzl wrote:] > >> Do you know about any other disadvantages? While I believe discussion of disadvantages would help, I see a more fundamental question: "What modifications/extensions to RFC 3168 are appropriate to achieve the benefits being discussed?" (Of course, RFCs 4301 and 6040 discuss handling of ECN in tunnels; this much extension is hopefully a given.) > I think the biggest issue is the interaction between ECN and non-ECN > flows (and packets; I'm not quite sure what Richard means here -- there's an obvious question about one starving the other (and I do think that's an issue, but not quite a "disadvantage"). > for TCP, only data segments are specified to optionally be ECN-enabled, > not pure ACKs, and other control segments (some are allowed as > experimental, i.e. SYN/ACK). This is an obvious area for improvement; but I really can't see it as a "disadvantage" of ECN. > If ECN would have been seen as universally good (back in the day), > it is odd that one L4 flow (TCP session) is constituted from both > ECN- and non-ECN segments during it's lifetime. I don't see that as "odd" -- just "suboptimal". > The natural conclusion would be to assume that ECN on pure ACK, FIN, RST > is detrimental in some way (personally I tend to disagree; there may not > be any significant benefit, but it wouldn't break anything either - > just the opposite, pure ACKs would serve as probes into the congestion > state of the return path, once the data direction within the TCP flow > reverses). Again, an obvious area for improvement... > But these points are transport specific; Exactly! It makes very little sense to blame "ECN" for these issues. > However, guidance to transport protocol designers on the use of ECN > with control segments etc seems like it could be in scope for this > document? I don't agree. The Abstract says: " " This document describes the potential benefits to applications when " they enable Explicit Congestion Notification (ECN). which implies to me that it should discuss benefits regardless of the particular transport protocol (and I think it does). The document describes setting the ECT(0) or ECT(1) codepoint in the IP header and how routers may react to that. Not until Section 4 does it mention particular transports; and IMHO those are listed strictly as examples. I believe the document intentionally avoids questions about the design of transport protocols; and I think it should continue to avoid those. But the document _does_ mention several times the desirability of ECN-marking packets which would not otherwise be dropped. I quite agree that is desirable; but it is a fundamental change to RFC 3168; and I think we need to justify it considerably more than this document does. This will not be a trivial change to deploy. It will indeed require deployment in routers and transport stacks, but the question is quite independent of the transport _protocols_ -- and I strongly suggest we don't confuse the two. -- John Leslie From nobody Mon Feb 17 13:28:25 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 2AB521A0295 for ; Mon, 17 Feb 2014 13:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 776QURgOmLeq for ; Mon, 17 Feb 2014 13:28:21 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id CB3721A028A for ; Mon, 17 Feb 2014 13:28:20 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id AF5362B40D1; Mon, 17 Feb 2014 21:28:15 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 17 Feb 2014 21:28:15 -0000 Message-ID: In-Reply-To: <20140217174626.GL54716@verdi> References: <012C3117EDDB3C4781FD802A8C27DD4F2605812E@SACEXCMBX02-PRD.hq.netapp.com> <9CFAC2B4-BFBE-4A8A-9AAC-9495B3A2EAC6@ifi.uio.no> <012C3117EDDB3C4781FD802A8C27DD4F26068204@SACEXCMBX02-PRD.hq.netapp.com> <20140217174626.GL54716@verdi> Date: Mon, 17 Feb 2014 21:28:15 -0000 From: gorry@erg.abdn.ac.uk To: "John Leslie" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/DoZXSC16yuQmlh3R4F4BhEZOZkI Cc: "Scheffenegger, Richard" , Dave Taht , Michael Welzl , "aqm@ietf.org" Subject: Re: [aqm] draft-welzl-ecn-benefits 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: Mon, 17 Feb 2014 21:28:24 -0000 I have a few responses in-line: > Scheffenegger, Richard wrote: >> [Michael Welzl wrote:] >> >>> Do you know about any other disadvantages? > > While I believe discussion of disadvantages would help, I see a more > fundamental question: > > "What modifications/extensions to RFC 3168 are appropriate to achieve > the benefits being discussed?" > > (Of course, RFCs 4301 and 6040 discuss handling of ECN in tunnels; > this much extension is hopefully a given.) > That's a good topic - but that's surely one for tsvwg if you are suggesting a change to ECN. >> I think the biggest issue is the interaction between ECN and non-ECN >> flows (and packets; > > I'm not quite sure what Richard means here -- there's an obvious > question about one starving the other (and I do think that's an issue, > but not quite a "disadvantage"). > I think maybe we are off-topic for the draft I was envisaging - which was "what are all the things that ECN can offer to applications". >> for TCP, only data segments are specified to optionally be ECN-enabled, >> not pure ACKs, and other control segments (some are allowed as >> experimental, i.e. SYN/ACK). > > This is an obvious area for improvement; but I really can't see it as > a "disadvantage" of ECN. > I'm lost here too about the issue, unless you mean that packets may be queued separately when ECN is enabled and this results in a flow being in multiple queues - is that what you mean? >> If ECN would have been seen as universally good (back in the day), >> it is odd that one L4 flow (TCP session) is constituted from both >> ECN- and non-ECN segments during it's lifetime. > > I don't see that as "odd" -- just "suboptimal". > Is this the same as above? >> The natural conclusion would be to assume that ECN on pure ACK, FIN, RST >> is detrimental in some way (personally I tend to disagree; there may not >> be any significant benefit, but it wouldn't break anything either - >> just the opposite, pure ACKs would serve as probes into the congestion >> state of the return path, once the data direction within the TCP flow >> reverses). > > Again, an obvious area for improvement... > >> But these points are transport specific; > > Exactly! It makes very little sense to blame "ECN" for these issues. > >> However, guidance to transport protocol designers on the use of ECN >> with control segments etc seems like it could be in scope for this >> document? > > I don't agree. > I think this is something that needs to be done when we update ECN - should tsvwg decide to do this - my hope was that this ID would be useful to people designing apps/networks - not transport protocol people. > The Abstract says: > " > " This document describes the potential benefits to applications when > " they enable Explicit Congestion Notification (ECN). > > which implies to me that it should discuss benefits regardless of the > particular transport protocol (and I think it does). > > The document describes setting the ECT(0) or ECT(1) codepoint in the > IP header and how routers may react to that. Not until Section 4 does > it mention particular transports; and IMHO those are listed strictly > as examples. > > I believe the document intentionally avoids questions about the > design of transport protocols; and I think it should continue to avoid > those. > OK - that's what we were thinking. > But the document _does_ mention several times the desirability of > ECN-marking packets which would not otherwise be dropped. > > I quite agree that is desirable; but it is a fundamental change to > RFC 3168; and I think we need to justify it considerably more than > this document does. This will not be a trivial change to deploy. > > It will indeed require deployment in routers and transport stacks, > but the question is quite independent of the transport _protocols_ -- > and I strongly suggest we don't confuse the two. > This probably lies in a different document - but that is not to say we shouldn't progress the two ideas in parallel if both are good. > -- > John Leslie > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > Gorry From nobody Tue Feb 18 08:50:09 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 A58EC1A04CB for ; Tue, 18 Feb 2014 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548] 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 jF6r35HlED5Z for ; Tue, 18 Feb 2014 08:50:06 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E84191A0518 for ; Tue, 18 Feb 2014 08:50:01 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s1IGnvsM001652; Tue, 18 Feb 2014 09:49:58 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 18 Feb 2014 09:49:57 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 09:49:57 -0700 From: Greg White To: "Eggert, Lars" Thread-Topic: [aqm] PIE & CableLabs Thread-Index: AQHO3MAAFFH8PuCBIk6ZSa6cse1IYpobvoAAgACfOoCAn3usgA== Date: Tue, 18 Feb 2014 16:49:56 +0000 Message-ID: References: <17BA4215-B855-4424-9D8C-FCFE11A1849E@netapp.com> In-Reply-To: <17BA4215-B855-4424-9D8C-FCFE11A1849E@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/wVMRqRKTTkbDEBum75IP-ex5MzI Cc: "aqm@ietf.org" , Ralph Droms Subject: Re: [aqm] PIE & CableLabs 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, 18 Feb 2014 16:50:07 -0000 On 11/8/13, 2:22 PM, "Eggert, Lars" wrote: >Hi, > >On 08 Nov 2013, at 12:52, Greg White wrote: >>3) Probably not directly. We have requested that Cisco update the PIE I-D >> to include the updates to the core PIE algorithm made as part of the >> CableLabs evaluation. CableLabs will draft an I-D to cover the remaining >> gaps between that and what can be found in 1. I think this achieves >>what >> you are after. Let me know if not. > >That sounds like pretty good plan. > Lars, all, As per the discussion last November, I've completed and submitted a first draft of the I-D describing the usage of the PIE AQM in DOCSIS 3.0 & 3.1. Name: draft-white-aqm-docsis-pie Revision: 00 Title: A PIE-Based AQM for DOCSIS Cable Modems Document date: 2014-02-14 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-white-aqm-docsis-pie-00.txt Status: https://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/ Htmlized: http://tools.ietf.org/html/draft-white-aqm-docsis-pie-00 I'm interested in feedback on the draft, please review and provide comments. Best Regards, Greg From nobody Wed Feb 19 00:24:08 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 11ADE1A0100 for ; Wed, 19 Feb 2014 00:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 ax8JLG0x4Tq2 for ; Wed, 19 Feb 2014 00:24:06 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 281531A0074 for ; Wed, 19 Feb 2014 00:24:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,504,1389772800"; d="asc'?scan'208";a="71720472" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx2-out.netapp.com with ESMTP; 19 Feb 2014 00:24:02 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 00:24:01 -0800 From: "Eggert, Lars" To: Greg White Thread-Topic: [aqm] PIE & CableLabs Thread-Index: AQHO3MAAFFH8PuCBIk6ZSa6cse1IYpobvoAAgACfOoCAn3usgIABixiA Date: Wed, 19 Feb 2014 08:24:00 +0000 Message-ID: References: <17BA4215-B855-4424-9D8C-FCFE11A1849E@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.21] Content-Type: multipart/signed; boundary="Apple-Mail=_535B873A-4DD0-44AA-BC2B-FFFAAD7209DF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/ZvaLwKDRkKRFgbEbWel4F1vlWi0 Cc: "aqm@ietf.org" , Ralph Droms Subject: Re: [aqm] PIE & CableLabs 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: Wed, 19 Feb 2014 08:24:08 -0000 --Apple-Mail=_535B873A-4DD0-44AA-BC2B-FFFAAD7209DF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Great, thank you Greg & Rong! On 2014-2-18, at 17:49, Greg White wrote: > On 11/8/13, 2:22 PM, "Eggert, Lars" wrote: > >> Hi, >> >> On 08 Nov 2013, at 12:52, Greg White wrote: >>> 3) Probably not directly. We have requested that Cisco update the PIE I-D >>> to include the updates to the core PIE algorithm made as part of the >>> CableLabs evaluation. CableLabs will draft an I-D to cover the remaining >>> gaps between that and what can be found in 1. I think this achieves >>> what >>> you are after. Let me know if not. >> >> That sounds like pretty good plan. >> > > > Lars, all, > > As per the discussion last November, I've completed and submitted a first > draft of the I-D describing the usage of the PIE AQM in DOCSIS 3.0 & 3.1. > > > Name: draft-white-aqm-docsis-pie > Revision: 00 > Title: A PIE-Based AQM for DOCSIS Cable Modems > Document date: 2014-02-14 > Group: Individual Submission > Pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-white-aqm-docsis-pie-00.txt > Status: https://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/ > Htmlized: http://tools.ietf.org/html/draft-white-aqm-docsis-pie-00 > > > I'm interested in feedback on the draft, please review and provide > comments. > > Best Regards, > Greg > > --Apple-Mail=_535B873A-4DD0-44AA-BC2B-FFFAAD7209DF 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----- iQCVAwUBUwRqIdZcnpRveo1xAQKEXgP9Getvy/E8k9yaNSsqeCcKTn8qPNZnXUfC 9O+Gaz3NwuOTmv91LOEzmvb+ZisJQgXYAke/bcwnF7ytvC2rCZS+ik4r9UcJja+/ vfn6cNY05be7V1M110ZS+IqpECRACHH2+Ov4dBmSW1vTbETD4ZBOcFFpJpa7Idsm hqMHpzbSVcE= =Dlds -----END PGP SIGNATURE----- --Apple-Mail=_535B873A-4DD0-44AA-BC2B-FFFAAD7209DF-- From nobody Wed Feb 19 21:48:26 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 C99831A0618 for ; Wed, 19 Feb 2014 21:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 37JBFyMWTGO8 for ; Wed, 19 Feb 2014 21:48:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 715401A0263 for ; Wed, 19 Feb 2014 21:48:18 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1K5mDGg001305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Feb 2014 23:48:14 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s1K5m9LK011667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 00:48:13 -0500 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.249]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 20 Feb 2014 00:48:11 -0500 From: "Akhtar, Shahid (Shahid)" To: Nicolas KUHN Thread-Topic: [aqm] [AQM Evaluation Guidelines] Thread-Index: AQHPI/vv+zus/j21DEyix0k6ny5Bdpq9rpdg Date: Thu, 20 Feb 2014 05:48:10 +0000 Message-ID: References: <52CDAAF7.2060307@mti-systems.com> <012C3117EDDB3C4781FD802A8C27DD4F2602EB77@SACEXCMBX02-PRD.hq.netapp.com> <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> In-Reply-To: <0D6E78FE-D859-4C44-8611-7966FA1D3859@telecom-bretagne.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/4oZTUdYD4VLypI6EybholetJdes Cc: Richard Scheffenegger , "aqm@ietf.org" Subject: Re: [aqm] [AQM Evaluation Guidelines] 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, 20 Feb 2014 05:48:24 -0000 Hi Nicholas and other authors, Thank you for producing this document. I had some (long) comments where I h= ave also suggested some solutions/text, hopefully you find them helpful. Wh= en quoting from the document, I have used quotes and I have listed my comme= nts as 1-4. 1. The number of tests recommended per AQM scheme seems to be quite large a= s well as many tests that may be best done together are done independently. For example, there are different tests for fairness between flows (section = 3.2.3), level of traffic (mild, medium, heavy) (section 3.2.4), different t= ypes of bursty traffic (3.2.2) and different network environments (section = 3.3). In order to obtain a realistic estimate of AQM comparison, many of th= ese effects may need to be tested together. For example to increase level o= f traffic (in section 3.2.4) only long term TCP flows of 50s are proposed. = It would be better to test the level of congestion with realistic traffic (= and with realistic proportions) as proposed in section 3.2.4. Another examp= le would be to test fairness between flows of same type - e.g. long term TC= P flows when multiple types of TCP flows are present at a AQM controlled bu= ffer or test fairness between flows of different types - e.g. long term TCP= flows and web flows.=20 I noticed that in section 3.3 different network environments are mentioned.= I suggest that tests with appropriate realistic traffic be done on each of= these enviroments with various levels of congestion. One could measure fai= rness from these tests without the need for additional tests. This may have= the benefit of reducing overall number of tests as well. 2. There are four network enviroments mentioned in the document (section 3.= 3): Wifi - in home network. Data-Center communications. BB wireless/satellite. Low and high buffers This is a good set, however, recommed to add: Access networks - and further split access networks into DSL/FTTH networks = and Cable access networks. Cable access networks may have much larger numbe= r of flows than DSL/FTTH since they are shared by a large number of custome= rs There is another type of network environment - narrowband wireless (mobile)= networks where the AQM could be placed on the eNodeB, but perhaps this is = a complicated scenario, and best left for later or in another document. 3. I noticed that the modeling of different types of realistic traffic coul= d be made more accurate (section 3.2.2) "Bulk TCP transfer: (continuous file transmission, or repeating 5MB file tr= ansmission);" The largest type of traffic on the Internet that uses bulk TCP - or large f= iles via TCP is progressive download. The average speed of a Youtube video = is over 3Mbps and it is on average 4.5 minutes long - so the average file s= ize is considerably larger than 5MB. We have used an average of 38MB assumi= ng 480p video and 4.5 minutes for some of our experiments. The inter-arriva= l time of these files should have a realistic random distribution as well a= s size of the files.=20 "Realistic HTTP web traffic (repeated download of 700kB);" According to statistics that Google collected from 2010 about web traffic, = the average GET file size for web traffic was only 7KB. It is very importan= t to have the size of these files correct since AQMs can help transfers of = small files when large file downloads are also occurring. The effect of AQM= on a 7KB file would be very different than on a 700KB file. Web traffic al= so has a complex inter-arrival time relationship between the GET requests a= s well as the pages that produce these GET requests. However to make the te= sting simpler, a repeated download of a 7KB file with a Pareto distributed = size and Pareto distributed inter-arrival time may be an OK compromise. I noticed that adaptive streaming is not modelled as a type of realistic tr= affic. It is probably the most important and largest flow on the Internet t= oday - if we look at a recent Sandvine report of Internet traffic, about 75= % of Internet traffic is real-time entertainment of which the largest compo= nent is adaptive streaming based video traffic. In order to simulate adapti= ve streaming traffic, one would need a client that changes video quality ra= tes. To keep testing simpler, an option may be to generate realistic chunk = sized files at regular intervals. Average netflix speeds are around 2Mbps. = Typical chunk sizes range from 2s to 10s, but 4s may be a good average. The= chunk sizes should be varied with some random distribution as is typically= observed from real codecs.=20 4. In section 2.2.5, QoE metrics are mentioned. It may be valuable to spell= out some standard models or expressions to derive QoE from network paramet= ers so that these QoE can be compared between AQMs. In the literature there= is work that derives closed form expressions for QoE. The following are ex= amples and suggestions: Video - the work by Johan de Vriendt et al , "Model for estimating QoE of V= ideo delivered using HTTP Adaptive Streaming", IFIP/IEEE Workshop on QoE Ce= ntric Management, May 2013 may be useful here. The authors used over 500 sa= mples to derive their a closed form expressions. The authors derive the MOS= =3D alpha*(average bit rate) + beta*(standard deviation of bit rates) + si= gma*(no of bit rate switches) + gamma and then produce good values for alph= a, beta, sigma and gamma. Voice - The work in "Voice quality prediction models and their application = in VoIP networks" by L. Sun et al has closed form expressions for MOS score= s for most commercial codes. They derive a long closed form expression with= parameters a-j for key codecs (and then provide a-j for most commercial co= decs) based on end-to-end and packet loss. =20 Web - The delay for one average web GET file could be used as the represent= ative for the page load time Key metric for AQMs on access networks may be QoE since it provides and end= -user view. We have seen that often the absolute goodput does not matter as= much as the stability of the flow for Video (which tends to be the dominan= t traffic). Larger goodput may provide higher VQ levels for Video, but if h= igher volatility is also produced then that higher VQ level may not produce= a higher QoE. On the other hand, best metrics inter data center traffic may be goodput an= d delay since most of that traffic is likely to be inter machine traffic. Best regards, Shahid Akhtar. -----Original Message----- From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Nicolas KUHN Sent: Friday, February 07, 2014 5:58 AM To: Richard Scheffenegger Cc: aqm@ietf.org Subject: [aqm] [AQM Evaluation Guidelines] Dear all,=20 On the behalf of the contributors to the AQM Evaluation Guidelines, I encou= rage active discussion on the draft that we have written.=20 I just submitted the draft as an individual draft to the I-D Submission Too= l [0]. Please let us know what you think of the current document.=20 Kind regards,=20 Nicolas KUHN [0] http://datatracker.ietf.org/doc/draft-kuhn-aqm-eval-guidelines/ On Feb 5, 2014, at 10:01 PM, "Scheffenegger, Richard" wrote= : > Hi, >=20 > a new month, a new status report. >=20 > First of all, Wes and I as chairs would like to thank the editors who hav= e stepped forward to work on the AQM Evaluation Guideline draft. We are rea= lly thankful for their burst of efforts in the last couple weeks! >=20 > We expect that that a document will be ready for submission into the I-D = repository well before cutoff, as an individual draft, so that the WG can s= ee what the state of thinking is currently. Also, once the document is publ= ished on datatracker we'd like to encourage active discussion on it. >=20 > If the submitted -00 draft is felt to have a fairly complete outline of w= hat the current thinking in the WG is, we may be able to ask the WG for for= mal adoption during this IETF meeting, or shortly thereafter. >=20 >=20 >=20 >=20 > - WG Milestones: > - Submit AQM recommendations to IESG for publication, obsoleting RFC > 2309 (Goal: January 2014) > - draft-ietf-aqm-recommendation is accepted towards this milestone > - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ > - the draft has been updated per comments received > - if the authors are comfortable, a WGLC might be made on the next=20 > revision > - we would like to hear from other authors of RFC 2309 on this=20 > document, if anyone has contacts to them. >=20 >=20 > - Submit AQM algorithm evaluation guidelines to IESG for publication=20 > as Informational (Goal: July 2014) > - An editor team has come forth and is working on this > - A draft should be available for discussion in the London IETF > - We encourage discussion on the list and during the meeting, if this= =20 > draft should be adopted by the working group. >=20 > - Submit first algorithm specification to IESG for publication as=20 > Proposed Standard (Goal: December 2014) > - Since any Proposed Standard algorithm should be in line with the=20 > recommendations and be passable versus the evaluation guidelines, this=20 > milestone is dependend on the progress of the two work items above. > - Currently the only algorithm spec with a complete and active=20 > individual-submission draft is PIE >=20 > - Other items: > - draft-pan-aqm-pie is under active work as a proposed algorithm: > http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the draft > has expired and should be refreshed. > - draft-nichols-tsvwg-codel is expired; Dave Taht or others may=20 > revive it and/or describe pairing with FQ/SFQ algorithms: > http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt > - Other algorithm specifications are welcome! > - Though, we are not planning on adopting algorithms until=20 > recommendations and evaluation guidelines are mostly stable >=20 >=20 > Richard Scheffenegger >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm From nobody Thu Feb 20 12:36:56 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 8E6AA1A02D3 for ; Thu, 20 Feb 2014 12:36:55 -0800 (PST) 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 fRwlJ8RYhPKS for ; Thu, 20 Feb 2014 12:36:53 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5751A02D1 for ; Thu, 20 Feb 2014 12:36:53 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so1849313wgg.13 for ; Thu, 20 Feb 2014 12:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=gRUOg+nsjRaDYvHUop7FoRRBiqdsGd4jTml7Nr+/ZF4=; b=aPpm3Hm9JG7y3UJ1xKRdEsYIcrvTgvcgGXBMV38SI+igaNTTBgCAeiFD41bb08C4wf TzszVXZdm2+vUqF04Q8lDcDuC5m7tVoBeuAuvr9SKjALlcNsnHjCYJ0EYoDVVeefV7JJ eYo0shC+gJcgaG1AcN0x7Z7V1hrJJ2DPFFXMkICMTn/gCmA7ycNeb1wBDoZw+eI0/71o heIYG8imi/Dj7430+666W4mHY+UVZdMhhD97rsaxfBa0N5AdBuiDSk1Fj+3yc1HH2E9q IlbK/bNrLEVFz/Ib0WHs7wHR8cEj9nQdMHk21ZmNIGC4QtPp+PpDKkjpVTLPnZJTQz5w qmhQ== MIME-Version: 1.0 X-Received: by 10.180.206.172 with SMTP id lp12mr192914wic.46.1392928609193; Thu, 20 Feb 2014 12:36:49 -0800 (PST) Received: by 10.216.8.1 with HTTP; Thu, 20 Feb 2014 12:36:49 -0800 (PST) Date: Thu, 20 Feb 2014 15:36:49 -0500 Message-ID: From: Dave Taht To: "aqm@ietf.org" , bloat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/NGClGLIQiwJyp95UwKIL_REmqoQ Subject: [aqm] Arris thoughts on bufferbloat in the CMTS 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, 20 Feb 2014 20:36:55 -0000 I finally got my SCTE proceedings today. In there were a presentation and paper by Arris's CTO and several of his senior engineers... http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Presentation.pdf There are some very good ideas and analysis in here, a nice enhancement to SFQ easily implementable in hardware, and a new version of RED, called "LRED". In a first reading, there are a few things I quibble with (they missed the SQF-like portion of fq_codel entirely, for example), but it is really nice to have seen Jim's paper go from "so-called" in 2011, to "seminal" in 2013. These are worth reading thoroughly. I will wait until saturday to comment further. --=20 Dave T=E4ht From nobody Fri Feb 21 03:17:03 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 61BF21A0510 for ; Fri, 21 Feb 2014 03:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, 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 IFgwOm3W2euX for ; Fri, 21 Feb 2014 03:17:00 -0800 (PST) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 42FBD1A051E for ; Fri, 21 Feb 2014 03:16:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id C2B3A66028 for ; Fri, 21 Feb 2014 12:16:49 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+kfH21fMNk9 for ; Fri, 21 Feb 2014 12:16:49 +0100 (CET) Received: from [IPv6:2001:660:7301:3728:dd93:b27c:3a52:d946] (passerellev6v4.enst-bretagne.fr [192.108.117.5]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 8399A6601E for ; Fri, 21 Feb 2014 12:16:49 +0100 (CET) From: Nicolas KUHN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <289636E3-8327-4A40-8FB9-8E7CB0719481@telecom-bretagne.eu> Date: Fri, 21 Feb 2014 12:16:49 +0100 To: "aqm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/mqQxX00CsZJ9lmtO45S_vY9bp2g Subject: [aqm] [NS-2 implementation of AQMs] 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, 21 Feb 2014 11:17:02 -0000 Dear all,=20 We have a question regarding the NS-2 implementations of RED, CoDel, PIE = and others AQMs. Especially, we believe that the way buffer-overflows = are managed is not the same for each AQM scheme. In "Multimedia-unfriendly TCP Congestion Control and Home Gateway Queue = Management" (L. Stewart et al.) details that : "PS: The queue is packet (slot) based, and the maximum queue length is = specified as an integer number of packets: if (NumPktsInQ =E2=89=A5 PktQueueLength) drop incoming packet" However:=20 1- In droptail.cc: if((q_->length() + 1) >=3D qlim_) buffer overflow is = detected 2- In RED/PIE/CoDel/etc.: if((q_->length() >=3D qlim_) buffer overflow = is detected In the case of RED/PIE, when there are buffer overflows, the incoming = packet may not be dropped. As a result, the incoming packet needs to be = stored before the other packet is selected for drop: if((q_->length() >=3D= qlim_) should be avoided - and if((q_->length() + 1) >=3D qlim_) = preferred.=20 In the case of CoDel, when there are buffer overflows, the incoming = packets are dropped. if((q_->length() >=3D qlim_) is a good solution. Anyway, the authors of "Multimedia-unfriendly TCP Congestion Control and = Home Gateway Queue Management" (L. Stewart et al.) illustrate the impact = of this setting that should be carefully discussed. This point is of = interest while comparing the performance of various AQM schemes with = NS-2.=20 We believe that AQMs that need information about incoming packets before = tail-dropping them MUST detect buffer over flow when if((q_->length() + = 1) >=3D qlim_). Any thoughts?=20 Kind regards,=20 Amadou B. Bagayoko & Nicolas Kuhn From nobody Fri Feb 21 04:10:57 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 A2BF21A00AE for ; Fri, 21 Feb 2014 04:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 GkmfFYDHgw7V for ; Fri, 21 Feb 2014 04:10:52 -0800 (PST) Received: from courier.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439271A0524 for ; Fri, 21 Feb 2014 04:10:51 -0800 (PST) Received: from whp-28.cs.helsinki.fi (whp-28.cs.helsinki.fi [128.214.9.97]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Feb 2014 14:10:31 +0200 id 00068139.53074237.00004FBF Date: Fri, 21 Feb 2014 14:10:31 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whp-28.cs.helsinki.fi To: Nicolas KUHN In-Reply-To: <289636E3-8327-4A40-8FB9-8E7CB0719481@telecom-bretagne.eu> Message-ID: References: <289636E3-8327-4A40-8FB9-8E7CB0719481@telecom-bretagne.eu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1403875796-1392984631=:19922" X-CS-Test-DKIM: none Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/gzeDU7Hbm01jv841wB4a1hn09tU Cc: "aqm@ietf.org" Subject: Re: [aqm] [NS-2 implementation of AQMs] 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, 21 Feb 2014 12:10:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1403875796-1392984631=:19922 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT On Fri, 21 Feb 2014, Nicolas KUHN wrote: > We have a question regarding the NS-2 implementations of RED, CoDel, PIE > and others AQMs. Especially, we believe that the way buffer-overflows > are managed is not the same for each AQM scheme. > > In "Multimedia-unfriendly TCP Congestion Control and Home Gateway Queue > Management" (L. Stewart et al.) details that : > "PS: The queue is packet (slot) based, and the maximum queue length is > specified as an integer number of packets: > if (NumPktsInQ ≥ PktQueueLength) > drop incoming packet" > > However: > 1- In droptail.cc: if((q_->length() + 1) >= qlim_) buffer overflow is > detected > 2- In RED/PIE/CoDel/etc.: if((q_->length() >= qlim_) buffer overflow is > detected > > In the case of RED/PIE, when there are buffer overflows, the incoming > packet may not be dropped. As a result, the incoming packet needs to be > stored before the other packet is selected for drop: if((q_->length() >= > qlim_) should be avoided - and if((q_->length() + 1) >= qlim_) preferred. > > In the case of CoDel, when there are buffer overflows, the incoming > packets are dropped. if((q_->length() >= qlim_) is a good solution. > > Anyway, the authors of "Multimedia-unfriendly TCP Congestion Control and > Home Gateway Queue Management" (L. Stewart et al.) illustrate the impact > of this setting that should be carefully discussed. This point is of > interest while comparing the performance of various AQM schemes with > NS-2. > > We believe that AQMs that need information about incoming packets before > tail-dropping them MUST detect buffer over flow when if((q_->length() + > 1) >= qlim_). > Any thoughts? While doing some tests with RED using ns2 in the past, I noticed this same difference. I patched ns2 RED to get equal behavior (patch attached but it probably breaks some of the ns2 tests which is why I didn't consider trying to upstream it). -- i. --8323329-1403875796-1392984631=:19922 Content-Type: TEXT/x-diff; name=0001-Change-size-to-match-fifo-behavior.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=0001-Change-size-to-match-fifo-behavior.patch W1BBVENIIDEvMV0gQ2hhbmdlIHNpemUgdG8gbWF0Y2ggZmlmbyBiZWhhdmlv cg0KDQotLS0NCiBxdWV1ZS9yZWQuY2MgfCAgICA0ICsrKy0NCiAxIGZpbGUg Y2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQoNCmRp ZmYgLS1naXQgYS9xdWV1ZS9yZWQuY2MgYi9xdWV1ZS9yZWQuY2MNCmluZGV4 IDVhOWMyOTIuLmJlM2U0ZGIgMTAwNjQ0DQotLS0gYS9xdWV1ZS9yZWQuY2MN CisrKyBiL3F1ZXVlL3JlZC5jYw0KQEAgLTY4Niw2ICs2ODYsOCBAQCB2b2lk IFJFRFF1ZXVlOjplbnF1ZShQYWNrZXQqIHBrdCkNCiAJaW50IGRyb3B0eXBl ID0gRFRZUEVfTk9ORTsNCiAJaW50IHFsZW4gPSBxaWJfID8gcV8tPmJ5dGVM ZW5ndGgoKSA6IHFfLT5sZW5ndGgoKTsNCiAJaW50IHFsaW0gPSBxaWJfID8g KHFsaW1fICogZWRwXy5tZWFuX3BrdHNpemUpIDogcWxpbV87DQorCS8qIFRv IG1ha2UgYnVmZmVyIGVxdWFsIHRvIEZJRk8gYmVoYXZpb3IgKi8NCisJaW50 IHFsZW5hZnRlciA9IHFsZW4gKyAocWliXyA/IGNoLT5zaXplKCkgOiAxKTsN CiANCiAJY3VycV8gPSBxbGVuOwkvLyBoZWxwcyB0byB0cmFjZSBxdWV1ZSBk dXJpbmcgYXJyaXZhbCwgaWYgZW5hYmxlZA0KIA0KQEAgLTcxMiw3ICs3MTQs NyBAQCB2b2lkIFJFRFF1ZXVlOjplbnF1ZShQYWNrZXQqIHBrdCkNCiAJCWVk dl8udl9wcm9iID0gMC4wOw0KIAkJZWR2Xy5vbGQgPSAwOwkJDQogCX0NCi0J aWYgKHFsZW4gPj0gcWxpbSkgew0KKwlpZiAocWxlbmFmdGVyID49IHFsaW0p IHsNCiAJCS8vIHNlZSBpZiB3ZSd2ZSBleGNlZWRlZCB0aGUgcXVldWUgc2l6 ZQ0KIAkJZHJvcHR5cGUgPSBEVFlQRV9GT1JDRUQ7DQogCX0NCi0tIA0KMS43 LjkuNQ0KDQo= --8323329-1403875796-1392984631=:19922-- From nobody Fri Feb 21 06:52:43 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 939681A0179 for ; Fri, 21 Feb 2014 06:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 B0gRlmnlPJjY for ; Fri, 21 Feb 2014 06:52:37 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A54861A018D for ; Fri, 21 Feb 2014 06:52:37 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id i57so2402229yha.32 for ; Fri, 21 Feb 2014 06:52:33 -0800 (PST) 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=lu2a5SVoioU6KOKVVUOLgC7Wt5Ifp84pLELjDPfQqo4=; b=UiJPHX3iA0hSbsvmzACbu6B76hn6xPodM4teUVRMBaKWXpuF0tx6NFyUpZBAFKhhwN nZKrcPpMXHnvVDqSttJckwDjzv1xqFPqlOKaig9CRgCUh2DYtAjkrFlSEd2buIx6I1GV 2EKe3Ce7lIiErr63eKm6rbJ8cOxcpPCSZOk2nyYPOIJmrb5Hn7ktlDx57Dzlu+13gc6M 4ac4Pdm6L+zYDVfJ0GFFkMwqtm7SWbCSScqCIyq0gGZ8G/8e5XUsxD7llp/i1sHxpi/R OeOFmjKzoXSah5EL9uiHzaZTBoBucSdRp/M2IcaswrZJ8Ajmhe12wE4/p2wpT/EAmO/z NKOw== MIME-Version: 1.0 X-Received: by 10.236.143.148 with SMTP id l20mr11549304yhj.102.1392994353616; Fri, 21 Feb 2014 06:52:33 -0800 (PST) Received: by 10.170.53.205 with HTTP; Fri, 21 Feb 2014 06:52:33 -0800 (PST) In-Reply-To: References: <289636E3-8327-4A40-8FB9-8E7CB0719481@telecom-bretagne.eu> Date: Fri, 21 Feb 2014 15:52:33 +0100 Message-ID: From: Naeem Khademi To: =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/UObRONnQXVviDla1X-Wz8h0llBc Cc: Nicolas KUHN , "aqm@ietf.org" Subject: Re: [aqm] [NS-2 implementation of AQMs] 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, 21 Feb 2014 14:52:39 -0000 Nicolas, Good catch although I tend to think that the impact of this would be more visible on FIFO/DropTail queues; with an AQM presumably set at a low threshold this impact will probably be less profound (although depending on too many other factors, such as the load, multiplexing level, BDP, etc). Naeem On Fri, Feb 21, 2014 at 1:10 PM, Ilpo J=C3=A4rvinen wrote: > On Fri, 21 Feb 2014, Nicolas KUHN wrote: > >> We have a question regarding the NS-2 implementations of RED, CoDel, PIE >> and others AQMs. Especially, we believe that the way buffer-overflows >> are managed is not the same for each AQM scheme. >> >> In "Multimedia-unfriendly TCP Congestion Control and Home Gateway Queue >> Management" (L. Stewart et al.) details that : >> "PS: The queue is packet (slot) based, and the maximum queue length is >> specified as an integer number of packets: >> if (NumPktsInQ =E2=89=A5 PktQueueLength) >> drop incoming packet" >> >> However: >> 1- In droptail.cc: if((q_->length() + 1) >=3D qlim_) buffer overflow is >> detected >> 2- In RED/PIE/CoDel/etc.: if((q_->length() >=3D qlim_) buffer overflow i= s >> detected >> >> In the case of RED/PIE, when there are buffer overflows, the incoming >> packet may not be dropped. As a result, the incoming packet needs to be >> stored before the other packet is selected for drop: if((q_->length() >= =3D >> qlim_) should be avoided - and if((q_->length() + 1) >=3D qlim_) preferr= ed. >> >> In the case of CoDel, when there are buffer overflows, the incoming >> packets are dropped. if((q_->length() >=3D qlim_) is a good solution. >> >> Anyway, the authors of "Multimedia-unfriendly TCP Congestion Control and >> Home Gateway Queue Management" (L. Stewart et al.) illustrate the impact >> of this setting that should be carefully discussed. This point is of >> interest while comparing the performance of various AQM schemes with >> NS-2. >> >> We believe that AQMs that need information about incoming packets before >> tail-dropping them MUST detect buffer over flow when if((q_->length() + >> 1) >=3D qlim_). >> Any thoughts? > > While doing some tests with RED using ns2 in the past, I noticed this sam= e > difference. I patched ns2 RED to get equal behavior (patch attached but i= t > probably breaks some of the ns2 tests which is why I didn't consider > trying to upstream it). > > > -- > i. > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From nobody Fri Feb 21 12:06:27 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 1F1911A027D for ; Fri, 21 Feb 2014 12:06:26 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): cc: Ilpo J\344rvinen ; Fri, 21 Feb 2014 12:06:23 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id AC75A1A0267 for ; Fri, 21 Feb 2014 12:06:23 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1LK2Twc018169; Fri, 21 Feb 2014 15:02:29 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402212002.s1LK2Twc018169@maildrop2.v6ds.occnc.com> To: Naeem Khademi From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Feb 2014 15:52:33 +0100." Date: Fri, 21 Feb 2014 15:02:29 -0500 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/bkf3ZIcv7BfaNTPW9cRqJo6_kjs Cc: Ilpo Järvinen , Nicolas KUHN , "aqm@ietf.org" Subject: Re: [aqm] [NS-2 implementation of AQMs] X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com 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, 21 Feb 2014 20:06:26 -0000 In message Naeem Khademi writes: > Nicolas, > > Good catch although I tend to think that the impact of this would be > more visible on FIFO/DropTail queues; with an AQM presumably set at a > low threshold this impact will probably be less profound (although > depending on too many other factors, such as the load, multiplexing > level, BDP, etc). > > Naeem In real routers, at least large routers, the queue limit is measured in bytes, not packets. In many interfaces the queue limit is also setable in msec rather than have the user/admin figure out how many bytes that should be at a given speed and have the user/admin set different values on interfaces of different speed. OTOH a lot of big router configs are machine generated by the SP. In small routers and particularly hosts used as routers the queue limit is often expressed in packets but IMHO that is bad since a queue full of TCP ACKs is a lot less than a queue with the same number of full MSS TCP packets. Curtis > On Fri, Feb 21, 2014 at 1:10 PM, Ilpo Järvinen > wrote: > > On Fri, 21 Feb 2014, Nicolas KUHN wrote: > > > >> We have a question regarding the NS-2 implementations of RED, CoDel, PIE > >> and others AQMs. Especially, we believe that the way buffer-overflows > >> are managed is not the same for each AQM scheme. > >> > >> In "Multimedia-unfriendly TCP Congestion Control and Home Gateway Queue > >> Management" (L. Stewart et al.) details that : > >> "PS: The queue is packet (slot) based, and the maximum queue length is > >> specified as an integer number of packets: > >> if (NumPktsInQ ≥ PktQueueLength) > >> drop incoming packet" > >> > >> However: > >> 1- In droptail.cc: if((q_->length() + 1) >= qlim_) buffer overflow is > >> detected > >> 2- In RED/PIE/CoDel/etc.: if((q_->length() >= qlim_) buffer overflow is > >> detected > >> > >> In the case of RED/PIE, when there are buffer overflows, the incoming > >> packet may not be dropped. As a result, the incoming packet needs to be > >> stored before the other packet is selected for drop: if((q_->length() >= > >> qlim_) should be avoided - and if((q_->length() + 1) >= qlim_) preferred. > >> > >> In the case of CoDel, when there are buffer overflows, the incoming > >> packets are dropped. if((q_->length() >= qlim_) is a good solution. > >> > >> Anyway, the authors of "Multimedia-unfriendly TCP Congestion Control and > >> Home Gateway Queue Management" (L. Stewart et al.) illustrate the impact > >> of this setting that should be carefully discussed. This point is of > >> interest while comparing the performance of various AQM schemes with > >> NS-2. > >> > >> We believe that AQMs that need information about incoming packets before > >> tail-dropping them MUST detect buffer over flow when if((q_->length() + > >> 1) >= qlim_). > >> Any thoughts? > > > > While doing some tests with RED using ns2 in the past, I noticed this same > > difference. I patched ns2 RED to get equal behavior (patch attached but it > > probably breaks some of the ns2 tests which is why I didn't consider > > trying to upstream it). > > > > > > -- > > i. From nobody Mon Feb 24 04:19:32 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 04A8B1A045D for ; Mon, 24 Feb 2014 04:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 PRus8qFduDUO for ; Mon, 24 Feb 2014 04:19:28 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 46F751A03EB for ; Mon, 24 Feb 2014 04:19:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,534,1389772800"; d="scan'208";a="145006772" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 24 Feb 2014 04:19:27 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 04:19:27 -0800 From: "Scheffenegger, Richard" To: Greg White , "aqm@ietf.org" Thread-Topic: [aqm] updated draft agenda / PIE & CableLabs Thread-Index: Ac8xWpUyXYNoRSzvSNqu9iPy5M9oKQ== Date: Mon, 24 Feb 2014 12:19:27 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F26086E2D@SACEXCMBX02-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.106.53.53] 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/gJFu5t-eY0IS5deT5Qnzg9j4nmQ Cc: "Eggert, Lars" , Ralph Droms Subject: [aqm] updated draft agenda / PIE & CableLabs 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: Mon, 24 Feb 2014 12:19:30 -0000 Hi, In order for Greg to give a quick overview of the changes between PIE and t= he variant adopted by CableLabs for DOCSIS 3.1, a tentative slot was added = to the preliminary agenda. For those interested in a more full discussion, there might be a slot at IC= CRG (preceding the AQM slot), where Greg could have a longer proper slot fo= r the presentation of that variant of PIE. Best regards, Richard Scheffenegger AQM Agenda IETF 89 in London, United Kingdom Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) ****************************************************** WG status --------- 14:20 Agenda bashing AQM status Chairs 10 min =20 WG items -------- 14:30 draft-ietf-aqm-recommendation Fred Baker / Gorry Fairhurst 10 min=20 =20 Charter items ------------- =20 14:40 draft-welzl-ecn-benefits Gorry Fairhurst/Michael Welzl 15 min 14:55 draft-kuhn-aqm-eval-guidelines Nicolas Kuhn et. al. 45 min if time permits: Algorithm Proposals ------------------- =20 15:40 draft-lauten-aqm-gsp Wolfram Lautenschlaeger 10 min =20 15:45 draft-white-aqm-docsis-pie Greg White 10 min From nobody Mon Feb 24 07:10: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 7B82A1A00AE for ; Mon, 24 Feb 2014 07:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 0VQ0bbA51I4m for ; Mon, 24 Feb 2014 07:10:30 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id A223E1A00B7 for ; Mon, 24 Feb 2014 07:10:22 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WHxAg-0007d8-LN; Mon, 24 Feb 2014 16:10:18 +0100 Received: from 089144238033.atnat0047.highway.bob.at ([89.144.238.33] helo=[192.168.1.4]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WHxAa-0005Mq-Nh; Mon, 24 Feb 2014 16:10:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F26086E2D@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 24 Feb 2014 16:09:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F26086E2D@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 12 sum msgs/h 5 total rcpts 12845 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B5363C110017312806D5478F5A4703529351BC5E X-UiO-SPAM-Test: remote_host: 89.144.238.33 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 7 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/zqZis8kBBVUC-8rrh3IgTBaBN4c Cc: "LAUTENSCHLAEGER, WOLFRAM \(WOLFRAM\)" , Greg White , Lars Eggert , "aqm@ietf.org list" , Ralph Droms Subject: Re: [aqm] updated draft agenda / PIE & CableLabs 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: Mon, 24 Feb 2014 15:10:34 -0000 Ok, this is getting confusing, with two talks (also the one by Wolfram = Lautenschlaeger) that were mentioned as *maybe* happening in AQM, = depending on whether time permits, and else maybe going to ICCRG, when = ICCRG is in fact scheduled *before* AQM. So here's a proposal. We give both Wolfram (who we already agreed with = about that, in fact) and Greg a 20 minute slot each in ICCRG, to present = more details. Then, if time permits, *in addition* they *may* get a = 10-minute chance in AQM. Is that a plan? Greg, this would mean that you'll *definitely* also = present to ICCRG. ok? Cheers, Michael On 24. feb. 2014, at 13:19, "Scheffenegger, Richard" = wrote: > Hi, >=20 > In order for Greg to give a quick overview of the changes between PIE = and the variant adopted by CableLabs for DOCSIS 3.1, a tentative slot = was added to the preliminary agenda. >=20 > For those interested in a more full discussion, there might be a slot = at ICCRG (preceding the AQM slot), where Greg could have a longer proper = slot for the presentation of that variant of PIE. >=20 > Best regards, >=20 >=20 > Richard Scheffenegger >=20 >=20 > AQM Agenda > IETF 89 in London, United Kingdom > Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) > ****************************************************** >=20 > WG status > --------- >=20 > 14:20 > Agenda bashing > AQM status > Chairs > 10 min >=20 >=20 > WG items > -------- >=20 > 14:30 > draft-ietf-aqm-recommendation > Fred Baker / Gorry Fairhurst > 10 min=20 >=20 >=20 > Charter items > ------------- >=20 > 14:40 > draft-welzl-ecn-benefits > Gorry Fairhurst/Michael Welzl > 15 min >=20 > 14:55 > draft-kuhn-aqm-eval-guidelines > Nicolas Kuhn et. al. > 45 min >=20 >=20 > if time permits: >=20 > Algorithm Proposals > ------------------- >=20 > 15:40 > draft-lauten-aqm-gsp > Wolfram Lautenschlaeger > 10 min >=20 > 15:45 > draft-white-aqm-docsis-pie > Greg White > 10 min >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Mon Feb 24 08:02: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 8B2CF1A01A6 for ; Mon, 24 Feb 2014 08:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.389 X-Spam-Level: ** X-Spam-Status: No, score=2.389 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.547] 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 b0dVLdRKOTd3 for ; Mon, 24 Feb 2014 08:02:50 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 22C501A019E for ; Mon, 24 Feb 2014 08:02:50 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s1OG2KTm031377; Mon, 24 Feb 2014 09:02:20 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 24 Feb 2014 09:02:20 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 09:02:19 -0700 From: Greg White To: Michael Welzl , "Scheffenegger, Richard" Thread-Topic: [aqm] updated draft agenda / PIE & CableLabs Thread-Index: AQHPMXKKE/kJhiQlX0Oiq9St2VXY/5rEkK+A Date: Mon, 24 Feb 2014 16:02:19 +0000 Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F26086E2D@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.4.10.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <0D7935EA52B91045A042377CEF7DA9FA@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/SbC-QLC2bwhq2hQLx9j2oeo7V48 Cc: "LAUTENSCHLAEGER, WOLFRAM \(WOLFRAM\)" , Lars Eggert , "aqm@ietf.org list" , Ralph Droms Subject: Re: [aqm] updated draft agenda / PIE & CableLabs 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: Mon, 24 Feb 2014 16:02:51 -0000 Works for me. Thanks all! -Greg On 2/24/14, 8:09 AM, "Michael Welzl" wrote: >Ok, this is getting confusing, with two talks (also the one by Wolfram >Lautenschlaeger) that were mentioned as *maybe* happening in AQM, >depending on whether time permits, and else maybe going to ICCRG, when >ICCRG is in fact scheduled *before* AQM. > >So here's a proposal. We give both Wolfram (who we already agreed with >about that, in fact) and Greg a 20 minute slot each in ICCRG, to present >more details. Then, if time permits, *in addition* they *may* get a >10-minute chance in AQM. > >Is that a plan? Greg, this would mean that you'll *definitely* also >present to ICCRG. ok? > >Cheers, >Michael > > >On 24. feb. 2014, at 13:19, "Scheffenegger, Richard" >wrote: > >> Hi, >>=20 >> In order for Greg to give a quick overview of the changes between PIE >>and the variant adopted by CableLabs for DOCSIS 3.1, a tentative slot >>was added to the preliminary agenda. >>=20 >> For those interested in a more full discussion, there might be a slot >>at ICCRG (preceding the AQM slot), where Greg could have a longer proper >>slot for the presentation of that variant of PIE. >>=20 >> Best regards, >>=20 >>=20 >> Richard Scheffenegger >>=20 >>=20 >> AQM Agenda >> IETF 89 in London, United Kingdom >> Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) >> ****************************************************** >>=20 >> WG status >> --------- >>=20 >> 14:20 >> Agenda bashing >> AQM status >> Chairs >> 10 min >>=20 >>=20 >> WG items >> -------- >>=20 >> 14:30 >> draft-ietf-aqm-recommendation >> Fred Baker / Gorry Fairhurst >> 10 min=20 >>=20 >>=20 >> Charter items >> ------------- >>=20 >> 14:40 >> draft-welzl-ecn-benefits >> Gorry Fairhurst/Michael Welzl >> 15 min >>=20 >> 14:55 >> draft-kuhn-aqm-eval-guidelines >> Nicolas Kuhn et. al. >> 45 min >>=20 >>=20 >> if time permits: >>=20 >> Algorithm Proposals >> ------------------- >>=20 >> 15:40 >> draft-lauten-aqm-gsp >> Wolfram Lautenschlaeger >> 10 min >>=20 >> 15:45 >> draft-white-aqm-docsis-pie >> Greg White >> 10 min >>=20 >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > From nobody Mon Feb 24 09:28:51 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 4FF011A01BE for ; Mon, 24 Feb 2014 09:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 oYCwRTnDlEuB for ; Mon, 24 Feb 2014 09:28:47 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 96BAD1A0193 for ; Mon, 24 Feb 2014 09:28:46 -0800 (PST) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WHzKf-0004pY-5w for aqm@ietf.org; Mon, 24 Feb 2014 18:28:45 +0100 Received: from 089144238033.atnat0047.highway.bob.at ([89.144.238.33] helo=[192.168.1.4]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WHzKe-00017T-4a for aqm@ietf.org; Mon, 24 Feb 2014 18:28:45 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F26086E2D@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 24 Feb 2014 18:28:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E2F8332-A21A-497A-8D35-E057BD9C8A8B@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F26086E2D@SACEXCMBX02-PRD.hq.netapp.com> To: "aqm@ietf.org list" X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 8 sum msgs/h 4 total rcpts 12860 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F0EE66A8849156F22F5D5E9D8DED919724E2327A X-UiO-SPAM-Test: remote_host: 89.144.238.33 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 18 max/h 9 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/OhKKJNBMl6G5kVCxfrFYRj5vBUo Subject: Re: [aqm] updated draft agenda / PIE & CableLabs 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: Mon, 24 Feb 2014 17:28:49 -0000 Fyi, all, To give them a chance to present more details, there are 20-min slots = for both Greg's presentation and the presentation of Wolfram = Lautenschlaeger in ICCRG, which is happening on Monday: https://datatracker.ietf.org/meeting/89/agenda/iccrg/ - so this session should be of interest to AQM'ers. Cheers, Michael On 24. feb. 2014, at 13:19, "Scheffenegger, Richard" = wrote: > Hi, >=20 > In order for Greg to give a quick overview of the changes between PIE = and the variant adopted by CableLabs for DOCSIS 3.1, a tentative slot = was added to the preliminary agenda. >=20 > For those interested in a more full discussion, there might be a slot = at ICCRG (preceding the AQM slot), where Greg could have a longer proper = slot for the presentation of that variant of PIE. >=20 > Best regards, >=20 >=20 > Richard Scheffenegger >=20 >=20 > AQM Agenda > IETF 89 in London, United Kingdom > Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) > ****************************************************** >=20 > WG status > --------- >=20 > 14:20 > Agenda bashing > AQM status > Chairs > 10 min >=20 >=20 > WG items > -------- >=20 > 14:30 > draft-ietf-aqm-recommendation > Fred Baker / Gorry Fairhurst > 10 min=20 >=20 >=20 > Charter items > ------------- >=20 > 14:40 > draft-welzl-ecn-benefits > Gorry Fairhurst/Michael Welzl > 15 min >=20 > 14:55 > draft-kuhn-aqm-eval-guidelines > Nicolas Kuhn et. al. > 45 min >=20 >=20 > if time permits: >=20 > Algorithm Proposals > ------------------- >=20 > 15:40 > draft-lauten-aqm-gsp > Wolfram Lautenschlaeger > 10 min >=20 > 15:45 > draft-white-aqm-docsis-pie > Greg White > 10 min >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Mon Feb 24 22:43: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 095961A0319 for ; Mon, 24 Feb 2014 22:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 9fbyQ5VYk2py for ; Mon, 24 Feb 2014 22:43:17 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id BC4FA1A023F for ; Mon, 24 Feb 2014 22:43:17 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1P6hCFs026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 00:43:13 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1P6hA8q027656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 07:43:11 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.165]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 25 Feb 2014 07:43:11 +0100 From: "LAUTENSCHLAEGER, WOLFRAM (WOLFRAM)" To: Michael Welzl , "Scheffenegger, Richard" Thread-Topic: [aqm] updated draft agenda / PIE & CableLabs Thread-Index: AQHPMXKbQlGcxSrOC0iI5TORsmQQDprFhl5Q Date: Tue, 25 Feb 2014 06:43:10 +0000 Message-ID: <0A452E1DADEF254C9A7AC1969B878128053BA0@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F26086E2D@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/BmXsGiApJv0OgYGKXyIlff6eOH8 Cc: Greg White , Lars Eggert , "aqm@ietf.org list" , Ralph Droms Subject: Re: [aqm] updated draft agenda / PIE & CableLabs 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, 25 Feb 2014 06:43:20 -0000 That's OK for me! Wolfram -----Urspr=FCngliche Nachricht----- Von: aqm [mailto:aqm-bounces@ietf.org] Im Auftrag von Michael Welzl Gesendet: Montag, 24. Februar 2014 16:09 An: Scheffenegger, Richard Cc: LAUTENSCHLAEGER, WOLFRAM (WOLFRAM); Greg White; Lars Eggert; aqm@ietf.o= rg list; Ralph Droms Betreff: Re: [aqm] updated draft agenda / PIE & CableLabs Ok, this is getting confusing, with two talks (also the one by Wolfram Laut= enschlaeger) that were mentioned as *maybe* happening in AQM, depending on = whether time permits, and else maybe going to ICCRG, when ICCRG is in fact = scheduled *before* AQM. So here's a proposal. We give both Wolfram (who we already agreed with abou= t that, in fact) and Greg a 20 minute slot each in ICCRG, to present more d= etails. Then, if time permits, *in addition* they *may* get a 10-minute cha= nce in AQM. Is that a plan? Greg, this would mean that you'll *definitely* also presen= t to ICCRG. ok? Cheers, Michael On 24. feb. 2014, at 13:19, "Scheffenegger, Richard" wrote: > Hi, >=20 > In order for Greg to give a quick overview of the changes between PIE and= the variant adopted by CableLabs for DOCSIS 3.1, a tentative slot was adde= d to the preliminary agenda. >=20 > For those interested in a more full discussion, there might be a slot at = ICCRG (preceding the AQM slot), where Greg could have a longer proper slot = for the presentation of that variant of PIE. >=20 > Best regards, >=20 >=20 > Richard Scheffenegger >=20 >=20 > AQM Agenda > IETF 89 in London, United Kingdom > Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) > ****************************************************** >=20 > WG status > --------- >=20 > 14:20 > Agenda bashing > AQM status > Chairs > 10 min >=20 >=20 > WG items > -------- >=20 > 14:30 > draft-ietf-aqm-recommendation > Fred Baker / Gorry Fairhurst > 10 min=20 >=20 >=20 > Charter items > ------------- >=20 > 14:40 > draft-welzl-ecn-benefits > Gorry Fairhurst/Michael Welzl > 15 min >=20 > 14:55 > draft-kuhn-aqm-eval-guidelines > Nicolas Kuhn et. al. > 45 min >=20 >=20 > if time permits: >=20 > Algorithm Proposals > ------------------- >=20 > 15:40 > draft-lauten-aqm-gsp > Wolfram Lautenschlaeger > 10 min >=20 > 15:45 > draft-white-aqm-docsis-pie > Greg White > 10 min >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm From nobody Fri Feb 28 04:07:30 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 BE3BF1A0722 for ; Fri, 28 Feb 2014 04:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 U-L0EGd33upY for ; Fri, 28 Feb 2014 04:07:25 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C8C7E1A06D1 for ; Fri, 28 Feb 2014 04:07:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,561,1389772800"; d="scan'208,217";a="146238459" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 28 Feb 2014 04:07:24 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 04:07:23 -0800 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: IETF89 - London Thread-Index: Ac80fP4RCboZlHNMTxiAQGseuDl4CQ== Date: Fri, 28 Feb 2014 12:07:23 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260A34E9@SACEXCMBX02-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.122.105.28] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F260A34E9SACEXCMBX02PRDh_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/ViIIv0k-8IN3VRe8g_ic1WmnpTg Subject: [aqm] IETF89 - London 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, 28 Feb 2014 12:07:27 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F260A34E9SACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi group, just a quick reminder: Two AQM algorithms will be presented in the ICCRG slot, so that during the = AQM slot we can concentrate on the items that closely align with our charte= r milestones. These two presentations should start - pending any agenda bashing or shuffl= ing of talks - at the times mentioned below: Monday, March 3, 2014, 15:20-17:30, Room Balmoral Starting approx. 16:00-16:20: Wolfram Lautenschlaeger, Global Synchronization Protection for Packet Queue= s, 20 min http://tools.ietf.org/html/draft-lauten-aqm-gsp-00 starting approx.. 16:20-16:40: Greg White, A PIE-Based AQM for DOCSIS Cable Modems, 20 min http://tools.ietf.org/html/draft-white-aqm-docsis-pie-00 Best regards, Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F260A34E9SACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi group,
 
just a quick reminder:
 
Two AQM algorithms will be presented in the ICCRG slot, so that during= the AQM slot we can concentrate on the items that closely align with our c= harter milestones.
 
These two presentations should start – pending any agenda bashin= g or shuffling of talks – at the times mentioned below:
 
= Monday, March 3, 2014, 15:20-17:30, Room Balmoral
 
= Starting approx. 16:00-16:20:
=  
= Wolfram Lautenschlaeger, Global Synchronization Protection for Packet Queue= s, 20 min
=  
= starting approx.. 16:20-16:40:
=  
= Greg White, A PIE-Based AQM for DOCSIS Cable Modems, 20 min
 
Best regards,
 
Richard Scheffenegger
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F260A34E9SACEXCMBX02PRDh_--