From wes@mti-systems.com Wed May 1 20:09:42 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73B221F9A20 for ; Wed, 1 May 2013 20:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBPuaZOb3wiW for ; Wed, 1 May 2013 20:09:37 -0700 (PDT) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id 067B921F8556 for ; Wed, 1 May 2013 20:09:33 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.209]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4239XVZ000352 for ; Wed, 1 May 2013 23:09:33 -0400 Received: (qmail 12403 invoked by uid 0); 2 May 2013 03:09:32 -0000 Received: from unknown (HELO ?192.168.1.121?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 2 May 2013 03:09:32 -0000 Message-ID: <5181D8E2.1040306@mti-systems.com> Date: Wed, 01 May 2013 23:09:22 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Linda Dunbar References: <8C48B86A895913448548E6D15DA7553B82A5E5@xmb-rcd-x09.cisco.com> <517FF171.4010306@mti-systems.com> <4A95BA014132FF49AE685FAB4B9F17F645B16159@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B16159@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Fred Baker \(fred\)" , "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 03:09:43 -0000 On 4/30/2013 6:17 PM, Linda Dunbar wrote: > Wes, > > Question inserted below: > >> -----Original Message----- >> """ >> Hence, network communication to the host regarding the moderation of >> its traffic flow SHOULD use an AQM algorithm to determine which >> packets it should affect, and then implement that effect by marking >> ECN-capable traffic "Congestion Experienced (CE)" or dropping non- >> ECN-capable traffic. > > > [Linda] Do you mean that downstream nodes treat packets with ECN bits marked differently than that packets whose ECN bits are not marked? > In another words, is "congestion experienced (CE)" encoded in the packets? > Hi Linda, that was actually a direct quote from Fred's document, so I can't take credit for it ... however, all that it's saying is that the congested queue set the CE bit (when ECT is set), per normal ECN protocol. It isn't saying anything new about the downstream nodes that see CE has already been set. -- Wes Eddy MTI Systems From fred@cisco.com Thu May 2 07:00:14 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1E21F8523 for ; Thu, 2 May 2013 07:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.263 X-Spam-Level: X-Spam-Status: No, score=-109.263 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFT7+PH34xaD for ; Thu, 2 May 2013 07:00:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2677421F8A4E for ; Thu, 2 May 2013 07:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=167; q=dns/txt; s=iport; t=1367503210; x=1368712810; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=GI4Cl+9C1tY9Cq9lEE+ZAOUacRRxpmsqapSZfvtICdE=; b=FUSj7qkpXt3HrWBlmkcnvwUVTdhHgGv3igEjOiWairSJZyBugjVtETFX B6m2KOREDVKHcfy2V1RuVO7uqMf1Epte2NDkJaO7W5DyKD9a98rRHSlIT bqIq8yLfKGKHTEieImbIwuTkoqZWUexSr009ymgHwCwao4YHcVSYae59b Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkGANFwglGtJV2c/2dsb2JhbABSgwc3vx9/Fm0DBIIhAQQ6UQEqFEInBBuIBAyhNp9EjnGDKWEDmE+QC4MNgic X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208";a="205447471" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 02 May 2013 14:00:09 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r42E04CY019400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 May 2013 14:00:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 2 May 2013 09:00:05 -0500 From: "Fred Baker (fred)" To: "aqm@ietf.org" Thread-Topic: Question re draft-baker-aqm-recommendations recomendation #3 Thread-Index: AQHORz1YyDkxAq34406BC5YFqZiMgQ== Date: Thu, 2 May 2013 14:00:04 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B830610@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [aqm] Question re draft-baker-aqm-recommendations recomendation #3 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 14:00:15 -0000 Do we generally agree with the recommendation of http://tools.ietf.org/html= /draft-baker-aqm-recommendation-01#section-4.3? This is the question of aut= o-tuning. From andrewmcgr@google.com Thu May 2 08:37:47 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD6821F8F2C for ; Thu, 2 May 2013 08:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJIEGfwTCAbu for ; Thu, 2 May 2013 08:37:43 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id B032921F8EF7 for ; Thu, 2 May 2013 08:37:42 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id gf12so605673vcb.15 for ; Thu, 02 May 2013 08:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FBDThp88yXS49NjM+6V5jvxnXbUGjziLDRT6xxIWaeE=; b=cjhFo9LBht8SCmxvktH2pcsf4E7GI+rP4mvgNeMHhGDesN98P62kBwAnLIcou64aOy JdrTLX/Io/wjQZ3aykntbIcDZotzv8MnmUklKYvRrgyNBckOK/dOAmDMwww+v2Ec+h7O fpXudEunqDebPUCz8JCA0zBvbVK1qHbBblKeXvzCbiXutfVUAJSp8mkmxLrcJRKB4YHe C3lUgamIOnxkMgh5SJ5oMIp4KwpAnspJBW4eoddWvUwkHvSOad8wALNzvkDRDEGwAE99 j20Cimm3oSkFJF3drPX8Ai0+DsKUvkX6U/joM/1YCFECQwhioMFWj1kgu00cbq05Z5R0 vsWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FBDThp88yXS49NjM+6V5jvxnXbUGjziLDRT6xxIWaeE=; b=U6uVd61WfByWDP9YFFHovlmeCTwZHI0soyhj+Vw3HQ3vrowXmWY05gmzpWDihhLBCU SSjTZgUObpQIYrE6EypVj+nfC/Mj/QY/Zd0AoF/78GZXEUuPwgSIfOPyDGdx/nUkzWp2 X9eze3cztjeuzi+MZLLuFrn47I5KBNuPCZIwTChxbGgrn2OYG1lP5+XKPz4MxzkQYsoT NY4QwNhpFX2O0lhVFTGF0KTYfYrMiMbGc8FnPrD7vEhzdoD1yPtGeoGGJia8rOnHu1nO ST6qLTzsquqv1s8Pm6vH4qBfpEeiHIhks5V+xAcNKZdrpTuZ9XTkgzGQpmjM3RB0xd/j 3c+Q== MIME-Version: 1.0 X-Received: by 10.52.27.163 with SMTP id u3mr1946067vdg.60.1367509059170; Thu, 02 May 2013 08:37:39 -0700 (PDT) Received: by 10.220.208.135 with HTTP; Thu, 2 May 2013 08:37:39 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B830610@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B830610@xmb-rcd-x09.cisco.com> Date: Fri, 3 May 2013 01:37:39 +1000 Message-ID: From: Andrew Mcgregor To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=20cf307ca52ab3375804dbbe0377 X-Gm-Message-State: ALoCoQlchfHj+O5IMy6iLTikBK0ZJrRFRBsSKGXfIcF17VdOfdEXqvLAspoHDi0l6J/V3nni/MkfvWkguJsOnAB+vUl9Pi6ZdUjSexL/6otcD3pm9rK3isV/cQX0WJ7PV7d3UF4EphvULTd68SSl3AcVdU8l+KwVJMl4rr+LZ9JbBRB/NoXIz/NFoofP5lt48z+/ujOXEH/q Cc: "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #3 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 15:37:47 -0000 --20cf307ca52ab3375804dbbe0377 Content-Type: text/plain; charset=ISO-8859-1 Yes, that recommendation is necessary and should stand. On 3 May 2013 00:00, Fred Baker (fred) wrote: > Do we generally agree with the recommendation of > http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.3? > This is the question of auto-tuning. > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --20cf307ca52ab3375804dbbe0377 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, that recommendation is necessary and should stand.


On 3 May 2= 013 00:00, Fred Baker (fred) <fred@cisco.com> wrote:
Do we generally agree with the recommendatio= n of http://tools.ietf.org/html/draft-baker-aqm= -recommendation-01#section-4.3? This is the question of auto-tuning.

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



--
Andrew McGregor=A0|=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--20cf307ca52ab3375804dbbe0377-- From john@jlc.net Thu May 2 09:44:04 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E7921F85C3 for ; Thu, 2 May 2013 09:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlqwqNjNGF9b for ; Thu, 2 May 2013 09:43:59 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DF52F21F8437 for ; Thu, 2 May 2013 09:43:58 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CC9F133C26; Thu, 2 May 2013 12:43:58 -0400 (EDT) Date: Thu, 2 May 2013 12:43:58 -0400 From: John Leslie To: Wesley Eddy Message-ID: <20130502164358.GF23227@verdi> References: <8C48B86A895913448548E6D15DA7553B82A5E5@xmb-rcd-x09.cisco.com> <517FF171.4010306@mti-systems.com> <4A95BA014132FF49AE685FAB4B9F17F645B16159@dfweml509-mbx.china.huawei.com> <5181D8E2.1040306@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5181D8E2.1040306@mti-systems.com> User-Agent: Mutt/1.4.1i Cc: aqm@ietf.org, Linda Dunbar Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 16:44:04 -0000 Wesley Eddy wrote: > On 4/30/2013 6:17 PM, Linda Dunbar wrote: >> >> Do you mean that downstream nodes treat packets with ECN bits marked >> differently than that packets whose ECN bits are not marked? >> In another words, is "congestion experienced (CE)" encoded in the packets? > >... all that it's saying is that the congested queue set the CE bit > (when ECT is set), per normal ECN protocol. It isn't saying anything > new about the downstream nodes that see CE has already been set. A downstream node _could_ treat the packet differently: it wouldn't matter much for what we're interested in. Note that a downstream node could reasonably drop a packet already CE-marked if that node _also_ is congested. It wouldn't actually help IMHO if the flow containing the marked packet is well-behaved; but there's really no way to tell whether the flow is well-behaved. With room for doubt, it's arguably right to drop it at an even lighter level of congestion: in all reasonable cases of two or more nodes congested on the path, we should expect another packet to come along _not_ already CE-marked. (I'm not actually proposing this -- least of all proposing to _standardize_ this; but perhaps it will help folks to think through the issue.) In some future "perfect world", where CE can mark packets _before_ there is any reason to drop any, I might talk about standardizing such a practice. ;^) -- John Leslie From dave.taht@gmail.com Thu May 2 12:43:20 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079CA21F905B for ; Thu, 2 May 2013 12:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPUTSaSDrJ3V for ; Thu, 2 May 2013 12:43:15 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BB38B21F8D70 for ; Thu, 2 May 2013 12:43:15 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar20so1078591iec.39 for ; Thu, 02 May 2013 12:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=8Smzc7sbQ4AuKtebSCmHTRwDKmaHV9XGWXe0mTSD1QQ=; b=Z+Wqz9PDmIOgmIHSf6RWmtywf3A/aIlHKdz9XyorLelZLdGW2cYpSbIJylcWPZ8AUA 3YzqvStY5IqJHJW9f2pIoV8dohKpAuWtN6qmxJoeFc/qPC4Q3geIBK5X6fEUi3ypZcNo jqZfhYh2PhhIw9chkElqmTDzyyYwUebfmjvDRd6a237EYwjR/rlWRKOtv05HBStP6Res omos1Ku8X4B1lc7IqfTuhCCOTVIGskMVjTECJXs3ldkpZ4WXmHkNdzh49iOljSQF/suy iMo89erTQ4CDKw9qZ/RE+Uajc/uiZje8Q3SRV7n0M33ebrsm2teABsj5e7QeiEh1VhWW 9ZWg== MIME-Version: 1.0 X-Received: by 10.50.25.102 with SMTP id b6mr15474305igg.27.1367523795408; Thu, 02 May 2013 12:43:15 -0700 (PDT) Received: by 10.64.7.51 with HTTP; Thu, 2 May 2013 12:43:15 -0700 (PDT) In-Reply-To: References: <8C48B86A895913448548E6D15DA7553B830610@xmb-rcd-x09.cisco.com> Date: Thu, 2 May 2013 12:43:15 -0700 Message-ID: From: Dave Taht To: Andrew Mcgregor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Fred Baker \(fred\)" , "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #3 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 19:43:20 -0000 On Thu, May 2, 2013 at 8:37 AM, Andrew Mcgregor wro= te: > Yes, that recommendation is necessary and should stand. +1 Or perhaps strengthened: An AQM algorithm should be enabled by default, and thus should "do no harm" when used with its defaults. to save me time on the review process: section 4.4: +1 section 4.5: 4.5. TCP and SCTP congestion control algorithms SHOULD maximize their use of available bandwidth without incurring loss or undue round trip delay I don't see the need to specify TCP and SCTP here. Rather: Congestion control algorithms SHOULD maximize their use of available bandwidth without incurring undue loss or undue round trip delay > > On 3 May 2013 00:00, Fred Baker (fred) wrote: >> >> Do we generally agree with the recommendation of >> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.3= ? >> This is the question of auto-tuning. >> >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > > > > -- > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > > _______________________________________________ > 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 g.white@CableLabs.com Fri May 3 15:55:23 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8198E21F8EE1; Fri, 3 May 2013 15:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUp-6wBl2c8y; Fri, 3 May 2013 15:55:19 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0C21F8696; Fri, 3 May 2013 15:55:07 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r43Mt2MH005045; Fri, 3 May 2013 16:55:02 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 03 May 2013 16:55:02 -0600 (MDT) 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.0123.003; Fri, 3 May 2013 16:55:03 -0600 From: Greg White To: Preethi Natarajan , "iccrg@irtf.org" , "aqm@ietf.org" Thread-Topic: [aqm] Follow-up: PIE performance in cable modem environments Thread-Index: AQHOQHkKaa+IaeVR9EG660JnW8MhmZjvanOAgABzgACABEOWgA== Date: Fri, 3 May 2013 22:55:02 +0000 Message-ID: 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.2.130206 x-originating-ip: [10.4.10.57] Content-Type: multipart/alternative; boundary="_000_CDA991601166Cgwhitecablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 22:55:23 -0000 --_000_CDA991601166Cgwhitecablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Preethi, I did a diff on the new version of the PIE code vs the earlier release and = found, as you stated, that the basic algorithm hasn't changed. I do see so= me other improvements/changes though. One which, I think, bears discussion= is the weighting of packet drops based on size. In the new code there is the option (turned on in the simulations I reporte= d on in my paper) to drop packets according to p*pkt_size/mean_pkt_size whe= re p is the drop probability calculated by the PIE control law. This serves= to significantly decrease the drop probability of the small VoIP and gamin= g packets, which may be sensitive to loss (from a QoE perspective) and non-= responsive to loss (from a congestion control perspective). This is eviden= ced by the low packet loss rate for gaming traffic that I reported in my pa= per. However, I worry that the unintended consequence may be that this weighting= incentivizes application developers toward the use of small packets, which= seems ill advised. Thoughts? -Greg From: Preethi Natarajan > Date: Tuesday, April 30, 2013 5:48 PM To: Greg White >, Preet= hi Natarajan >, "iccrg@= irtf.org" >, "= tsvwg@ietf.org" >, "aqm@ietf.org" = > Cc: "Rong Pan (ropan)" >, "Bill Ver= Steeg (versteb)" >, "Chiara Pi= glione (cpiglion)" >, "Mythil= i Suryanarayana Prabhu (mysuryan)" >, "Fred Baker (fred)" >, Dan R= ice > Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments Hi, Thank you Greg for the update and the link to the white paper. We wanted to quickly clarify about how we tuned PIE for DOCSIS. The basic PIE algorithm has not changed. We updated the simulation code wit= h the missing line mentioned below (which was a bug). The DOCSIS MAC layer = has this special nature of stop-and-go with 5ms-6ms request and grant delay= . This requires adjustment of any algorithm: for example CoDel has to incr= ease its target delay from 5ms to a higher value. Similarly, our new parame= ters are to make PIE adjust faster for the DOCSIS stop-and-go behavior. Ple= ase note that eventually all these design parameters will be automatically = set, users of the PIE algorithm would not be required to set any design par= ameters. Again, many thanks for your update. PIE team From: Greg White > Date: Tuesday, April 30, 2013 3:54 PM To: Preethi Natarajan >= , "iccrg@irtf.org" >, "tsvwg@ietf.org" >, "aqm@ietf.org" > Cc: "Rong Pan (ropan)" >, "Bill Ver= Steeg (versteb)" >, "Chiara Pi= glione (cpiglion)" >, "Mythil= i Suryanarayana Prabhu (mysuryan)" >, "Fred Baker (fred)" >, Danie= l Rice > Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments Additionally, I've re-run my suite of simulations using the updated PIE cod= e from Cisco. The results (in much more detail than I presented at ICCRG) = are documented in a white paper available here: Active Queue Management Algorithms for DOCSIS 3.0 Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well i= n the cable environment, and for sharing the resulting code. Best Regards, Greg From: Preethi Natarajan > Date: Tuesday, April 23, 2013 5:18 PM To: "iccrg@irtf.org" >, "tsvwg@ietf.org" >, "aqm@ietf.org" > Cc: "Rong Pan (ropan)" >, "Bill Ver= Steeg (versteb)" >, "Chiara Pi= glione (cpiglion)" >, "Mythil= i Suryanarayana Prabhu (mysuryan)" >, "Fred Baker (fred)" > Subject: [aqm] Follow-up: PIE performance in cable modem environments Hello, This is a follow-up to Greg White's (from Cable Labs) talk at the recent IC= CRG meeting on PIE's performance in cable modem environments. Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We = investigated PIE's performance using this model. The key items from this in= vestigation: 1. Bug in PIE code: The previous PIE release (that Greg used for evaluat= ions) was missing a line of code. This missing line brings down drop probab= ility under certain conditions and turns out to be critical for the cable m= odem scenario. Without this line of code, the drop probability remains high= and takes longer to come down even when the queue delay has remained lower= than the reference. The updated ns-2 PIE code can be found here =97 ftp://= ftpeng.cisco.com/pie/. 2. Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cu= bic variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed= by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive an= d unresponsive to packet drops/notifications, pretty much like UDP traffic.= Please find more details about the bug here -- http://sourceforge.net/trac= ker/?func=3Ddetail&aid=3D3608750&group_id=3D149743&atid=3D775392. We are working with Cable Labs to verify the cable modem results, they'll s= oon be available on our FTP site along with the PIE code. A technical paper about PIE was recently accepted at the IEEE Conference on= High Performance Switching and Routing 2013. A copy of the paper is attach= ed here. The Linux PIE implementation is expected to be ready by next week and we'll= follow-up on that as well. Many thanks, Preethi on behalf of PIE team. --_000_CDA991601166Cgwhitecablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Preethi,

I did a diff on the new version of the PIE code vs the earlier release= and found, as you stated, that the basic algorithm hasn't changed.  I= do see some other improvements/changes though.  One which, I think, b= ears discussion is the weighting of packet drops based on size.

In the new code there is the option (turned on in the simulations I re= ported on in my paper) to drop packets according to p*pkt_size/mean_pkt_siz= e where p is the drop probability calculated by the PIE control law. This s= erves to significantly decrease the drop probability of the small VoIP and gaming packets, which may be se= nsitive to loss (from a QoE perspective) and non-responsive to loss (from a= congestion control perspective).  This is evidenced by the low packet= loss rate for gaming traffic that I reported in my paper.

However, I worry that the unintended consequence may be that this weig= hting incentivizes application developers toward the use of small packets, = which seems ill advised.

Thoughts?

-Greg



From: Preethi Natarajan <preethi.cis@gmail.com>
Date: Tuesday, April 30, 2013 5:48 = PM
To: Greg White <g.white@cablelabs.com>, Preethi Natarajan &= lt;preethi.cis@gmail.com>, = "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "aqm@ietf.org" <aqm@ietf.org<= /a>>
Cc: "Rong Pan (ropan)" &l= t;ropan@cisco.com>, "Bill Ve= r Steeg (versteb)" <versteb@ci= sco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)&quo= t; <fred@cisco.com>, Dan Rice &= lt;d.rice@cablelabs.com>
Subject: Re: [aqm] Follow-up: PIE p= erformance in cable modem environments

Hi,

Thank you Greg for the update and the link to the white paper.

We wanted to quickly clarify about how we tuned PIE for DOCSIS.

The bas= ic PIE algorithm has not changed. We updated the simulation code with the m= issing line mentioned below (which was a bug). The DOCSIS MAC layer has this special nature of stop-and-go with 5ms-6ms reque= st and grant delay. This requires adjustment of any algorithm: for example =  CoDel has to increase its target delay from 5ms to a higher value. Si= milarly, our new parameters are to make PIE adjust faster for the DOCSIS stop-and-go behavior. Please note that ev= entually all these design parameters will be automatically set, users of th= e PIE algorithm would not be required to set any design parameters. 

Again, many thanks for your update. 
PIE tea= m

From: Greg White <g.white@CableLabs.com>
Date: Tuesday, April 30, 2013 3:54 = PM
To: Preethi Natarajan <preethi.cis@gmail.com>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>
Cc: "Rong Pan (ropan)" &l= t;ropan@cisco.com>, "Bill Ve= r Steeg (versteb)" <versteb@ci= sco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)&quo= t; <fred@cisco.com>, Daniel Ric= e <D.Rice@CableLabs.com><= br> Subject: Re: [aqm] Follow-up: PIE p= erformance in cable modem environments

Additionally, I've re-run my suite of simulations using the updated PI= E code from Cisco.  The results (in much more detail than I presented = at ICCRG) are documented in a white paper available here:

Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work w= ell in the cable environment, and for sharing the resulting code.  

Best Regards,
Greg

From: Preethi Natarajan <preethi.cis@gmail.com>
Date: Tuesday, April 23, 2013 5:18 = PM
To: "iccrg@irtf.org" <icc= rg@irtf.org>, "tsvwg@ietf.org= " <tsvwg@ietf.org>, &q= uot;aqm@ietf.org" <aqm@ietf.org>
Cc: "Rong Pan (ropan)" &l= t;ropan@cisco.com>, "Bill Ve= r Steeg (versteb)" <versteb@ci= sco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)&quo= t; <fred@cisco.com>
Subject: [aqm] Follow-up: PIE perfo= rmance in cable modem environments

Hello,

This is a follow-up to Greg White's (from = Cable Labs) talk at the recent ICCRG meeting on PIE's performance in cable = modem environments. 

Post the meeting, Greg was kind to share h= is ns-2 DOCSIS model with us. We investigated PIE's performance using this = model. The key items from this investigation: 
  1. Bug in PIE code: The previous PIE release (that Greg us= ed for evaluations) was missing a line of code. This missing line brings do= wn drop probability under certain conditions and turns out to be critical for the cable modem scenario. Without this li= ne of code, the drop probability remains high and takes longer to come down= even when the queue delay has remained lower than the reference. The updat= ed ns-2 PIE code can be found here =97 ftp://ftpeng.cisco.com/pi= e/.
  2. Bug in ns-2 TCP/Linux: Greg's cable = modem simulations used the TCP Cubic variant. We discovered a serious = bug in ns-2 TCP/Linux Agent (confirmed by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and unresponsive to packet dr= ops/notifications, pretty much like UDP traffic. Please find more details a= bout the bug here -- http:/= /sourceforge.net/tracker/?func=3Ddetail&aid=3D3608750&group_id=3D14= 9743&atid=3D775392.
We are working= with Cable Labs to verify the cable modem results, they'll soon be availab= le on our FTP site along with the PIE code.

A technical paper about PIE was recently a= ccepted at the IEEE Conference on High Performance Switching and Routing 20= 13. A copy of the paper is attached here.

The&nbs= p;Linux PIE implementation is expected to be ready by next week and we'll f= ollow-up on that as well. 

Many thanks,
Preethi on behalf of PIE team.
--_000_CDA991601166Cgwhitecablelabscom_-- From john@jlc.net Fri May 3 16:53:58 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E511F21F8F0D for ; Fri, 3 May 2013 16:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.779 X-Spam-Level: X-Spam-Status: No, score=-105.779 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syTOg0OTdWQo for ; Fri, 3 May 2013 16:53:45 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFE821F8B13 for ; Fri, 3 May 2013 16:53:45 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9C08A33C27; Fri, 3 May 2013 19:53:45 -0400 (EDT) Date: Fri, 3 May 2013 19:53:45 -0400 From: John Leslie To: Greg White Message-ID: <20130503235345.GP23227@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "iccrg@irtf.org" , "aqm@ietf.org" , Preethi Natarajan Subject: Re: [aqm] [iccrg] Follow-up: PIE performance in cable modem environments X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 23:53:59 -0000 Greg White wrote: > > I did a diff on the new version of the PIE code vs the earlier release > and found, as you stated, that the basic algorithm hasn't changed. > I do see some other improvements/changes though. One which, I think, > bears discussion is the weighting of packet drops based on size. > > In the new code there is the option (turned on in the simulations I > reported on in my paper) to drop packets according to > p*pkt_size/mean_pkt_size where p is the drop probability calculated by > the PIE control law. This serves to significantly decrease the drop > probability of the small VoIP and gaming packets, which may be > sensitive to loss (from a QoE perspective) and non-responsive to loss > (from a congestion control perspective). This is evidenced by the low > packet loss rate for gaming traffic that I reported in my paper. > > However, I worry that the unintended consequence may be that this > weighting incentivizes application developers toward the use of small > packets, which seems ill advised. The IESG has approved for publication as an RFC: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ which, basically, says "Don't do that". -- John Leslie From dave.taht@gmail.com Sat May 4 02:09:48 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773DB21F95EC for ; Sat, 4 May 2013 02:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55Ng400kViqG for ; Sat, 4 May 2013 02:09:44 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3262621F9539 for ; Sat, 4 May 2013 02:09:44 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id u16so1318883iet.0 for ; Sat, 04 May 2013 02:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dKHxX+PdJTTPPuDX4JSH3kJMMzXq6DahiRnlLOoteEk=; b=mrWb0DGvVkWEOTDQInaZxBB/PHjbiYnmsaEUp+B7pmB0x7wydJ6IeYz76gx5fqoGLJ 1iP2SfhvbYy8Dnoz6HRl3VlddFW9HQDCqs6/nwCoNqFYZucwCTDdrHDbXig4lHATG41G 222zfV1uz/cqillmgewosf3VOWrEWTEAuLPlRNWUBrrNYoDvd3Ys7I6KC2QN9d0y79yF 65zoQaNJ9tg38FGz8nOEa7RoWuhqeRby7ABK52qZ7qJUIj8I6gF6rEj0E5M96h7bznFv dgffV/5UVvueJ4IQvI+BaiDR+1fs2jUUIvDuOPu7jGbpOd6cECKJz3yEHLt620U0ON5X DMVg== MIME-Version: 1.0 X-Received: by 10.50.25.102 with SMTP id b6mr444452igg.27.1367658583614; Sat, 04 May 2013 02:09:43 -0700 (PDT) Received: by 10.64.7.51 with HTTP; Sat, 4 May 2013 02:09:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 May 2013 02:09:43 -0700 Message-ID: From: Dave Taht To: Greg White Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "iccrg@irtf.org" , "aqm@ietf.org" , Preethi Natarajan Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2013 09:09:48 -0000 On Fri, May 3, 2013 at 3:55 PM, Greg White wrote: > Preethi, > > I did a diff on the new version of the PIE code vs the earlier release an= d > found, as you stated, that the basic algorithm hasn't changed. I do see > some other improvements/changes though. One which, I think, bears > discussion is the weighting of packet drops based on size. > > In the new code there is the option (turned on in the simulations I repor= ted > on in my paper) to drop packets according to p*pkt_size/mean_pkt_size whe= re > p is the drop probability calculated by the PIE control law. This serves = to > significantly decrease the drop probability of the small VoIP and gaming > packets, which may be sensitive to loss (from a QoE perspective) and > non-responsive to loss (from a congestion control perspective). This is > evidenced by the low packet loss rate for gaming traffic that I reported = in > my paper. > > However, I worry that the unintended consequence may be that this weighti= ng > incentivizes application developers toward the use of small packets, whic= h > seems ill advised. > > Thoughts? Optimizing a little bit for smaller packets is an old trick that goes back to wondershaper, and most likely prior. Personally, I'd have liked it if the internet MTU had stayed below 580 until the world was running universally at above 4Mbits. As for how PIE does it, I haven't got the linux sources yet, so I haven't looked at it. the *fq_codel settings used in your study used a quantum of 300, which has much the same effect as however PIE is doing it, most likely. You can quibble as to how much to de-optimize for big packets, but it is generally a fairly reliable indicator of bulk vs ack or interactive traffic, and optimizing for the smaller packets is very useful on asymmetric low speed uplinks. It seems like an increasingly less useful optimization as speeds get higher and higher. There are some newer interactive protocols (videoconferencing comes to mind) where packet sizes of larger than 300 bytes seem possible, and DNSSEC bloats up dns packets - but for the vast majority of other sorts of traffic, acks, syns, normal dns, dhcp, voip, gaming, etc, optimizing for size a little bit is a win. As for disincentivizing the use of big packets, there are plenty of reasons for bulk transfers to try and send the biggest packet possible, and even if an app did start sending smaller packets the per-packet overhead of IP is increasingly trivial above 300 bytes, and in general smaller packets are better for the sharing of the network, anyway... >From wikipedia: "When data is formatted into packets, the bitrate of the communication medium can be better shared among users than if the network were circuit switched." > > -Greg > > > > From: Preethi Natarajan > Date: Tuesday, April 30, 2013 5:48 PM > To: Greg White , Preethi Natarajan > , "iccrg@irtf.org" , "tsvwg@ietf.o= rg" > , "aqm@ietf.org" > Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" > , "Chiara Piglione (cpiglion)" , > "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Bak= er > (fred)" , Dan Rice > > Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments > > Hi, > > Thank you Greg for the update and the link to the white paper. > > We wanted to quickly clarify about how we tuned PIE for DOCSIS. > > The basic PIE algorithm has not changed. We updated the simulation code w= ith > the missing line mentioned below (which was a bug). The DOCSIS MAC layer = has > this special nature of stop-and-go with 5ms-6ms request and grant delay. > This requires adjustment of any algorithm: for example CoDel has to > increase its target delay from 5ms to a higher value. Similarly, our new > parameters are to make PIE adjust faster for the DOCSIS stop-and-go > behavior. Please note that eventually all these design parameters will be > automatically set, users of the PIE algorithm would not be required to se= t > any design parameters. > > Again, many thanks for your update. > PIE team > > From: Greg White > Date: Tuesday, April 30, 2013 3:54 PM > To: Preethi Natarajan , "iccrg@irtf.org" > , "tsvwg@ietf.org" , "aqm@ietf.org" > > Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" > , "Chiara Piglione (cpiglion)" , > "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Bak= er > (fred)" , Daniel Rice > Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments > > Additionally, I've re-run my suite of simulations using the updated PIE c= ode > from Cisco. The results (in much more detail than I presented at ICCRG) = are > documented in a white paper available here: > Active Queue Management Algorithms for DOCSIS 3.0 > > Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well= in > the cable environment, and for sharing the resulting code. > > Best Regards, > Greg > > From: Preethi Natarajan > Date: Tuesday, April 23, 2013 5:18 PM > To: "iccrg@irtf.org" , "tsvwg@ietf.org" , > "aqm@ietf.org" > Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" > , "Chiara Piglione (cpiglion)" , > "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Bak= er > (fred)" > Subject: [aqm] Follow-up: PIE performance in cable modem environments > > Hello, > > This is a follow-up to Greg White's (from Cable Labs) talk at the recent > ICCRG meeting on PIE's performance in cable modem environments. > > Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. W= e > investigated PIE's performance using this model. The key items from this > investigation: > > Bug in PIE code: The previous PIE release (that Greg used for evaluations= ) > was missing a line of code. This missing line brings down drop probabilit= y > under certain conditions and turns out to be critical for the cable modem > scenario. Without this line of code, the drop probability remains high an= d > takes longer to come down even when the queue delay has remained lower th= an > the reference. The updated ns-2 PIE code can be found here =97 > ftp://ftpeng.cisco.com/pie/. > Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cubic > variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed b= y > Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and > unresponsive to packet drops/notifications, pretty much like UDP traffic. > Please find more details about the bug here -- > http://sourceforge.net/tracker/?func=3Ddetail&aid=3D3608750&group_id=3D14= 9743&atid=3D775392. > > We are working with Cable Labs to verify the cable modem results, they'll > soon be available on our FTP site along with the PIE code. > > A technical paper about PIE was recently accepted at the IEEE Conference = on > High Performance Switching and Routing 2013. A copy of the paper is attac= hed > here. > > The Linux PIE implementation is expected to be ready by next week and we'= ll > follow-up on that as well. > > Many thanks, > Preethi on behalf of PIE team. > > _______________________________________________ > 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 garmitage@swin.edu.au Sat May 4 02:45:44 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D95021F94FD; Sat, 4 May 2013 02:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7EX5GnoMdI6; Sat, 4 May 2013 02:45:38 -0700 (PDT) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5840721F91F1; Sat, 4 May 2013 02:45:38 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r449j2dV011176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 May 2013 19:45:03 +1000 Message-ID: <5184D89E.1050000@swin.edu.au> Date: Sat, 04 May 2013 19:45:02 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dave Taht References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Greg White , "iccrg@irtf.org" , "aqm@ietf.org" , Preethi Natarajan Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2013 09:45:44 -0000 On 05/04/2013 19:09, Dave Taht wrote: [..] > Personally, I'd have liked it if the internet MTU had stayed below 580 > until the world was running universally at above 4Mbits. IP over ATM, FTW ;) cheers, gja From fred@cisco.com Mon May 6 07:00:12 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA2D21F8A74 for ; Mon, 6 May 2013 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.052 X-Spam-Level: X-Spam-Status: No, score=-110.052 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63sfL28vnfUn for ; Mon, 6 May 2013 07:00:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F159121F9130 for ; Mon, 6 May 2013 07:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=269; q=dns/txt; s=iport; t=1367848807; x=1369058407; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5cXALaOKubYjjCpYAo3a+JW1ADg13/n6o4j1X83vTu4=; b=JQoiP/Az890PDpFSPx/TtrZmMkhLw+MawPhkUhpQxhna2QHvW1i3/5pA DyEJqhToXDIqRnWcv84mHZj4HKi4YtCLBxXfJ7eye8Pr4e0biWgarKLdq 9Z65xzOu6WZwAIpr6cPwwLShMLf5RudGdWOSzUYHfEkDWLTrVVivtVwXv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAAC3h1GtJXG8/2dsb2JhbABQgwc3gnW8DYEEFm0HgiEBBDpRASoUQicEG4gEDKB4nm6PAIMqYQOYVJAOgw2CJw X-IronPort-AV: E=Sophos;i="4.87,622,1363132800"; d="scan'208";a="206907772" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 06 May 2013 14:00:06 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r46E062V023814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 May 2013 14:00:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 6 May 2013 09:00:06 -0500 From: "Fred Baker (fred)" To: "aqm@ietf.org" Thread-Topic: Question re draft-baker-aqm-recommendations recomendation #4 Thread-Index: AQHOSmIC+wKluQHy+U2FD9Rc1I8WAw== Date: Mon, 6 May 2013 14:00:05 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <70B6167C6F3B5C4EB6D2E18FD9843C49@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 14:00:12 -0000 Do we generally agree with the recommendation of http://tools.ietf.org/html= /draft-baker-aqm-recommendation-01#section-4.4? This is the question of ens= uring that AQM technologies are applicable to all Internet traffic - not ju= st TCP, but UDP, SCTP, and so on. From michawe@ifi.uio.no Mon May 6 07:25:39 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203CD21F9049 for ; Mon, 6 May 2013 07:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrEMt3bTjS1i for ; Mon, 6 May 2013 07:25:33 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id D2A8821F8F0E for ; Mon, 6 May 2013 07:25:27 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UZMM2-000380-CF; Mon, 06 May 2013 16:25:26 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UZMM1-0000ro-VC; Mon, 06 May 2013 16:25:26 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> Date: Mon, 6 May 2013 16:25:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 10 sum msgs/h 4 total rcpts 4138 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.7, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.653, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A29C2F0ED15E60A535B7D6AEFDE1DE471F761A82 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -56 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1840 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: aqm@ietf.org Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 14:25:39 -0000 Hi, First of all, I'd like to say that I agree with all the recommendations = you asked about so far. I hesitated to answer as I wasn't sure if a ton = of "yes I do" responses are useful?! About this recommendation, I agree regarding what it actually = recommends, but I have a comment about the wording. This bit: "Hence, Active Queue Management algorithms that are effective with all = of those transports and the applications that use them are to be = preferred." sounds as if it would be the most normal thing in the world for an AQM = algorithm to make a decision based on the transport protocol, which I = think it shouldn't. To me, ECN is an IP-layer signal and routers = shouldn't have to investigate what's layered on it (which may go beyond = just looking at the "protocol" field in case of tunnels) in order to = make their decisions. I tried to come up with a better phrasing but failed... maybe it could = be an idea to just add a sentence after this one, saying something like = "Such algorithms do not need to consider any information in the packet = beyond its IP header." Cheers, Michael On 6. mai 2013, at 16:00, Fred Baker (fred) wrote: > Do we generally agree with the recommendation of = http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.4? = This is the question of ensuring that AQM technologies are applicable to = all Internet traffic - not just TCP, but UDP, SCTP, and so on. >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From linda.dunbar@huawei.com Mon May 6 07:36:55 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B58C21F861B for ; Mon, 6 May 2013 07:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTZfxEH0vBVP for ; Mon, 6 May 2013 07:36:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2959D21F93A3 for ; Mon, 6 May 2013 07:36:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASM43229; Mon, 06 May 2013 14:36:31 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 6 May 2013 15:35:28 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 6 May 2013 15:36:29 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.204]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Mon, 6 May 2013 07:36:25 -0700 From: Linda Dunbar To: "Fred Baker (fred)" , "aqm@ietf.org" Thread-Topic: Question re draft-baker-aqm-recommendations recomendation #4 Thread-Index: AQHOSmIC+wKluQHy+U2FD9Rc1I8WA5j4OWCw Date: Mon, 6 May 2013 14:36:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B1856E@dfweml509-mbx.china.huawei.com> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 14:36:55 -0000 Agree.=20 Linda > -----Original Message----- > From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: Monday, May 06, 2013 9:00 AM > To: aqm@ietf.org > Subject: [aqm] Question re draft-baker-aqm-recommendations > recomendation #4 >=20 > Do we generally agree with the recommendation of > http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section- > 4.4? This is the question of ensuring that AQM technologies are > applicable to all Internet traffic - not just TCP, but UDP, SCTP, and > so on. >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From fred@cisco.com Mon May 6 09:49:11 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840BA21F90DF for ; Mon, 6 May 2013 09:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+vi97YQRbL6 for ; Mon, 6 May 2013 09:49:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A222421F90B1 for ; Mon, 6 May 2013 09:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2163; q=dns/txt; s=iport; t=1367858946; x=1369068546; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9YHVV7+dWmhANfsG9ObKYD03cNskbPNs9wkScd5f1Ew=; b=lCK222NIbJkiRE2gDJhrN+pw6ScVkjEAH/2O0lkxVl2gBoTcSvxem/Am 80rKbUzN7/EK1zKWMa8YlyrQKj+XnASPtGgsKVDGHVmq6HBTZMP5JS2zM HGm3qTe6uaMc9eRYElXpiEpKlj/NV3g4SxmY4LiunhNIdozCJTOw2pP6L o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMHdh1GtJV2Y/2dsb2JhbABQgwc3vnyBAhZ0gh8BAQEDAQEBATc0CwULAgEIDgoKFBAnCyUCBA4FCId+Bgy/bI5+AjEHgnJhA5NfhHWQDoMNgic X-IronPort-AV: E=Sophos;i="4.87,622,1363132800"; d="scan'208";a="206973149" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 06 May 2013 16:49:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r46Gn6Te012608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 16:49:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 6 May 2013 11:49:05 -0500 From: "Fred Baker (fred)" To: Michael Welzl Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 Thread-Index: AQHOSnmeXY+bsHW5GUOsXJsz145jDQ== Date: Mon, 6 May 2013 16:49:05 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> In-Reply-To: <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] 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] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 16:49:11 -0000 On May 6, 2013, at 7:25 AM, Michael Welzl wrote: > Hi, >=20 > First of all, I'd like to say that I agree with all the recommendations y= ou asked about so far. I hesitated to answer as I wasn't sure if a ton of "= yes I do" responses are useful?! >=20 > About this recommendation, I agree regarding what it actually recommends,= but I have a comment about the wording. This bit: >=20 > "Hence, Active Queue Management algorithms that are effective with all of= those transports and the applications that use them are to be preferred." >=20 > sounds as if it would be the most normal thing in the world for an AQM al= gorithm to make a decision based on the transport protocol, which I think i= t shouldn't. To me, ECN is an IP-layer signal and routers shouldn't have to= investigate what's layered on it (which may go beyond just looking at the = "protocol" field in case of tunnels) in order to make their decisions. Thanks. I certainly agree that we should not be making transport-specific m= odifications; that was one thing that bothered me with cones, that it seeme= d to expect a different ECN encoding based on the DSCP. My point in this, i= f you can think of a better way to phrase it, is that the AQM algorithm som= eone implements needs to demonstrably work with the transports and applicat= ions it will be affecting. > I tried to come up with a better phrasing but failed... maybe it could be= an idea to just add a sentence after this one, saying something like "Such= algorithms do not need to consider any information in the packet beyond it= s IP header." >=20 > Cheers, > Michael >=20 >=20 > On 6. mai 2013, at 16:00, Fred Baker (fred) wrote: >=20 >> Do we generally agree with the recommendation of http://tools.ietf.org/h= tml/draft-baker-aqm-recommendation-01#section-4.4? This is the question of = ensuring that AQM technologies are applicable to all Internet traffic - not= just TCP, but UDP, SCTP, and so on. >>=20 >>=20 >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >=20 From john@jlc.net Mon May 6 12:17:33 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9519321F87D2 for ; Mon, 6 May 2013 12:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.773 X-Spam-Level: X-Spam-Status: No, score=-103.773 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4kIOa38zFy2 for ; Mon, 6 May 2013 12:17:28 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 44FFD21F87CD for ; Mon, 6 May 2013 12:17:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4526933C22; Mon, 6 May 2013 15:17:25 -0400 (EDT) Date: Mon, 6 May 2013 15:17:25 -0400 From: John Leslie To: Michael Welzl Message-ID: <20130506191725.GV23227@verdi> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> User-Agent: Mutt/1.4.1i Cc: "Fred Baker \(fred\)" , aqm@ietf.org Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 19:17:33 -0000 Michael Welzl wrote: > > About this recommendation, I agree regarding what it actually > recommends, but I have a comment about the wording. This bit: > > "Hence, Active Queue Management algorithms that are effective with > all of those transports and the applications that use them are to be > preferred." >... I think some wordsmithing would help... ] ] 4.4. Active Queue Management algorithms deployed SHOULD be effective on ] all common Internet traffic At the outset, do we mean to say that AQM specifications SHOULD have, e.g., a "UDP Considerations" section? (That's one way to read this.) Or do we mean that AQM SHOULD NOT be optimized for TCP? Or do we mean there exist some magical principles which enable AQM designers to optimize for IP traffic we haven't thought of yet? ] Active Queue Management algorithms often target TCP [RFC0793], as it ] is by far the predominant transport in the Internet today. However, ] we have significant use of UDP [RFC0768] in voice and video services, ] and find utility in SCTP [RFC4960] and DCCP [RFC4340]. Hence, Active ] Queue Management algorithms that are effective with all of those ] transports and the applications that use them are to be preferred. I'm not the least bit sure that "target TCP" is the point. There's an incredible range of traffic carried over TCP. It's typical for an AQM proposal to be tested in terms of how a bulk-transfer TCP reacts vs. an "interactive" web session series of "short" TCP streams. This, IMHO, isn't "targetting" TCP, but rather comparing bulk transfer vs. on-demand short-transfer -- where both happen to use TCP transport. They could just as well be using SCTP or any of several other transports. Do we mean to say that things would be significantly better if the tests were altered to use SCTP for some of the sessions? Besides, whether sessions are mixed transports or all TCP, the congestion-control algorithms are in fact varied. Don't we mean to say that AQM algorithms SHOULD work with a variety of congestion control algorithms? If we do mean to require consideration of multiple _transports_, what do we wish to see considered? I don't get much of a hint from this text. Back to Michael: > sounds as if it would be the most normal thing in the world for an > AQM algorithm to make a decision based on the transport protocol, > which I think it shouldn't. That's certainly one "solution"... And I also dislike it. > To me, ECN is an IP-layer signal and routers shouldn't have to > investigate what's layered on it (which may go beyond just looking > at the "protocol" field in case of tunnels) in order to make their > decisions. Yes, but... It seems unlikely that we're going to get a fully satisfactory AQM without separate queues for different flows. I'd like to believe the IPv6 flow label can give us what we need, but that's optimistic... > I tried to come up with a better phrasing but failed... maybe it > could be an idea to just add a sentence after this one, saying > something like "Such algorithms do not need to consider any > information in the packet beyond its IP header." I think more substantial rewording is needed. I'll be happy to suggest wording _after_ I see a better understanding of what we mean to say here. -- John Leslie From michawe@ifi.uio.no Mon May 6 12:36:28 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750DA21F9283 for ; Mon, 6 May 2013 12:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.886 X-Spam-Level: X-Spam-Status: No, score=-99.886 tagged_above=-999 required=5 tests=[AWL=-0.114, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUXq9-RYNpAN for ; Mon, 6 May 2013 12:36:22 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB221F9121 for ; Mon, 6 May 2013 12:36:22 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UZRCq-0002Dw-Bn; Mon, 06 May 2013 21:36:16 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UZRCp-0007fx-M3; Mon, 06 May 2013 21:36:16 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <20130506191725.GV23227@verdi> Date: Mon, 6 May 2013 21:36:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CCF558E-975C-4C86-9D67-CA431CC6FBA1@ifi.uio.no> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <20130506191725.GV23227@verdi> To: John Leslie X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 16 sum msgs/h 5 total rcpts 4159 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A762A3F404346226190B215503796387E9642B0F X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 513 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "Fred Baker \(fred\)" , aqm@ietf.org Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 19:36:28 -0000 On May 6, 2013, at 9:17 PM, John Leslie wrote: > Michael Welzl wrote: >>=20 >> About this recommendation, I agree regarding what it actually >> recommends, but I have a comment about the wording. This bit: >>=20 >> "Hence, Active Queue Management algorithms that are effective with >> all of those transports and the applications that use them are to be >> preferred." >> ... >=20 > I think some wordsmithing would help... > ]=20 > ] 4.4. Active Queue Management algorithms deployed SHOULD be effective = on > ] all common Internet traffic >=20 > At the outset, do we mean to say that AQM specifications SHOULD > have, e.g., a "UDP Considerations" section? (That's one way to read > this.) >=20 > Or do we mean that AQM SHOULD NOT be optimized for TCP? >=20 > Or do we mean there exist some magical principles which enable > AQM designers to optimize for IP traffic we haven't thought of yet? >=20 > ] Active Queue Management algorithms often target TCP [RFC0793], as = it > ] is by far the predominant transport in the Internet today. = However, > ] we have significant use of UDP [RFC0768] in voice and video = services, > ] and find utility in SCTP [RFC4960] and DCCP [RFC4340]. Hence, = Active > ] Queue Management algorithms that are effective with all of those > ] transports and the applications that use them are to be preferred.=20= >=20 > I'm not the least bit sure that "target TCP" is the point. There's > an incredible range of traffic carried over TCP. It's typical for an > AQM proposal to be tested in terms of how a bulk-transfer TCP reacts > vs. an "interactive" web session series of "short" TCP streams. This, > IMHO, isn't "targetting" TCP, but rather comparing bulk transfer vs. > on-demand short-transfer -- where both happen to use TCP transport. > They could just as well be using SCTP or any of several other = transports. >=20 > Do we mean to say that things would be significantly better if the > tests were altered to use SCTP for some of the sessions? >=20 > Besides, whether sessions are mixed transports or all TCP, the > congestion-control algorithms are in fact varied. Don't we mean to say > that AQM algorithms SHOULD work with a variety of congestion control > algorithms? >=20 > If we do mean to require consideration of multiple _transports_, > what do we wish to see considered? I don't get much of a hint from > this text. >=20 > Back to Michael: >=20 >> sounds as if it would be the most normal thing in the world for an >> AQM algorithm to make a decision based on the transport protocol, >> which I think it shouldn't. >=20 > That's certainly one "solution"... And I also dislike it. >=20 >> To me, ECN is an IP-layer signal and routers shouldn't have to >> investigate what's layered on it (which may go beyond just looking >> at the "protocol" field in case of tunnels) in order to make their >> decisions. >=20 > Yes, but... >=20 > It seems unlikely that we're going to get a fully satisfactory AQM > without separate queues for different flows. I'd like to believe the > IPv6 flow label can give us what we need, but that's optimistic=85 Seems like a case of "more specific and more complicated" vs. "more = vague but perhaps good enough" to me. I don't think that there's a = reasonable way to be more specific here, but maybe I'm just missing it. Cheers, Michael >> I tried to come up with a better phrasing but failed... maybe it >> could be an idea to just add a sentence after this one, saying >> something like "Such algorithms do not need to consider any >> information in the packet beyond its IP header." >=20 > I think more substantial rewording is needed. I'll be happy to > suggest wording _after_ I see a better understanding of what we mean > to say here. >=20 > -- > John Leslie From john@jlc.net Tue May 7 06:37:29 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2D621F8FB2 for ; Tue, 7 May 2013 06:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.779 X-Spam-Level: X-Spam-Status: No, score=-105.779 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcWRvtLXjZxW for ; Tue, 7 May 2013 06:37:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 79F3921F8FB6 for ; Tue, 7 May 2013 06:37:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 332E133C21; Tue, 7 May 2013 09:37:24 -0400 (EDT) Date: Tue, 7 May 2013 09:37:24 -0400 From: John Leslie To: "Fred Baker (fred)" Message-ID: <20130507133724.GY23227@verdi> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> User-Agent: Mutt/1.4.1i Cc: aqm@ietf.org, Michael Welzl Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2013 13:37:29 -0000 Fred Baker (fred) wrote: > On May 6, 2013, at 7:25 AM, Michael Welzl wrote: > >> ...sounds as if it would be the most normal thing in the world for an >> AQM algorithm to make a decision based on the transport protocol, >> which I think it shouldn't... > > I certainly agree that we should not be making transport-specific > modifications... > My point in this, if you can think of a better way to phrase it, is > that the AQM algorithm someone implements needs to demonstrably work > with the transports and applications it will be affecting. Hearing no differing suggestions, those words seem appropriate. Thus Section 4.4 might become: " " 4.4. Active Queue Management algorithms deployed SHOULD be effective on " all common Internet traffic " " Active Queue Management algorithms typically are verified to work with " TCP [RFC0793] and a limited number of applications of it. This no " longer represents a sufficient selection of actual traffic. We have " significant use of UDP [RFC0768] in voice and video services, as well " as SCTP [RFC4960] and DCCP [RFC4340]. Hence, Active Queue Management " algorithms should demonstrably work with other transports as well as " TCP, and with a wide variety of applications. -- John Leslie From g.white@CableLabs.com Tue Apr 30 15:54:53 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35A221F84E9; Tue, 30 Apr 2013 15:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TjL6+vcQqbF; Tue, 30 Apr 2013 15:54:49 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC32821F8506; Tue, 30 Apr 2013 15:54:48 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r3UMsiUO016133; Tue, 30 Apr 2013 16:54:45 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 30 Apr 2013 16:54:44 -0600 (MDT) 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.0123.003; Tue, 30 Apr 2013 16:54:45 -0600 From: Greg White To: Preethi Natarajan , "iccrg@irtf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Thread-Topic: [aqm] Follow-up: PIE performance in cable modem environments Thread-Index: AQHOQHkKaa+IaeVR9EG660JnW8MhmZjvanOA Date: Tue, 30 Apr 2013 22:54:44 +0000 Message-ID: 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.2.130206 x-originating-ip: [10.4.10.57] Content-Type: multipart/alternative; boundary="_000_CDA5A55A10F28gwhitecablelabscom_" MIME-Version: 1.0 X-Approved: ondar X-Mailman-Approved-At: Tue, 07 May 2013 09:16:36 -0700 Cc: "Chiara Piglione \(cpiglion\)" , "Bill Ver Steeg \(versteb\)" , "Fred Baker \(fred\)" , "Rong Pan \(ropan\)" , Daniel Rice , "Mythili Suryanarayana Prabhu \(mysuryan\)" Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2013 22:54:53 -0000 --_000_CDA5A55A10F28gwhitecablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Additionally, I've re-run my suite of simulations using the updated PIE cod= e from Cisco. The results (in much more detail than I presented at ICCRG) = are documented in a white paper available here: Active Queue Management Algorithms for DOCSIS 3.0 Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well i= n the cable environment, and for sharing the resulting code. Best Regards, Greg From: Preethi Natarajan > Date: Tuesday, April 23, 2013 5:18 PM To: "iccrg@irtf.org" >, "tsvwg@ietf.org" >, "aqm@ietf.org" > Cc: "Rong Pan (ropan)" >, "Bill Ver= Steeg (versteb)" >, "Chiara Pi= glione (cpiglion)" >, "Mythil= i Suryanarayana Prabhu (mysuryan)" >, "Fred Baker (fred)" > Subject: [aqm] Follow-up: PIE performance in cable modem environments Hello, This is a follow-up to Greg White's (from Cable Labs) talk at the recent IC= CRG meeting on PIE's performance in cable modem environments. Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We = investigated PIE's performance using this model. The key items from this in= vestigation: 1. Bug in PIE code: The previous PIE release (that Greg used for evaluat= ions) was missing a line of code. This missing line brings down drop probab= ility under certain conditions and turns out to be critical for the cable m= odem scenario. Without this line of code, the drop probability remains high= and takes longer to come down even when the queue delay has remained lower= than the reference. The updated ns-2 PIE code can be found here =97 ftp://= ftpeng.cisco.com/pie/. 2. Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cu= bic variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed= by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive an= d unresponsive to packet drops/notifications, pretty much like UDP traffic.= Please find more details about the bug here -- http://sourceforge.net/trac= ker/?func=3Ddetail&aid=3D3608750&group_id=3D149743&atid=3D775392. We are working with Cable Labs to verify the cable modem results, they'll s= oon be available on our FTP site along with the PIE code. A technical paper about PIE was recently accepted at the IEEE Conference on= High Performance Switching and Routing 2013. A copy of the paper is attach= ed here. The Linux PIE implementation is expected to be ready by next week and we'll= follow-up on that as well. Many thanks, Preethi on behalf of PIE team. --_000_CDA5A55A10F28gwhitecablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Additionally, I've re-run my suite of simulations using the updated PI= E code from Cisco.  The results (in much more detail than I presented = at ICCRG) are documented in a white paper available here:

Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work w= ell in the cable environment, and for sharing the resulting code.  

Best Regards,
Greg

From: Preethi Natarajan <preethi.cis@gmail.com>
Date: Tuesday, April 23, 2013 5:18 = PM
To: "iccrg@irtf.org" <icc= rg@irtf.org>, "tsvwg@ietf.org= " <tsvwg@ietf.org>, &q= uot;aqm@ietf.org" <aqm@ietf.org>
Cc: "Rong Pan (ropan)" &l= t;ropan@cisco.com>, "Bill Ve= r Steeg (versteb)" <versteb@ci= sco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)&quo= t; <fred@cisco.com>
Subject: [aqm] Follow-up: PIE perfo= rmance in cable modem environments

Hello,

This is a follow-up to Greg White's (from = Cable Labs) talk at the recent ICCRG meeting on PIE's performance in cable = modem environments. 

Post the meeting, Greg was kind to share h= is ns-2 DOCSIS model with us. We investigated PIE's performance using this = model. The key items from this investigation: 
  1. Bug in PIE code: The previous PIE release (that Greg us= ed for evaluations) was missing a line of code. This missing line brings do= wn drop probability under certain conditions and turns out to be critical for the cable modem scenario. Without this li= ne of code, the drop probability remains high and takes longer to come down= even when the queue delay has remained lower than the reference. The updat= ed ns-2 PIE code can be found here =97 ftp://ftpeng.cisco.com/pi= e/.
  2. Bug in ns-2 TCP/Linux: Greg's cable = modem simulations used the TCP Cubic variant. We discovered a serious = bug in ns-2 TCP/Linux Agent (confirmed by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and unresponsive to packet dr= ops/notifications, pretty much like UDP traffic. Please find more details a= bout the bug here -- http:/= /sourceforge.net/tracker/?func=3Ddetail&aid=3D3608750&group_id=3D14= 9743&atid=3D775392.
We are working= with Cable Labs to verify the cable modem results, they'll soon be availab= le on our FTP site along with the PIE code.

A technical paper about PIE was recently a= ccepted at the IEEE Conference on High Performance Switching and Routing 20= 13. A copy of the paper is attached here.

The&nbs= p;Linux PIE implementation is expected to be ready by next week and we'll f= ollow-up on that as well. 

Many thanks,
Preethi on behalf of PIE team.
 --_000_CDA5A55A10F28gwhitecablelabscom_-- From preethi.cis@gmail.com Tue Apr 30 16:48:16 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E3E21F87FB; Tue, 30 Apr 2013 16:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm6Sydr+NQUD; Tue, 30 Apr 2013 16:48:11 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id BA5D421F86F4; Tue, 30 Apr 2013 16:48:11 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kq12so623390pab.14 for ; Tue, 30 Apr 2013 16:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=qhn62pCeOZFO+6CvNndCoyuwGwhSQU9ZQM1WemMcEfY=; b=0zrToJwDT3OyQh0sw1L9FdgEPkNEwv2s2gdUUu+hfdje1cWs3msyjmf1lXmiHmuoaw QKU7gDYzD3VOF5fjhx3TATFZk1bUnVOaCOGDEo5JenOgwQOKaOnCk8p1/JNFHhmfuJ6M VNcnoA7fLarwGMfEe7ZmhedRYNF/PMHuyqWojVnpkXaBqdPSZX55zIUeSHT0X3K22Z/q EjLaQFF4oH3k4cmBEVklntMZMmq1PfdUy7aZXHk+0T1QD8SsMeca/HAIke0tStyoET/Z AQZzfzcZz2IaUW6l3j6cZF9t4+JHuqAB5vHLN9e1heZyAp2lboCV/6YqljmsWQJIBAAw Uveg== X-Received: by 10.66.221.37 with SMTP id qb5mr1715753pac.75.1367365691486; Tue, 30 Apr 2013 16:48:11 -0700 (PDT) Received: from [10.33.22.215] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id jw10sm534808pbb.3.2013.04.30.16.48.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Apr 2013 16:48:10 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.1.120420 Date: Tue, 30 Apr 2013 16:48:04 -0700 From: Preethi Natarajan To: Greg White , Preethi Natarajan , "iccrg@irtf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Message-ID: Thread-Topic: [aqm] Follow-up: PIE performance in cable modem environments In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3450185290_37846598" X-Mailman-Approved-At: Tue, 07 May 2013 09:16:36 -0700 Cc: "Chiara Piglione \(cpiglion\)" , "Bill Ver Steeg \(versteb\)" , "Fred Baker \(fred\)" , "Rong Pan \(ropan\)" , Daniel Rice , "Mythili Suryanarayana Prabhu \(mysuryan\)" Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2013 23:48:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3450185290_37846598 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Thank you Greg for the update and the link to the white paper. We wanted to quickly clarify about how we tuned PIE for DOCSIS. The basic PIE algorithm has not changed. We updated the simulation code wit= h the missing line mentioned below (which was a bug). The DOCSIS MAC layer ha= s this special nature of stop-and-go with 5ms-6ms request and grant delay. This requires adjustment of any algorithm: for example CoDel has to increase its target delay from 5ms to a higher value. Similarly, our new parameters are to make PIE adjust faster for the DOCSIS stop-and-go behavior. Please note that eventually all these design parameters will be automatically set, users of the PIE algorithm would not be required to set any design parameters. Again, many thanks for your update. PIE team From: Greg White Date: Tuesday, April 30, 2013 3:54 PM To: Preethi Natarajan , "iccrg@irtf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" , "Chiara Piglione (cpiglion)" , "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Baker (fred)" , Daniel Rice Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments Additionally, I've re-run my suite of simulations using the updated PIE cod= e from Cisco. The results (in much more detail than I presented at ICCRG) ar= e documented in a white paper available here: Active Queue Management Algorithms for DOCSIS 3.0 =20 Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well i= n the cable environment, and for sharing the resulting code. Best Regards, Greg From: Preethi Natarajan Date: Tuesday, April 23, 2013 5:18 PM To: "iccrg@irtf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" , "Chiara Piglione (cpiglion)" , "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Baker (fred)" Subject: [aqm] Follow-up: PIE performance in cable modem environments Hello, This is a follow-up to Greg White's (from Cable Labs) talk at the recent ICCRG meeting on PIE's performance in cable modem environments. Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We investigated PIE's performance using this model. The key items from this investigation:=20 1. Bug in PIE code: The previous PIE release (that Greg used for evaluations) was missing a line of code. This missing line brings down drop probability under certain conditions and turns out to be critical for the cable modem scenario. Without this line of code, the drop probability remains high and takes longer to come down even when the queue delay has remained lower than the reference. The updated ns-2 PIE code can be found here =8B ftp://ftpeng.cisco.com/pie/. 2. Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cubic variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and unresponsive to packet drops/notifications, pretty much like UDP traffic. Please find more details about the bug here -- http://sourceforge.net/tracker/?func=3Ddetail&aid=3D3608750&group_id=3D149743&ati= d =3D775392. We are working with Cable Labs to verify the cable modem results, they'll soon be available on our FTP site along with the PIE code. A technical paper about PIE was recently accepted at the IEEE Conference on High Performance Switching and Routing 2013. A copy of the paper is attache= d here. The Linux PIE implementation is expected to be ready by next week and we'll follow-up on that as well. Many thanks, Preethi on behalf of PIE team. --B_3450185290_37846598 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi,

Thank you Greg for the update = and the link to the white paper.

We wanted to quick= ly clarify about how we tuned PIE for DOCSIS.

The basic PIE algorith= m has not changed. We updated the simulation code with the missing line ment= ioned below (which was a bug). The DOCSIS MAC layer has this special nature of stop= -and-go with 5ms-6ms request and grant delay. This requires adjustment of an= y algorithm: for example  CoDel has to increase its target delay from 5= ms to a higher value. Similarly, our new parameters are to make PIE adjust f= aster for the DOCSIS stop-and-go behavior. Please note that eventually all t= hese design parameters will be automatically set, users of the PIE algorithm= would not be required to set any design parameters. 

Again, many thanks for your update. 
PIE team

From: Greg White <g.white= @CableLabs.com>
Date: Tuesd= ay, April 30, 2013 3:54 PM
To: Pre= ethi Natarajan <preethi.cis@gmail.= com>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.or= g>, "aqm@ietf.org" <aqm@ietf.org>
Cc:= "Rong Pan (ropan)" <ropan@cisco= .com>, "Bill Ver Steeg (versteb)" <versteb@cisco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>, "Mythili Suryanarayana P= rabhu (mysuryan)" <mysuryan@cisco.com= >, "Fred Baker (fred)" <fred@cisco= .com>, Daniel Rice <D.Rice@C= ableLabs.com>
Subject: Re: = [aqm] Follow-up: PIE performance in cable modem environments
<= br>
Additionally, I've re-run my suite of= simulations using the updated PIE code from Cisco.  The results (in mu= ch more detail than I presented at ICCRG) are documented in a white paper av= ailable here:

Th= anks to Preethi, Rong, et al. for debugging and tuning PIE to work well in t= he cable environment, and for sharing the resulting code.  
<= br>
Best Regards,
Greg

From: Preethi Natarajan <preethi.cis@gmail.com>
Date: Tuesday, April 23, 2013 5:18 PM
To: "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.= org>, "aqm@ietf.org" <aqm@ietf.org>
Cc: "Rong Pan (ropan)" <ropan@cisco.com>, "Bill Ver Steeg (versteb)" <versteb@cisco.com>, "Chiara Piglione (cpiglion)"= <cpiglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)" <fred@cisco.com>
Sub= ject: [aqm] Follow-up: PIE performance in cable modem environments

Hel= lo,

This is a follow-up to Greg White's (from Cable Labs) talk at the recen= t ICCRG meeting on PIE's performance in cable modem environments. 

Pos= t the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We inve= stigated PIE's performance using this model. The key items from this investi= gation: 
  1. Bug in PIE code: The previous PIE releas= e (that Greg used for evaluations) was missing a line of code. This missing = line brings down drop probability under certain conditions and turns out to be critical for the cable modem scenario. Without this li= ne of code, the drop probability remains high and takes longer to come down = even when the queue delay has remained lower than the reference. The updated= ns-2 PIE code can be found here — ftp://ftpeng.cisco.com/= pie/.
  2. Bug in ns-2 TCP/Linux: Greg's cable modem = simulations used the TCP Cubic variant. We discovered a serious bug in = ns-2 TCP/Linux Agent (confirmed by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and unresponsive to packet dr= ops/notifications, pretty much like UDP traffic. Please find more details ab= out the bug here -- http://sourceforge.ne= t/tracker/?func=3Ddetail&aid=3D3608750&group_id=3D149743&atid=3D775392.
We are work= ing with Cable Labs to verify the cable modem results, they'll soon be avail= able on our FTP site along with the PIE code.
The Linux PIE implementation is expected to be= ready by next week and we'll follow-up on that as well. 

Many thanks,
Preethi on behalf of PIE team.
=
--B_3450185290_37846598-- From preethi.cis@gmail.com Tue May 7 16:28:32 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC5D21F8EFD for ; Tue, 7 May 2013 16:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LkjBap-9lCy for ; Tue, 7 May 2013 16:28:28 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 54C4021F8F03 for ; Tue, 7 May 2013 16:28:27 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id wy7so761030pbc.38 for ; Tue, 07 May 2013 16:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=zpY4OaCPLi6PPpcpMA5KN27mT2wQ80oC6vBaZPSEqcM=; b=p7c4/euc9iEWfFjD7w40Qp+2fg/GiUe0sRh2OExwbKa5KMWzqIL8d9XV4sUV9Y6GiM 3Y/Cde/3P7C36Pind6A9qHheTkZZ5vLea/GBiOGvOX/uh1ZE9CHynfOm7nfTdxbNDy/e 7ChId060hl6DaaJtlMVNd0Fjk5GOEAoWJNFsNy/6vYGw0eBVzQGE3IElIx/2dyDkxZUb XhtlN0ewTKBasvO/8tRxo/FQW9lNNgbzgzthSCKnJqEKoNePEEzdLifCu+917EccvYyS tKjm/thOaXSn04A0M1p0gvQqr9cKS/Rt8AOAu3yJE616KjnZ1f9jR/eJ0ZGhqoQRqBnb dDQA== X-Received: by 10.66.251.39 with SMTP id zh7mr5270721pac.62.1367969307014; Tue, 07 May 2013 16:28:27 -0700 (PDT) Received: from [10.33.22.215] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id lq5sm32127103pab.19.2013.05.07.16.28.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 16:28:26 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.1.120420 Date: Tue, 07 May 2013 16:28:21 -0700 From: Preethi Natarajan To: Greg White , "iccrg@irtf.org" , "aqm@ietf.org" , "Rong Pan (ropan)" Message-ID: Thread-Topic: [aqm] Follow-up: PIE performance in cable modem environments In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3450788905_47253895" Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2013 23:28:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3450788905_47253895 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Greg, As other posts point out, the byte-mode operation has been around for a while and it is not unique/new to PIE. We weren't aware of Bob Briscoe's BCP draft until recently. We understand the concerns mentioned here. In fact, we encountered the DropTail's preferential treatment for small packets in our simulations (mentioned in the BCP draft) and that was our motivation to experiment with byte-mode. We think that a good alternative to byte-mode would be ToS/DiffServe-field based differential dropping, similar to WRED, since that would give similar benefits as byte-mode. That way, we don't have to stick to byte-mode based approach for PIE. Regards, The PIE Team From: Greg White Date: Friday, May 3, 2013 3:55 PM To: Preethi Natarajan , "iccrg@irtf.org" , "aqm@ietf.org" Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments Preethi, I did a diff on the new version of the PIE code vs the earlier release and found, as you stated, that the basic algorithm hasn't changed. I do see some other improvements/changes though. One which, I think, bears discussion is the weighting of packet drops based on size. In the new code there is the option (turned on in the simulations I reporte= d on in my paper) to drop packets according to p*pkt_size/mean_pkt_size where p is the drop probability calculated by the PIE control law. This serves to significantly decrease the drop probability of the small VoIP and gaming packets, which may be sensitive to loss (from a QoE perspective) and non-responsive to loss (from a congestion control perspective). This is evidenced by the low packet loss rate for gaming traffic that I reported in my paper. However, I worry that the unintended consequence may be that this weighting incentivizes application developers toward the use of small packets, which seems ill advised. Thoughts? -Greg From: Preethi Natarajan Date: Tuesday, April 30, 2013 5:48 PM To: Greg White , Preethi Natarajan , "iccrg@irtf.org" , "tsvwg@ietf.org= " , "aqm@ietf.org" Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" , "Chiara Piglione (cpiglion)" , "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Baker (fred)" , Dan Rice Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments Hi, Thank you Greg for the update and the link to the white paper. We wanted to quickly clarify about how we tuned PIE for DOCSIS. The basic PIE algorithm has not changed. We updated the simulation code wit= h the missing line mentioned below (which was a bug). The DOCSIS MAC layer ha= s this special nature of stop-and-go with 5ms-6ms request and grant delay. This requires adjustment of any algorithm: for example CoDel has to increase its target delay from 5ms to a higher value. Similarly, our new parameters are to make PIE adjust faster for the DOCSIS stop-and-go behavior. Please note that eventually all these design parameters will be automatically set, users of the PIE algorithm would not be required to set any design parameters. Again, many thanks for your update. PIE team From: Greg White Date: Tuesday, April 30, 2013 3:54 PM To: Preethi Natarajan , "iccrg@irtf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" , "Chiara Piglione (cpiglion)" , "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Baker (fred)" , Daniel Rice Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments Additionally, I've re-run my suite of simulations using the updated PIE cod= e from Cisco. The results (in much more detail than I presented at ICCRG) ar= e documented in a white paper available here: Active Queue Management Algorithms for DOCSIS 3.0 =20 Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well i= n the cable environment, and for sharing the resulting code. Best Regards, Greg From: Preethi Natarajan Date: Tuesday, April 23, 2013 5:18 PM To: "iccrg@irtf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Cc: "Rong Pan (ropan)" , "Bill Ver Steeg (versteb)" , "Chiara Piglione (cpiglion)" , "Mythili Suryanarayana Prabhu (mysuryan)" , "Fred Baker (fred)" Subject: [aqm] Follow-up: PIE performance in cable modem environments Hello, This is a follow-up to Greg White's (from Cable Labs) talk at the recent ICCRG meeting on PIE's performance in cable modem environments. Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We investigated PIE's performance using this model. The key items from this investigation:=20 1. Bug in PIE code: The previous PIE release (that Greg used for evaluations) was missing a line of code. This missing line brings down drop probability under certain conditions and turns out to be critical for the cable modem scenario. Without this line of code, the drop probability remains high and takes longer to come down even when the queue delay has remained lower than the reference. The updated ns-2 PIE code can be found here =8B ftp://ftpeng.cisco.com/pie/. 2. Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cubic variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and unresponsive to packet drops/notifications, pretty much like UDP traffic. Please find more details about the bug here -- http://sourceforge.net/tracker/?func=3Ddetail&aid=3D3608750&group_id=3D149743&ati= d =3D775392. We are working with Cable Labs to verify the cable modem results, they'll soon be available on our FTP site along with the PIE code. A technical paper about PIE was recently accepted at the IEEE Conference on High Performance Switching and Routing 2013. A copy of the paper is attache= d here. The Linux PIE implementation is expected to be ready by next week and we'll follow-up on that as well. Many thanks, Preethi on behalf of PIE team. --B_3450788905_47253895 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Greg,=

As other posts point out, the byte-mode operation = has been around for a while and it is not unique/new to PIE. 

We weren't aware of Bob Briscoe's BCP draft until recently. = We understand the concerns mentioned here. In fact, we encountered the DropT= ail's preferential treatment for small packets in our simulations (mentioned= in the BCP draft) and that was our motivation to  experiment with byte= -mode. 

We think that a good alternative to by= te-mode would be ToS/DiffServe-field based differential dropping, similar to= WRED, since that would give similar benefits as byte-mode. That way, we don= 't have to stick to byte-mode based approach for PIE.

Regards,

From: Greg White <g.white@CableLabs.com>
= Date: Friday, May 3, 2013 3:55 PM
= To: Preethi Natarajan <pre= ethi.cis@gmail.com>, "iccrg@irtf.org<= /a>" <iccrg@irtf.org>, "aqm@ietf.org" <aqm@= ietf.org>
Subject: Re: [aqm= ] Follow-up: PIE performance in cable modem environments

<= /div>
Preethi,

I did a= diff on the new version of the PIE code vs the earlier release and found, a= s you stated, that the basic algorithm hasn't changed.  I do see some o= ther improvements/changes though.  One which, I think, bears discussion= is the weighting of packet drops based on size.

In the new code there is the= option (turned on in the simulations I reported on in my paper) to drop pac= kets according to p*pkt_size/mean_pkt_size where p is the drop probability c= alculated by the PIE control law. This serves to significantly decrease the drop probability of the small VoIP and gaming packets, which may be se= nsitive to loss (from a QoE perspective) and non-responsive to loss (from a = congestion control perspective).  This is evidenced by the low packet l= oss rate for gaming traffic that I reported in my paper.

However, I worry that the u= nintended consequence may be that this weighting incentivizes application de= velopers toward the use of small packets, which seems ill advised.

Thoughts?

-Greg



From: Pree= thi Natarajan <preethi.cis@gmail.c= om>
Date: Tuesday, April 30,= 2013 5:48 PM
To: Greg White <g.white@cablelabs.com>, Preethi = Natarajan <preethi.cis@gmail.com>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <t= svwg@ietf.org>, "aqm@ietf.org" <= aqm@ietf.org>
Cc: "Rong Pan (ropan)" <= ropan@cisco.com>, "Bill Ver Steeg (versteb)" <versteb@cisco.com>, "Chiara Piglione (cpiglion)" <<= a href=3D"mailto:cpiglion@cisco.com">cpiglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)" <fred@cisco.com>, Dan Rice <d.rice@cablelabs.com>
Subject: Re: [aqm] Follow-up: PIE performance in cable modem enviro= nments

Hi,

Thank you Greg = for the update and the link to the white paper.

We = wanted to quickly clarify about how we tuned PIE for DOCSIS.

<= /div>The bas= ic PIE algorithm has not changed. We updated the simulation code with the mi= ssing line mentioned below (which was a bug). The DOCSIS MAC layer has this special nature of stop-and-go with 5ms-6ms reque= st and grant delay. This requires adjustment of any algorithm: for example &= nbsp;CoDel has to increase its target delay from 5ms to a higher value. Simi= larly, our new parameters are to make PIE adjust faster for the DOCSIS stop-and-go behavior. Please note that ev= entually all these design parameters will be automatically set, users of the= PIE algorithm would not be required to set any design parameters. 

Again, many thanks for your update. 
<= span class=3D"Apple-style-span" style=3D"font-size: 16px; ">PIE team

From: Greg White <g.white@CableLabs.com>
D= ate: Tuesday, April 30, 2013 3:54 PM
To: Preethi Natarajan <pr= eethi.cis@gmail.com>, "iccrg@irtf.org= " <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "aqm@ietf.org" <aqm@iet= f.org>
Cc: "Rong Pan (ropan)= " <ropan@cisco.com>, "Bill Ver St= eeg (versteb)" <versteb@cisco.com&= gt;, "Chiara Piglione (cpiglion)" <cp= iglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)" <fred@cisco.com>, Daniel Rice <D.Rice@CableLabs.com>
Subject: Re: [aqm] Follow-up: PIE performance in cable modem env= ironments

Additional= ly, I've re-run my suite of simulations using the updated PIE code from Cisc= o.  The results (in much more detail than I presented at ICCRG) are doc= umented in a white paper available here:

Th= anks to Preethi, Rong, et al. for debugging and tuning PIE to work well in t= he cable environment, and for sharing the resulting code.  
<= br>
Best Regards,
Greg

From: Preethi Natarajan <preethi.cis@gmail.com>
Date: Tuesday, April 23, 2013 5:18 PM
To: "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.= org>, "aqm@ietf.org" <aqm@ietf.org>
Cc: "Rong Pan (ropan)" <ropan@cisco.com>, "Bill Ver Steeg (versteb)" <versteb@cisco.com>, "Chiara Piglione (cpiglion)"= <cpiglion@cisco.com>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker (fred)" <fred@cisco.com>
Sub= ject: [aqm] Follow-up: PIE performance in cable modem environments

Hel= lo,

This is a follow-up to Greg White's (from Cable Labs) talk at the recen= t ICCRG meeting on PIE's performance in cable modem environments. 

Pos= t the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We inve= stigated PIE's performance using this model. The key items from this investi= gation: 
  1. Bug in PIE code: The previous PIE releas= e (that Greg used for evaluations) was missing a line of code. This missing = line brings down drop probability under certain conditions and turns out to be critical for the cable modem scenario. Without this li= ne of code, the drop probability remains high and takes longer to come down = even when the queue delay has remained lower than the reference. The updated= ns-2 PIE code can be found here — ftp://ftpeng.cisco.com/= pie/.
  2. Bug in ns-2 TCP/Linux: Greg's cable modem = simulations used the TCP Cubic variant. We discovered a serious bug in = ns-2 TCP/Linux Agent (confirmed by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and unresponsive to packet dr= ops/notifications, pretty much like UDP traffic. Please find more details ab= out the bug here -- http://sourceforge.ne= t/tracker/?func=3Ddetail&aid=3D3608750&group_id=3D149743&atid=3D775392.
We are work= ing with Cable Labs to verify the cable modem results, they'll soon be avail= able on our FTP site along with the PIE code.
The Linux PIE implementation is expected to be= ready by next week and we'll follow-up on that as well. 

Many thanks,
Preethi on behalf of PIE team.
=
= --B_3450788905_47253895-- From fred@cisco.com Thu May 9 07:00:10 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1A021F8519 for ; Thu, 9 May 2013 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDBBP7PHUY1k for ; Thu, 9 May 2013 07:00:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3921F851C for ; Thu, 9 May 2013 07:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=340; q=dns/txt; s=iport; t=1368108006; x=1369317606; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=1WxLmKfI2XREvz/+lkTxdBngnkugZXcWC4twIIlmLEE=; b=gx4VstxtgK/QGvDQ/3MqB0k74remvcWOxligr7p/xIewGVFbdBwVyBIG Nt8Ffs1pTBCHrJ/XDNxkJkD2tr+IxNs9bvRW6pUBJTKEdjxLNYR5CE58e g4B8iAr96uIX9UsBHQdfjv1dso3ZGWpd7kxl83HRJNC9ebN8IeMmu7yZP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAD6ri1GtJXHB/2dsb2JhbABSgwc3gnW9EnsWbQeCIQEEOlEBKhRCJwQbDId4DJ1Hn26Od4MsYQOYUpAPgw+CJw X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208339325" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 09 May 2013 14:00:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r49E0428014804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 May 2013 14:00:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 9 May 2013 09:00:04 -0500 From: "Fred Baker (fred)" To: "aqm@ietf.org" Thread-Topic: Question re draft-baker-aqm-recommendations recomendation #5 Thread-Index: AQHOTL2Bqg2y1VIi1UqHCIrhzQ5siA== Date: Thu, 9 May 2013 14:00:04 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8565D6@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.118.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <0B545B023D20ED4BBB30F5CCDD41141E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [aqm] Question re draft-baker-aqm-recommendations recomendation #5 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 14:00:10 -0000 Do we generally agree with the recommendation of http://tools.ietf.org/html= /draft-baker-aqm-recommendation-01#section-4.5? This is the question of TCP= /SCTP Congestion Control: I would like to, as a community, recommend that i= t maximize throughput while minimizing delay, which is to say, do so withou= t being overly aggressive. From michawe@ifi.uio.no Thu May 9 11:23:38 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C321F9180 for ; Thu, 9 May 2013 11:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.148 X-Spam-Level: X-Spam-Status: No, score=-101.148 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvrGv4jBso3M for ; Thu, 9 May 2013 11:23:33 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id A3FC221F8A6B for ; Thu, 9 May 2013 11:23:33 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UaVV5-0006Xn-BU; Thu, 09 May 2013 20:23:31 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1UaVV4-0003JP-Qj; Thu, 09 May 2013 20:23:31 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <8C48B86A895913448548E6D15DA7553B8565D6@xmb-rcd-x09.cisco.com> Date: Thu, 9 May 2013 20:23:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11A513D9-E6D3-4FF3-A14F-785670841F86@ifi.uio.no> References: <8C48B86A895913448548E6D15DA7553B8565D6@xmb-rcd-x09.cisco.com> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 4194 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 09360885990CF5E09F1D6FB924B81F087F1F82F6 X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 523 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #5 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 18:23:38 -0000 I agree with what the recommendation says, but don't see the point of = having it in the document. 1) it doesn't even mention AQM, 2) the behavior of TCP and SCTP is = defined in other RFCs, what's the point of saying "they should actually = do this and that"? To guide people diverging from the standards, or = prepare future standards? For the first, I'm not sure if we should care = much in an RFC about people that don't care about RFCs; for the second, = I think we have lots of guidance notes in this direction already (some = would be in RFC5783, e.g. RFC2914) Cheers, Michael On May 9, 2013, at 4:00 PM, Fred Baker (fred) wrote: > Do we generally agree with the recommendation of = http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.5? = This is the question of TCP/SCTP Congestion Control: I would like to, as = a community, recommend that it maximize throughput while minimizing = delay, which is to say, do so without being overly aggressive. >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From subramanian.vijay@gmail.com Thu May 9 11:31:19 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06DE21F8F6E for ; Thu, 9 May 2013 11:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWoTpg05cUkK for ; Thu, 9 May 2013 11:31:19 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0F21F8F9E for ; Thu, 9 May 2013 11:31:18 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l11so1847144qcy.9 for ; Thu, 09 May 2013 11:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bI2V7V7W7e1wWT1GYAOudS0bQxRsJVilVpSsKITnEvY=; b=tfdRiWeIxm/kEahhjCP0qciIn6+0ZyFv6e4L7KNJSBSuSvzuZvyrIfoGigCeZjMVqb ppUK2kKDqX5AHTamU5XMuWbp9YVHzIP6YQVAzctIF1GuFYkqg/tL1Y4TNbVaVvBcan2f oMpUA3cZqd9ZOgOf212nhMjY60St2N6bf1SOUkAfsI4n2kb/9jBHGIy29ui2s9kkq1OX l2Mud4bJrlTzTwHL0EN473qYh7IIT14snlla1UKS5FgSIWhXEH/qw4mJHu9dt6Lg1VHE DHC/kbqw3/pOLZYhQlvoCJ/z6WMhb9vrXAg3Yl9bvi2zP3ynQ0C+1QJ0GIvobfKhzdoH RQsA== MIME-Version: 1.0 X-Received: by 10.224.127.131 with SMTP id g3mr9437277qas.91.1368124278334; Thu, 09 May 2013 11:31:18 -0700 (PDT) Received: by 10.49.121.202 with HTTP; Thu, 9 May 2013 11:31:18 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B8565D6@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B8565D6@xmb-rcd-x09.cisco.com> Date: Thu, 9 May 2013 11:31:18 -0700 Message-ID: From: Vijay Subramanian To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11c1e2d29e8df504dc4d4118 Cc: "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #5 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 18:31:19 -0000 --001a11c1e2d29e8df504dc4d4118 Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, A couple of points. 1: The recommendation mentions TCP and SCTP but not transports such as DCCP. I assume the recommendation holds for all transports. 2: The focus of this draft seems to be on AQMs and the other recommendations seem to deal with actions that routers can take. I am not sure what action on the part of a router is being recommended here. If this goal can be achieved using ECN, it is already covered in recommendation #2. Thanks, Vijay On 9 May 2013 07:00, Fred Baker (fred) wrote: > Do we generally agree with the recommendation of > http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.5? > This is the question of TCP/SCTP Congestion Control: I would like to, as a > community, recommend that it maximize throughput while minimizing delay, > which is to say, do so without being overly aggressive. > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --001a11c1e2d29e8df504dc4d4118 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Fred,

A couple of points.=A0
1: The recommendation mentions TCP and SCTP but not transpor= ts such as DCCP. I assume the recommendation holds for all transports.
2: The focus of this draft seems to be on AQMs and the other rec= ommendations seem to deal with actions that routers can take. I am not sure= what action
=A0on the part of a router is being recommende= d here. If this goal can be achieved using ECN, it is already covered in re= commendation #2.

Thanks,
Vijay=A0



<= br>
On 9 May 2013 07:00, Fred Baker (fred) <fred@ci= sco.com> wrote:
Do we generally agree with the recommendatio= n of http://tools.ietf.org/html/draft-baker-aqm= -recommendation-01#section-4.5? This is the question of TCP/SCTP Conges= tion Control: I would like to, as a community, recommend that it maximize t= hroughput while minimizing delay, which is to say, do so without being over= ly aggressive.


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

--001a11c1e2d29e8df504dc4d4118-- From rs@netapp.com Fri May 10 05:53:10 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1421F8EAA for ; Fri, 10 May 2013 05:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDX799C8NbZg for ; Fri, 10 May 2013 05:53:00 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 95B0D21F8E51 for ; Fri, 10 May 2013 05:52:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,647,1363158000"; d="scan'208,217";a="257481793" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 10 May 2013 05:52:59 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4ACqwWA009396; Fri, 10 May 2013 05:52:58 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Fri, 10 May 2013 05:52:58 -0700 From: "Scheffenegger, Richard" To: Vijay Subramanian , "Fred Baker (fred)" Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #5 Thread-Index: AQHOTONoFLlfr73IdE2qxO+qQN84sZj+XcSA Date: Fri, 10 May 2013 12:52:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B77239@SACEXCMBX02-PRD.hq.netapp.com> References: <8C48B86A895913448548E6D15DA7553B8565D6@xmb-rcd-x09.cisco.com> 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.106.53.53] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F24B77239SACEXCMBX02PRDh_" MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #5 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 12:53:10 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F24B77239SACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fred, I agree with Vijay and Michael; The last four words of the title can also be confusing [to the session, oth= er flows, ...] (without incurring loss or undue round trip delay). If such a section remains, I'd argue against naming of specific protocols; = from a router / AQM POV, it might be worthwhile to mention what an AQM SHOU= LD NOT do considering common congestion control algorithms (ie. delay the c= ongestion signal - obviously; drop entire flights or lots of consecutive p= ackets of one flow - difficult without state; drop/mark retransmitted packe= ts - again difficult without a means to identify them. RFC3168 for TCP (SC= TP) recommends, however, that retransmissions should not be ECT marked. How= ever I am dubious about the claimed benefit; a lost (as the only means to s= ignal persistent congestion) retransmitted segment is WORSE than a lost ori= ginal packet (which carries ECT, and would only receive a CE mark). Also, L= inux seems to ignore that specific paragraph in RFC3168...). So, without focusing only on TCP CC - are there any scenarios where an AQM = could overshoot and elicit too much of a reaction from a transport CC [drop= ping a retransmitted segment will cause a RTO with IETF spec'd TCP/SCTP]? I= f they are general (ie. applicable to SCTP, DDCP, [RTMFP]...), documenting = them in this document seems reasonable. Best regards, Richard Scheffenegger From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of Vijay= Subramanian Sent: Donnerstag, 09. Mai 2013 20:31 To: Fred Baker (fred) Cc: aqm@ietf.org Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendatio= n #5 Hi Fred, A couple of points. 1: The recommendation mentions TCP and SCTP but not transports such as DCCP= . I assume the recommendation holds for all transports. 2: The focus of this draft seems to be on AQMs and the other recommendation= s seem to deal with actions that routers can take. I am not sure what actio= n on the part of a router is being recommended here. If this goal can be ach= ieved using ECN, it is already covered in recommendation #2. Thanks, Vijay On 9 May 2013 07:00, Fred Baker (fred) > wrote: Do we generally agree with the recommendation of http://tools.ietf.org/html= /draft-baker-aqm-recommendation-01#section-4.5? This is the question of TCP= /SCTP Congestion Control: I would like to, as a community, recommend that i= t maximize throughput while minimizing delay, which is to say, do so withou= t being overly aggressive. _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm --_000_012C3117EDDB3C4781FD802A8C27DD4F24B77239SACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fred,

 = ;

I agree wi= th Vijay and Michael;

 = ;

The last four words of the title can also be confusing = [to the session, other flows, …] (without incurring loss or undue round trip delay).

 = ;

If such a = section remains, I’d argue against naming of specific protocols; from= a router / AQM POV, it might be worthwhile to mention what an AQM SHOULD NOT do considering common congestion control algorithms (ie. delay = the congestion signal – obviously; drop  entire flights or lots = of consecutive packets of one flow – difficult without state; drop/ma= rk retransmitted packets  - again difficult without a means to identify them. RFC3168 for TCP (SCTP) recommends, however, that= retransmissions should not be ECT marked. However I am dubious about the c= laimed benefit; a lost (as the only means to signal persistent congestion) = retransmitted segment is WORSE than a lost original packet (which carries ECT, and would only receive a CE mar= k). Also, Linux seems to ignore that specific paragraph in RFC3168…).=

 = ;

 = ;

So, withou= t focusing only on TCP CC – are there any scenarios where an AQM coul= d overshoot and elicit too much of a reaction from a transport CC [dropping a retransmitted segment will cause a RTO with IETF spec’d = TCP/SCTP]? If they are general (ie. applicable to SCTP, DDCP, [RTMFP]…= ;), documenting them in this document seems reasonable.

 = ;

Best regar= ds,

 = ;

Richard Scheffenegger

 <= /p>

From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of Vijay Subramanian
Sent: Donnerstag, 09. Mai 2013 20:31
To: Fred Baker (fred)
Cc: aqm@ietf.org
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recom= endation #5

 

Hi Fred,

 

A couple of points. 

1: The recommendation mentions TCP and SCTP but not = transports such as DCCP. I assume the recommendation holds for all transpor= ts.

2: The focus of this draft seems to be on AQMs and t= he other recommendations seem to deal with actions that routers can take. I= am not sure what action

 on the part of a router is being recommended h= ere. If this goal can be achieved using ECN, it is already covered in recom= mendation #2.

 

Thanks,

Vijay 

 

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F24B77239SACEXCMBX02PRDh_-- From subramanian.vijay@gmail.com Fri May 10 16:39:11 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5074521F9184 for ; Fri, 10 May 2013 16:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfIkmBTCqQAk for ; Fri, 10 May 2013 16:39:06 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68521F90B9 for ; Fri, 10 May 2013 16:39:06 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id x7so2764679qeu.38 for ; Fri, 10 May 2013 16:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=LRyuxa/eQI02aVkV1MgYA2XzTfWc0m5mVyk33pwfzlQ=; b=dOD/x10YeSq9JlGTeAdtxIgN9/VEPvBI4R+pApCOYUnARGS7Pl+45aDvfOZXhRWdP4 MyXoqCqNZOOJIinaoQXSGaHoOcv3kTFMTmE7jQHreq0HeMVUPRs0rPUs2s79XVTYG4/I Qu1L3QCAo/uvuPg0CXNI+c6zsVrnB4K3SUH0ryO9ljo4PKOKmGMUfmze1wyQjMvP09or L7rIy+TMwQ3PEwE0aLd7WqR5aQSF6kqWO58eSQ8ZBcmK8+3aR3ftu3RhnwaKLp5qJ1o0 IHmz5hXu2uBYidXKlD0DseU0ePVSsBbPTZg+TxP5ywFVOO4+s8C9Nmel7J48WP80GOlR lj1A== MIME-Version: 1.0 X-Received: by 10.224.166.203 with SMTP id n11mr13383060qay.87.1368229145902; Fri, 10 May 2013 16:39:05 -0700 (PDT) Received: by 10.49.121.202 with HTTP; Fri, 10 May 2013 16:39:05 -0700 (PDT) Date: Fri, 10 May 2013 16:39:05 -0700 Message-ID: From: Vijay Subramanian To: Dave Taht , "aqm@ietf.org" , bloat@lists.bufferbloat.net, Eric Dumazet Content-Type: multipart/alternative; boundary=089e0139fe1037b7d504dc65ac46 Cc: "Rong Pan \(ropan\)" , cpiglion@cisco.com, mysuryan@cisco.com, "Preethi Natarajan \(prenatar\)" Subject: [aqm] PIE code available X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 23:39:11 -0000 --089e0139fe1037b7d504dc65ac46 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We are finally in a position to release the PIE (Proportional Integral controller Enhanced) Linux code. Many of you are already aware of the work at IETF and discussions on PIE on the aqm and bloat mailing lists. Thanks for all the feedback. Documents and code are available over ftp at ftp://ftpeng.cisco.com/pie The Linux code is available at ftp://ftpeng.cisco.com/pie/linux_code PIE is written as a kernel module and should work with recent kernels. There is also a patch to iproute-3.9 tc tool to configure PIE. README files explain the usage. The complete source files are also available so it should not be too difficult to make it compile on a different iproute2 version. Please check that your basic tests are in sync with what we have seen. Sample results are available at ftp://ftpeng.cisco.com/pie/linux_code/linux_sampleresults/ Please let us know if you see any discrepancies. Thanks in advance for all code reviews. If you have suggestions to improve the code, they are welcome. (Thanks to Eric Dumazet and Dave Taht for Codel codebase). We will also release a version of PIE called Fair-queue-PIE soon (hopefully by the end of the month). If you have any questions, let us know. Thanks, on behalf of PIE team, Vijay Subramanian --089e0139fe1037b7d504dc65ac46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,

We are finally in a pos= ition to release the PIE (Proportional Integral controller Enhanced) Linux = code.
Many of you are already aware of the work at IETF and= discussions on PIE on the aqm and bloat mailing lists. Thanks for all the = feedback.=A0

Documents and code are available over ftp a= t=A0ftp://ftpeng.cisco.com/pie
The Linux code is available at=A0ftp://ftpeng.cisco.com/pie/linux_code

PIE is written as a kernel module and shoul= d work with recent kernels. There is also a patch to
iprout= e-3.9 tc tool to configure PIE. README files explain the usage. The complet= e source files are also available so it should not be too difficult to make= it compile on a different iproute2 version.

Please check that your basic tests are in s= ync with what we have seen. Sample results are available at=A0ftp://ftpeng.cisc= o.com/pie/linux_code/linux_sampleresults/
Please let us know if you see any discrepancies.

Thanks in advance for all code reviews. If you have s= uggestions to improve the code, they are welcome. (Thanks to Eric Dumazet a= nd Dave Taht for Codel codebase). We will also release a version of PIE cal= led Fair-queue-PIE soon (hopefully by the end of the month).

If you have any questions, let us know.

Thanks,
on behalf of PIE = team,

Vijay Subramanian


--089e0139fe1037b7d504dc65ac46-- From stephen@networkplumber.org Fri May 10 17:03:14 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D475321F905B for ; Fri, 10 May 2013 17:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRFzSfKbI-46 for ; Fri, 10 May 2013 17:03:14 -0700 (PDT) Received: from mail-da0-x22b.google.com (mail-da0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9621F9048 for ; Fri, 10 May 2013 17:03:14 -0700 (PDT) Received: by mail-da0-f43.google.com with SMTP id u7so611931dae.16 for ; Fri, 10 May 2013 17:03:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=Jt3EFNzhHyubexg4SQcGSj3Cmlc3O0ck666WvFfrQAs=; b=PcVSZ114L/aO/sinFWOdmlv4e3MXovdMdyFSQyGqkaUGz6attyGBlZ6SavSduooOtG N2bUdkmf37CDZnMac62XjdDgDw6m6B4EPV7eOsfhpqy4OfjAwYkwH6hbIYNRTPp2YOH4 6XNzL6NcL/swMvmNTPd7141kGAWWu2iviqCsrwr9WZhFaksv97M71jqwELCz+iBOwiwE 4VfHEBh3UJ4VjKPyPpHniICB06vhsosv1U5OvWGw1c0LnjcYoWHNJNB4XPqACDbf2zbc ug95WsoNSbxEnNnbd04eXpmGxUdRQlEvF7wHOfu0il3fIizNcLkz6styje1GY1h1zKzx G/ew== X-Received: by 10.68.130.167 with SMTP id of7mr19845712pbb.169.1368230593848; Fri, 10 May 2013 17:03:13 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-71-109.bvtn.or.frontiernet.net. [50.53.71.109]) by mx.google.com with ESMTPSA id kv2sm4299004pbc.28.2013.05.10.17.03.12 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 10 May 2013 17:03:13 -0700 (PDT) Date: Fri, 10 May 2013 17:03:09 -0700 From: Stephen Hemminger To: Vijay Subramanian Message-ID: <20130510170309.07f58589@nehalam.linuxnetplumber.net> In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmk3wjhD6NH1nk/7JNOEp0J/H0hg+UJKvKo7PoAv5IKuc+Wf+sYYxzDsHOpspNTcVTtvqz0 Cc: cpiglion@cisco.com, Eric Dumazet , Dave Taht , bloat@lists.bufferbloat.net, "Rong Pan \(ropan\)" , "aqm@ietf.org" , mysuryan@cisco.com, "Preethi Natarajan \(prenatar\)" Subject: Re: [aqm] PIE code available X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2013 00:03:14 -0000 On Fri, 10 May 2013 16:39:05 -0700 Vijay Subramanian wrote: > Hi folks, > > We are finally in a position to release the PIE (Proportional Integral > controller Enhanced) Linux code. > Many of you are already aware of the work at IETF and discussions on PIE on > the aqm and bloat mailing lists. Thanks for all the feedback. > > Documents and code are available over ftp at ftp://ftpeng.cisco.com/pie > The Linux code is available at ftp://ftpeng.cisco.com/pie/linux_code > > PIE is written as a kernel module and should work with recent kernels. > There is also a patch to > iproute-3.9 tc tool to configure PIE. README files explain the usage. The > complete source files are also available so it should not be too difficult > to make it compile on a different iproute2 version. > > Please check that your basic tests are in sync with what we have seen. > Sample results are available at > ftp://ftpeng.cisco.com/pie/linux_code/linux_sampleresults/ > Please let us know if you see any discrepancies. > > Thanks in advance for all code reviews. If you have suggestions to improve > the code, they are welcome. (Thanks to Eric Dumazet and Dave Taht for Codel > codebase). We will also release a version of PIE called Fair-queue-PIE soon > (hopefully by the end of the month). > > If you have any questions, let us know. > > Thanks, > on behalf of PIE team, > > Vijay Subramanian Why not submit it to netdev and get real hard review? From subramanian.vijay@gmail.com Fri May 10 17:45:02 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3409921F905F for ; Fri, 10 May 2013 17:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S37-iRoIeoi8 for ; Fri, 10 May 2013 17:44:57 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id B15F721F909A for ; Fri, 10 May 2013 17:44:54 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id s14so2777635qeb.17 for ; Fri, 10 May 2013 17:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4zUnXoNQZ2djund4F0Sz7zffbL/ZV6zETJrTYoo4pP4=; b=AZO32P5Y7mHgJOXrKI0L4ynrtx8cThSsG2F6JW4WDTPHNvbdJ+nYmd1byPsMXyVUpS izUlrJZphqNt043RYoTBtKMhe1O6mMRvcnI1XK1yqdVNP9l7E8FQRP+RY/7DeNxdDifQ UK6bD0kFzWV0erywACrdIOXiBtWwBTLmCXlW4e4JT5pErK1Jn+UFSBwRnZpx2lItG1Kz deT6G7l9QaVLAExnNLRdQqzN8/XRO6nrmrhi/yncCCxNseHqGhOznHT0waORXQ5dKt8Y t5WFNGvsutFRgV9eqeUPY638YpH7+5v/Eqv2xOotXcE6toEtPke+q1zqy9RF9kqaaT8Z hk+A== MIME-Version: 1.0 X-Received: by 10.224.58.141 with SMTP id g13mr13588120qah.49.1368233094199; Fri, 10 May 2013 17:44:54 -0700 (PDT) Received: by 10.49.121.202 with HTTP; Fri, 10 May 2013 17:44:54 -0700 (PDT) In-Reply-To: <20130510170309.07f58589@nehalam.linuxnetplumber.net> References: <20130510170309.07f58589@nehalam.linuxnetplumber.net> Date: Fri, 10 May 2013 17:44:54 -0700 Message-ID: From: Vijay Subramanian To: Stephen Hemminger Content-Type: multipart/alternative; boundary=20cf3074b5048ce19704dc66970a Cc: cpiglion@cisco.com, Eric Dumazet , Dave Taht , bloat@lists.bufferbloat.net, "Rong Pan \(ropan\)" , "aqm@ietf.org" , mysuryan@cisco.com, "Preethi Natarajan \(prenatar\)" Subject: Re: [aqm] PIE code available X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2013 00:45:02 -0000 --20cf3074b5048ce19704dc66970a Content-Type: text/plain; charset=ISO-8859-1 > Why not submit it to netdev and get real hard review? > Absolutely Stephen. That is the eventual intention. I thought before submitting to netdev it would be good to get some review and testing done by bufferbloat folks. I will submit to netdev soon if nothing major turns up on the bloat lists. Thanks Vijay --20cf3074b5048ce19704dc66970a Content-Type: text/html; charset=ISO-8859-1

Why not submit it to netdev and get real hard review?

Absolutely Stephen. That is the eventual intention. I thought before submitting to netdev it would be good to get some review and testing done by bufferbloat folks.
I will submit to netdev soon if nothing major turns up on the bloat lists.

Thanks
Vijay

--20cf3074b5048ce19704dc66970a-- From fred@cisco.com Mon May 13 07:00:10 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9A21F931B for ; Mon, 13 May 2013 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.153 X-Spam-Level: X-Spam-Status: No, score=-108.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5PUyfzCOq9B for ; Mon, 13 May 2013 07:00:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD1A21F9401 for ; Mon, 13 May 2013 07:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=175; q=dns/txt; s=iport; t=1368453606; x=1369663206; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=c5qU+Gd3zi7vtLg4Slll4DLvxus3cael3GbvTnIbb2c=; b=ANurwJKOEpreyGkQdPQiTzy/r9teCUrWSybOr9tqfgGIzTBH9xM/kGnM +I2MNd4BbPQrtZABuRpSKwUpApzPbdpvj/H7SF6TVA/eesI4gx9cWPjPR a/2lNscqLAsv8WF9vdShAJpBQlOGkqHSMjxv+Z+84QMS+FvXFMp3J9OCM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAO3wkFGtJV2b/2dsb2JhbABagwc3gnW9NIEDFm0DBIIhAQQ6UQEqFEInBBuIBAycY55XjneDLGEDmFKQD4MPgic X-IronPort-AV: E=Sophos;i="4.87,662,1363132800"; d="scan'208";a="209782569" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 13 May 2013 14:00:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4DE04XB011802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 May 2013 14:00:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 13 May 2013 09:00:04 -0500 From: "Fred Baker (fred)" To: "aqm@ietf.org" Thread-Topic: Question re draft-baker-aqm-recommendations recomendation #6 Thread-Index: AQHOT+IqD2szuYe6V0yhIn+2gFWPyw== Date: Mon, 13 May 2013 14:00:03 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [aqm] Question re draft-baker-aqm-recommendations recomendation #6 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 14:00:11 -0000 Do we generally agree with the recommendation of http://tools.ietf.org/html= /draft-baker-aqm-recommendation-01#section-4.6? This is the question of con= tinuing research. From michawe@ifi.uio.no Mon May 13 07:03:41 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE5F21F968E for ; Mon, 13 May 2013 07:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.883 X-Spam-Level: X-Spam-Status: No, score=-100.883 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+KB1G+R2EtB for ; Mon, 13 May 2013 07:03:37 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id D867F21F968D for ; Mon, 13 May 2013 07:03:31 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UbtLe-0000cb-8s; Mon, 13 May 2013 16:03:30 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UbtLd-0003xZ-Uc; Mon, 13 May 2013 16:03:30 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> Date: Mon, 13 May 2013 16:03:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <751419C7-7112-474E-A5B2-0D821A5F97C8@ifi.uio.no> References: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 8 sum msgs/h 5 total rcpts 4235 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DCC29AA6B3CC73D2703252320B0F57BF43DADA87 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1876 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: aqm@ietf.org Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #6 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 14:03:41 -0000 yo-ho! (with ICCRG chair hat on :-) ) On 13. mai 2013, at 16:00, Fred Baker (fred) wrote: > Do we generally agree with the recommendation of = http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.6? = This is the question of continuing research. >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From wes@mti-systems.com Mon May 13 07:39:49 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE0021F870F for ; Mon, 13 May 2013 07:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFI6wYT1JAJC for ; Mon, 13 May 2013 07:39:44 -0700 (PDT) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49421F86F7 for ; Mon, 13 May 2013 07:39:43 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.206]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4DEdg0C029668 for ; Mon, 13 May 2013 10:39:42 -0400 Received: (qmail 16605 invoked by uid 0); 13 May 2013 14:39:41 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.132.251) by 0 with ESMTPA; 13 May 2013 14:39:41 -0000 Message-ID: <5190FB21.5080100@mti-systems.com> Date: Mon, 13 May 2013 10:39:29 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: multipart/mixed; boundary="------------080909030904030100010103" Subject: [aqm] floating a draft charter X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 14:39:50 -0000 This is a multi-part message in MIME format. --------------080909030904030100010103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello AQMers. To get us a step closer to having a working group, we'll need a charter. I drafted the attached one, and think it's an okay starting point. If we can either hack on this or if someone has a better one, I think it will be good to get done before the Berlin meeting, since we'd like to have a WG-forming BoF. FYI, I think we would logically adopt Fred's draft for the first milestone. -- Wes Eddy MTI Systems --------------080909030904030100010103 Content-Type: text/plain; charset=windows-1252; name="AQM-charter-130508.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="AQM-charter-130508.txt" QWN0aXZlIFF1ZXVlIE1hbmFnZW1lbnQgYW5kIFBhY2tldCBTY2hlZHVsaW5nIChBUU0pDQoN CiAgSW50ZXJuZXQgcm91dGVycywgbG93ZXItbGF5ZXIgc3dpdGNoZXMsIG90aGVyIG1pZGRs ZWJveGVzIGluY2x1ZGUNCiAgYnVmZmVycyBvciBxdWV1ZXMgdG8gaG9sZCBwYWNrZXRzIHdo ZW4gdGhleSBhcmUgbm90IGltbWVkaWF0ZWx5DQogIGFibGUgdG8gYmUgZm9yd2FyZGVkIHRv IHRoZSBuZXh0IGhvcC4NCg0KICBUaGUgcXVldWVzIGFyZSBpbnRlbmRlZCB0byBhYnNvcmIg YnVyc3RzIG9mIHRyYWZmaWMgdGhhdCBtYXkNCiAgbmF0dXJhbGx5IG9jY3VyLCBhbmQgYXZv aWQgdW5uZWNjZXNzYXJ5IGxvc3Nlcy4gIEhvd2V2ZXIsIHF1ZXVlcw0KICBhbHNvIGNhdXNl IGxhdGVuY3kgYW5kIGppdHRlciBpbiB0aGUgZXZlbnR1YWwgYXJyaXZhbCB0aW1lcyBvZg0K ICBwYWNrZXRzLiAgVGhpcyBjYW4gY2F1c2UgaXNzdWVzIGFuZCBjb21wbGljYXRpb25zIGZv ciBpbnRlcmFjdGl2ZQ0KICBhcHBsaWNhdGlvbnMuDQoNCiAgRXh0cmVtZWx5IGxhcmdlIGJ1 ZmZlcnMgaGF2ZSBiZWVuIG5vdGljZWQgaW4gc29tZSBzb2Z0d2FyZSBhbmQNCiAgZXF1aXBt ZW50LiAgV2hlbiB0aGVzZSBxdWV1ZXMgZmlsbCwgaW50ZXJhY3RpdmUgYXBwbGljYXRpb25z IGFuZA0KICBvdGhlciB0cmFmZmljIGNhbiBiZSBzZXZlcmVseSBpbXBhY3RlZCBvciBjb21w bGV0ZWx5IGJyb2tlbiwgZHVlDQogIHRvIGhpZ2ggYW5kIHBvdGVudGlhbGx5IG9zY2lsbGF0 aW5nIGRlbGF5cy4NCiAgDQogIFRoZSBBY3RpdmUgUXVldWUgTWFuYWdlbWVudCBhbmQgUGFj a2V0IFNjaGVkdWxpbmcgd29ya2luZyBncm91cA0KICAoQVFNKSB3b3JrcyBvbiBhbGdvcml0 aG1zIGZvciBwcm9hY3RpdmVseSBtYW5hZ2luZyBxdWV1ZXMgaW4NCiAgb3JkZXIgdG86DQoN CiAgKDEpIGhlbHAgZmxvdyBzb3VyY2VzIGNvbnRyb2wgdGhlaXIgc2VuZGluZyByYXRlcyBi ZWZvcmUgdGhlDQogIG9uc2V0IG9mIG5lY2Vzc2FyeSBsb3NzZXMsIGUuZy4gdGhyb3VnaCBF Q04NCg0KICAoMikgaGVscCBtaW5pbWl6ZSBkZWxheXMgZm9yIGludGVyYWN0aXZlIGFwcGxp Y2F0aW9ucw0KDQogICgzKSBoZWxwIHByb3RlY3QgZmxvd3MgZnJvbSBuZWdhdGl2ZSBpbXBh Y3RzIG9mIG90aGVyIG1vcmUNCiAgYWdncmVzc2l2ZSBvciBtaXNiZWhhdmluZyBmbG93cw0K DQogIFRoZSBBUU0gd29ya2luZyBncm91cCB3aWxsIHB1Ymxpc2ggSW5mb3JtYXRpb25hbCBh bmQgQmVzdCBDdXJyZW50DQogIFByYWN0aWNlcyBkb2N1bWVudHMgdGhhdCBjb3ZlciB0aGUg ZGVzaWduLCB1c2UsIGFuZCBjb25maWd1cmF0aW9uDQogIG9mIGFsZ29yaXRobXMgZm9yIG1h bmFnaW5nIHF1ZXVlcyBpbiBJbnRlcm5ldCBkZXZpY2VzIGFuZCBzb2Z0d2FyZS4NCg0KICBU aGUgQVFNIHdvcmtpbmcgZ3JvdXAgd2lsbCBhbHNvIHB1Ymxpc2ggYWxnb3JpdGhtIHNwZWNp ZmljYXRpb25zDQogIHRoYXQgYXJlIGZvdW5kIHRvIGJlIGJyb2FkbHkgYXBwbGljYWJsZSBh bmQgYmVuZWZpY2lhbC4gIEV2YWx1YXRpbmcNCiAgdGhlc2UgYWxnb3JpdGhtcyBzaGFsbCBi ZSBkb25lIGluIGNvb3JkaW5hdGlvbiB3aXRoIHRoZSBJbnRlcm5ldA0KICBDb25nZXN0aW9u IENvbnRyb2wgUmVzZWFyY2ggR3JvdXAgKElDQ1JHKSBpbiBvcmRlciB0byBzZWxlY3QgYW5k DQogIGFzc2VzcyB0aGUgcmVsZXZhbnQgY3JpdGVyaWEsIHNjZW5hcmlvcywgYW5kIG1ldHJp Y3MuDQoNCiAgQVFNIGFsZ29yaXRobXMgZG8gbm90IGhhdmUgdG8gYmUgaW1wbGVtZW50ZWQg dW5pdmVyc2FsbHkgaW4gb3JkZXINCiAgdG8gYmUgZWZmZWN0aXZlLiAgU3BlY2lmaWNhdGlv bnMgd2lsbCBhaWQgaW4gcHJvZHVjaW5nIHByb3Blcg0KICBpbXBsZW1lbnRhdGlvbnMgdGhh dCBhdm9pZCBwb3RlbnRpYWwgYW1iaWd1aXRpZXMgYW5kIGNvcm5lciBjYXNlcy4NCiAgIklu dGVyb3BlcmFiaWxpdHkiIG9mIGFsZ29yaXRobXMgYW5kIGltcGxlbWVudGF0aW9ucyBvZiB0 aGVtIGlzDQogIG5vdCB0aGUgcmVhc29uIGZvciBjcmVhdGluZyB0aGVzZSBzcGVjaWZpY2F0 aW9uczsgY29ycmVjdG5lc3MgaXMNCiAgdGhlIHByaW1hcnkgbW90aXZhdGlvbi4NCiAgDQog IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgbm90IG1ha2UgY2hhbmdlcyB0byBFQ04sIERpZmZT ZXJ2LCBvciBvdGhlcg0KICBJRVRGIHByb3RvY29scywgdGhvdWdoIGV4aXN0aW5nIEVDTiwg RGlmZlNlcnYsIGFuZCBvdGhlciBtZWNoYW5pc21zDQogIG1heSBiZSB1c2VkIHdpdGhpbiB0 aGUgYWxnb3JpdGhtcyBwcm9wb3NlZC4NCiAgDQoNCiAgR29hbHMgYW5kIE1pbGVzdG9uZXMN Cg0KICBKYW51YXJ5IDIwMTQgIFN1Ym1pdCBBUU0gcmVjb21tZW5kYXRpb25zIHRvIElFU0cg Zm9yIHB1YmxpY2F0aW9uIGFzIEJDUCBvYnNvbGV0aW5nIFJGQyAyMzA5DQogIEp1bHkgMjAx NCAgICAgU3VibWl0IEFRTSBldmFsdWF0aW9uIGd1aWRlbGluZXMgdG8gSUVTRyBmb3IgcHVi bGljYXRpb24gYXMgSW5mb3JtYXRpb25hbA0KICBEZWNlbWJlciAyMDE0IFN1Ym1pdCBmaXJz dCBhbGdvcml0aG0gc3BlY2lmaWNhdGlvbiB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBQ cm9wb3NlZCBTdGFuZGFyZA0KDQoNCiAgUmVsZXZhbnQgZG9jdW1lbnRzOg0KICBkcmFmdC1i YWtlci1hcW0tcmVjb21tZW5kYXRpb24NCiAgZHJhZnQtcGFuLXRzdndnLXBpZQ0KICBkcmFm dC1uaWNob2xzLXRzdndnLWNvZGVs --------------080909030904030100010103-- From wes@mti-systems.com Mon May 13 07:47:35 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBD921F87FB for ; Mon, 13 May 2013 07:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqx3QL2cbcFD for ; Mon, 13 May 2013 07:47:29 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14821F871D for ; Mon, 13 May 2013 07:47:29 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.210]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4DElTKN011957 for ; Mon, 13 May 2013 10:47:29 -0400 Received: (qmail 27588 invoked by uid 0); 13 May 2013 14:47:28 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.132.251) by 0 with ESMTPA; 13 May 2013 14:47:28 -0000 Message-ID: <5190FCF5.20200@mti-systems.com> Date: Mon, 13 May 2013 10:47:17 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 14:47:35 -0000 For planning an AQM BoF in Berlin, my thought is that a rather short BoF to beat up the charter and scope of work is what we'd want. The problem is pretty well understood, and I don't think more than a very brief overview is needed for people that might be interested from other areas. I don't think we want to deep-dive into algorithms at this BoF, other than to show that they are becoming an active area of work again, that drafts are being brought to the IETF, and that there is interest in getting them done as IETF-stream RFCs. In other words, one of the shorter timeslots should suffice, I think. -- Wes Eddy MTI Systems From michawe@ifi.uio.no Mon May 13 08:22:20 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD7821F9227 for ; Mon, 13 May 2013 08:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvs-TMqNZAlu for ; Mon, 13 May 2013 08:22:13 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D86821F92C5 for ; Mon, 13 May 2013 08:22:12 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UbuZk-0000KX-9b; Mon, 13 May 2013 17:22:08 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UbuZj-0005xU-Rq; Mon, 13 May 2013 17:22:08 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <5190FCF5.20200@mti-systems.com> Date: Mon, 13 May 2013 17:22:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D4A7D7F-C60C-42EC-B648-A87B088CAACE@ifi.uio.no> References: <5190FCF5.20200@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 8 sum msgs/h 4 total rcpts 4241 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 43E890F3075ADEB5F10016D675DAF4EAC325FC20 X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 526 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: aqm@ietf.org, David Ros Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 15:22:20 -0000 On May 13, 2013, at 4:47 PM, Wesley Eddy wrote: > For planning an AQM BoF in Berlin, my thought is that > a rather short BoF to beat up the charter and scope of > work is what we'd want. >=20 > The problem is pretty well understood, and I don't think > more than a very brief overview is needed for people that > might be interested from other areas. >=20 > I don't think we want to deep-dive into algorithms at this > BoF, other than to show that they are becoming an active > area of work again, that drafts are being brought to the > IETF, and that there is interest in getting them done as > IETF-stream RFCs. >=20 > In other words, one of the shorter timeslots should > suffice, I think. =85 and we have asked for a long one for ICCRG, so folks who do want to = discuss details of current algorithms have a place to go :-) Cheers, Michael From David.Ros@telecom-bretagne.eu Mon May 13 08:26:29 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C359021F90CD for ; Mon, 13 May 2013 08:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM-CwWq54iZq for ; Mon, 13 May 2013 08:26:25 -0700 (PDT) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5A21F8EB9 for ; Mon, 13 May 2013 08:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 6E3EE66003; Mon, 13 May 2013 17:26:22 +0200 (CEST) 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 7MqhwXjbGozj; Mon, 13 May 2013 17:26:22 +0200 (CEST) Received: from [10.199.26.254] (unknown [193.253.141.152]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id A212966001; Mon, 13 May 2013 17:26:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: David Ros In-Reply-To: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> Date: Mon, 13 May 2013 17:26:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF4E1E4-6091-4717-8007-B86C5F433544@telecom-bretagne.eu> References: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1283) Cc: "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #6 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 15:26:29 -0000 On 13 mai 2013, at 16:00, Fred Baker (fred) wrote: > Do we generally agree with the recommendation of = http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.6? = This is the question of continuing research. >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm +2 (+1 with iccrg chair hat on, +1 without hat) David =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams From garmitage@swin.edu.au Mon May 13 15:46:27 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CEB21F9239 for ; Mon, 13 May 2013 15:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSDrUHgz-adu for ; Mon, 13 May 2013 15:46:22 -0700 (PDT) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7789321F92FC for ; Mon, 13 May 2013 15:46:22 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r4DMk7os011493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 May 2013 08:46:18 +1000 Message-ID: <51916D2F.2020306@swin.edu.au> Date: Tue, 14 May 2013 08:46:07 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: aqm@ietf.org References: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #6 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 22:46:27 -0000 On 05/14/2013 00:00, Fred Baker (fred) wrote: > Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.6? This is the question of continuing research. Yes (with lurker hat on) cheers, gja From dave.taht@gmail.com Mon May 13 15:49:50 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E342621F8D71 for ; Mon, 13 May 2013 15:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh3+LijaGWuv for ; Mon, 13 May 2013 15:49:46 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8725B21F87C5 for ; Mon, 13 May 2013 15:49:46 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so5674969vbh.12 for ; Mon, 13 May 2013 15:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wp4VHM4y6Q4NFWQbJitOz3lgWNbKve5lmw9n35LuDDY=; b=N+5ez7MGk8A3qfjZWvzkgdr64u8gI52Vtjdr+8G+Wy849Y2mtwg+lb5pVOn6tV06j/ X4plglifYaqZDlyEX0DjcjWqwNzWMKTSNPkothDyeYyRL+cKJm3epB6UQvECBh6H9ufv lJvtSHH+s1NOhlZ4suLPnxWeZSnoHKQHbhVCPpj2E2X024ASC7sNYQbl6oCfR1YvE+mt WuMWyrkYpVoxG1boq94rIwbBA834aO0NTE5+QMxn3L9RTR5QSHHVw2yopAuP6xz+62Ns 8Fj6lq1G6pVlVDplrjxMbb+IX90tbXej/LnMDLRWgQfJ29ahmMHdEMvyxska+rOKacxu S8wQ== MIME-Version: 1.0 X-Received: by 10.52.29.142 with SMTP id k14mr16888645vdh.124.1368485386016; Mon, 13 May 2013 15:49:46 -0700 (PDT) Received: by 10.58.7.10 with HTTP; Mon, 13 May 2013 15:49:45 -0700 (PDT) In-Reply-To: <5BF4E1E4-6091-4717-8007-B86C5F433544@telecom-bretagne.eu> References: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> <5BF4E1E4-6091-4717-8007-B86C5F433544@telecom-bretagne.eu> Date: Mon, 13 May 2013 15:49:45 -0700 Message-ID: From: Dave Taht To: David Ros Content-Type: multipart/alternative; boundary=20cf307d041c5068b504dca15598 Cc: Fred Baker , "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #6 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 22:49:51 -0000 --20cf307d041c5068b504dca15598 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 13, 2013 at 8:26 AM, David Ros w= rote: > On 13 mai 2013, at 16:00, Fred Baker (fred) wrote: > > > Do we generally agree with the recommendation of > http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.6? > This is the question of continuing research. > +10 --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --20cf307d041c5068b504dca15598 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 13, 2013 at 8:26 AM, David R= os <David.Ros@telecom-bretagne.eu> wrote:
On 13 mai 2013, at 16:00, Fred Baker (fred) wrote:

> Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section= -4.6? This is the question of continuing research.

+10

--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.te= klibre.com/cerowrt/subscribe.html=20 --20cf307d041c5068b504dca15598-- From garmitage@swin.edu.au Mon May 13 15:56:09 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E04021F9239 for ; Mon, 13 May 2013 15:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX8YwIZniJcG for ; Mon, 13 May 2013 15:56:03 -0700 (PDT) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8521F9234 for ; Mon, 13 May 2013 15:56:01 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r4DMtxsC002144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 May 2013 08:55:59 +1000 Message-ID: <51916F7F.1020601@swin.edu.au> Date: Tue, 14 May 2013 08:55:59 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: aqm@ietf.org References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> <20130507133724.GY23227@verdi> In-Reply-To: <20130507133724.GY23227@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 22:56:09 -0000 On 05/07/2013 23:37, John Leslie wrote: > Fred Baker (fred) wrote: >> On May 6, 2013, at 7:25 AM, Michael Welzl wrote: >> >>> ...sounds as if it would be the most normal thing in the world for an >>> AQM algorithm to make a decision based on the transport protocol, >>> which I think it shouldn't... >> >> I certainly agree that we should not be making transport-specific >> modifications... >> My point in this, if you can think of a better way to phrase it, is >> that the AQM algorithm someone implements needs to demonstrably work >> with the transports and applications it will be affecting. > > Hearing no differing suggestions, those words seem appropriate. Thus > Section 4.4 might become: > " > " 4.4. Active Queue Management algorithms deployed SHOULD be effective on > " all common Internet traffic > " > " Active Queue Management algorithms typically are verified to work with > " TCP [RFC0793] and a limited number of applications of it. This no > " longer represents a sufficient selection of actual traffic. We have > " significant use of UDP [RFC0768] in voice and video services, as well > " as SCTP [RFC4960] and DCCP [RFC4340]. Hence, Active Queue Management > " algorithms should demonstrably work with other transports as well as > " TCP, and with a wide variety of applications. I see a difference between the scope of Fred's "...demonstrably work with the transports and applications it will be affecting" and the scope of the section heading ("...be effective on all common Internet traffic") or even "..as well as TCP, and with a wide variety of applications." I certainly agree that an AQM algorithm ought not necessarily be transport-layer aware. But the wording above could lead to a situation where acceptance of a future AQM scheme is derailed because it doesn't "work" with some (yet to be defined) "wide variety of applications". I prefer the wiggle room allowed by "..the transports and applications it will be affecting" rather than "...all common Internet traffic". cheers, gja From john@jlc.net Mon May 13 16:48:18 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E356321F941F for ; Mon, 13 May 2013 16:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRninObcNUG2 for ; Mon, 13 May 2013 16:48:13 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BDF9521F944C for ; Mon, 13 May 2013 16:48:13 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9EB9B33C23; Mon, 13 May 2013 19:48:11 -0400 (EDT) Date: Mon, 13 May 2013 19:48:11 -0400 From: John Leslie To: grenville armitage Message-ID: <20130513234811.GI23227@verdi> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> <20130507133724.GY23227@verdi> <51916F7F.1020601@swin.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51916F7F.1020601@swin.edu.au> User-Agent: Mutt/1.4.1i Cc: aqm@ietf.org Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 23:48:19 -0000 grenville armitage wrote: > On 05/07/2013 23:37, John Leslie wrote: >> Fred Baker (fred) wrote: >> >>> My point in this, if you can think of a better way to phrase it, is >>> that the AQM algorithm someone implements needs to demonstrably work >>> with the transports and applications it will be affecting. >>... >>" ... Hence, Active Queue Management >>" algorithms should demonstrably work with other transports as well as >>" TCP, and with a wide variety of applications. > > I see a difference between the scope of Fred's "...demonstrably > work with the transports and applications it will be affecting" > and the scope of the section heading ("...be effective on all > common Internet traffic") or even "..as well as TCP, and with > a wide variety of applications." I'm not sure I understand the distinction here... My main thought as I wordsmithed was that there's really no way for an AQM algorithm to know _what_ "transports and applications it will be affecting". > I certainly agree that an AQM algorithm ought not necessarily > be transport-layer aware. But the wording above could lead to > a situation where acceptance of a future AQM scheme is derailed > because it doesn't "work" with some (yet to be defined) "wide > variety of applications". I suppose the process could be "delayed"; but "derailed" seems unlikely. But frankly I don't see much difference between the two wordings in that respect. > I prefer the wiggle room allowed by "..the transports and > applications it will be affecting" rather than "...all common > Internet traffic". To tell truth, I have no emotional attachment to my wording. (But perhaps this objection is to some other words??) Perhaps Grenville could send proposed text? -- John Leslie From garmitage@swin.edu.au Wed May 15 02:53:27 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8BB21F8ADF for ; Wed, 15 May 2013 02:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PghvXA0knQey for ; Wed, 15 May 2013 02:53:22 -0700 (PDT) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by ietfa.amsl.com (Postfix) with ESMTP id DA1B021F8A74 for ; Wed, 15 May 2013 02:53:20 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r4F9rA3U000335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 May 2013 19:53:19 +1000 Message-ID: <51935B06.9050207@swin.edu.au> Date: Wed, 15 May 2013 19:53:10 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: aqm@ietf.org References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> <20130507133724.GY23227@verdi> <51916F7F.1020601@swin.edu.au> <20130513234811.GI23227@verdi> In-Reply-To: <20130513234811.GI23227@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 09:53:28 -0000 On 05/14/2013 09:48, John Leslie wrote: [..] > Perhaps Grenville could send proposed text? A small tweak to the subsection heading and the last sentence: 4.4. Active Queue Management algorithms deployed SHOULD be effective on all transports and applications they will be affecting Active Queue Management algorithms typically are verified to work with TCP [RFC0793] and a limited number of applications of it. This no longer represents a sufficient selection of actual traffic. We have significant use of UDP [RFC0768] in voice and video services, as well as SCTP [RFC4960] and DCCP [RFC4340]. Hence, Active Queue Management algorithms should demonstrably work with all transports and applications they will be affecting. cheers, gja From michawe@ifi.uio.no Wed May 15 03:07:16 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2838121F8E56 for ; Wed, 15 May 2013 03:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.627 X-Spam-Level: X-Spam-Status: No, score=-101.627 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rrc9+tmg0Bm for ; Wed, 15 May 2013 03:07:11 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7C921F854E for ; Wed, 15 May 2013 03:07:11 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UcYc2-0001ew-1J; Wed, 15 May 2013 12:07:10 +0200 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 1UcYc1-0003LG-IC; Wed, 15 May 2013 12:07:09 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <51935B06.9050207@swin.edu.au> Date: Wed, 15 May 2013 12:07:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8C9FF3E3-B233-48B7-9E69-449028B56A28@ifi.uio.no> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> <20130507133724.GY23227@verdi> <51916F7F.1020601@swin.edu.au> <20130513234811.GI23227@verdi> <51935B06.9050207@swin.edu.au> To: grenville armitage X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 4272 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 14875474EF7BCFDA94B944B23E556C4E38589BB7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1886 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: aqm@ietf.org Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 10:07:16 -0000 I like it! On 15. mai 2013, at 11:53, grenville armitage wrote: > > > On 05/14/2013 09:48, John Leslie wrote: > [..] >> Perhaps Grenville could send proposed text? > > A small tweak to the subsection heading and the last sentence: > > 4.4. Active Queue Management algorithms deployed SHOULD be effective on > all transports and applications they will be affecting > > Active Queue Management algorithms typically are verified to work with > TCP [RFC0793] and a limited number of applications of it. This no > longer represents a sufficient selection of actual traffic. We have > significant use of UDP [RFC0768] in voice and video services, as well > as SCTP [RFC4960] and DCCP [RFC4340]. Hence, Active Queue Management > algorithms should demonstrably work with all transports and applications > they will be affecting. > > cheers, > gja > > > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From steing@ifi.uio.no Wed May 15 08:11:50 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DBF21F8F83; Wed, 15 May 2013 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGIrVo0PEbGg; Wed, 15 May 2013 08:11:45 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA821F8AD8; Wed, 15 May 2013 08:11:44 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcdMl-0005Wl-5S; Wed, 15 May 2013 17:11:43 +0200 Received: from 1x-193-157-202-195.uio.no ([193.157.202.195]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from ) id 1UcdMk-0004fY-EU; Wed, 15 May 2013 17:11:43 +0200 From: Stein Gjessing Content-Type: multipart/alternative; boundary="Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93" Date: Wed, 15 May 2013 17:11:41 +0200 Message-Id: To: aqm@ietf.org, rtcweb@ietf.org, lmap@ietf.org, tsvwg@ietf.org, rmcat@ietf.org, multipathtcp@ietf.org, video-codec@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 2607 max rcpts/h 28 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 45A26AF8F0515C0711EDC4E4402EEAD2BB95E78D X-UiO-SPAM-Test: remote_host: 193.157.202.195 spam_score: -54 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 36 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: Stein Gjessing Subject: [aqm] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 15:11:50 -0000 --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Here is an excellent venue for discussions and publication of results. Cheers,=20 Stein __________________________________________________________ Packet Video 2013 - Special Session on Low-Latency Interactive Video Sponsored by IEEE Communications Society December 12. and 13., 2013, San Jose, Ca, USA Call for papers. =20 http://pv2013.itec.aau.at/call-for-papers/accepted-special-sessions/#ss1 Several years ago, it was found that users do not like video quality = fluctuations. At that time the predominant belief was that network rate = fluctuations should be minimized, in order to reasonably interoperate = with TCP in the network. This led to the creation of a number of = so-called "TCP-friendly" congestion controls that exhibit a smoother = sending rate than TCP, while avoiding to send more than a conformant TCP = under similar conditions. TFRC is perhaps the best known example of such = a congestion control mechanism. A lot has happened since then: =95 The notion of TCP-friendliness has received massive = criticism; the widespread deployment of a more aggressive TCP variant, = CUBIC, has not led to an Internet meltdown, making the case that = diverging from strict TCP-friendliness is possible. =95 Latency minimization has become a major goal, especially in = the face of =93bufferbloat=94: large delays from large buffers with = simplistic FIFO-queue management. =95 Codecs have improved; novel video codecs are able to adjust = the data rate, but modern codecs may also produce variable bitrate = transmissions with burstier packet flows than before. =95 TFRC has been embedded in the DCCP protocol, which has = probably never been used for anything other than experiments; instead of = running over DCCP, RTP-based applications now contain proprietary = congestion control mechanisms. The emergence of the RTCWEB protocol suite for real-time communication = between Web browsers has renewed the interest in developing congestion = control standards for real-time media. This time, however, the goal is = to get things right: delay should be minimized, and standards should = realize congestion control using RTP with RTCP signaling. The IETF = =93Real-time Media Congestion Avoidance Techniques=94 (RMCAT) working = group has been founded to address this need. New questions arise: what = type of congestion controls do we need? How much feedback should we = send? How do we make this work in multi-user scenarios, e.g., for video = conferencing? What should be the API between a video codec and a new = delay-based congestion controlled RTP stream? What is the quality that = can be expected from the combination of a codec and congestion control = mechanism, when we consider better metrics than plain PSNR? Topics of interest include, but are not limited to: =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms =95 Necessary RTP/RTCP extensions =95 Field experience with video codecs in a low-delay, real-time = setting =95 Interactions between applications and RTP flows =95 Failing to meet real-time schedules: impact, techniques to = detect, instrument or diagnose it Organizers: =95 Michael Welzl, University of Oslo (michawe at ifi.uio.no) =95 Stein Gjessing, University of Oslo (steing at ifi.uio.no)= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://pv2013.itec.aau.at/call-for-papers/accepted-special-session= s/#ss1

Several years ago, it was found that users do not like = video quality fluctuations. At that time the predominant belief was that = network rate fluctuations should be minimized, in order to reasonably = interoperate with TCP in the network. This led to the creation of a = number of so-called "TCP-friendly" congestion controls that exhibit a = smoother sending rate than TCP, while avoiding to send more than a = conformant TCP under similar conditions. TFRC is perhaps the best known = example of such a congestion control mechanism.

A lot has = happened since then:
=95 The notion of = TCP-friendliness has received massive criticism; the widespread = deployment of a more aggressive TCP variant, CUBIC, has not led to an = Internet meltdown, making the case that diverging from strict = TCP-friendliness is possible.
=95 Latency minimization has = become a major goal, especially in the face of =93bufferbloat=94: large = delays from large buffers with simplistic FIFO-queue = management.
=95 TFRC = has been embedded in the DCCP protocol, which has probably never been = used for anything other than experiments; instead of running over DCCP, = RTP-based applications now contain proprietary congestion control = mechanisms.

The emergence of the RTCWEB protocol suite for = real-time communication between Web browsers has renewed the interest in = developing congestion control standards for real-time media. This time, = however, the goal is to get things right: delay should be minimized, and = standards should realize congestion control using RTP with RTCP = signaling. The IETF =93Real-time Media Congestion Avoidance Techniques=94 = (RMCAT) working group has been founded to address this need. New = questions arise: what type of congestion controls do we need? How much = feedback should we send? How do we make this work in multi-user = scenarios, e.g., for video conferencing? What should be the API between = a video codec and a new delay-based congestion controlled RTP stream? = What is the quality that can be expected from the combination of a codec = and congestion control mechanism, when we consider better metrics than = plain PSNR?

Topics of interest include, but are not limited = to:
= =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms
=95 = Necessary RTP/RTCP extensions
=95 Field experience with video = codecs in a low-delay, real-time setting
=95 Interactions between = applications and RTP flows
=95 Failing to meet real-time = schedules: impact, techniques to detect, instrument or diagnose = it

Organizers:
=95 Michael Welzl, University of = Oslo (michawe at ifi.uio.no)
=95 Stein = Gjessing, University of Oslo (steing at ifi.uio.no)
= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93-- From jiyengar@fandm.edu Tue May 28 10:46:25 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098E511E80F6 for ; Tue, 28 May 2013 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo5wu36XvXEM for ; Tue, 28 May 2013 10:46:23 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 22E4721F9285 for ; Tue, 28 May 2013 10:46:23 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id a1so4159371qcx.6 for ; Tue, 28 May 2013 10:46:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bxlYR1F8f8wJOHJ4tNcm2pNx57nVbS4BB2REp26W/Bo=; b=CSx/RJFKC2fChwGAmVctwgXLZqSh4eMpvORLpeRt6gXRH5xGd32boSt6dPtyimyaRz CMgxODtSa0NZXoktu0YmZyUMXqd+8Xpf0idt/RVFeFfJWcSjWZhF/i1WPtGDaHM5gu0R HhW+L9eIK8XLmF8TuHgQBnoMnMFqHdFUVd7lG9EoiYHgf4LvlQu97V2M1BH7UlQxX+fU n4UiL32rNhggt2qw1Tl9SbSQ4VHpeZguLOFLPvtMR+JyoRy4HnBa7c9Y6fiC9RbCqrKP sOD0c7CyM8tCodiCTSTj1U5QE/6Sgkyrxqtp7elF4Yy8iJ9rVcNpBMq1+A6fEmBnc/It FhwA== MIME-Version: 1.0 X-Received: by 10.229.64.69 with SMTP id d5mr2371131qci.38.1369763182575; Tue, 28 May 2013 10:46:22 -0700 (PDT) Received: by 10.49.49.103 with HTTP; Tue, 28 May 2013 10:46:22 -0700 (PDT) In-Reply-To: References: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> <5BF4E1E4-6091-4717-8007-B86C5F433544@telecom-bretagne.eu> Date: Tue, 28 May 2013 13:46:22 -0400 Message-ID: From: Janardhan Iyengar To: Dave Taht Content-Type: multipart/alternative; boundary=089e0163525aec96f604ddcad74a X-Gm-Message-State: ALoCoQkGABe1OKRJ7aYy4HaQmYFC0uGXJIY5m2A+aH73mR2CyKatLysbSWj2tX9y4+1cAramjs0w Cc: "aqm@ietf.org" , David Ros , Fred Baker Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #6 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 17:46:25 -0000 --089e0163525aec96f604ddcad74a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 (with apologies-for-the-delayed-signal and pun-intended hats on) On Mon, May 13, 2013 at 6:49 PM, Dave Taht wrote: > > > On Mon, May 13, 2013 at 8:26 AM, David Ros wrote: > >> On 13 mai 2013, at 16:00, Fred Baker (fred) wrote: >> >> > Do we generally agree with the recommendation of >> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.6= ? >> This is the question of continuing research. >> > > +10 > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > --089e0163525aec96f604ddcad74a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 (with apologies-for-the-delayed-signal and pun-intended= hats on)


On Mon, May 13, 2013 at 6:49 PM, Dave Taht <dave.taht@gmail.com> wrote:


On Mon, May 13, 2013 at 8:26 AM, David Ros <<= a href=3D"mailto:David.Ros@telecom-bretagne.eu" target=3D"_blank">David.Ros= @telecom-bretagne.eu> wrote:
On 13 mai 2013, at 16:00, Fred Baker (fred) wrote:

> Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section= -4.6? This is the question of continuing research.

+10


--
Dave T=E4ht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/sub= scribe.html=20
_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm


--089e0163525aec96f604ddcad74a-- From gettysjim@gmail.com Tue May 28 14:51:00 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096B921F87CD for ; Tue, 28 May 2013 14:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJpDxmMnVwaa for ; Tue, 28 May 2013 14:50:58 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7E00421F8746 for ; Tue, 28 May 2013 14:50:58 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so2310976obq.35 for ; Tue, 28 May 2013 14:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IJec4+3fdJTP4BscUy+HiDSapC4idGbyJzF88qrUVZk=; b=EO38bidbpct0CyOM6zSRAP7kEDmyO8OqoJoDkVJz9J7dwW1VbL5/LcPDHtkSIu4MHP 2uVhcbE0czsCyWnaIOiAzeuexovZhMlvFRBCuRDc+Dg4ftMKmuwAzBLAO2oJiuD6ag/u KrTV74rXWB++aLlxJmoBlK6AzdmJ+YY+MIeomwE4/wfVnMhnMtmhktXxoXUWoZndFLJ3 jrsYrTqOnQal3gYbpNxPIgjP1nOOg7ExstRSpiiY1qYnno9V6uitzhmzQ2c6OnLEpCcH 9daCXnICzFJg4yG1ngaeIRVHt4b5TV0JYNIaQi5LduOy6Ftfls2j9fT3uHqzcNA6Z+OU HBWA== MIME-Version: 1.0 X-Received: by 10.60.84.67 with SMTP id w3mr13537825oey.59.1369777856924; Tue, 28 May 2013 14:50:56 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.87.129 with HTTP; Tue, 28 May 2013 14:50:56 -0700 (PDT) In-Reply-To: References: <8C48B86A895913448548E6D15DA7553B85A7CD@xmb-rcd-x09.cisco.com> <5BF4E1E4-6091-4717-8007-B86C5F433544@telecom-bretagne.eu> Date: Tue, 28 May 2013 17:50:56 -0400 X-Google-Sender-Auth: tCUsQ6Yj3iFkiK6o75xh2c4iHHw Message-ID: From: Jim Gettys To: Janardhan Iyengar Content-Type: multipart/alternative; boundary=089e0111b88695556f04ddce42af Cc: David Ros , Fred Baker , Dave Taht , "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #6 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:51:00 -0000 --089e0111b88695556f04ddce42af Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +10 from me too: we're far from done, though it's time to start deploying what we have... - Jim On Tue, May 28, 2013 at 1:46 PM, Janardhan Iyengar < janardhan.iyengar@fandm.edu> wrote: > +1 (with apologies-for-the-delayed-signal and pun-intended hats on) > > > On Mon, May 13, 2013 at 6:49 PM, Dave Taht wrote: > >> >> >> On Mon, May 13, 2013 at 8:26 AM, David Ros > > wrote: >> >>> On 13 mai 2013, at 16:00, Fred Baker (fred) wrote: >>> >>> > Do we generally agree with the recommendation of >>> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.= 6? >>> This is the question of continuing research. >>> >> >> +10 >> >> >> -- >> Dave T=E4ht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> _______________________________________________ >> 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 > > --089e0111b88695556f04ddce42af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+10= from me too: we're far from done, though it's time to start deploy= ing what we have...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim



On Tue, May 28, 2= 013 at 1:46 PM, Janardhan Iyengar <janardhan.iyengar@fandm.edu> wrote:
+1 (with apologies-for-the-= delayed-signal and pun-intended hats on)




<= div class=3D"gmail_quote">
On Mon, May 13, 2013 at 8:26 AM, David Ros <= span dir=3D"ltr"><David.Ros@telecom-bretagne.eu> wrote:
On 13 mai 2013, at 16:00, Fred Baker (fred) wrote:

> Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section= -4.6? This is the question of continuing research.

+10


--
Dave T=E4ht

Fixing buffe= rbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html= =20
___________________________= ____________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm



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


--089e0111b88695556f04ddce42af-- From spencer@wonderhamster.org Wed May 29 00:30:42 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6787E21F894E for ; Wed, 29 May 2013 00:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guGd-JUWCSaS for ; Wed, 29 May 2013 00:30:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA9721F8916 for ; Wed, 29 May 2013 00:30:36 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net [99.108.174.213]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LdYN8-1TzyId2EhG-00io03; Wed, 29 May 2013 03:30:34 -0400 Message-ID: <51A5AE9F.30905@wonderhamster.org> Date: Wed, 29 May 2013 02:30:39 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: aqm@ietf.org References: <5190FCF5.20200@mti-systems.com> In-Reply-To: <5190FCF5.20200@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:caV+QBj+hVse9p4W8MEbXU8/OhYvHObTf8NRIQSrqN9 u7Q3NY08dLEmrMVwYPPCpchSpF4QKN37GkoFlsIEjR4TWlHIjC MXgruPOxBaE9O/DgQnLrsaBQ5lFAliEroH8fuUJDRDaTyCQ+kp Ji1yciPEDo3iiVibmpz2m8WfUZM2gPeIv40sxCTN59tIlReJXE EASQN/IisbOnrybV+7d+FBoewqEpQAYdzlh1N3tKTtkbmaYfkm dvp3cXOCVl+A5rZsHb787CnMRVqONJUxWnA8ZWtX2+ZowK4dbk AEYN/hYAGjN27ZoXsiDniDAwMQtt19cW8X2rz+i6WA1kEHvaqI d3QzhvG7BNlbQZZq/1KpQmksWWMY9R8j2KvdG3kTV Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 07:30:42 -0000 On 5/13/2013 9:47 AM, Wesley Eddy wrote: > For planning an AQM BoF in Berlin, my thought is that > a rather short BoF to beat up the charter and scope of > work is what we'd want. Wes, thank you for your work as AQM moves BOFward. > The problem is pretty well understood, and I don't think > more than a very brief overview is needed for people that > might be interested from other areas. I don't know if this would be helpful for anyone except me, but ... if there are lessons learned about the obstacles proposed AQN mechanisms faced in getting deployed, that might be helpful to remind people about, whether at a BOF, or as a proposed working group starts to work. > I don't think we want to deep-dive into algorithms at this > BoF, other than to show that they are becoming an active > area of work again, that drafts are being brought to the > IETF, and that there is interest in getting them done as > IETF-stream RFCs. Makes sense to me. > In other words, one of the shorter timeslots should > suffice, I think. Makes sense to me. Were you thinking 60-minutes or 90 minutes? Spencer From wes@mti-systems.com Wed May 29 09:22:45 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CBC21F95E1 for ; Wed, 29 May 2013 09:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNwlI5ggd+vk for ; Wed, 29 May 2013 09:22:39 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7901E21F96C2 for ; Wed, 29 May 2013 09:22:36 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.209]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4TGMZon026535 for ; Wed, 29 May 2013 12:22:35 -0400 Received: (qmail 24103 invoked by uid 0); 29 May 2013 16:22:35 -0000 Received: from unknown (HELO ?172.27.250.182?) (wes@mti-systems.com@63.226.32.150) by 0 with ESMTPA; 29 May 2013 16:22:35 -0000 Message-ID: <51A62B46.90401@mti-systems.com> Date: Wed, 29 May 2013 12:22:30 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Spencer Dawkins References: <5190FCF5.20200@mti-systems.com> <51A5AE9F.30905@wonderhamster.org> In-Reply-To: <51A5AE9F.30905@wonderhamster.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: aqm@ietf.org Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 16:22:45 -0000 On 5/29/2013 3:30 AM, Spencer Dawkins wrote: > >> The problem is pretty well understood, and I don't think >> more than a very brief overview is needed for people that >> might be interested from other areas. > > I don't know if this would be helpful for anyone except me, but ... if > there are lessons learned about the obstacles proposed AQN mechanisms > faced in getting deployed, that might be helpful to remind people about, > whether at a BOF, or as a proposed working group starts to work. > To some extent, Fred's draft is touching on this, and if we have an agenda slot to talk about his work there, then maybe Fred can cover this? >> In other words, one of the shorter timeslots should >> suffice, I think. > > Makes sense to me. Were you thinking 60-minutes or 90 minutes? I was thinking 60 minutes, but it could easily expand to 90. For agenda items, I suggest: 5 min - brief summary of AQM discussion in TSVAREA at last IETF 5 min - summary of AQM mailing list discussion to-date 10 min - overview of draft charter, and the need/plan to get significant participation from OPS and other areas 10 min - look for consensus on whether packet scheduling also should be in-scope or whether the focus is on "pure" AQM 10 min - talk about the state of Fred's document 10 min - brief summary/summaries of ongoing AQM algorithm work(?) 10 min - call for consensus on chartering a WG in the TSV area We might want to expand the time for Fred's document, to be able to actually talk about the content to greater extent. We might also want to add time if there are operator types of folks that we could find in order to talk about their hopes, dreams, and concerns about this work. Of course, this is just my 2 cents, and others might have better ideas. -- Wes Eddy MTI Systems From swb@internet2.edu Wed May 29 09:39:16 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C221F96AB for ; Wed, 29 May 2013 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VGkuKkd4Kjp for ; Wed, 29 May 2013 09:39:10 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4A41921F9688 for ; Wed, 29 May 2013 09:39:10 -0700 (PDT) Received: from mail67-co1-R.bigfish.com (10.243.78.254) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 16:39:08 +0000 Received: from mail67-co1 (localhost [127.0.0.1]) by mail67-co1-R.bigfish.com (Postfix) with ESMTP id EAF8C800AD; Wed, 29 May 2013 16:39:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 8 X-BigFish: S8(zzbb2dI98dIda00hdc73hzz1f42h1d77h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1b1cn1b1bi1155h) Received: from mail67-co1 (localhost.localdomain [127.0.0.1]) by mail67-co1 (MessageSwitch) id 136984554735263_22883; Wed, 29 May 2013 16:39:07 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.247]) by mail67-co1.bigfish.com (Postfix) with ESMTP id F0B0380007B; Wed, 29 May 2013 16:39:06 +0000 (UTC) Received: from CH1PRD0811HT001.namprd08.prod.outlook.com (157.56.245.85) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 16:39:06 +0000 Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.155.36) with Microsoft SMTP Server (TLS) id 14.16.311.1; Wed, 29 May 2013 16:39:04 +0000 Message-ID: <51A62F27.6030707@internet2.edu> Date: Wed, 29 May 2013 12:39:03 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Wesley Eddy References: <5190FCF5.20200@mti-systems.com> <51A5AE9F.30905@wonderhamster.org> <51A62B46.90401@mti-systems.com> In-Reply-To: <51A62B46.90401@mti-systems.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [67.241.75.185] X-OriginatorOrg: internet2.edu Cc: aqm@ietf.org Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 16:39:16 -0000 On 05/29/13 12:22, Wesley Eddy allegedly wrote: > I was thinking 60 minutes, but it could easily expand to 90. If it were 90 minutes you could expand on "brief summary/summaries of ongoing AQM algorithm work". 10 minutes is close to nothing, you can't get into the substantive issues. From wes@mti-systems.com Wed May 29 09:45:02 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6386021F96DB for ; Wed, 29 May 2013 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLQW+-35sk45 for ; Wed, 29 May 2013 09:44:56 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id A1D5821F96CF for ; Wed, 29 May 2013 09:44:51 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.203]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4TGiouM031078 for ; Wed, 29 May 2013 12:44:50 -0400 Received: (qmail 12864 invoked by uid 0); 29 May 2013 16:44:50 -0000 Received: from unknown (HELO ?172.27.250.182?) (wes@mti-systems.com@63.226.32.150) by 0 with ESMTPA; 29 May 2013 16:44:50 -0000 Message-ID: <51A6307D.2090302@mti-systems.com> Date: Wed, 29 May 2013 12:44:45 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Scott Brim References: <5190FCF5.20200@mti-systems.com> <51A5AE9F.30905@wonderhamster.org> <51A62B46.90401@mti-systems.com> <51A62F27.6030707@internet2.edu> In-Reply-To: <51A62F27.6030707@internet2.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: aqm@ietf.org Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 16:45:02 -0000 On 5/29/2013 12:39 PM, Scott Brim wrote: > On 05/29/13 12:22, Wesley Eddy allegedly wrote: >> I was thinking 60 minutes, but it could easily expand to 90. > > If it were 90 minutes you could expand on "brief summary/summaries of > ongoing AQM algorithm work". 10 minutes is close to nothing, you can't > get into the substantive issues. > Yeah, if people want to do that, we should. My thought was only that for a BoF, we should be showing whether or not there are people who will do the work, and that the details of the algorithms and how they perform on test data sets might be too much. By the way, so far I think we've only heard about CoDel and PIE being written as I-Ds ... if there are other "next generation" AQMs that people are working on, or existing algorithms that people think should be progressed in this WG, we should definitely get those onto the radar as well. -- Wes Eddy MTI Systems From emmanuel.lochin@isae.fr Thu May 30 00:48:27 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D1221F975C for ; Thu, 30 May 2013 00:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA6PPqjSmv-z for ; Thu, 30 May 2013 00:48:23 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4210F21F9769 for ; Thu, 30 May 2013 00:48:16 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id 4518722E2C0; Thu, 30 May 2013 09:48:09 +0200 (CEST) Received: from [10.33.1.1] (pc-lochin.isae.fr [10.33.1.1]) by catalpa (Postfix) with ESMTP id BD9EFB7D5F; Thu, 30 May 2013 09:48:11 +0200 (CEST) Message-ID: <51A70516.5080003@isae.fr> Date: Thu, 30 May 2013 09:51:50 +0200 From: Emmanuel Lochin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: wes@mti-systems.com, swb@internet2.edu, aqm@ietf.org References: <51A6307D.2090302@mti-systems.com> <51A7002B.5070301@isae.fr> In-Reply-To: <51A7002B.5070301@isae.fr> Content-Type: multipart/alternative; boundary="------------080104010609050604090500" Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:48:27 -0000 This is a multi-part message in MIME format. --------------080104010609050604090500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, We are working on a novel stateless AQM named FavorQueue that might be of interest. I will attend Berlin meeting and could make a short talk on it. See our preliminary study here : http://arxiv.org/pdf/1103.2303v2.pdf Emmanuel > > -------- Message original -------- > Sujet: Re: [aqm] BoF planning > Date : Wed, 29 May 2013 12:44:45 -0400 > De : Wesley Eddy > Organisation : MTI Systems > Pour : Scott Brim > Copie à : aqm@ietf.org > > > > On 5/29/2013 12:39 PM, Scott Brim wrote: > > On 05/29/13 12:22, Wesley Eddy allegedly wrote: > >> I was thinking 60 minutes, but it could easily expand to 90. > > > > If it were 90 minutes you could expand on "brief summary/summaries of > > ongoing AQM algorithm work". 10 minutes is close to nothing, you can't > > get into the substantive issues. > > > > Yeah, if people want to do that, we should. My thought was only that > for a BoF, we should be showing whether or not there are people who > will do the work, and that the details of the algorithms and how they > perform on test data sets might be too much. > > By the way, so far I think we've only heard about CoDel and PIE being > written as I-Ds ... if there are other "next generation" AQMs that > people are working on, or existing algorithms that people think should > be progressed in this WG, we should definitely get those onto the > radar as well. > > -- > Wes Eddy > MTI Systems > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" --------------080104010609050604090500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi all,

We are working on a novel stateless AQM named FavorQueue that might be of interest.
I will attend Berlin meeting and could make a short talk on it.
See our preliminary study here : http://arxiv.org/pdf/1103.2303v2.pdf

Emmanuel


-------- Message original --------
Sujet: Re: [aqm] BoF planning
Date : Wed, 29 May 2013 12:44:45 -0400
De : Wesley Eddy <wes@mti-systems.com>
Organisation : MTI Systems
Pour : Scott Brim <swb@internet2.edu>
Copie à : aqm@ietf.org 


On 5/29/2013 12:39 PM, Scott Brim wrote:
> On 05/29/13 12:22, Wesley Eddy allegedly wrote:
>> I was thinking 60 minutes, but it could easily expand to 90.
> 
> If it were 90 minutes you could expand on "brief summary/summaries of
> ongoing AQM algorithm work".  10 minutes is close to nothing, you can't
> get into the substantive issues.
> 

Yeah, if people want to do that, we should.  My thought was only that
for a BoF, we should be showing whether or not there are people who
will do the work, and that the details of the algorithms and how they
perform on test data sets might be too much.

By the way, so far I think we've only heard about CoDel and PIE being
written as I-Ds ... if there are other "next generation" AQMs that
people are working on, or existing algorithms that people think should
be progressed in this WG, we should definitely get those onto the
radar as well.

-- 
Wes Eddy
MTI Systems
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




-- 
Emmanuel Lochin
Professeur ISAE - OSSI
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE)
Issu du rapprochement SUPAERO et ENSICA
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88
Web : http://personnel.isae.fr/emmanuel-lochin/
---
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"
--------------080104010609050604090500-- From David.Ros@telecom-bretagne.eu Thu May 30 00:52:58 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9FB21F9774 for ; Thu, 30 May 2013 00:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIWnnxmV+jzK for ; Thu, 30 May 2013 00:52:39 -0700 (PDT) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id B015B21F9756 for ; Thu, 30 May 2013 00:52:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 181CF6601B; Thu, 30 May 2013 09:52:35 +0200 (CEST) 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 6lQ+JwiVYR2m; Thu, 30 May 2013 09:52:34 +0200 (CEST) Received: from dhcp-salsa-i98.rennes.enst-bretagne.fr (dhcp-salsa-i98.rennes.enst-bretagne.fr [10.35.128.98]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 9A8106600A; Thu, 30 May 2013 09:52:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: David Ros In-Reply-To: <51A70516.5080003@isae.fr> Date: Thu, 30 May 2013 09:52:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6789DECA-FA73-43FB-A8DA-76EDBD35B281@telecom-bretagne.eu> References: <51A6307D.2090302@mti-systems.com> <51A7002B.5070301@isae.fr> <51A70516.5080003@isae.fr> To: Emmanuel Lochin X-Mailer: Apple Mail (2.1283) Cc: wes@mti-systems.com, swb@internet2.edu, aqm@ietf.org Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:52:59 -0000 On 30 mai 2013, at 09:51, Emmanuel Lochin wrote: > Hi all, >=20 > We are working on a novel stateless AQM named FavorQueue that might be = of interest. > I will attend Berlin meeting and could make a short talk on it. Hi, As Michael said, we at ICCRG have a long slot, so folks may give a = not-so-short talk if they prefer :-) David > See our preliminary study here : http://arxiv.org/pdf/1103.2303v2.pdf >=20 > Emmanuel >=20 >>=20 >> -------- Message original -------- >> Sujet: Re: [aqm] BoF planning >> Date : Wed, 29 May 2013 12:44:45 -0400 >> De : Wesley Eddy >> Organisation : MTI Systems >> Pour : Scott Brim >> Copie =E0 : aqm@ietf.org >>=20 >> On 5/29/2013 12:39 PM, Scott Brim wrote: >> > On 05/29/13 12:22, Wesley Eddy allegedly wrote: >> >> I was thinking 60 minutes, but it could easily expand to 90. >> >=20 >> > If it were 90 minutes you could expand on "brief summary/summaries = of >> > ongoing AQM algorithm work". 10 minutes is close to nothing, you = can't >> > get into the substantive issues. >> >=20 >>=20 >> Yeah, if people want to do that, we should. My thought was only that >> for a BoF, we should be showing whether or not there are people who >> will do the work, and that the details of the algorithms and how they >> perform on test data sets might be too much. >>=20 >> By the way, so far I think we've only heard about CoDel and PIE being >> written as I-Ds ... if there are other "next generation" AQMs that >> people are working on, or existing algorithms that people think = should >> be progressed in this WG, we should definitely get those onto the >> radar as well. >>=20 >> --=20 >> Wes Eddy >> MTI Systems >> _______________________________________________ >> aqm mailing list >>=20 >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >>=20 >=20 >=20 > --=20 > Emmanuel Lochin > Professeur ISAE - OSSI > Institut Sup=E9rieur de l'A=E9ronautique et de l'Espace (ISAE) > Issu du rapprochement SUPAERO et ENSICA > 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 > Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 > Web :=20 > http://personnel.isae.fr/emmanuel-lochin/ >=20 > --- > "This email and any attachments are confidential. They may contain = legally privileged information or copyright material. You should not = read, copy, use or disclose them without authorisation. If you are not = an intended recipient, please contact us at once by return email and = then delete both messages. We do not accept liability in connection with = computer virus, data corruption, delay, interruption, unauthorised = access or unauthorised amendment. This notice should not be removed" >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ "It would seem that you have no useful skill or talent whatsoever," he = said. "Have you thought of going into teaching?" -- Terry Pratchett From emmanuel.lochin@isae.fr Thu May 30 00:56:58 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC49721F97C7 for ; Thu, 30 May 2013 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMjZCGVOhoFF for ; Thu, 30 May 2013 00:56:55 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id BE55321F97AB for ; Thu, 30 May 2013 00:56:54 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id CDB1922E402; Thu, 30 May 2013 09:56:45 +0200 (CEST) Received: from [10.33.1.1] (pc-lochin.isae.fr [10.33.1.1]) by catalpa (Postfix) with ESMTP id 562A2B7D93; Thu, 30 May 2013 09:56:48 +0200 (CEST) Message-ID: <51A7071A.8090808@isae.fr> Date: Thu, 30 May 2013 10:00:26 +0200 From: Emmanuel Lochin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: David Ros References: <51A6307D.2090302@mti-systems.com> <51A7002B.5070301@isae.fr> <51A70516.5080003@isae.fr> <6789DECA-FA73-43FB-A8DA-76EDBD35B281@telecom-bretagne.eu> In-Reply-To: <6789DECA-FA73-43FB-A8DA-76EDBD35B281@telecom-bretagne.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: wes@mti-systems.com, swb@internet2.edu, aqm@ietf.org Subject: Re: [aqm] BoF planning X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:56:59 -0000 On 30/05/2013 09:52, David Ros wrote: > On 30 mai 2013, at 09:51, Emmanuel Lochin wrote: > >> Hi all, >> >> We are working on a novel stateless AQM named FavorQueue that might be of interest. >> I will attend Berlin meeting and could make a short talk on it. > Hi, > > As Michael said, we at ICCRG have a long slot, so folks may give a not-so-short talk if they prefer :-) Cool :) > > David > > >> See our preliminary study here : http://arxiv.org/pdf/1103.2303v2.pdf >> >> Emmanuel >> >>> -------- Message original -------- >>> Sujet: Re: [aqm] BoF planning >>> Date : Wed, 29 May 2013 12:44:45 -0400 >>> De : Wesley Eddy >>> Organisation : MTI Systems >>> Pour : Scott Brim >>> Copie à : aqm@ietf.org >>> >>> On 5/29/2013 12:39 PM, Scott Brim wrote: >>>> On 05/29/13 12:22, Wesley Eddy allegedly wrote: >>>>> I was thinking 60 minutes, but it could easily expand to 90. >>>> If it were 90 minutes you could expand on "brief summary/summaries of >>>> ongoing AQM algorithm work". 10 minutes is close to nothing, you can't >>>> get into the substantive issues. >>>> >>> Yeah, if people want to do that, we should. My thought was only that >>> for a BoF, we should be showing whether or not there are people who >>> will do the work, and that the details of the algorithms and how they >>> perform on test data sets might be too much. >>> >>> By the way, so far I think we've only heard about CoDel and PIE being >>> written as I-Ds ... if there are other "next generation" AQMs that >>> people are working on, or existing algorithms that people think should >>> be progressed in this WG, we should definitely get those onto the >>> radar as well. >>> >>> -- >>> Wes Eddy >>> MTI Systems >>> _______________________________________________ >>> aqm mailing list >>> >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >>> >> >> -- >> Emmanuel Lochin >> Professeur ISAE - OSSI >> Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) >> Issu du rapprochement SUPAERO et ENSICA >> 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 >> Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 >> Web : >> http://personnel.isae.fr/emmanuel-lochin/ >> >> --- >> "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > ================================================================= > David ROS > http://www.rennes.enst-bretagne.fr/~dros/ > > "It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" From mirja.kuehlewind@ikr.uni-stuttgart.de Thu May 30 05:21:09 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CD121F9360 for ; Thu, 30 May 2013 05:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohsevsg9Yr-R for ; Thu, 30 May 2013 05:20:55 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 66EA721F9354 for ; Thu, 30 May 2013 05:20:55 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id E8E5A60192; Thu, 30 May 2013 14:20:51 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id C99AB60184; Thu, 30 May 2013 14:20:51 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: aqm@ietf.org Date: Thu, 30 May 2013 14:20:51 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <5190FB21.5080100@mti-systems.com> In-Reply-To: <5190FB21.5080100@mti-systems.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201305301420.51606.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Wesley Eddy Subject: Re: [aqm] floating a draft charter X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 12:21:09 -0000 Hi Wes, thanks for writting up the chapter. The text reads really well. I'm in favor of using AQM and ECN, but when I was asking on the mailing lis= t,=20 why ECN is not used, the main answer was it's too complex (that relates to= =20 AQM) and doesn't give large benefits (as operators focus on low loss rates= =20 and high utilization only).=20 I believe the key to get AQM (and ECN) deployed is a very simple AQM scheme= =2E=20 And with simple I don't only mean simple to parametrize (like Codel) but al= so=20 a simple and easy to understand algorithm. E.g. a step function like propos= ed=20 with DCTCP (but higher threshold slightly below the may buffersize) to=20 incentive deployment of ECN. Loss-based connections would experienced the=20 same DropTail behavior than today, while ECN-enabled connections could=20 benefit. If more connection support ECN in future the threshold could be=20 lower. That's just a very brief idea (on deployment).=20 But my point is, we should not only to standardize more and more AQM=20 mechanisms because that's a large research area which maybe even should be= =20 homed in the IRTF, but we need to find actually deployment strategies. Havi= ng=20 a working group on AQM will already help to make people aware of the topic= =20 and maybe think about using AQM. But only standardizing more and more AQM=20 queue, might end up in investing a lot of working that no-one will ever use. Mirja On Monday 13 May 2013 16:39:29 Wesley Eddy wrote: > Hello AQMers. To get us a step closer to having a working > group, we'll need a charter. > > I drafted the attached one, and think it's an okay starting > point. If we can either hack on this or if someone has a > better one, I think it will be good to get done before the > Berlin meeting, since we'd like to have a WG-forming BoF. > > FYI, I think we would logically adopt Fred's draft for the > first milestone. =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From rs@netapp.com Thu May 30 07:59:38 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895FD21F885A for ; Thu, 30 May 2013 07:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSX-8pmfY2iu for ; Thu, 30 May 2013 07:59:33 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3AA21F9354 for ; Thu, 30 May 2013 07:59:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,770,1363158000"; d="scan'208";a="59614182" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 30 May 2013 07:59:26 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4UExQQg001580; Thu, 30 May 2013 07:59:26 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 30 May 2013 07:59:26 -0700 From: "Scheffenegger, Richard" To: Mirja Kuehlewind , "aqm@ietf.org" Thread-Topic: [aqm] floating a draft charter Thread-Index: AQHOT+e6aet5PcoMAEajIxapSmIFuJkeNciA//+0NmA= Date: Thu, 30 May 2013 14:59:25 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BBA438@SACEXCMBX02-PRD.hq.netapp.com> References: <5190FB21.5080100@mti-systems.com> <201305301420.51606.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201305301420.51606.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wesley Eddy Subject: Re: [aqm] floating a draft charter X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:59:39 -0000 The (operational) difficulty with a simple step-function ECN marking would = be that it treats non-ECN, and ECN flows differently, depending on the reac= tion to that signal. As soon as a mix of ECN and non-ECN reaches the thresh= old, all non-ECN packets would be dropped, but ECN would be marked (until = Drop-Tail of the queue has to happen when it runs full). Thus ECN would pus= h out non-ECN. Of course, for a DCTCP like sender/receiver with a gradual reaction (possib= ly even a per-segment congestion control reaction in the form of pacing or = cwnd adjustment), that would be a big incentive. Another question I have - from the control loop perspective, it would be pr= eferential to mark/drop at the head of the queue (at dequeue) rather at enq= ueue, which delays the signal (ECN or loss) by the queuing delay. What is t= he main obstacle, that this approach is rapidly dismissed, other than the "= wasted" cycles keeping a segment, that may be marked/dropped later, in the = queue. Are there implementation difficulties that basically rule out such a= strategy to minimize the delay of the congestion signal to the end hosts? = Or would (somehow) the drop of a segment of a different flow, which wasn't = actually the one that eventually overloads the queue, lead to unfairness be= tween flows or synchronization effects? Best regards, Richard Scheffenegger > -----Original Message----- > From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of > Mirja Kuehlewind > Sent: Donnerstag, 30. Mai 2013 14:21 > To: aqm@ietf.org > Cc: Wesley Eddy > Subject: Re: [aqm] floating a draft charter >=20 > Hi Wes, >=20 > thanks for writting up the chapter. The text reads really well. >=20 > I'm in favor of using AQM and ECN, but when I was asking on the mailing > list, why ECN is not used, the main answer was it's too complex (that > relates to > AQM) and doesn't give large benefits (as operators focus on low loss rate= s > and high utilization only). >=20 > I believe the key to get AQM (and ECN) deployed is a very simple AQM > scheme. > And with simple I don't only mean simple to parametrize (like Codel) but > also a simple and easy to understand algorithm. E.g. a step function like > proposed with DCTCP (but higher threshold slightly below the may > buffersize) to incentive deployment of ECN. Loss-based connections would > experienced the same DropTail behavior than today, while ECN-enabled > connections could benefit. If more connection support ECN in future the > threshold could be lower. That's just a very brief idea (on deployment). >=20 > But my point is, we should not only to standardize more and more AQM > mechanisms because that's a large research area which maybe even should b= e > homed in the IRTF, but we need to find actually deployment strategies. > Having a working group on AQM will already help to make people aware of > the topic and maybe think about using AQM. But only standardizing more an= d > more AQM queue, might end up in investing a lot of working that no-one > will ever use. >=20 > Mirja >=20 >=20 >=20 > On Monday 13 May 2013 16:39:29 Wesley Eddy wrote: > > Hello AQMers. To get us a step closer to having a working group, > > we'll need a charter. > > > > I drafted the attached one, and think it's an okay starting point. If > > we can either hack on this or if someone has a better one, I think it > > will be good to get done before the Berlin meeting, since we'd like to > > have a WG-forming BoF. > > > > FYI, I think we would logically adopt Fred's draft for the first > > milestone. >=20 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From wes@mti-systems.com Thu May 30 09:13:54 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3071421F96CC for ; Thu, 30 May 2013 09:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Yo4vDN7HI8 for ; Thu, 30 May 2013 09:13:48 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41421F96AC for ; Thu, 30 May 2013 09:13:48 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.207]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4UGDlOQ018209 for ; Thu, 30 May 2013 12:13:47 -0400 Received: (qmail 7241 invoked by uid 0); 30 May 2013 16:13:47 -0000 Received: from unknown (HELO ?172.27.250.182?) (wes@mti-systems.com@63.226.32.150) by 0 with ESMTPA; 30 May 2013 16:13:47 -0000 Message-ID: <51A77AB5.9040302@mti-systems.com> Date: Thu, 30 May 2013 12:13:41 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mirja Kuehlewind References: <5190FB21.5080100@mti-systems.com> <201305301420.51606.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201305301420.51606.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: aqm@ietf.org Subject: Re: [aqm] floating a draft charter X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:13:54 -0000 On 5/30/2013 8:20 AM, Mirja Kuehlewind wrote: > > But my point is, we should not only to standardize more and more AQM > mechanisms because that's a large research area which maybe even should be > homed in the IRTF, but we need to find actually deployment strategies. Having > a working group on AQM will already help to make people aware of the topic > and maybe think about using AQM. But only standardizing more and more AQM > queue, might end up in investing a lot of working that no-one will ever use. I suggest appending something like this to the charter: Many AQM algorithms have been proposed in academic literature, but very few are widely implemented and deployed. A goal of the working group is to produce recommendations that will actually be used, and algorithms that will actually be implemented, deployed in equipment, and enabled. Towards these ends, the group actively encourages participation from operators and implementers, and will coordinate with the IETF OPS area and other relevant parts of the IETF and Internet community. Wider research and evaluation of AQM mechanisms shall be coordinated with the IRTF/ICCRG, and significant participation in this WG from the academic and research community is highly desirable, when it is directly relevant to implementation and deployment. We will definitely need to get engagement from some of the operators that participate in the IETF, and should solicit participation more widely outside as well (e.g. advertise to NANOG list, bufferbloat list, etc.) in order to attract operators and implementers that aren't already aware of this activity. Would this help to address your concern? -- Wes Eddy MTI Systems From ycheng@google.com Thu May 30 09:17:17 2013 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE74821F95FC for ; Thu, 30 May 2013 09:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01sDr6QnkdNp for ; Thu, 30 May 2013 09:17:17 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 40DD121F96E5 for ; Thu, 30 May 2013 09:17:12 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ee20so458124lab.0 for ; Thu, 30 May 2013 09:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kSGd8pgFRw0xE9xoZ34bJGjp0Wq0x2BJD40/Sy1HDQA=; b=If9DuHBaRuriEmgpmvDZtJvT2vHf41lmbPz8TXLhO9VGc22LFKi8mGELct7OcvWrza dEGzaB+XUKs2MOj1TJARnM2z+tlyLkjObp5PLqWKCuubCeOFNwKA18x1OkyfrXaqArR2 YbIjOVIQOjPz3bSA6bZzF/P6N3TT6zZCY0pPKxreL7tyWe0iGlCcIj5a6/FpKKKogQMa +etalLSqbEbKraikbb1xck6bVXtvJOC52Hmww9JYiZlCHR2CKyiZ92m3qiDCF6xria77 q/3xhT1PhTtFvvB5Ddrvguqqcj3nI1HMTATTbTQj7DuAJIG+7Vr0yeN5RTL3vRs8EEn+ CvrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=kSGd8pgFRw0xE9xoZ34bJGjp0Wq0x2BJD40/Sy1HDQA=; b=Ny48c+yZ6m3g5yVihADpATDBdki5QywTPHYtBTW1swD3Vr3MdQpl5GKspXg226ZZvS j1Kx6ihA4W0RNIRRQBCIKV/Asm2UX51/Hxs/NGhZqQkYSrNRUJUqfWKeq93H2SzeadKV ANpfVLja+bgFSTkLkhIgD9BoUhoihDsOiELRX5lE0comlseZr1OAG62j0cbk/E249Ami VL5aut7np+lGxM6LJgD26pbe8eWLmacGuuh+l2Z5DRGBURTOgJF8o/DUv3yHDhGXXMF6 Zl0V9QvKbTtlHKzg9xKLuPT1vswoWr+lLGSiEWL1DLqhPzZqfDyjSyS/YgiXIt0HT9S9 zh/Q== X-Received: by 10.112.21.234 with SMTP id y10mr4113537lbe.53.1369930631134; Thu, 30 May 2013 09:17:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.80.227 with HTTP; Thu, 30 May 2013 09:16:51 -0700 (PDT) In-Reply-To: <51A77AB5.9040302@mti-systems.com> References: <5190FB21.5080100@mti-systems.com> <201305301420.51606.mirja.kuehlewind@ikr.uni-stuttgart.de> <51A77AB5.9040302@mti-systems.com> From: Yuchung Cheng Date: Thu, 30 May 2013 09:16:51 -0700 Message-ID: To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn+70e4wLTzQVWP5WvI8tpFpxQSlk/ckLAcQqfYhUj0BR/WZdvefe6OTrtUIGBFRpVKVvm31WiQXBqN23yKabUje4GxriFYYmHZWRMF4z523j1AGlOIaTHsmC3cId8USCw2WYD/fBy1UlhQ8o4Fy5P7PSHP8eMJVjmzc1sLudg2cH1MILoBtdb4rRYEta0f2ZHsbP7h Cc: Mirja Kuehlewind , aqm@ietf.org Subject: Re: [aqm] floating a draft charter X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:17:18 -0000 On Thu, May 30, 2013 at 9:13 AM, Wesley Eddy wrote: > On 5/30/2013 8:20 AM, Mirja Kuehlewind wrote: >> >> But my point is, we should not only to standardize more and more AQM >> mechanisms because that's a large research area which maybe even should be >> homed in the IRTF, but we need to find actually deployment strategies. Having >> a working group on AQM will already help to make people aware of the topic >> and maybe think about using AQM. But only standardizing more and more AQM >> queue, might end up in investing a lot of working that no-one will ever use. > > > I suggest appending something like this to the charter: > > Many AQM algorithms have been proposed in academic literature, but > very few are widely implemented and deployed. A goal of the working I would suggest changing "A goal" to "the goal" > group is to produce recommendations that will actually be used, and > algorithms that will actually be implemented, deployed in equipment, > and enabled. Towards these ends, the group actively encourages > participation from operators and implementers, and will coordinate > with the IETF OPS area and other relevant parts of the IETF and > Internet community. Wider research and evaluation of AQM mechanisms > shall be coordinated with the IRTF/ICCRG, and significant > participation in this WG from the academic and research community is > highly desirable, when it is directly relevant to implementation and > deployment. > > > We will definitely need to get engagement from some of the operators > that participate in the IETF, and should solicit participation more > widely outside as well (e.g. advertise to NANOG list, bufferbloat > list, etc.) in order to attract operators and implementers that aren't > already aware of this activity. > > Would this help to address your concern? > > > -- > Wes Eddy > MTI Systems > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm