From Martin.Stiemerling@neclab.eu Mon Nov 5 07:32:33 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1431021F87D4; Mon, 5 Nov 2012 07:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.537 X-Spam-Level: X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBzLYoIo7o2m; Mon, 5 Nov 2012 07:32:29 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BFEEE21F883D; Mon, 5 Nov 2012 07:32:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 45A2F102418; Mon, 5 Nov 2012 16:32:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl8xqbAAJhcL; Mon, 5 Nov 2012 16:32:23 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 21E0F102421; Mon, 5 Nov 2012 16:32:13 +0100 (CET) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 16:31:32 +0100 Message-ID: <5097DBF1.30907@neclab.eu> Date: Mon, 5 Nov 2012 16:32:01 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: undisclosed-recipients:; Subject: TSV AD Office Hours@IETF#85 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] X-Mailman-Approved-At: Mon, 05 Nov 2012 07:36:27 -0800 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:32:33 -0000 Hi all, The TSV AD office hours in Atlanta will be held Tuesday, Nov 6, 1pm to 3pm. Room: IESG Office 202 Floor plan: http://www.ietf.org/meeting/85/floor-plans.pdf Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From wes@mti-systems.com Sun Nov 25 18:56:36 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5F21F84DF for ; Sun, 25 Nov 2012 18:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=-0.114, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo63juLEq+qF for ; Sun, 25 Nov 2012 18:56:35 -0800 (PST) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id A590B21F8432 for ; Sun, 25 Nov 2012 18:56:32 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAQ2uVg3007654 for ; Sun, 25 Nov 2012 21:56:31 -0500 Received: (qmail 26838 invoked by uid 0); 26 Nov 2012 02:56:31 -0000 Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.143.209) by 0 with ESMTPA; 26 Nov 2012 02:56:31 -0000 Message-ID: <50B2DA5E.1040005@mti-systems.com> Date: Sun, 25 Nov 2012 21:56:30 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: tsv-area@ietf.org Subject: AQM work in the IETF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 02:56:36 -0000 As TSV ADs, Martin and I have been wondering lately about AQM work. At this point, thanks largely to Jim Gettys, we all know about large buffers, and we know what bulk-transfer with loss-based congestion control can do to interactive traffic when large queues exist. We know one thing that can be done to help is the use of AQMs, but the IETF is currently not doing a whole lot to help in this regard. There is the CoDel I-D that was discussed in the TSVAREA meeting in Vancouver: http://tools.ietf.org/html/draft-nichols-tsvwg-codel-00 But this is an individual submission that Martin and I would be happy to sponsor, and not a working group activity. At the last IETF meeting, we had a request to talk about PIE, which we didn't have time for in TSVAREA, but ICCRG did: http://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.ppt This was really interesting, and we wonder if the community is interested in continuing to hear about AQMs in this space, and what the IETF should be doing. If people have thoughts about this, we'd like to hear about them on this list, and/or during the TSVAREA meeting in Orlando at the next IETF meeting. We want to know what the level of interest in AQMs is, and might make this a focus of the TSVAREA meeting, if a lot of people seem to think it's a good idea. Particularly, I have wondered: - Should we have a working group looking at AQMs? - If so, does it make sense to shoot for Standards Track specifications? - Would we be able to come up with actual requirements on an AQM so that it's implementable for cheap in hardware and software, and behaves well under load? - Would it be valuable to have a test suite for AQMs similar to what ICCRG was doing for high-rate TCP? - Would it be valuable to have a BCP (or multiple) on configuring "legacy AQM" like RED, or the use of AQM metrics like "sojourn time" rather than variations of the queue length? - If any of this is of value, how much belongs in the ICCRG versus TSV working groups? Thanks for your thoughts :). -- Wes Eddy MTI Systems From carlberg@g11.org.uk Mon Nov 26 04:12:30 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9796021F8588 for ; Mon, 26 Nov 2012 04:12:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR0uyjx+6tHf for ; Mon, 26 Nov 2012 04:12:25 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3FADE21F857E for ; Mon, 26 Nov 2012 04:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=j07BpCGzZgX4qF0jsKoKUV8UxlzKMg7MymsDgqq/LD8=; b=ChzzJNvJ6/oYnyCgOc0wsZZ9FqZmBTdXucdqMdws3pWtaEFWZkKDNVFywOREBoV5VcKyjbnrM+f/8Ooy1cfDH0Ep89UxKUzL3N9LWvm2CXt+90ZWzSmniGgFU/56WoSe; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:35058 helo=[10.0.1.20]) by portland.eukhosting.net with esmtp (Exim 4.80) (envelope-from ) id 1TcxXw-000EYe-JO; Mon, 26 Nov 2012 12:12:20 +0000 Subject: Re: AQM work in the IETF Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: <50B2DA5E.1040005@mti-systems.com> Date: Mon, 26 Nov 2012 07:12:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B2DA5E.1040005@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 12:12:30 -0000 I, for one, would be very interested to see work done in this area, so = count me as one of the infamous "+1". I think a good place to start is = a BCP (or multiple, depending on what is to be accomplished), and then = from that point consider subsequent related topics. And certainly, we'd = want the Ops folks involved, though that brings up the question of = whether such an effort should start in Ops first. Perhaps other questions to bring to the table would be: - would there be a need for a requirements and/or framework document? =20= - does one anticipate signaling (predominantly, intra-domain) to = configure AQM nodes to reflect an administrative policy? the downside of the above questions is that they can slow the entire = process down and perhaps get us in a situation of lost in introspective = thought. On the other hand, they could help provide direction of any = potential working group and help bound the problem space. I think the = problems still exist in finding the "sweet spot" in determining the = right configurations for AQM, and dissiminating this information on a = domain-wide basis. -ken On Nov 25, 2012, at 9:56 PM, Wesley Eddy wrote: > Particularly, I have wondered: > - Should we have a working group looking at AQMs? > - If so, does it make sense to shoot for Standards Track > specifications? > - Would we be able to come up with actual requirements > on an AQM so that it's implementable for cheap in > hardware and software, and behaves well under load? > - Would it be valuable to have a test suite for AQMs > similar to what ICCRG was doing for high-rate TCP? > - Would it be valuable to have a BCP (or multiple) on > configuring "legacy AQM" like RED, or the use of AQM > metrics like "sojourn time" rather than variations of > the queue length? > - If any of this is of value, how much belongs in the > ICCRG versus TSV working groups? From touch@isi.edu Mon Nov 26 10:01:15 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFD721F84E9 for ; Mon, 26 Nov 2012 10:01:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggVwj9lCfr9J for ; Mon, 26 Nov 2012 10:01:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id BF32D21F84E6 for ; Mon, 26 Nov 2012 10:01:14 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qAQI0hXi007742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Nov 2012 10:00:43 -0800 (PST) Message-ID: <50B3AE4A.2030007@isi.edu> Date: Mon, 26 Nov 2012 10:00:42 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Wesley Eddy Subject: Re: AQM work in the IETF References: <50B2DA5E.1040005@mti-systems.com> In-Reply-To: <50B2DA5E.1040005@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:01:15 -0000 Hi, all, Although I would expect TSV-AREA and others (APPS, even SEC) to have strong interest and participatio, perhaps this should be raised as a plenary issue and then handled within either INT or OPS where IMO it belongs. Joe On 11/25/2012 6:56 PM, Wesley Eddy wrote: > As TSV ADs, Martin and I have been wondering lately about > AQM work. > > At this point, thanks largely to Jim Gettys, we all know > about large buffers, and we know what bulk-transfer with > loss-based congestion control can do to interactive traffic > when large queues exist. > > We know one thing that can be done to help is the use of > AQMs, but the IETF is currently not doing a whole lot to > help in this regard. > > There is the CoDel I-D that was discussed in the TSVAREA > meeting in Vancouver: > http://tools.ietf.org/html/draft-nichols-tsvwg-codel-00 > But this is an individual submission that Martin and I > would be happy to sponsor, and not a working group > activity. > > At the last IETF meeting, we had a request to talk about > PIE, which we didn't have time for in TSVAREA, but ICCRG > did: > http://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.ppt > > This was really interesting, and we wonder if the > community is interested in continuing to hear about > AQMs in this space, and what the IETF should be doing. > > If people have thoughts about this, we'd like to hear > about them on this list, and/or during the TSVAREA > meeting in Orlando at the next IETF meeting. We want > to know what the level of interest in AQMs is, and > might make this a focus of the TSVAREA meeting, if a > lot of people seem to think it's a good idea. > > Particularly, I have wondered: > - Should we have a working group looking at AQMs? > - If so, does it make sense to shoot for Standards Track > specifications? > - Would we be able to come up with actual requirements > on an AQM so that it's implementable for cheap in > hardware and software, and behaves well under load? > - Would it be valuable to have a test suite for AQMs > similar to what ICCRG was doing for high-rate TCP? > - Would it be valuable to have a BCP (or multiple) on > configuring "legacy AQM" like RED, or the use of AQM > metrics like "sojourn time" rather than variations of > the queue length? > - If any of this is of value, how much belongs in the > ICCRG versus TSV working groups? > > Thanks for your thoughts :). > From john@jlc.net Mon Nov 26 11:54:41 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A6F21F852D for ; Mon, 26 Nov 2012 11:54:41 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q5stz3cW+DZ for ; Mon, 26 Nov 2012 11:54:40 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BCF9B21F852C for ; Mon, 26 Nov 2012 11:54:40 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id B31D333C28; Mon, 26 Nov 2012 14:54:40 -0500 (EST) Date: Mon, 26 Nov 2012 14:54:40 -0500 From: John Leslie To: Wesley Eddy Subject: Re: AQM work in the IETF Message-ID: <20121126195440.GB1941@verdi> References: <50B2DA5E.1040005@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B2DA5E.1040005@mti-systems.com> User-Agent: Mutt/1.4.1i Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:54:41 -0000 Wesley Eddy wrote: > > As TSV ADs, Martin and I have been wondering lately about > AQM work. > > At this point, thanks largely to Jim Gettys, we all know > about large buffers, and we know what bulk-transfer with > loss-based congestion control can do to interactive traffic > when large queues exist. > > We know one thing that can be done to help is the use of > AQMs, but the IETF is currently not doing a whole lot to > help in this regard. This issue tends to fall in the cracks between areas. :^( TSV is the area best adapted to standardize AQM algorithms; but there is no mechanism to request a particular algorithm be used, or to report which algorithm was in use. It's not entirely clear where those mechanisms might fit; and of course passing parameters would be desirable... >... Particularly, I have wondered: > - Should we have a working group looking at AQMs? I have great difficulty imaging a charter. > - If so, does it make sense to shoot for Standards Track > specifications? Probably not yet. > - Would we be able to come up with actual requirements > on an AQM so that it's implementable for cheap in > hardware and software, and behaves well under load? That's the easy part. > - Would it be valuable to have a test suite for AQMs > similar to what ICCRG was doing for high-rate TCP? Not clear. > - Would it be valuable to have a BCP (or multiple) on > configuring "legacy AQM" like RED, or the use of AQM > metrics like "sojourn time" rather than variations of > the queue length? At the current state-of-the-art, No (IMHO). > - If any of this is of value, how much belongs in the > ICCRG versus TSV working groups? Clearly, anything can be chartered to ICCRG: but this doesn't typically lead to fast progress. I would suggest discussion in of how to communicate algorithms and parameters. -- John Leslie From michawe@ifi.uio.no Tue Nov 27 01:29:34 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322D321F8580 for ; Tue, 27 Nov 2012 01:29:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brzruPpYPC-v for ; Tue, 27 Nov 2012 01:29:33 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7621F8534 for ; Tue, 27 Nov 2012 01:29:32 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TdHTs-0005m5-AP; Tue, 27 Nov 2012 10:29:28 +0100 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 1TdHTr-0007OH-V6; Tue, 27 Nov 2012 10:29:28 +0100 Subject: Re: AQM work in the IETF Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20121126195440.GB1941@verdi> Date: Tue, 27 Nov 2012 10:29:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3A39BADF-6AC5-4BB3-A10A-D3D679473301@ifi.uio.no> References: <50B2DA5E.1040005@mti-systems.com> <20121126195440.GB1941@verdi> To: John Leslie X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 309 max rcpts/h 15 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: 5872DDE254234E8DFC08B2549271469222680A03 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 53 max/h 9 blacklist 0 greylist 0 ratelimit 0 Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 09:29:35 -0000 Hi, On 26. nov. 2012, at 20:54, John Leslie wrote: >> - If any of this is of value, how much belongs in the >> ICCRG versus TSV working groups? >=20 > Clearly, anything can be chartered to ICCRG: but this doesn't > typically lead to fast progress. I think we can mention draft-fairhurst-tcpm-newcwv as a counter-example, = that one was dealt with quite swiftly. In fact, the notorical "slow progress" cases (Compound TCP, CUBIC, HTCP, = even my own MulTFRC) are slow because of the authors not following up, = so ICCRG itself isn't the reason. Cheers, Michael From David.Ros@telecom-bretagne.eu Tue Nov 27 07:20:47 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7562921F8419 for ; Tue, 27 Nov 2012 07:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tem5GO4aiPhZ for ; Tue, 27 Nov 2012 07:20:46 -0800 (PST) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id B1B9D21F8235 for ; Tue, 27 Nov 2012 07:20:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 1B598301A5; Tue, 27 Nov 2012 16:20:42 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRMsT9pYo5yB; Tue, 27 Nov 2012 16:20:41 +0100 (CET) Received: from arabica.home (ARennes-653-1-12-57.w92-139.abo.wanadoo.fr [92.139.171.57]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id 5914A301A4; Tue, 27 Nov 2012 16:20:41 +0100 (CET) Subject: Re: AQM work in the IETF Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: David Ros In-Reply-To: <50B2DA5E.1040005@mti-systems.com> Date: Tue, 27 Nov 2012 16:20:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84F1B97D-E073-4B44-B0C1-0ED0F2ADCDB8@telecom-bretagne.eu> References: <50B2DA5E.1040005@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1283) Cc: iccrg list , tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:20:47 -0000 On 26 nov. 2012, at 03:56, Wesley Eddy wrote: > As TSV ADs, Martin and I have been wondering lately about > AQM work. >=20 > At this point, thanks largely to Jim Gettys, we all know > about large buffers, and we know what bulk-transfer with > loss-based congestion control can do to interactive traffic > when large queues exist. >=20 > We know one thing that can be done to help is the use of > AQMs, but the IETF is currently not doing a whole lot to > help in this regard. >=20 > There is the CoDel I-D that was discussed in the TSVAREA > meeting in Vancouver: > http://tools.ietf.org/html/draft-nichols-tsvwg-codel-00 > But this is an individual submission that Martin and I > would be happy to sponsor, and not a working group > activity. >=20 > At the last IETF meeting, we had a request to talk about > PIE, which we didn't have time for in TSVAREA, but ICCRG > did: > http://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.ppt >=20 > This was really interesting, and we wonder if the > community is interested in continuing to hear about > AQMs in this space, and what the IETF should be doing. >=20 > If people have thoughts about this, we'd like to hear > about them on this list, and/or during the TSVAREA > meeting in Orlando at the next IETF meeting. We want > to know what the level of interest in AQMs is, and > might make this a focus of the TSVAREA meeting, if a > lot of people seem to think it's a good idea. Hi, Some thoughts from Michael & I, with ICCRG chair hats on. I'm cc'ing the = ICCRG list, just in case. >=20 > Particularly, I have wondered: > - Should we have a working group looking at AQMs? > - If so, does it make sense to shoot for Standards Track > specifications? > - Would we be able to come up with actual requirements > on an AQM so that it's implementable for cheap in > hardware and software, and behaves well under load? > - Would it be valuable to have a test suite for AQMs > similar to what ICCRG was doing for high-rate TCP? An AQM test suite is in the purview of ICCRG, IOHO. And it'd certainly = be valuable to have such a test suite. > - Would it be valuable to have a BCP (or multiple) on > configuring "legacy AQM" like RED, or the use of AQM > metrics like "sojourn time" rather than variations of > the queue length? > - If any of this is of value, how much belongs in the > ICCRG versus TSV working groups? Metrics-related stuff (as in, e.g., what metric should an arbitrary AQM = algorithm base its decisions upon) looks to us as ICCRG material. Other = stuff seems more fit to TSV. ICCRG has served as an "intermediate" forum = for experimental things that are not ready for a WG yet, so we can take = that role again w.r.t. AQMs and TSVWG, just like the RG did for = high-speed-TCPs and TCPM -- and, as Michael said, things getting stuck = in the ICCRG-to-TCPM path wasn't the fault of the RG, actually. Or, the = RG can be the home of Experimental RFCs for AQMs, that would move later = to TSVWG when (if) moving to Standards-track. Our take is, AQMs in general fit in ICCRG, and for some AQM-related = things Informational or Experimental RFCs are possible outputs from the = RG; in particular, we would very much like to see the new PIE proposal = published through ICCRG. Thanks, David. >=20 > Thanks for your thoughts :). >=20 > --=20 > Wes Eddy > MTI Systems =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/ Deadlines really start to press a week or two after they pass. -- John = Perry