Re: AQM work in the IETF
Bob Briscoe <bob.briscoe@bt.com> Mon, 03 December 2012 18:25 UTC
Return-Path: <bob.briscoe@bt.com>
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 B494A21F894A for <tsv-area@ietfa.amsl.com>; Mon, 3 Dec 2012 10:25:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level:
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ONJRK3yuCv1B for <tsv-area@ietfa.amsl.com>; Mon, 3 Dec 2012 10:25:15 -0800 (PST)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8A28D21F8949 for <tsv-area@ietf.org>; Mon, 3 Dec 2012 10:25:14 -0800 (PST)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 18:25:10 +0000
Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 18:25:11 +0000
Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Mon, 3 Dec 2012 18:25:03 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1354559103523; Mon, 3 Dec 2012 18:25:03 +0000
Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qB3IP1UX015831; Mon, 3 Dec 2012 18:25:01 GMT
Message-ID: <201212031825.qB3IP1UX015831@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 03 Dec 2012 18:24:58 +0000
To: Wesley Eddy <wes@mti-systems.com>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: Re: AQM work in the IETF
In-Reply-To: <50B2DA5E.1040005@mti-systems.com>
References: <50B2DA5E.1040005@mti-systems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: 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 <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2012 18:25:15 -0000
Wes, My 2 pennies worth inline At 02:56 26/11/2012, 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? Yes. During the lead-up to the RMCAT workshop & BoF, a number of us said that there are three problems for r-t apps, which I would rank in this order of importance (highest first): - AQM behaviour - competing TCP congestion avoidance behaviour - r-t app congestion avoidance behaviour So it makes sense to tackle the most important one as well as the least important. >- If so, does it make sense to shoot for Standards Track > specifications? Well, I would have thought informational specs of various algos proven to work well and a BCP saying what any algo should / should-not do. >- 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? Yes >- Would it be valuable to have a test suite for AQMs > similar to what ICCRG was doing for high-rate TCP? Yes and no. No, in that the tests for an AQM should be tailored to find deficiencies in a specific AQM that may be suspected by understanding the design of each one. Certainly, after that, other AQMs should be subjected to similar tests. However, this implies that the test surface should continually expand. This extensibility could be described in an RFC, but it implies a living document is also required. Yes, in that we can't expect everyone to think from first principles, so a process people can use that saves them thinking can be useful. >- 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? Yes. The advice in RFC3819 needs a serious update, for instance. Recently an industry consultant asked me where there is good advice on how to config existing switches and routers, and I realised the level of advice on the Web, let alone in the RFCs, is well out of date. >- If any of this is of value, how much belongs in the > ICCRG versus TSV working groups? Well, RED and particularly WRED is very widely deployed. So that implies at least guidelines about legacy should be in TSV not ICCRG. We are really gunning for self-configuring AQMs. They are not yet widely deployed so one could say that is a research subject. However, static config AQMs have been researched to death already (and parameter sensitivity), so I think we can say the area in general is understood enough to go straight into the IETF, not ICCRG. AQM for wireless interfaces has been less researched - probably better to have ICCRG activity in parallel, but allow anything sufficiently mature in the IETF too. Joe Touch says INT or OPS. I don't agree - there isn't the expertise there. I admit the core competence in TSV is e2e protocols, but TSV is where nearly all the expertise in queuing sits too. We should present to INT & OPS, but not do the work there. Thanks for raising this. Bob >Thanks for your thoughts :). > >-- >Wes Eddy >MTI Systems ________________________________________________________________ Bob Briscoe, BT Innovate & Design
- AQM work in the IETF Wesley Eddy
- Re: AQM work in the IETF ken carlberg
- Re: AQM work in the IETF Joe Touch
- Re: AQM work in the IETF John Leslie
- Re: AQM work in the IETF Michael Welzl
- Re: AQM work in the IETF David Ros
- RE: AQM work in the IETF sebastien.jobert
- Re: AQM work in the IETF Bob Briscoe
- Re: AQM work in the IETF Matthew Ford
- RE: AQM work in the IETF Jose Saldana
- Re: AQM work in the IETF Michael Welzl
- Re: AQM work in the IETF Joe Touch
- RE: AQM work in the IETF Jose Saldana
- Re: AQM work in the IETF Joe Touch
- Re: AQM work in the IETF ken carlberg
- Re: AQM work in the IETF Gorry Fairhurst