From sebastien.jobert@orange.com Mon Dec 3 05:31:54 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 4A08D21F870D for ; Mon, 3 Dec 2012 05:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] 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 F0clqWg7lOFP for ; Mon, 3 Dec 2012 05:31:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 784CD21F8705 for ; Mon, 3 Dec 2012 05:31:53 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0F4E218C5F9; Mon, 3 Dec 2012 14:31:52 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E030B4C015; Mon, 3 Dec 2012 14:31:51 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 14:31:51 +0100 From: To: Wesley Eddy , "tsv-area@ietf.org" Subject: RE: AQM work in the IETF Thread-Topic: AQM work in the IETF Thread-Index: AQHNy4Gp3KfHSaKyDU2T0aaz/TnXVpgHGuzA Date: Mon, 3 Dec 2012 13:31:51 +0000 Message-ID: <5427_1354541511_50BCA9C7_5427_84_1_7F67B91079F7C74F9DAB55FC7872661E081D3C@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <50B2DA5E.1040005@mti-systems.com> In-Reply-To: <50B2DA5E.1040005@mti-systems.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 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, 03 Dec 2012 13:31:54 -0000 Hi all, I have a basic question about this proposal, for my own understanding: what= would more precisely be the problem statement? Would this activity only ai= m at providing solutions to the "buffer bloat" issue, or would it also addr= ess other topics related to queue management? Which use cases are targeted? As an example, could this activity include the notion of "wireless congesti= on" (which might be related to other activities, inside or outside IETF: e.= g. ConEx, UPCON, ...), and could it lead to study and to document new suita= ble AQM mechanisms for this? As far as I can see, I think the main interest and usage would be for "wire= less congestion" in such context. Thanks for the clarification. Cheers, S=E9bastien -----Message d'origine----- De=A0: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] De la p= art de Wesley Eddy Envoy=E9=A0: lundi 26 novembre 2012 03:57 =C0=A0: tsv-area@ietf.org Objet=A0: AQM work in the IETF 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 :). --=20 Wes Eddy MTI Systems ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bob.briscoe@bt.com Mon Dec 3 10:25: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 B494A21F894A for ; 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 ; 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 ; 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, 3 Dec 2012 18:24:58 +0000 To: Wesley Eddy From: Bob Briscoe 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From ford@isoc.org Tue Dec 4 00:26:08 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 DEF3C21F89D4 for ; Tue, 4 Dec 2012 00:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.085 X-Spam-Level: X-Spam-Status: No, score=-97.085 tagged_above=-999 required=5 tests=[AWL=5.953, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, 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 G1iTSodSk8zN for ; Tue, 4 Dec 2012 00:26:08 -0800 (PST) Received: from smtp201.dfw.emailsrvr.com (smtp201.dfw.emailsrvr.com [67.192.241.201]) by ietfa.amsl.com (Postfix) with ESMTP id 35D8721F8964 for ; Tue, 4 Dec 2012 00:26:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id E47612F040B; Tue, 4 Dec 2012 03:24:13 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.dfw1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 3332B2F008E; Tue, 4 Dec 2012 03:24:11 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: AQM work in the IETF From: Matthew Ford In-Reply-To: <50B2DA5E.1040005@mti-systems.com> Date: Tue, 4 Dec 2012 12:24:09 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DA02A81-F120-47D9-8497-F60C75271D2E@isoc.org> References: <50B2DA5E.1040005@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1499) 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, 04 Dec 2012 08:26:09 -0000 Hi Wes, Informed by a recent ISOC-hosted roundtable meeting (report is here: = http://www.internetsociety.org/doc/bandwidth-management-internet-society-t= echnology-roundtable-series) I have responses to some of your timely = questions (speaking personally, of course): On 26 Nov 2012, at 06:56, Wesley Eddy wrote: > Particularly, I have wondered: > - Should we have a working group looking at AQMs? I believe there is a strong and growing need for AQM at bottleneck links = and there is a need to document suitable algorithms and provide industry = guidance (in the form of BCPs) regarding tuning, where that is a = consideration, and applicability of particular mechanisms. But to get = beyond wishful thinking we need enough interest to produce a draft = charter, at least. > - If so, does it make sense to shoot for Standards Track > specifications? For promising and broadly supported algorithms, sure, why not? > - 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? I hope so, otherwise I think we have a pretty serious problem looming. > - Would it be valuable to have a test suite for AQMs > similar to what ICCRG was doing for high-rate TCP? I think this could be worth shooting for, although I can already imagine = lengthy discussions about the validity and relative 'weight' of specific = tests.=20 > - If any of this is of value, how much belongs in the > ICCRG versus TSV working groups? I tend to think this is valuable to the extent that it can be done in = the IETF rather than the IRTF. And I agree with Bob - most of the = relevant expertise is in TSV, although co-ordination with INT and OPS is = certainly going to be important. Mat From jsaldana@unizar.es Tue Dec 4 01:07:55 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 296EC21F859A for ; Tue, 4 Dec 2012 01:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 IEVXPsnrfXZz for ; Tue, 4 Dec 2012 01:07:54 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id D71E521F854B for ; Tue, 4 Dec 2012 01:07:53 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id qB497nYM024100; Tue, 4 Dec 2012 10:07:50 +0100 From: "Jose Saldana" To: "'Matthew Ford'" , "'Wesley Eddy'" References: <50B2DA5E.1040005@mti-systems.com> <9DA02A81-F120-47D9-8497-F60C75271D2E@isoc.org> In-Reply-To: <9DA02A81-F120-47D9-8497-F60C75271D2E@isoc.org> Subject: RE: AQM work in the IETF Date: Tue, 4 Dec 2012 10:07:51 +0100 Organization: Universidad de Zaragoza Message-ID: <004d01cdd1fe$d6f967a0$84ec36e0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEeT7inqMR/iDP3KpUJrNs4H1kaEgITpMeYmVa8uVA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 09:07:55 -0000 Hi all. I am following the discussion about buffers and AQM, so here go my 2 cents: In our research group in the University of Zaragoza, we have studied the effect of different buffer policies on some services, mainly real-time ones based on UDP (VoIP and networked games), when competing with other traffic. We have also calculated the results in terms of subjective quality estimators. Although we have not used AQM, we have used different FIFO buffer implementations: - Buffer measured in bytes - Buffer measured in number of packets - Time-limited buffer A summary of some of the conclusions: - In general, big buffers are bad for real-time traffic (of course). - If the buffer is measured in bytes, it is better for real-time services: they use small packets, and the drop probability is higher for big packets. - If the buffer is measured in packets, logically drop probability is the same for every packet. - Bufferbloat: Very big buffers make it impossible to use real-time services, when there is congestion. The added delays become unacceptable. Four papers about the question (you can find them in http://diec.unizar.es/~jsaldana/personal/index.htm): - "The Effect of Router Buffer Size on Subjective Gaming Quality Estimators based on Delay and Jitter", IEEE CCNC 2012 - "Influence of Online Games Traffic Multiplexing and Router Buffer on Subjective Quality", IEEE CCNC 2012 - "Evaluating the Influence of Multiplexing Schemes and Buffer Implementation on Perceived VoIP Conversation Quality," Computer Networks (Elsevier), 2012 If this work can be of any help, it would be perfect. As you see, we "like" studying buffers, so we could perhaps do some research studies about different AQM policies if necessary. Best regards, Jose > -----Mensaje original----- > De: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] En > nombre de Matthew Ford > Enviado el: martes, 04 de diciembre de 2012 9:24 > Para: Wesley Eddy > CC: tsv-area@ietf.org > Asunto: Re: AQM work in the IETF > > Hi Wes, > > Informed by a recent ISOC-hosted roundtable meeting (report is here: > http://www.internetsociety.org/doc/bandwidth-management-internet- > society-technology-roundtable-series) I have responses to some of your > timely questions (speaking personally, of course): > > > On 26 Nov 2012, at 06:56, Wesley Eddy wrote: > > > Particularly, I have wondered: > > - Should we have a working group looking at AQMs? > > I believe there is a strong and growing need for AQM at bottleneck links and > there is a need to document suitable algorithms and provide industry > guidance (in the form of BCPs) regarding tuning, where that is a > consideration, and applicability of particular mechanisms. But to get beyond > wishful thinking we need enough interest to produce a draft charter, at least. > > > - If so, does it make sense to shoot for Standards Track > > specifications? > > For promising and broadly supported algorithms, sure, why not? > > > - 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? > > I hope so, otherwise I think we have a pretty serious problem looming. > > > - Would it be valuable to have a test suite for AQMs similar to what > > ICCRG was doing for high-rate TCP? > > I think this could be worth shooting for, although I can already imagine > lengthy discussions about the validity and relative 'weight' of specific tests. > > > - If any of this is of value, how much belongs in the ICCRG versus > > TSV working groups? > > I tend to think this is valuable to the extent that it can be done in the IETF > rather than the IRTF. And I agree with Bob - most of the relevant expertise is > in TSV, although co-ordination with INT and OPS is certainly going to be > important. > > Mat > From michawe@ifi.uio.no Tue Dec 4 01:23:25 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 EE19221F8630 for ; Tue, 4 Dec 2012 01:23:24 -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 3v8-pLlEcaxy for ; Tue, 4 Dec 2012 01:23:24 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 6261321F86B7 for ; Tue, 4 Dec 2012 01:23:21 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Tfoij-00051V-Fe; Tue, 04 Dec 2012 10:23:17 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Tfoii-00005M-Sq; Tue, 04 Dec 2012 10:23:17 +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: <004d01cdd1fe$d6f967a0$84ec36e0$@unizar.es> Date: Tue, 4 Dec 2012 10:23:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B2DA5E.1040005@mti-systems.com> <9DA02A81-F120-47D9-8497-F60C75271D2E@isoc.org> <004d01cdd1fe$d6f967a0$84ec36e0$@unizar.es> To: jsaldana@unizar.es X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 4 sum rcpts/h 12 sum msgs/h 6 total rcpts 464 max rcpts/h 15 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.171, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DF4F0FD568BFB302FE70A1A04446B0614B418F83 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -51 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 132 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, 04 Dec 2012 09:23:25 -0000 Hi, Since you mention byte vs. packet based queues: the effect of using one = or the other can indeed be quite interesting. I'd like to throw this = paper into the mix: Lawrence Stewart, David Hayes, Grenville Armitage, Michael Welzl, = Andreas Petlund: "Multimedia-unfriendly TCP Congestion Control and Home = Gateway Queue Management", ACM Multimedia Systems Conference (MMSys = 2011), 23-25 February 2011, San Jose, California, USA. Cheers, Michael On 4. des. 2012, at 10:07, Jose Saldana wrote: > Hi all. I am following the discussion about buffers and AQM, so here = go my 2 > cents: >=20 > In our research group in the University of Zaragoza, we have studied = the > effect of different buffer policies on some services, mainly real-time = ones > based on UDP (VoIP and networked games), when competing with other = traffic. > We have also calculated the results in terms of subjective quality > estimators. >=20 > Although we have not used AQM, we have used different FIFO buffer > implementations: >=20 > - Buffer measured in bytes > - Buffer measured in number of packets > - Time-limited buffer >=20 > A summary of some of the conclusions: >=20 > - In general, big buffers are bad for real-time traffic (of course). > - If the buffer is measured in bytes, it is better for real-time = services: > they use small packets, and the drop probability is higher for big = packets. > - If the buffer is measured in packets, logically drop probability is = the > same for every packet. > - Bufferbloat: Very big buffers make it impossible to use real-time > services, when there is congestion. The added delays become = unacceptable. >=20 > Four papers about the question (you can find them in > http://diec.unizar.es/~jsaldana/personal/index.htm): >=20 > - "The Effect of Router Buffer Size on Subjective Gaming Quality = Estimators > based on Delay and Jitter", IEEE CCNC 2012 > - "Influence of Online Games Traffic Multiplexing and Router Buffer on > Subjective Quality", IEEE CCNC 2012 > - "Evaluating the Influence of Multiplexing Schemes and Buffer > Implementation on Perceived VoIP Conversation Quality," Computer = Networks > (Elsevier), 2012 >=20 > If this work can be of any help, it would be perfect. As you see, we = "like" > studying buffers, so we could perhaps do some research studies about > different AQM policies if necessary. >=20 > Best regards, >=20 > Jose >=20 >> -----Mensaje original----- >> De: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] En >> nombre de Matthew Ford >> Enviado el: martes, 04 de diciembre de 2012 9:24 >> Para: Wesley Eddy >> CC: tsv-area@ietf.org >> Asunto: Re: AQM work in the IETF >>=20 >> Hi Wes, >>=20 >> Informed by a recent ISOC-hosted roundtable meeting (report is here: >> http://www.internetsociety.org/doc/bandwidth-management-internet- >> society-technology-roundtable-series) I have responses to some of = your >> timely questions (speaking personally, of course): >>=20 >>=20 >> On 26 Nov 2012, at 06:56, Wesley Eddy wrote: >>=20 >>> Particularly, I have wondered: >>> - Should we have a working group looking at AQMs? >>=20 >> I believe there is a strong and growing need for AQM at bottleneck = links > and >> there is a need to document suitable algorithms and provide industry >> guidance (in the form of BCPs) regarding tuning, where that is a >> consideration, and applicability of particular mechanisms. But to get > beyond >> wishful thinking we need enough interest to produce a draft charter, = at > least. >>=20 >>> - If so, does it make sense to shoot for Standards Track >>> specifications? >>=20 >> For promising and broadly supported algorithms, sure, why not? >>=20 >>> - 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? >>=20 >> I hope so, otherwise I think we have a pretty serious problem = looming. >>=20 >>> - Would it be valuable to have a test suite for AQMs similar to = what >>> ICCRG was doing for high-rate TCP? >>=20 >> I think this could be worth shooting for, although I can already = imagine >> lengthy discussions about the validity and relative 'weight' of = specific > tests. >>=20 >>> - If any of this is of value, how much belongs in the ICCRG versus >>> TSV working groups? >>=20 >> I tend to think this is valuable to the extent that it can be done in = the > IETF >> rather than the IRTF. And I agree with Bob - most of the relevant > expertise is >> in TSV, although co-ordination with INT and OPS is certainly going to = be >> important. >>=20 >> Mat >>=20 >=20 >=20 From touch@isi.edu Tue Dec 4 09:18:16 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 72A0821F8C55 for ; Tue, 4 Dec 2012 09:18:16 -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 Myi2TAi-kxfm for ; Tue, 4 Dec 2012 09:18:10 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC821F8C00 for ; Tue, 4 Dec 2012 09:18:10 -0800 (PST) Received: from [192.168.0.20] (dlr-bs.smartcity.net [207.190.3.250]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qB4HHMYZ005738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Dec 2012 09:17:33 -0800 (PST) Message-ID: <50BE3022.3070404@isi.edu> Date: Tue, 04 Dec 2012 09:17:22 -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: jsaldana@unizar.es Subject: Re: AQM work in the IETF References: <50B2DA5E.1040005@mti-systems.com> <9DA02A81-F120-47D9-8497-F60C75271D2E@isoc.org> <004d01cdd1fe$d6f967a0$84ec36e0$@unizar.es> In-Reply-To: <004d01cdd1fe$d6f967a0$84ec36e0$@unizar.es> 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: Tue, 04 Dec 2012 17:18:16 -0000 On 12/4/2012 1:07 AM, Jose Saldana wrote: > Hi all. I am following the discussion about buffers and AQM, so here go my 2 > cents: > > In our research group in the University of Zaragoza, we have studied the > effect of different buffer policies on some services, mainly real-time ones > based on UDP (VoIP and networked games), when competing with other traffic. > We have also calculated the results in terms of subjective quality > estimators. > > Although we have not used AQM, we have used different FIFO buffer > implementations: > > - Buffer measured in bytes > - Buffer measured in number of packets > - Time-limited buffer > > A summary of some of the conclusions: > > - In general, big buffers are bad for real-time traffic (of course). > - If the buffer is measured in bytes, it is better for real-time services: > they use small packets, and the drop probability is higher for big packets. This depends on whether the resources are byte-based or packet-based. Byte-based examples include bandwidth (when supporting variable-sized frames at L2), encryption/authentication of the entire packet, and memory (using variable-sized buffers). Packet-based include header processing overheads, fixed-frame network capacity, and fixed-size buffers. How different traffic reacts to limited resources depends on how these resources are implemented, and which resources are limited/constrained. There's no single answer based solely on traffic. Joe From jsaldana@unizar.es Tue Dec 4 10:28:56 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 2246621F8CB7 for ; Tue, 4 Dec 2012 10:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 SgCD+WyP2lLC for ; Tue, 4 Dec 2012 10:28:55 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5A38221F8CAB for ; Tue, 4 Dec 2012 10:28:55 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id qB4ISnb2027302; Tue, 4 Dec 2012 19:28:49 +0100 From: "Jose Saldana" To: "'Joe Touch'" References: <50B2DA5E.1040005@mti-systems.com> <9DA02A81-F120-47D9-8497-F60C75271D2E@isoc.org> <004d01cdd1fe$d6f967a0$84ec36e0$@unizar.es> <50BE3022.3070404@isi.edu> In-Reply-To: <50BE3022.3070404@isi.edu> Subject: RE: AQM work in the IETF Date: Tue, 4 Dec 2012 19:28:52 +0100 Organization: Universidad de Zaragoza Message-ID: <000f01cdd24d$36f282b0$a4d78810$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEeT7inqMR/iDP3KpUJrNs4H1kaEgITpMeYAQgyiTcBnyFx8ZlCIp6A Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:28:56 -0000 Thanks, Joe. Another limitation to take into account is the number of packets per second that the buffer is able to send. Sometimes there is a gap between small packets, since there is a minimum time between packets. Best regards, Jose > -----Mensaje original----- > De: Joe Touch [mailto:touch@isi.edu] > Enviado el: martes, 04 de diciembre de 2012 18:17 > Para: jsaldana@unizar.es > CC: 'Matthew Ford'; 'Wesley Eddy'; tsv-area@ietf.org > Asunto: Re: AQM work in the IETF > > > > On 12/4/2012 1:07 AM, Jose Saldana wrote: > > Hi all. I am following the discussion about buffers and AQM, so here > > go my 2 > > cents: > > > > In our research group in the University of Zaragoza, we have studied > > the effect of different buffer policies on some services, mainly > > real-time ones based on UDP (VoIP and networked games), when > competing with other traffic. > > We have also calculated the results in terms of subjective quality > > estimators. > > > > Although we have not used AQM, we have used different FIFO buffer > > implementations: > > > > - Buffer measured in bytes > > - Buffer measured in number of packets > > - Time-limited buffer > > > > A summary of some of the conclusions: > > > > - In general, big buffers are bad for real-time traffic (of course). > > - If the buffer is measured in bytes, it is better for real-time services: > > they use small packets, and the drop probability is higher for big packets. > > This depends on whether the resources are byte-based or packet-based. > > Byte-based examples include bandwidth (when supporting variable-sized > frames at L2), encryption/authentication of the entire packet, and memory > (using variable-sized buffers). > > Packet-based include header processing overheads, fixed-frame network > capacity, and fixed-size buffers. > > How different traffic reacts to limited resources depends on how these > resources are implemented, and which resources are limited/constrained. > There's no single answer based solely on traffic. > > Joe From touch@isi.edu Tue Dec 4 10:34:13 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 174D821F8C6E for ; Tue, 4 Dec 2012 10:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.372 X-Spam-Level: X-Spam-Status: No, score=-104.372 tagged_above=-999 required=5 tests=[AWL=2.000, 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 w6qmsUog715x for ; Tue, 4 Dec 2012 10:34:12 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 08A2A21F858B for ; Tue, 4 Dec 2012 10:34:11 -0800 (PST) Received: from [192.168.0.20] (dlr-bs.smartcity.net [207.190.3.250]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qB4IX3Ev013031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Dec 2012 10:33:12 -0800 (PST) Message-ID: <50BE41DF.4070301@isi.edu> Date: Tue, 04 Dec 2012 10:33:03 -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: jsaldana@unizar.es Subject: Re: AQM work in the IETF References: <50B2DA5E.1040005@mti-systems.com> <9DA02A81-F120-47D9-8497-F60C75271D2E@isoc.org> <004d01cdd1fe$d6f967a0$84ec36e0$@unizar.es> <50BE3022.3070404@isi.edu> <000f01cdd24d$36f282b0$a4d78810$@unizar.es> In-Reply-To: <000f01cdd24d$36f282b0$a4d78810$@unizar.es> 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: Tue, 04 Dec 2012 18:34:13 -0000 On 12/4/2012 10:28 AM, Jose Saldana wrote: > Thanks, Joe. > > Another limitation to take into account is the number of packets per second > that the buffer is able to send. Sometimes there is a gap between small > packets, since there is a minimum time between packets. Such gaps are like per-packet overheads, which act like larger L2 headers, and can be accounted for that way. Joe > > Best regards, > > Jose > >> -----Mensaje original----- >> De: Joe Touch [mailto:touch@isi.edu] >> Enviado el: martes, 04 de diciembre de 2012 18:17 >> Para: jsaldana@unizar.es >> CC: 'Matthew Ford'; 'Wesley Eddy'; tsv-area@ietf.org >> Asunto: Re: AQM work in the IETF >> >> >> >> On 12/4/2012 1:07 AM, Jose Saldana wrote: >>> Hi all. I am following the discussion about buffers and AQM, so here >>> go my 2 >>> cents: >>> >>> In our research group in the University of Zaragoza, we have studied >>> the effect of different buffer policies on some services, mainly >>> real-time ones based on UDP (VoIP and networked games), when >> competing with other traffic. >>> We have also calculated the results in terms of subjective quality >>> estimators. >>> >>> Although we have not used AQM, we have used different FIFO buffer >>> implementations: >>> >>> - Buffer measured in bytes >>> - Buffer measured in number of packets >>> - Time-limited buffer >>> >>> A summary of some of the conclusions: >>> >>> - In general, big buffers are bad for real-time traffic (of course). >>> - If the buffer is measured in bytes, it is better for real-time > services: >>> they use small packets, and the drop probability is higher for big > packets. >> >> This depends on whether the resources are byte-based or packet-based. >> >> Byte-based examples include bandwidth (when supporting variable-sized >> frames at L2), encryption/authentication of the entire packet, and memory >> (using variable-sized buffers). >> >> Packet-based include header processing overheads, fixed-frame network >> capacity, and fixed-size buffers. >> >> How different traffic reacts to limited resources depends on how these >> resources are implemented, and which resources are limited/constrained. >> There's no single answer based solely on traffic. >> >> Joe From carlberg@g11.org.uk Tue Dec 4 12:51:13 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 7BA6321F85DC for ; Tue, 4 Dec 2012 12:51:13 -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 whKj81sp7Xjd for ; Tue, 4 Dec 2012 12:51:12 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id BFDA521F858A for ; Tue, 4 Dec 2012 12:51:12 -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:Subject:Mime-Version:Content-Type; bh=raLxKbjoQdiWGq8a4s5EPkbmGMGe+dd/vLlAtWmNjUg=; b=lwk7cJtdBgxE6JDW6jdSFDTcd3XxK03f6gQXKMGsxW3ZvoaW16hE0c+ooXiCFpDp6TTqjEZXDEuvHUwAEZt9EboBDft3hyU0fUytjnd7nY1a+uqr7Q3WTXMFI6BYHB8C; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:33747 helo=[10.0.1.20]) by portland.eukhosting.net with esmtp (Exim 4.80) (envelope-from ) id 1TfzSO-002K8C-Qo; Tue, 04 Dec 2012 20:51:08 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: AQM work in the IETF From: ken carlberg In-Reply-To: <201212031825.qB3IP1UX015831@bagheera.jungle.bt.co.uk> Date: Tue, 4 Dec 2012 15:51:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <652DDAE3-B722-4437-9441-99A92519D97B@g11.org.uk> References: <50B2DA5E.1040005@mti-systems.com> <201212031825.qB3IP1UX015831@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1499) 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: Tue, 04 Dec 2012 20:51:13 -0000 Bob, >>=20 >> - If any of this is of value, how much belongs in the >> ICCRG versus TSV working groups? >=20 > Well, RED and particularly WRED is very widely deployed. So that = implies at least guidelines about legacy should be in TSV not ICCRG. >=20 > 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. >=20 > 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. >=20 > 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. I think the exception is a BCP or simply a common practice that = discusses guidelines concerning deployed AQM. Something like that would = seem to be more in line with OPS. I don't think it has to be = all-or-nothing in terms where AQM work resides -- parts here and there = could be distributed depending heavily on what is being proposed/done. = And I would agree that a considerable amount of the expertise (and = energy) on the topic is in TSV. A few years ago, the requirements for adding a resource priority header = was initially done in IEPREP, and then when it was fleshed out (by the = group most interested in the topic), it was turned over to SIP (where = the expertise existed) and finalized there. I'm not saying we would = need to do the exact same thing, but we have options to consider. -ken From gorry@erg.abdn.ac.uk Wed Dec 5 06:25:32 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 1B79121F8C0D for ; Wed, 5 Dec 2012 06:25:32 -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 oH0J4P-nxTGz for ; Wed, 5 Dec 2012 06:25:31 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE4121F8BF7 for ; Wed, 5 Dec 2012 06:25:31 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 4DE2C2B4515; Wed, 5 Dec 2012 14:25:30 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 117212B4096; Wed, 5 Dec 2012 14:25:29 +0000 (GMT) Message-ID: <50BF5958.8000005@erg.abdn.ac.uk> Date: Wed, 05 Dec 2012 14:25:28 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 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 Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 14:25:32 -0000 My thoughts.... (1) TSVWG is about to submit a draft on Byte and Packet Congestion Notification - My understanding was that this was already about AQM, so yes this does fall within the IETF's area of interest. TSV may not be a bad area to do this (although it seems unusual), because the implications of AQM are directly linked to transport behaviours (AQM is not really to protect the forwarding or control plane or linked to routing, more to throttle resources for a flow). (2) It may be hard to set a charter. There are certainly problems here: - are there tools to easily see what is happening in deployed networks? this could perhaps be suited to ICCRG? - is there a common reference model we could use to compare? Is there wisdom on what may be bad, good, etc... It would be nice to have standard terminology, and guidelines... - are there specific algorithms, or combinations of techniques (like CoDel) that should be described ... could be tricky without a common framework? In sumamry, I think if we ignore this, then we are in danger of ignoring the existence of growing use of AQM, we've ignored other technologies in the past, and that can be bad when they become popular or turn in strange ways. To me it seems like transport - but if it is, then people from other areas MUST be engaged. Gorry On 26/11/2012 02:56, 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 :). >