From chelai@cisco.com Wed Jul 10 16:43: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 6D04D11E814E; Wed, 10 Jul 2013 16:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kYnkvpgVEuWp; Wed, 10 Jul 2013 16:42:56 -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 7FEB121F9B38; Wed, 10 Jul 2013 16:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8199; q=dns/txt; s=iport; t=1373499775; x=1374709375; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JD1mJnu2lnchGEMAxov2z+JrzktK+Y27xua2GBg46/Y=; b=g4C/OCFf3raKEiTQ04BzB1ks6Jnar3d59EIWMZsGaO6NbD4+fSzC/qZF jSQduEJqhNe1IW6ovcndB0AjabDx6N3HzRK8bXU+d2InvDf9N6R3p/YOm UfL7I6V8K7dx5aF5bA6ajFrU2ZPGwlDc1u8u4nXjd8noXG2gEB4tbUDE8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAOXw3VGtJV2b/2dsb2JhbABagwkyTcEngQ4WdIIjAQEBAQIBZRQFBwQCAQgRAQMBAQEKAhcEBzIUAwYIAgQBDQEECAGIAAYMt16PMgYrAgUGgwNsA4hvkBSQIYFYgTmCKA X-IronPort-AV: E=Sophos;i="4.87,1039,1363132800"; d="scan'208";a="233346935" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 10 Jul 2013 23:42:54 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6ANgr0q016324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 23:42:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 18:42:53 -0500 From: "Cheng-Jia Lai (chelai)" To: Dave Taht , "Toerless Eckert (eckert)" Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) Thread-Index: AQHOfaBDTO2Q2/ChiUO6fKWGKHceJZleig/Q Date: Wed, 10 Jul 2013 23:42:52 +0000 Message-ID: References: <20130710180147.GA614@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.170] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [aqm] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) 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, 10 Jul 2013 23:43:00 -0000 Yes, NM could also work with ECN (and it should be made so). In fact, we di= d implementation using WRED on routers that support ECN markings. If RTP en= dpoints support ECN markings, WRED will mark ECN instead of dropping the pa= ckets as avg Q size is between min & max threshold. But it still suffers fr= om unfairness at congestion, where the avg Q size starts to exceed the max = threshold for the lowest priority packet class... We did experience a hard time trying to properly configure WRED parameters = for preferential dropping of video packets with our NM implementation... It= is a good insight you said here: maybe it is worth exploring how our work = can perhaps use other AQM algorithms like CoDel, PIE, etc. In fact, NM doesn't need specific AQM to drop by probabilities... it will b= e interesting to see how it can work with delay-based dropping. However, NM= does require some "weighted" version of those AQMs. Hopefully a weighted v= ersion (if any) won't introduce new parameters (or too many) to configure t= he AQM. Regards, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of D= ave Taht Sent: Wednesday, July 10, 2013 12:02 PM To: Toerless Eckert (eckert) Cc: rmcat@ietf.org; rtcweb@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality un= der congestion (draft-lai-tsvwg-normalizer-00.txt) On Wed, Jul 10, 2013 at 11:01 AM, Toerless Eckert (eckert) wrote: > When dealing with congestion for real-time datagram (UDP/RTP) based video= flows, one idea > that we think has shown to provide good value is to intelligently drop in= the network > preferentially the least important packets within a video flow, for examp= le non-referenced > P-frames, because their loss creates the lowest impact to video quality. I've begun to look at webrtc of late in the context of fq_codel. One thing that might work would be ECN marking important frames and not ECN marking others. Problem overall is that ecn can be gamed and is largely not enabled, and so on... > One of the main concerns raised against such schemes was one of fairness.= If flows > would start to indicate different priorities for packets in them, how wou= ld we > be able to avoid that flows would indicate all their packets to be of hig= h priority > to shift packet drops to other flows. Or even more importantly: how could= we motivate > flows to indicate that some of their packets are low priority without the= m having to > fear that they would experience more loss than than flows that don't do t= his. same gaming problem... > So, there is one draft that we would like to present (presumably in TSVWG= ) explaining > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.tx= t > > (Actually, this is how we did solve the problem in our implementatin of i= ntelligent dropping, > so this is not theoretical). In the case of the fq_codel algorithm I can see a "delayed drop" mechanism happening, where upon deciding to drop, it could defer a drop up to a few packets based on the classification of the packet, say 3 packets at most. Since flows are already identified, this is kind of easy by adding another state variable... At the moment what I have deployed and tested most is a simple 3 tier fq_codel based shaper, which has a priority, best effort, and background queue. The priority queue is generally only DNS traffic, the background is only CS1, and fq_codel does such a good job with sparse streams in the general case that for VOIP, etc on the networks I fiddle with, there is no point in having much more than the BE queue. And presently all other markings are ignored. video is another story. (or could be, I don't know enough about webrtc's behaviors to "see" what will happen) So I can see trying to utilize the AF markings as you describe in your draft in codel's drop decision. While this is also subject to being gamed, the disincentives are slight. This is a little different from using "drop probability" as the decider, however, but I would hope that this mapping of the old AF style random drop ideas into the new style delay ideas could work... And what codel depends on is a definition of "TCP friendly". That if a stream is not going to behave in a tcp friendly manner, then an entirely different strategy for such flows seems necessary, and glomming on some additional state isn't going to be the right thing. > Now granted, the problem of fairness is but one element of building a com= plete ssytem > around the idea of intelligent dropping, so if folks here on the lists wo= uld like to > see for example > > a) how well can it work in routers to shift packet drops to low-prio pa= ckets I guess where I fall apart here is how to shift the encoders to send thinne= r streams at any level of packet drop. > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward > Then please let us know. We'd be very interested to provide insight into = the parts of > those pieces that we have also worked out or discuss the ones we have not= (primarily c ;-) I'd be interested in specific codecs, example video streams, and test scripts to try and fiddle with this, as well as viable metrics. > > Thanks! > Toerless > > In-Reply-To: > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: >> Hi all, >> >> We have submitted a new Internet draft to describe a Normalization Marke= r (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of = NM deployment is to create a new incentive for video encoders to generate m= ore discardable packets when using AF PHB in DIffServ. We are looking forwa= rd to your review comments. >> >> Best regards, >> CJ >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert= ); Fred Yip (fyip) >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt >> >> >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >> >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-nor= malizer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normali= zer >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-0= 0 >> >> >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) with >> discardable packets in a more balanced distribution. >> >> >> >> >> The IETF Secretariat >> > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From wes@mti-systems.com Wed Jul 10 21:43: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 CDDF01F0D3D for ; Wed, 10 Jul 2013 21:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 X6cWMWnVWAOA for ; Wed, 10 Jul 2013 21:43:11 -0700 (PDT) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 10AEF1F0D3F for ; Wed, 10 Jul 2013 21:43:09 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6B4gU3D008423 for ; Thu, 11 Jul 2013 00:42:30 -0400 Received: (qmail 28065 invoked by uid 0); 11 Jul 2013 04:42:30 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.122?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 11 Jul 2013 04:42:30 -0000 Message-ID: <51DE37B1.3010909@mti-systems.com> Date: Thu, 11 Jul 2013 00:42:25 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [aqm] draft BoF agenda 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, 11 Jul 2013 04:43:18 -0000 Richard and I have come up with the draft agenda below for the AQM BoF in Berlin. Some presentations are still being confirmed. If you have any significant thoughts about this, we'll be happy to hear them. Background (chairs) - 5 min (1700 - 1705) (introduce the BoF and give a brief summary of AQM discussion in TSVAREA at last IETF draft charter will be posted to mailing list, and we will assume people are roughly familiar with it) Recommendations (Fred Baker) - 10 min (1705 - 1715) (talk about the state of the document and what it's trying to do in terms of updating 2309 and adding lessons learned) http://tools.ietf.org/html/draft-baker-aqm-recommendation Example Algorithms For Consideration - 30 min (1715 - 1745) PIE (speaker TBD) - 10 min http://tools.ietf.org/html/draft-pan-tsvwg-pie *FQ_CODEL and/or variants (speaker TBD) - 10 min http://tools.ietf.org/html/draft-nichols-tsvwg-codel compare/contrast goals/features (speaker TBD) - 10 min (need to mention packet scheduling versus pure single-queue AQM as distinguishing features here) BoF Questions (chairs) - remaining time (1745 - 1830) (put up draft charter on screen for reference) - should packet scheduling be a part of the charter? - are the goals of this WG clear, well-scoped, solvable, and useful? - should Fred's document be an initial WG item? - how many people might be planning to work directly on algorithms? (writing the specs, implementing, testing / evaluating) - should the group require evaluation criteria and requirements to be finished before adopting algorithm specifications? - should the group initially aim for a single AQM spec, or take on multiple algorithms in parallel? - should an AQM working group be formed? - should the working group NOT be formed? Adjourn BoF at or before 1830 -- Wes Eddy MTI Systems From wes@mti-systems.com Wed Jul 10 21:50:34 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 BF39321F8D10 for ; Wed, 10 Jul 2013 21:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ULfsl2Yme2vJ for ; Wed, 10 Jul 2013 21:50:29 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 056AC21F9C66 for ; Wed, 10 Jul 2013 21:50:27 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6B4oPaV013787 for ; Thu, 11 Jul 2013 00:50:25 -0400 Received: (qmail 12794 invoked by uid 0); 11 Jul 2013 04:50:25 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.122?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 11 Jul 2013 04:50:24 -0000 Message-ID: <51DE398B.2090103@mti-systems.com> Date: Thu, 11 Jul 2013 00:50:19 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: multipart/mixed; boundary="------------010701030105060209010900" Subject: [aqm] updated 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, 11 Jul 2013 04:50:34 -0000 This is a multi-part message in MIME format. --------------010701030105060209010900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think the attached updated draft charter reflects most of the feedback that we've heard so far. Note that Dave Taht suggested we might want to go with something like "Smarter Queue Management" (SQM) for the WG name, because purely AQM as a name may not capture FQ type of mechanisms that we may want to have in-scope. I think that scoping discussion may still be going on into Berlin, but it's a good point, and likely some other people have cute ideas for a name that could capture the potential broader scope. -- Wes Eddy MTI Systems --------------010701030105060209010900 Content-Type: text/plain; charset=windows-1252; name="AQM-charter-130711.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="AQM-charter-130711.txt" Active Queue Management and Packet Scheduling (AQM) or Smarter Queue Management (SQM) (suggested by Dave Taht) Internet routers, lower-layer switches, other middleboxes include buffers or queues to hold packets when they are not immediately able to be forwarded to the next hop. The queues are intended to absorb bursts of traffic that may naturally occur, and avoid unneccessary losses. However, queues also cause latency and jitter in the eventual arrival times of packets. This can create issues and complications for interactive applications. Extremely large buffers have been noticed in some software and equipment. When these queues fill, interactive applications and other traffic can be severely impacted or completely broken, due to high and potentially oscillating delays. The Active Queue Management and Packet Scheduling working group (AQM) works on algorithms for proactively managing queues in order to: (1) help flow sources control their sending rates before the onset of necessary losses, e.g. through ECN (2) help minimize delays for interactive applications (3) help protect flows from negative impacts of other more aggressive or misbehaving flows The AQM working group will publish Informational and Best Current Practices documents that cover the design, use, and configuration of algorithms for managing queues in Internet devices and software. The AQM working group will also publish algorithm specifications that are found to be broadly applicable and beneficial. Evaluating these algorithms shall be done in coordination with the Internet Congestion Control Research Group (ICCRG) in order to select and assess the relevant criteria, scenarios, and metrics. AQM algorithms do not have to be implemented universally in order to be effective. Specifications will aid in producing proper implementations that avoid potential ambiguities and corner cases. "Interoperability" of algorithms and implementations of them is not the reason for creating these specifications; correctness is the primary motivation. The working group will not make changes to ECN, DiffServ, or other IETF protocols, though existing ECN, DiffServ, and other mechanisms may be used within the algorithms proposed. Many AQM algorithms have been proposed in academic literature, but very few are widely implemented and deployed. The 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. Goals and Milestones January 2014 Submit AQM recommendations to IESG for publication as BCP obsoleting RFC 2309 July 2014 Submit AQM evaluation guidelines to IESG for publication as Informational December 2014 Submit first algorithm specification to IESG for publication as Proposed Standard Relevant documents: Recommendations --------------- http://tools.ietf.org/html/draft-baker-aqm-recommendation Algorithms Potentially for Consideration ---------------------------------------- PIE: http://tools.ietf.org/html/draft-pan-tsvwg-pie CoDel: http://tools.ietf.org/html/draft-nichols-tsvwg-codel FavorQueue: http://arxiv.org/pdf/1103.2303v2.pdf --------------010701030105060209010900-- From garmitage@swin.edu.au Thu Jul 11 03:11: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 B3B4821F9D59 for ; Thu, 11 Jul 2013 03:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 JdZUeO61rocA for ; Thu, 11 Jul 2013 03:11:48 -0700 (PDT) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1B21F9C8E for ; Thu, 11 Jul 2013 03:11:43 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r6BABQrs001934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 20:11:40 +1000 Message-ID: <51DE84CE.1050602@swin.edu.au> Date: Thu, 11 Jul 2013 20:11:26 +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: <51DE398B.2090103@mti-systems.com> In-Reply-To: <51DE398B.2090103@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [aqm] updated 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, 11 Jul 2013 10:11:53 -0000 On 07/11/2013 14:50, Wesley Eddy wrote: [..] > I think that scoping discussion may > still be going on into Berlin, but it's a good point, and likely > some other people have cute ideas for a name that could capture > the potential broader scope. I don't see "SQM" adding clarity (and risks bike-shedding over what constitutes 'Smarter...' and whether that implies scheduling algorithms any more than 'Active..." does). The (draft) full name "Active Queue Management and Packet Scheduling" seems entirely reasonable, even if unpronounceable as an acronym. (But if we're interested in alternative names: since pkt scheduling usually implies N>1 queues, which implies classification prior to queue-ification, perhaps the "CQS" working group instead? For "classification, queuing and scheduling". 'Cos we might want to also say a few words about how traffic is classified into these actively managed and scheduled queue(s)...) cheers, gja From gettysjim@gmail.com Thu Jul 11 08:47:03 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 D1E1221F9DFC for ; Thu, 11 Jul 2013 08:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=0.303, 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 ehKoLPK-SIKu for ; Thu, 11 Jul 2013 08:47:03 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1183521F9DDC for ; Thu, 11 Jul 2013 08:47:03 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so9938628obc.24 for ; Thu, 11 Jul 2013 08:47:02 -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=756szttOMBSaD8vdON/auw8LW5MKRMcDVkMOCZ4E52E=; b=TNhW4iD7kCOmBYGITjQYNyHdvO8oUKYy33TPa1SmyAJlGYKqwPoDOVMXfAaJGrqY9S JHTZ7wcH2k41qDZ8wjsuCpsWQnnxX8L0pEmRbv6r13M6s+v4Z1cco/vFxYrJN3K8cGE0 IoeHutYUB4LUpkOHqTPniDgqBkpnlu78t7tZFf2gKzB2RbuKE80gRlyUe7WjADm5vLd/ Hwep/piRvdpKYUmvOPpJ0eHw0GTw5vGYUrR7wqUrqBA+7/2vHfrub8mEZBwESSSSq/bn 60pu2KAw3a5j4LCU9LlvR0oHwZpbfPVo9W/BwNmopdcq3zFqtqshJ9FDc5Oys6W5IN1/ 8G6g== MIME-Version: 1.0 X-Received: by 10.182.128.6 with SMTP id nk6mr32601112obb.11.1373557622594; Thu, 11 Jul 2013 08:47:02 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.144.67 with HTTP; Thu, 11 Jul 2013 08:47:02 -0700 (PDT) In-Reply-To: <51DE398B.2090103@mti-systems.com> References: <51DE398B.2090103@mti-systems.com> Date: Thu, 11 Jul 2013 11:47:02 -0400 X-Google-Sender-Auth: GXrAUMVNEocadRKUMWub3-q9dS4 Message-ID: From: Jim Gettys To: Wesley Eddy Content-Type: multipart/alternative; boundary=e89a8ff242a32c60f504e13e4e3c Cc: "aqm@ietf.org" Subject: Re: [aqm] updated 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, 11 Jul 2013 15:47:04 -0000 --e89a8ff242a32c60f504e13e4e3c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy wrote: > I think the attached updated draft charter reflects most of the > feedback that we've heard so far. > > Note that Dave Taht suggested we might want to go with something > like "Smarter Queue Management" (SQM) for the WG name, because > purely AQM as a name may not capture FQ type of mechanisms that we > may want to have in-scope. I think that scoping discussion may > still be going on into Berlin, but it's a good point, and likely > some other people have cute ideas for a name that could capture > the potential broader scope. > Both Dave's and my experience as relative newcomers to this area is that the term AQM is pretty tightly bound to mark/drop algorithms in the minds of many people in the IETF, who also categorize other algorithms as queuing algorithms. and make a pretty strong mental distinction between them. As my blog post this week http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues, the killer combination is a cross between rapidly autotuning mark/drop algorithms with what we're calling flow queueing (since it isn't "fair" in the also traditional sense of TCP fair queueing at all, and may not involve TCP flows necessarily either). So while I'd be happy to lump this all into the AQM name bucket personally, I do think that a name that makes clear we're considering algorithms that may marry both lines of intellectual thought together will avoid confusion among many who have worked in one area or the other, but not both. "Smart queue management" or SQM is the best we've come up with for a term. - Jim > -- > Wes Eddy > MTI Systems > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > --e89a8ff242a32c60f504e13e4e3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu= , Jul 11, 2013 at 12:50 AM, Wesley Eddy <wes@mti-systems.com> wrote:
I think the attached updated draft charter reflects most o= f the
feedback that we've heard so far.

Note that Dave Taht suggested we might want to go with something
like "Smarter Queue Management" (SQM) for the WG name, because purely AQM as a name may not capture FQ type of mechanisms that we
may want to have in-scope. =A0I think that scoping discussion may
still be going on into Berlin, but it's a good point, and likely
some other people have cute ideas for a name that could capture
the potential broader scope.

Both Dave's and my experience a= s relative newcomers to this area is that the term AQM is pretty tightly bo= und to mark/drop algorithms in the minds of many people in the IETF, who al= so categorize other algorithms as queuing algorithms. and make a pretty str= ong mental distinction between them.

As my blog post this week http://gettys.wordpress.com= /2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enoug= h/#more-1091 argues, the killer combination is a cross between rapidly = autotuning mark/drop algorithms with what we're calling flow queueing (= since it isn't "fair" in the also traditional sense of TCP fa= ir queueing at all, and may not involve TCP flows necessarily either).

So while I'd be happy to l= ump this all into the AQM name bucket personally, I do think that a name th= at makes clear we're considering algorithms that may marry both lines o= f intellectual thought together will avoid confusion among many who have wo= rked in one area or the other, but not both. =A0"Smart queue managemen= t" or SQM is the best we've come up with for a term.
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim


--
Wes Eddy
MTI Systems

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


--e89a8ff242a32c60f504e13e4e3c-- From gorry@erg.abdn.ac.uk Thu Jul 11 09:07: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 CAA8021F9F80 for ; Thu, 11 Jul 2013 09:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 j6cqtLfVMtON for ; Thu, 11 Jul 2013 09:07:22 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A694E21F9BB2 for ; Thu, 11 Jul 2013 09:07:22 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5274C2B40D1; Thu, 11 Jul 2013 17:06:53 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 11 Jul 2013 17:06:53 +0100 Message-ID: <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <51DE398B.2090103@mti-systems.com> Date: Thu, 11 Jul 2013 17:06:53 +0100 From: gorry@erg.abdn.ac.uk To: "Jim Gettys" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] updated 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, 11 Jul 2013 16:07:35 -0000 I agreed that AQM has to some extent already been deployed in some places and this could be confusing to then redefine or obsolete this. For what it's worth I don't like "smart" queueing as a name - implying it's sounds like a marketing term rather than a combination of "AQM" mark/drop and flow scheduling. If SQM was short for scheduling and queue management I may have liked the abbreviation more, ... let's see where this discussion ends. Gorry > On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy wrote: > >> I think the attached updated draft charter reflects most of the >> feedback that we've heard so far. >> >> Note that Dave Taht suggested we might want to go with something >> like "Smarter Queue Management" (SQM) for the WG name, because >> purely AQM as a name may not capture FQ type of mechanisms that we >> may want to have in-scope. I think that scoping discussion may >> still be going on into Berlin, but it's a good point, and likely >> some other people have cute ideas for a name that could capture >> the potential broader scope. >> > > Both Dave's and my experience as relative newcomers to this area is that > the term AQM is pretty tightly bound to mark/drop algorithms in the minds > of many people in the IETF, who also categorize other algorithms as > queuing > algorithms. and make a pretty strong mental distinction between them. > > As my blog post this week > http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues, > the killer combination is a cross between rapidly autotuning > mark/drop algorithms with what we're calling flow queueing (since it isn't > "fair" in the also traditional sense of TCP fair queueing at all, and may > not involve TCP flows necessarily either). > > So while I'd be happy to lump this all into the AQM name bucket > personally, > I do think that a name that makes clear we're considering algorithms that > may marry both lines of intellectual thought together will avoid confusion > among many who have worked in one area or the other, but not both. "Smart > queue management" or SQM is the best we've come up with for a term. > - Jim > > >> -- >> Wes Eddy >> MTI Systems >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >> >> > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From David.Ros@telecom-bretagne.eu Thu Jul 11 09:21: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 5A67F21F9F7C for ; Thu, 11 Jul 2013 09:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 dGP96inHd0aj for ; Thu, 11 Jul 2013 09:21:44 -0700 (PDT) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 166EB21F9DD3 for ; Thu, 11 Jul 2013 09:21:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 2B85C6601A; Thu, 11 Jul 2013 18:21:40 +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 iuM5uEtyf5Db; Thu, 11 Jul 2013 18:21:39 +0200 (CEST) Received: from arabica.home (ARennes-653-1-254-69.w109-218.abo.wanadoo.fr [109.218.29.69]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 760BA66024; Thu, 11 Jul 2013 18:21:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: David Ros X-Priority: 3 (Normal) In-Reply-To: <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> Date: Thu, 11 Jul 2013 18:21:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1283) Cc: Wesley Eddy , Jim Gettys , aqm@ietf.org Subject: Re: [aqm] updated 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, 11 Jul 2013 16:21:54 -0000 On 11 juil. 2013, at 18:06, gorry@erg.abdn.ac.uk wrote: >=20 > I agreed that AQM has to some extent already been deployed in some = places > and this could be confusing to then redefine or obsolete this. >=20 +1 > For what it's worth I don't like "smart" queueing as a name - implying > it's sounds like a marketing term rather than a combination of "AQM" > mark/drop and flow scheduling. +1 >=20 > If SQM was short for scheduling and queue management I may have liked = the > abbreviation more, ... let's see where this discussion ends. Since we're looking for acronyms that (a) are pronounceable, (b) do not = sound like a marketing gimmick, (c) match to a WG name that conveys the = essence of what the WG will do, then why not simply: QMAPS? (Queue = Management And Packet Scheduling). David >=20 > Gorry >=20 >=20 >> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy = wrote: >>=20 >>> I think the attached updated draft charter reflects most of the >>> feedback that we've heard so far. >>>=20 >>> Note that Dave Taht suggested we might want to go with something >>> like "Smarter Queue Management" (SQM) for the WG name, because >>> purely AQM as a name may not capture FQ type of mechanisms that we >>> may want to have in-scope. I think that scoping discussion may >>> still be going on into Berlin, but it's a good point, and likely >>> some other people have cute ideas for a name that could capture >>> the potential broader scope. >>>=20 >>=20 >> Both Dave's and my experience as relative newcomers to this area is = that >> the term AQM is pretty tightly bound to mark/drop algorithms in the = minds >> of many people in the IETF, who also categorize other algorithms as >> queuing >> algorithms. and make a pretty strong mental distinction between them. >>=20 >> As my blog post this week >> = http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-= traditional-aqm-is-not-enough/#more-1091argues, >> the killer combination is a cross between rapidly autotuning >> mark/drop algorithms with what we're calling flow queueing (since it = isn't >> "fair" in the also traditional sense of TCP fair queueing at all, and = may >> not involve TCP flows necessarily either). >>=20 >> So while I'd be happy to lump this all into the AQM name bucket >> personally, >> I do think that a name that makes clear we're considering algorithms = that >> may marry both lines of intellectual thought together will avoid = confusion >> among many who have worked in one area or the other, but not both. = "Smart >> queue management" or SQM is the best we've come up with for a term. >> - Jim >>=20 >>=20 >>> -- >>> Wes Eddy >>> MTI Systems >>>=20 >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >>>=20 >>>=20 >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >>=20 >=20 >=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/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams From gettysjim@gmail.com Thu Jul 11 10:35:40 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 3B03221F9FA4 for ; Thu, 11 Jul 2013 10:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[AWL=0.202, 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 IAvzmFvQZZhV for ; Thu, 11 Jul 2013 10:35:39 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC6321F9F7E for ; Thu, 11 Jul 2013 10:35:31 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so11512740oah.25 for ; Thu, 11 Jul 2013 10:35:30 -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=xXsR8z1n9Vl4IdbCZBk2JezheMoWbIu9ADTOeELvAZA=; b=nBor3kLkrha+bINC/q77QkAAegcgLp01Yq1/FDlYyMGibBLLjge46iZ1xkf2v6ajbA Xxoa+thAL2miryyz1b70rWkEjVrjdMh/z42p0kNE4QVmxVzeBCWzGCAkMD0WsCpPk1p3 13B6uauN53YliToUMNl2UFalsEgPoWnM7n9Ir9EkjPvCtG72AK7GPKWmObsX229TTJ3E DqWkw9Z9bAl7H7JO4Khryhm0UaUZpj7FiOT7IHT1e2pf8IjmckmfptY3jSug7keeC0ZM MplfWVGqz/znJ++THyAm7IeirYoENULKkLNXZdeXbIVBZSbedwhNETrOgXEMGPlhxKmR FG3Q== MIME-Version: 1.0 X-Received: by 10.60.102.202 with SMTP id fq10mr11116700oeb.42.1373564130752; Thu, 11 Jul 2013 10:35:30 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.144.67 with HTTP; Thu, 11 Jul 2013 10:35:30 -0700 (PDT) In-Reply-To: <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> Date: Thu, 11 Jul 2013 13:35:30 -0400 X-Google-Sender-Auth: SSWWqIHCxuYMekk1PcyFjUHqU1E Message-ID: From: Jim Gettys To: David Ros Content-Type: multipart/alternative; boundary=089e01182bb217007604e13fd2b4 Cc: Gorry Fairhurst , Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] updated 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, 11 Jul 2013 17:35:40 -0000 --089e01182bb217007604e13fd2b4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 11, 2013 at 12:21 PM, David Ros wrote: > > On 11 juil. 2013, at 18:06, gorry@erg.abdn.ac.uk wrote: > > > > > I agreed that AQM has to some extent already been deployed in some places > > and this could be confusing to then redefine or obsolete this. > > > > +1 > > > > For what it's worth I don't like "smart" queueing as a name - implying > > it's sounds like a marketing term rather than a combination of "AQM" > > mark/drop and flow scheduling. > > +1 > > > > > > If SQM was short for scheduling and queue management I may have liked > the > > abbreviation more, ... let's see where this discussion ends. > Scheduling and Queue Management is fine with me... > > Since we're looking for acronyms that (a) are pronounceable, (b) do not > sound like a marketing gimmick, (c) match to a WG name that conveys the > essence of what the WG will do, then why not simply: QMAPS? (Queue > Management And Packet Scheduling). > I'm not willing to bikeshed working group names and will live with whatever people like. I'm certainly not great at selecting names, having bound the free variable with a window system name. Names can be important: one of the problems with the "RED" algorithm, whose initial formation was, IIRC, "Random Early Discard". The name's connotation implied it "randomly" discarded your packets and does so sooner rather than later; not what most network operators want to hear. Kathie and Van named CoDel both because "Constant Delay" describes its intended behavior, but also because "coddling" your packets sounds warm and fuzzy, rather than nasty and random. The great unwashed fail to understand that packet drops can be good for their network's health... I will not reply further to this thread. - Jim > David > > > > > > Gorry > > > > > >> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy > wrote: > >> > >>> I think the attached updated draft charter reflects most of the > >>> feedback that we've heard so far. > >>> > >>> Note that Dave Taht suggested we might want to go with something > >>> like "Smarter Queue Management" (SQM) for the WG name, because > >>> purely AQM as a name may not capture FQ type of mechanisms that we > >>> may want to have in-scope. I think that scoping discussion may > >>> still be going on into Berlin, but it's a good point, and likely > >>> some other people have cute ideas for a name that could capture > >>> the potential broader scope. > >>> > >> > >> Both Dave's and my experience as relative newcomers to this area is that > >> the term AQM is pretty tightly bound to mark/drop algorithms in the > minds > >> of many people in the IETF, who also categorize other algorithms as > >> queuing > >> algorithms. and make a pretty strong mental distinction between them. > >> > >> As my blog post this week > >> > http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues > , > >> the killer combination is a cross between rapidly autotuning > >> mark/drop algorithms with what we're calling flow queueing (since it > isn't > >> "fair" in the also traditional sense of TCP fair queueing at all, and > may > >> not involve TCP flows necessarily either). > >> > >> So while I'd be happy to lump this all into the AQM name bucket > >> personally, > >> I do think that a name that makes clear we're considering algorithms > that > >> may marry both lines of intellectual thought together will avoid > confusion > >> among many who have worked in one area or the other, but not both. > "Smart > >> queue management" or SQM is the best we've come up with for a term. > >> - Jim > >> > >> > >>> -- > >>> Wes Eddy > >>> MTI Systems > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > > ================================================================= > 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 > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --089e01182bb217007604e13fd2b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu= , Jul 11, 2013 at 12:21 PM, David Ros <David.Ros@telecom-breta= gne.eu> wrote:

On 11 juil. 2013, at 18:06, gorry@e= rg.abdn.ac.uk wrote:

>
> I agreed that AQM has to some extent already been deployed in some pla= ces
> and this could be confusing to then redefine or obsolete this.
>

+1


> For what it's worth I don't like "smart" queueing as= a name - implying
> it's sounds like a marketing term rather than a combination of &qu= ot;AQM"
> mark/drop and flow scheduling.

+1


>
> If SQM was short for =A0scheduling and queue management I may have lik= ed the
> abbreviation more, ... let's see where this discussion ends.

Scheduling and Queue Management is fine with me...

Since we're looking for acronyms that (a) are pronounceable, (b) = do not sound like a marketing gimmick, (c) match to a WG name that conveys = the essence of what the WG will do, then why not simply: QMAPS? (Queue Mana= gement And Packet Scheduling).

I'm not willing to bikeshed working group names and will live w= ith whatever people like. =A0I'm certainly not great at selecting names= , having bound the free variable with a window system name.

Names can be important: one of= the problems with the "RED" algorithm, whose initial formation w= as, IIRC, "Random Early Discard". =A0The name's connotation i= mplied it "randomly" discarded your packets and does so sooner ra= ther than later; not what most network operators want to hear. Kathie and V= an named CoDel both because "Constant Delay" describes its intend= ed behavior, but also because "coddling" your packets sounds warm= and fuzzy, rather than nasty and random. The great unwashed fail to unders= tand that packet drops can be good for their network's health...

I will not reply further to th= is thread.
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0- Jim


David


>
> Gorry
>
>
>> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>>
>>> I think the attached updated draft charter reflects most of th= e
>>> feedback that we've heard so far.
>>>
>>> Note that Dave Taht suggested we might want to go with somethi= ng
>>> like "Smarter Queue Management" (SQM) for the WG nam= e, because
>>> purely AQM as a name may not capture FQ type of mechanisms tha= t we
>>> may want to have in-scope. =A0I think that scoping discussion = may
>>> still be going on into Berlin, but it's a good point, and = likely
>>> some other people have cute ideas for a name that could captur= e
>>> the potential broader scope.
>>>
>>
>> Both Dave's and my experience as relative newcomers to this ar= ea is that
>> the term AQM is pretty tightly bound to mark/drop algorithms in th= e minds
>> of many people in the IETF, who also categorize other algorithms a= s
>> queuing
>> algorithms. and make a pretty strong mental distinction between th= em.
>>
>> As my blog post this week
>> http://gettys.wordpress.com/2013/07/10/low-latency-requires-sma= rt-queuing-traditional-aqm-is-not-enough/#more-1091argues,
>> the killer combination is a cross between rapidly autotuning
>> mark/drop algorithms with what we're calling flow queueing (si= nce it isn't
>> "fair" in the also traditional sense of TCP fair queuein= g at all, and may
>> not involve TCP flows necessarily either).
>>
>> So while I'd be happy to lump this all into the AQM name bucke= t
>> personally,
>> I do think that a name that makes clear we're considering algo= rithms that
>> may marry both lines of intellectual thought together will avoid c= onfusion
>> among many who have worked in one area or the other, but not both.= =A0"Smart
>> queue management" or SQM is the best we've come up with f= or a term.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim
>>
>>
>>> --
>>> Wes Eddy
>>> MTI Systems
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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
htt= p://www.rennes.enst-bretagne.fr/~dros/

I love deadlines. I like the whooshing sound they make as they fly by. -- D= ouglas Adams




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

--089e01182bb217007604e13fd2b4-- From garmitage@swin.edu.au Thu Jul 11 13:01: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 DAC9B21F9B0A for ; Thu, 11 Jul 2013 13:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 vlzU1eH2j1aP for ; Thu, 11 Jul 2013 13:01:13 -0700 (PDT) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF1221F92BB for ; Thu, 11 Jul 2013 13:01:12 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r6BK0cDW019328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 06:00:39 +1000 Message-ID: <51DF0EE6.3080203@swin.edu.au> Date: Fri, 12 Jul 2013 06:00:38 +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: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> In-Reply-To: <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [aqm] updated 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, 11 Jul 2013 20:01:19 -0000 On 07/12/2013 02:21, David Ros wrote: > > On 11 juil. 2013, at 18:06, gorry@erg.abdn.ac.uk wrote: [..] >> If SQM was short for scheduling and queue management I may have >> liked the abbreviation more, ... let's see where this discussion >> ends. Like it too. > > Since we're looking for acronyms that (a) are pronounceable, (b) do > not sound like a marketing gimmick, (c) match to a WG name that > conveys the essence of what the WG will do, then why not simply: > QMAPS? (Queue Management And Packet Scheduling). QUEUE -- Queue Utilisation for Enhanced User Experience ? (Thank you, I'll be here all week...) cheers, gja From bob.briscoe@bt.com Thu Jul 11 17:16:03 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 91FD021F9B7E for ; Thu, 11 Jul 2013 17:16:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bmxwYi2xczf for ; Thu, 11 Jul 2013 17:15:58 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2D421F99FC for ; Thu, 11 Jul 2013 17:15:55 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 01:15:48 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 01:15:52 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 01:15:52 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.20]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6C0FnT7026110; Fri, 12 Jul 2013 01:15:49 +0100 Message-ID: <201307120015.r6C0FnT7026110@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 01:15:47 +0100 To: Dave Taht From: Bob Briscoe In-Reply-To: References: <8C48B86A895913448548E6D15DA7553B82A5E5@xmb-rcd-x09.cisco.com> <517FF171.4010306@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: Wesley Eddy , "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: Fri, 12 Jul 2013 00:16:03 -0000 Dave, At 17:40 30/04/2013, Dave Taht wrote: >On Tue, Apr 30, 2013 at 9:29 AM, Wesley Eddy wrote: > > On 4/29/2013 10:00 AM, Fred Baker (fred) wrote: > >> Do we generally agree with the recommendation of > http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.2? > This is the question of signaling to an endpoint using both dropping and ECN. > > The second part (imposing an upper bound) might be worth expanding a > > bit. I don't know what a reasonable upper bound is, for failing into > > a tail-drop mode, > >No reason to specify "tail" drop here. I agree with you here that it doesn't have to be tail-drop. But I would add that we need to record the lessons learned in the past, not just say "drop" and hope people understand. 1/ The RED algo was defined such that at a configured length of the smoothed queue it rose to 100% drop probability. When that was initially implemented in alt_q, it allowed an unresponsive flow to turn RED into a DOS amplifier, because 100% drop = 0% throughput. Of course, once the algo drops 100% of incoming traffic, the smoothed queue will reduce and the drop prob will reduce, but this led to unstable behaviour. In the alt_q RED code you can still see this 100% drop stuff that Kenjiro Cho commented out, and replaced with fall-back to tail drop. When I last looked at the CoDel code (which wasn't recently), if unresponsive traffic was keeping the queue above threshold, it used the drop_next_ variable to continually decrease the time between drops until it would eventually drop 100%. I figured it was likely the same instability would ensue. You may have fixed this since, given CoDel performed badly with unresponsive traffic in the early tests. My point is that we need to record this advice, because everyone seems to start out making the same mistake - the boundary conditions of the algos get overlooked, and they are important for Internet stability. So we should give examples of good and bad approaches for the boundary conditions. An example of a good simple strategy would be something very much like tail drop, but where the 'tail' is a fixed tight delay cap, not the tail of the buffer. BTW #1, once in dropping mode, the CoDel code that I looked at initially took the square-root of the count of drops to decrease the time between drops. Ironically this leads to a /linear/ increase in drop frequency over /time/. So I'm sure there should be a much simpler way to code it without the square root, by driving drops from elapsed time not drop count. BTW #2, in that same CoDel code, the dropping pattern once in the dropping mode did not depend on how large the queuing delay was getting - it was all pre-ordained how it would behave. Again, this may have since been fixed, but to me it seemed very wrong not to drop more frequently if the queuing delay was getting longer and longer. When I looked at the original CoDel code, I just thought the word auto-tuning was being used as empty marketing BS. It's use of service time certainly auto-tuned the queue threshold to the link rate. However, in both its modes it didn't change how quickly it responded dependent on how bad the problem had become. As an output of this proposed AQM WG, I would like to see advice that says what auto-tuning means, not just the empty word "auto-tuning", ie. not just using time as the unit of queuing, but also an AQM should not take a hard-coded time to respond irrespective of how much the queuing delay has grown. [Sorry for responding nearly 2 months late (I'm just catching up on stuff that arrived while I was tuned out from the AQM list, due to other work)] Bob ________________________________________________________________ Bob Briscoe, BT From fred@cisco.com Thu Jul 11 18:06:37 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 0A7E711E825E for ; Thu, 11 Jul 2013 18:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.425 X-Spam-Level: X-Spam-Status: No, score=-110.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, 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 7NEHMk9LKGm9 for ; Thu, 11 Jul 2013 18:06:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC0E11E826A for ; Thu, 11 Jul 2013 18:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=609; q=dns/txt; s=iport; t=1373591186; x=1374800786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4wskEOHuhsAfRVcHFuR/yw5Few5EVJfZ5BJzFYIAZFc=; b=VGuTp7jgiVoZ5LJtvwPNPqoxQ7ip3RjiODQsc41/Bh/sqriJ+AlWnjeB qC/0g5a+9gERw4wSYnHamT4bg3eKmLtgB98XebvodQYbfPMU6vdiZprNb XPMyBP1Oez2gCoLfuYbET3Qy1tv6xN1rsTavqW9gkkLyYbhrRnqlPjwhI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAO9V31GtJV2Z/2dsb2JhbABagwaBA4I/vxeBBxZ0giMBAQEDATo/BQsCAQgiFBAyJQIEDgUIiAEGtw+PLgIxB4MJbAOpKoMRgig X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="233821344" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 12 Jul 2013 01:06:25 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6C16Pd6024579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 01:06:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 20:06:25 -0500 From: "Fred Baker (fred)" To: Bob Briscoe Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #2 Thread-Index: AQHOfpwHTwWjyvZ3UEaBWpaxjnZQNg== Date: Fri, 12 Jul 2013 01:06:23 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B93913E@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B82A5E5@xmb-rcd-x09.cisco.com> <517FF171.4010306@mti-systems.com> <201307120015.r6C0FnT7026110@bagheera.jungle.bt.co.uk> In-Reply-To: <201307120015.r6C0FnT7026110@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <597205E6F0A8054F99B3BD65B2B80D72@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wesley Eddy , Dave Taht , "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: Fri, 12 Jul 2013 01:06:37 -0000 On Jul 11, 2013, at 5:15 PM, Bob Briscoe wrote: > As an output of this proposed AQM WG, I would like to see advice that say= s what auto-tuning means, not just the empty word "auto-tuning", ie. not ju= st using time as the unit of queuing, but also an AQM should not take a har= d-coded time to respond irrespective of how much the queuing delay has grow= n. I'm all for that. Maybe we can get the WG, if there is one, to add a docume= nt describing that, or add text to the AQM recommendation. Suggest text/app= roach? I'd suggest perhaps discussing this in Berlin.= From bob.briscoe@bt.com Thu Jul 11 18:22:59 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 B565311E80D9 for ; Thu, 11 Jul 2013 18:22:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmSFOjR8mWTe for ; Thu, 11 Jul 2013 18:22:54 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id DA98D11E820C for ; Thu, 11 Jul 2013 18:22:53 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 02:22:51 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 02:22:50 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 02:22:48 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.20]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6C1MlTD026331; Fri, 12 Jul 2013 02:22:47 +0100 Message-ID: <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 02:22:14 +0100 To: "Fred Baker (fred)" From: Bob Briscoe In-Reply-To: <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> <6CCF558E-975C-4C86-9D67-CA431CC6FBA1@ifi.uio.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 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: Fri, 12 Jul 2013 01:22:59 -0000 Fred, At 15:00 06/05/2013, Fred Baker (fred) wrote: >Do we generally agree with the recommendation of=20 >http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.4?= =20 >This is the question of ensuring that AQM=20 >technologies are applicable to all Internet=20 >traffic - not just TCP, but UDP, SCTP, and so on. I'm not as much a fan of recommendation #4 as=20 everyone else seems to be. I think it's a wordsmithing issue, not= fundamental. I suggest wording such as: "AQMs SHOULD allow=20 congestion controls to remain as effective as=20 they are with other widely accepted AQMs or with tail drop." Reasoning: An AQM can't be effective with all=20 transports, because congestion control is=20 achieved by the e2e transport, not the AQM alone. "All transports" includes: * unresponsive transports that aren't trying to be effective, * and delay-based transports like VEGAS & LEDBAT=20 that don't work well in some circumstances. The suggested wording makes it clear we're=20 talking about criteria for testing AQMs against=20 transports that we already know are able to be=20 effective. Not about the AQM forcing a 'normal'=20 congestion control behaviour even if the=20 congestion control doesn't want to play, or 'normal' has been redefined. The reason I care about the wording here is that=20 some may read this as a licence to include=20 per-flow rate policing within the AQM (cf AFD,=20 XCHOKe, etc). I strongly believe that per-flow=20 rate policers SHOULD NOT be in /every/ AQM. AFD (and similar algos) still wrongly hit more=20 recent hi-performance transports like Cubic=20 because it is so much faster than lame Reno=20 transports, even tho the Reno transports wouldn't=20 be able to use the extra capacity. If an operator wants to deploy this flow-policing=20 (please no), it is sufficient to have one on each=20 path, at a 'customer edge' node, deployed as part=20 of per-customer policy. Then there's a chance=20 they can be turned off once the operator=20 recognises they aren't helping. If we're=20 successful enough to get AQM in every queue in=20 the Internet, I don't want that to mean we've=20 also got per-flow policers embedded in every=20 queue too. Then, we're stuffed for future flexibility. Bob At 20:36 06/05/2013, Michael Welzl wrote: >On May 6, 2013, at 9:17 PM, John Leslie wrote: > > > 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=85 > >Seems like a case of "more specific and more=20 >complicated" vs. "more vague but perhaps good=20 >enough" to me. I don't think that there's a=20 >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." > > > > 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 > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT=20 From bob.briscoe@bt.com Thu Jul 11 18:28: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 51F1111E81F0 for ; Thu, 11 Jul 2013 18:28:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IudyBdP3SA+i for ; Thu, 11 Jul 2013 18:28:42 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9411E80D7 for ; Thu, 11 Jul 2013 18:28:39 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 02:28:37 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 02:28:38 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 02:28:38 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.20]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6C1Save026348; Fri, 12 Jul 2013 02:28:36 +0100 Message-ID: <201307120128.r6C1Save026348@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 02:28:34 +0100 To: "Fred Baker (fred)" From: Bob Briscoe In-Reply-To: <8C48B86A895913448548E6D15DA7553B81F454@xmb-rcd-x09.cisco.c om> References: <8C48B86A895913448548E6D15DA7553B81F454@xmb-rcd-x09.cisco.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: "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #1 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, 12 Jul 2013 01:28:48 -0000 Fred, To save mail header processing, I've ammortised most of my replies. Sorry I'm very late. #1 Operational deployments SHOULD implement AQM Agree #2 Signaling to the endpoints of a session Agree (and see my note to Dave Taht just now wherein I said we should give examples of good and bad approaches. Good: drop at a tight delay cap; Bad 100% drop) #3 Active Queue Management algorithms deployed SHOULD NOT require operational tuning Agree (and see same note to Dave Taht wherein I said time as a queue threshold is not sufficient to get a tick in the auto-tuning box - responsiveness of the algo also needs to depend on how bad the queue is getting) #4 AQM deployed SHOULD be effective on all common Internet traffic Disagree (see next posting: summary: SHOULD allow congestion controls to remain as effective as they are with other generally accepted AQMs or with tail drop) #5 TCP and SCTP congestion control algorithms SHOULD maximize ... Don't disagree, but it's out of scope, as Michael said. The other recommendations already say what the AQM side needs to do to try to keep at the knee - this recommendation is aimed at transport protocols, so it should be cut - not in scope. #6 Need for further research Agree Bob At 15:00 24/04/2013, Fred Baker (fred) wrote: >Do we generally agree with the recommendation of >http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.1? > > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT From ropan@cisco.com Thu Jul 11 18:45: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 9889C21F9F17 for ; Thu, 11 Jul 2013 18:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[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 gz2fL8ycI-k6 for ; Thu, 11 Jul 2013 18:45:22 -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 A6CE011E814B for ; Thu, 11 Jul 2013 18:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7337; q=dns/txt; s=iport; t=1373593506; x=1374803106; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DikYBAV2FGcR8REEQ3a4mTn76gbpxuYV/9E5e5isUmE=; b=e/RlxfYEYAX8ixMaOT1LbEvLJEkh9Wm1hcWlIeo/LmrOYlMbv3vBMhXR T0CZw1Q6apeXabEzuKZJmj4qBhmB6PxTanXmzS5dEP1dkDIKIuRFkNBYV 5fYNw2n9oZuAsid+nDOvipUdFBnXmJWvv0cQM9dZYuv4pEwy3oubWmEwF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADtf31GtJXG9/2dsb2JhbABagwY0T8FVgQcWdIIjAQEBBAEBAWQHCxIBCBgKSwslAgQBCQQFCBOHdAy3CI8wMQeDCWwDlAWFAZAkgxGCKA X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="233658518" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2013 01:45:06 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6C1j57M025741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 01:45:05 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.152]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 20:45:05 -0500 From: "Rong Pan (ropan)" To: Bob Briscoe , "Fred Baker (fred)" Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 Thread-Index: AQHOfp5aSbtadc4LyUiiEoD2XBB3OplhH4uA Date: Fri, 12 Jul 2013 01:45:03 +0000 Message-ID: In-Reply-To: <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.148.146] Content-Type: text/plain; charset="Windows-1252" 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: Fri, 12 Jul 2013 01:45:27 -0000 Please see inline=8A. On 7/12/13 9:22 AM, "Bob Briscoe" wrote: >Fred, > >At 15:00 06/05/2013, 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? >>=20 >>This is the question of ensuring that AQM >>technologies are applicable to all Internet >>traffic - not just TCP, but UDP, SCTP, and so on. > >I'm not as much a fan of recommendation #4 as >everyone else seems to be. I think it's a wordsmithing issue, not >fundamental. > >I suggest wording such as: "AQMs SHOULD allow >congestion controls to remain as effective as >they are with other widely accepted AQMs or with tail drop." > >Reasoning: An AQM can't be effective with all >transports, because congestion control is >achieved by the e2e transport, not the AQM alone. "All transports" >includes: >* unresponsive transports that aren't trying to be effective, >* and delay-based transports like VEGAS & LEDBAT >that don't work well in some circumstances. > >The suggested wording makes it clear we're >talking about criteria for testing AQMs against >transports that we already know are able to be >effective. Not about the AQM forcing a 'normal' >congestion control behaviour even if the >congestion control doesn't want to play, or 'normal' has been redefined. > >The reason I care about the wording here is that >some may read this as a licence to include >per-flow rate policing within the AQM (cf AFD, >XCHOKe, etc). I strongly believe that per-flow >rate policers SHOULD NOT be in /every/ AQM. > >AFD (and similar algos) still wrongly hit more >recent hi-performance transports like Cubic >because it is so much faster than lame Reno >transports, even tho the Reno transports wouldn't >be able to use the extra capacity. There might be some misunderstanding about AFD. AFD that is implemented in Cisco products is not per-flow rate policing. It is class based. Also, AFD would not enforce fair rate among different classes. If a class does not use up its share, the extra share would go to other queues. So in your example of Cubic and Reno, I don't think there would be an issue. Regards, Rong > >If an operator wants to deploy this flow-policing >(please no), it is sufficient to have one on each >path, at a 'customer edge' node, deployed as part >of per-customer policy. Then there's a chance >they can be turned off once the operator >recognises they aren't helping. If we're >successful enough to get AQM in every queue in >the Internet, I don't want that to mean we've >also got per-flow policers embedded in every >queue too. Then, we're stuffed for future flexibility. > > >Bob > >At 20:36 06/05/2013, Michael Welzl wrote: > >>On May 6, 2013, at 9:17 PM, John Leslie wrote: >> >> > 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=8A >> >>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." >> > >> > 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 >> >>_______________________________________________ >>aqm mailing list >>aqm@ietf.org >>https://www.ietf.org/mailman/listinfo/aqm > >________________________________________________________________ >Bob Briscoe, BT > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm From ropan@cisco.com Thu Jul 11 18:46: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 0EF6F21F9E11 for ; Thu, 11 Jul 2013 18:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[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 hmwBiplPXevI for ; Thu, 11 Jul 2013 18:46:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C2BD621F9CD9 for ; Thu, 11 Jul 2013 18:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7722; q=dns/txt; s=iport; t=1373593593; x=1374803193; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cyvU1J6R2IjF0eeC0VPvb9jq8BYlMxtIYgk6kwmEyfU=; b=W9oW0fcODTxSn1n40zJasrN7I2Cq036CTjNW4WUGFEQp6NfNHVCwStJh 4STIJj4uX+RfHVMqEZNEjQKR0RAfaAWkHtCLHiEn335Ke6LtNP6JDFplQ 61NfMB5Mx1ltSCuk7pj0KQe8XyszrfZSMAUbxft2FzutRjFfvEkWzHFvY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPRe31GtJV2Y/2dsb2JhbABagwY0T8FVgQcWdIIjAQEBBAEBAWQHCxIBCBgKSwslAgQBCQQFCBOHdAy3B48wMQeDCWwDlAWFAZAkgxGCKA X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="233853127" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jul 2013 01:46:26 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6C1kQGF001800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 01:46:26 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.152]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 20:46:26 -0500 From: "Rong Pan (ropan)" To: Bob Briscoe , "Fred Baker (fred)" Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #4 Thread-Index: AQHOfp5aSbtadc4LyUiiEoD2XBB3OplhH4uAgAAAYIA= Date: Fri, 12 Jul 2013 01:46:24 +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.2.1.120420 x-originating-ip: [10.21.148.146] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <9DE3AF0DF2009D489248E16ED48C152B@emea.cisco.com> 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: Fri, 12 Jul 2013 01:46:38 -0000 On 7/12/13 9:45 AM, "Rong Pan (ropan)" wrote: >Please see inline=A9. > >On 7/12/13 9:22 AM, "Bob Briscoe" wrote: > >>Fred, >> >>At 15:00 06/05/2013, 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 >>>? >>>=20 >>>This is the question of ensuring that AQM >>>technologies are applicable to all Internet >>>traffic - not just TCP, but UDP, SCTP, and so on. >> >>I'm not as much a fan of recommendation #4 as >>everyone else seems to be. I think it's a wordsmithing issue, not >>fundamental. >> >>I suggest wording such as: "AQMs SHOULD allow >>congestion controls to remain as effective as >>they are with other widely accepted AQMs or with tail drop." >> >>Reasoning: An AQM can't be effective with all >>transports, because congestion control is >>achieved by the e2e transport, not the AQM alone. "All transports" >>includes: >>* unresponsive transports that aren't trying to be effective, >>* and delay-based transports like VEGAS & LEDBAT >>that don't work well in some circumstances. >> >>The suggested wording makes it clear we're >>talking about criteria for testing AQMs against >>transports that we already know are able to be >>effective. Not about the AQM forcing a 'normal' >>congestion control behaviour even if the >>congestion control doesn't want to play, or 'normal' has been redefined. >> >>The reason I care about the wording here is that >>some may read this as a licence to include >>per-flow rate policing within the AQM (cf AFD, >>XCHOKe, etc). I strongly believe that per-flow >>rate policers SHOULD NOT be in /every/ AQM. >> >>AFD (and similar algos) still wrongly hit more >>recent hi-performance transports like Cubic >>because it is so much faster than lame Reno >>transports, even tho the Reno transports wouldn't >>be able to use the extra capacity. > > >There might be some misunderstanding about AFD. AFD that is implemented in >Cisco products is not per-flow rate policing. It is class based. Also, AFD >would not enforce fair rate among different classes. If a class does not >use up its share, the extra share would go to other queues. So in your >example of Cubic and Reno, I don't think there would be an issue. Sorry typo, extra share would go to other classes (NOT queues) that are sharing the same queue. > > >Regards, > >Rong > > > > >> >>If an operator wants to deploy this flow-policing >>(please no), it is sufficient to have one on each >>path, at a 'customer edge' node, deployed as part >>of per-customer policy. Then there's a chance >>they can be turned off once the operator >>recognises they aren't helping. If we're >>successful enough to get AQM in every queue in >>the Internet, I don't want that to mean we've >>also got per-flow policers embedded in every >>queue too. Then, we're stuffed for future flexibility. >> >> >>Bob >> >>At 20:36 06/05/2013, Michael Welzl wrote: >> >>>On May 6, 2013, at 9:17 PM, John Leslie wrote: >>> >>> > 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=A9 >>> >>>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." >>> > >>> > 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 >>> >>>_______________________________________________ >>>aqm mailing list >>>aqm@ietf.org >>>https://www.ietf.org/mailman/listinfo/aqm >> >>________________________________________________________________ >>Bob Briscoe, BT >> >>_______________________________________________ >>aqm mailing list >>aqm@ietf.org >>https://www.ietf.org/mailman/listinfo/aqm > From dave.taht@gmail.com Thu Jul 11 18:50:03 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 2543121F9EB5 for ; Thu, 11 Jul 2013 18:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.345, 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 UYa6ktqtVWmS for ; Thu, 11 Jul 2013 18:50:01 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DE2CA21F9E83 for ; Thu, 11 Jul 2013 18:50:00 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so19516968ieb.16 for ; Thu, 11 Jul 2013 18:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=45u1o2Nd7SoJwuzoQtRGURAkWM/BFwDkmtbhm4uyWbw=; b=F/y8eCBWWf64wriCDPsUaMs8CV43NTNC9NrAemgW293Y1/oP2dimyBuG6SrrUlNaUD f/Q3P1K76uARYa8NFza9cSHsFVwk3iP6sjiCwQAhrisq7XEdHkG9i8QcKYfUSxOjVZhY x2e8XpwVKzzx0/eR9WkGjB4qt+VZyVFV60/9dSBiN3WE8I9C5qaS8Eu5OV2ce0QVAisc gbEIoLptBBemKCvMJSYatZJQ2u2H4yEXDRTY5z5CjV1KnJWIl9YpiRTrrcAHvXsto0Ii mOR8EbSaMzFL6LEMEHnzNItBtXwKTzOk0jsQxU6cPZuuSuPLquTuNIeR/yUf+zM977jp JAgA== MIME-Version: 1.0 X-Received: by 10.43.133.70 with SMTP id hx6mr12231733icc.34.1373593800057; Thu, 11 Jul 2013 18:50:00 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Thu, 11 Jul 2013 18:49:59 -0700 (PDT) In-Reply-To: <201307120128.r6C1Save026348@bagheera.jungle.bt.co.uk> References: <8C48B86A895913448548E6D15DA7553B81F454@xmb-rcd-x09.cisco.com> <201307120128.r6C1Save026348@bagheera.jungle.bt.co.uk> Date: Thu, 11 Jul 2013 18:49:59 -0700 Message-ID: From: Dave Taht To: Bob Briscoe 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 #1 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, 12 Jul 2013 01:50:03 -0000 Since this is a rollup email, this is a rollup in response. On Thu, Jul 11, 2013 at 6:28 PM, Bob Briscoe wrote: > Fred, > > To save mail header processing, I've ammortised most of my replies. Sorry > I'm very late. > > #1 Operational deployments SHOULD implement AQM > Agree Agree > #2 Signaling to the endpoints of a session > Agree Agree. > (and see my note to Dave Taht just now wherein I said we should give > examples of good and bad approaches. Good: drop at a tight delay cap; Bad > 100% drop) Codel stops dropping at the target delay (5ms). Aside from possible quantization error in the timestamping it's impossible to get to 100% drop. I enjoyed your examples of existing approaches and where they went wrong. I could certainly add more, notably from our efforts in extending SFQ to higher bandwidths and the SFQ + ARED effort that preceded fq_codel. > > #3 Active Queue Management algorithms deployed SHOULD NOT require > operational tuning > Agree Agree, but I'd capitalize the REQUIRE bit, in that everything in this world can benefit from a little tuning here and there... as one major example, which is in conflict with your byte-congest draft, using a smaller quantum than the default helps on asymmetric links in fq_codel (and pie uses a probalistic drop mechanism also based on packet size). The smaller quantum thing has been well proven to work on multiple shapers/schedulers going back to wondershaper. > (and see same note to Dave Taht wherein I said time as a queue threshold = is > not sufficient to get a tick in the auto-tuning box - responsiveness of t= he > algo also needs to depend on how bad the queue is getting) The sqrt->linear drop approach is tcp friendly and currently works well on a wide range of RTTs. It certainly seems like a worthwhile research effort to measure and act on the slope of the curve, both up and down, in a codel variant, in order to get better results faster. And the results of the hybrid fq_codel are interesting in that perspective as flows do affect one another, particularly in steady state. Right now a drop in one queue can be followed quickly by a drop in another queue (at steady state), and that could be randomized somewhat or fed into a feedback mechanism also. I do show this behavior on the rrul vs web traffic benchmark on the slidesets I've been showing. Note that steady state is something of a rarity outside of benchmarks. another thought is to periodically perturb the flow list. sigh. more resear= ch. > #4 AQM deployed SHOULD be effective on all common Internet traffic > Disagree (see next posting: summary: SHOULD allow congestion controls to > remain as effective as they are with other generally accepted AQMs or wit= h > tail drop) > > #5 TCP and SCTP congestion control algorithms SHOULD maximize ... > Don't disagree, but it's out of scope, as Michael said. The other > recommendations already say what the AQM side needs to do to try to keep = at > the knee - this recommendation is aimed at transport protocols, so it sho= uld > be cut - not in scope. > > #6 Need for further research > Agree 4,5,6 agree. 6, agree strongly, but who will fund it? > > > Bob > > > At 15:00 24/04/2013, Fred Baker (fred) wrote: >> >> Do we generally agree with the recommendation of >> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.1= ? >> >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > 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 bob.briscoe@bt.com Thu Jul 11 18:56: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 060FF21E8063 for ; Thu, 11 Jul 2013 18:56:28 -0700 (PDT) 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=[AWL=-0.000, 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 HaLQpSOD2Zyx for ; Thu, 11 Jul 2013 18:56:23 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4010021E805F for ; Thu, 11 Jul 2013 18:56:19 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 02:56:18 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 02:56:17 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 02:56:15 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.20]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6C1uCC8026410; Fri, 12 Jul 2013 02:56:12 +0100 Message-ID: <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 02:56:09 +0100 To: Wesley Eddy From: Bob Briscoe In-Reply-To: References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_825992705==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Gorry Fairhurst , Jim Gettys , David Ros , "aqm@ietf.org" Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 01:56:28 -0000 --=====================_825992705==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 1/ Name suggestion: How about just "Queue Management (QMAN)"? Otherwise, if we coin the term smart queue mgmt, merely by proposing an SQM algorithm, every idiot gets to have everyone else call his/her algo smart. 2/ Scope: "Internet routers, lower-layer switches, other middleboxes." Can we have host buffers in scope pls? This is the transport area, afterall. 3/ "routers, ... include buffers or queues" Buffers and queues are not members of the same set (IMO). I don't think this is a picky terminology point. Can we adopt the convention that the buffer is the fixed memory allocation (hardware or software), and the queue is the software construct within the buffer? It already caused confusion when the problem got called bufferbloat, so people thought we were implying the solution was small buffers, so they tune out, because they rightly believe this will lead to unnecessarily high loss. Actually, on a high speed line with high in-degree, it's good practice to have a very large buffer to absorb bursts, as long as you have a adaptive queue threshold within it that rapidly clamps a tight limit on a standing queue. Same problem in next para: " Extremely large buffers have been noticed in some software and equipment. When these queues fill, ..." -> " Extremely large unmanaged buffers have been noticed in some software and equipment. When these buffers fill, ..." -> 4/ "...proactively managing queues ..." Picky: I think you mean reactively. Proactively maybe a bit ambitious. 5/ I suggest the enumerated bullets are changed to those below: "The Active Queue Management and Packet Scheduling working group works on algorithms for proactively managing queues in order to: (1) Minimise standing queues (2) help flow sources control their sending rates without unnecessary losses, e.g. through ECN (3) help minimize delays for interactive applications (4) /consider the merits of various techniques/ to protect flows from negative impacts of other more aggressive or misbehaving flows Reasoning: ECN: The original text was: "(1) help flow sources control their sending rates before the onset of necessary losses, e.g. through ECN" is not accepted wisdom. What's written in RFC3168 makes sense: that marking for ECN traffic has to start at exactly the same point as loss for non-ECN traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy load everyone has to take losses, whether ECN or not, but I don't think that's what you're talking about here. Protecting flows: The question of whether/how to recommend flow isolation or not is part of chartered work - the outcome shouldn't be prejudged in the charter. 6/ " The AQM working group will publish Informational and Best Current Practices documents that cover the design, use, and configuration of algorithms for managing queues in Internet devices and software. " Add: The scope will include both how best to configure existing equipment / software as well as recommendations on designing new equipment / software. 7/ " The working group will not make changes to ECN, DiffServ, or other IETF protocols, though existing ECN, DiffServ, and other mechanisms may be used within the algorithms proposed. " Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly any such changes will need to be co-ordinated with the AQM WG, given the code is likely to be entwined with AQM code. 8/ "Many AQM algorithms have been proposed in academic literature, but very few are widely implemented and deployed. " Is this trying to say very few types of AQM are deployed, or very few instances? I think it is trying to say the latter, but that just isn't true (IMO). WRED is very widely deployed in enterprise networks. And RED is implemented near-univerally by the main equipment vendors, and less widely deployed, but not insignificant. 9/ Gap in charter coverage? "Merits of whether to isolate flows and if so how." There are multiple functions that often get lumped under "AQM": a) minimising a standing queue b) desynchronising losses (/marks) c) preventing large packet lock-out d) detecting and policing flows with excessive rate e) isolating flows from each other (e.g. SFQ) a,b,c) can be done neutrally and imply no possible policy control. d,e) depend on policy (which may or may not be hard-coded rather than configurable, e.g. all flows get equal scheduler priority). There's been significant discussion on the list about the merits of different ways of doing flow isolation. This is the area where I think there is most latent disagreement. We have pretty good consensus already around the recommendations in Fred's doc. We will have to grasp the flow-isolation and policing nettles, so the charter ought to say we're going to. For instance, my stance is that policy-related functions (d+e) should only be deployed at edge-policy enforcement points, not in every buffer. Altho SFQ clearly makes an associated AQM like CoDel work nicely, I preferred the direction Fred described in: in which there's a distinguished shared queue, then anything that starts causing delay in that queue gets either isolated in its own queue or focused policing. Rather than isolating every flow into separate queues from the start, because that requires prejudging the share of the scheduler everyone gets. We have found that with multiple real-time video streams, they all have highly variable rates, so they multiplex really well together in a FIFO. However, if you put them through FQ or WRR, they all get forced into ruts that are always the wrong size for all of them. This isn't a problem if the sum is not often close to capacity (which is why SFQ can appear to be OK with multiple videos). However, the whole point of isolation is to protect flows when the system /is/ close to capacity. Bob At 18:35 11/07/2013, Jim Gettys wrote: >On Thu, Jul 11, 2013 at 12:21 PM, David Ros ><David.Ros@telecom-bretagne.eu> wrote: > >On 11 juil. 2013, at 18:06, >gorry@erg.abdn.ac.uk wrote: > > > > > I agreed that AQM has to some extent already been deployed in some places > > and this could be confusing to then redefine or obsolete this. > > > >+1 > > > > For what it's worth I don't like "smart" queueing as a name - implying > > it's sounds like a marketing term rather than a combination of "AQM" > > mark/drop and flow scheduling. > >+1 > > > > > > If SQM was short for scheduling and queue management I may have liked the > > abbreviation more, ... let's see where this discussion ends. > > >Scheduling and Queue Management is fine with me... > >Since we're looking for acronyms that (a) are pronounceable, (b) do >not sound like a marketing gimmick, (c) match to a WG name that >conveys the essence of what the WG will do, then why not simply: >QMAPS? (Queue Management And Packet Scheduling). > > >I'm not willing to bikeshed working group names and will live with >whatever people like. I'm certainly not great at selecting names, >having bound the free variable with a window system name. > >Names can be important: one of the problems with the "RED" >algorithm, whose initial formation was, IIRC, "Random Early >Discard". The name's connotation implied it "randomly" discarded >your packets and does so sooner rather than later; not what most >network operators want to hear. Kathie and Van named CoDel both >because "Constant Delay" describes its intended behavior, but also >because "coddling" your packets sounds warm and fuzzy, rather than >nasty and random. The great unwashed fail to understand that packet >drops can be good for their network's health... > >I will not reply further to this thread. > - Jim > > >David > > > > > > Gorry > > > > > >> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy > <wes@mti-systems.com> wrote: > >> > >>> I think the attached updated draft charter reflects most of the > >>> feedback that we've heard so far. > >>> > >>> Note that Dave Taht suggested we might want to go with something > >>> like "Smarter Queue Management" (SQM) for the WG name, because > >>> purely AQM as a name may not capture FQ type of mechanisms that we > >>> may want to have in-scope. I think that scoping discussion may > >>> still be going on into Berlin, but it's a good point, and likely > >>> some other people have cute ideas for a name that could capture > >>> the potential broader scope. > >>> > >> > >> Both Dave's and my experience as relative newcomers to this area is that > >> the term AQM is pretty tightly bound to mark/drop algorithms in the minds > >> of many people in the IETF, who also categorize other algorithms as > >> queuing > >> algorithms. and make a pretty strong mental distinction between them. > >> > >> As my blog post this week > >> > http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues, > >> the killer combination is a cross between rapidly autotuning > >> mark/drop algorithms with what we're calling flow queueing (since it isn't > >> "fair" in the also traditional sense of TCP fair queueing at all, and may > >> not involve TCP flows necessarily either). > >> > >> So while I'd be happy to lump this all into the AQM name bucket > >> personally, > >> I do think that a name that makes clear we're considering algorithms that > >> may marry both lines of intellectual thought together will avoid confusion > >> among many who have worked in one area or the other, but not both. "Smart > >> queue management" or SQM is the best we've come up with for a term. > >> - Jim > >> > >> > >>> -- > >>> Wes Eddy > >>> MTI Systems > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > >================================================================= >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 > > > > >_______________________________________________ >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 ________________________________________________________________ Bob Briscoe, BT --=====================_825992705==.ALT Content-Type: text/html; charset="us-ascii"
1/ Name suggestion: How about just "Queue Management (QMAN)"?
Otherwise, if we coin the term smart queue mgmt, merely by proposing an SQM algorithm, every idiot gets to have everyone else call his/her algo smart.

2/ Scope: "Internet routers, lower-layer switches, other middleboxes."
Can we have host buffers in scope pls? This is the transport area, afterall.

3/ "routers, ... include buffers or queues" Buffers and queues are not members of the same set (IMO). I don't think this is a picky terminology point. Can we adopt the convention that the buffer is the fixed memory allocation (hardware or software), and the queue is the software construct within the buffer?

It already caused confusion when the problem got called bufferbloat, so people thought we were implying the solution was small buffers, so they tune out, because they rightly believe this will lead to unnecessarily high loss. Actually, on a high speed line with high in-degree, it's good practice to have a very large buffer to absorb bursts, as long as you have a adaptive queue threshold within it that rapidly clamps a tight limit on a standing queue.

Same problem in next para:
" Extremely large buffers have been noticed in some software and
  equipment.  When these queues fill, ..." ->
" Extremely large unmanaged buffers have been noticed in some software and
  equipment.  When these buffers fill, ..." ->

4/ "...proactively managing queues ..."
Picky: I think you mean reactively. Proactively maybe a bit ambitious.

5/ I suggest the enumerated bullets are changed to those below:

"The Active Queue Management and Packet Scheduling working group
  works on algorithms for proactively managing queues in
  order to:

  (1) Minimise standing queues

  (2) help flow sources control their sending rates without unnecessary
  losses, e.g. through ECN

  (3) help minimize delays for interactive applications

  (4) /consider the merits of various techniques/ to protect flows from negative impacts of other more
  aggressive or misbehaving flows

Reasoning:

ECN: The original text was:
"(1) help flow sources control their sending rates before the
  onset of necessary losses, e.g. through ECN"
is not accepted wisdom. What's written in RFC3168 makes sense: that marking for ECN traffic has to start at exactly the same point as loss for non-ECN traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy load everyone has to take losses, whether ECN or not, but I don't think that's what you're talking about here.

Protecting flows:
The question of whether/how to recommend flow isolation or not is part of chartered work - the outcome shouldn't be prejudged in the charter.

6/
"  The AQM working group will publish Informational and Best Current
  Practices documents that cover the design, use, and configuration
  of algorithms for managing queues in Internet devices and software.
"
Add: The scope will include both how best to configure existing equipment / software as well as recommendations on designing new equipment / software.

7/ "  The working group will not make changes to ECN, DiffServ, or other
  IETF protocols, though existing ECN, DiffServ, and other mechanisms
  may be used within the algorithms proposed.
"
Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly any such changes will need to be co-ordinated with the AQM WG, given the code is likely to be entwined with AQM code.

8/  "Many AQM algorithms have been proposed in academic literature, but
  very few are widely implemented and deployed.  "

Is this trying to say very few types of AQM are deployed, or very few instances? I think it is trying to say the latter, but that just isn't true (IMO). WRED is very widely deployed in enterprise networks. And RED is implemented near-univerally by the main equipment vendors, and less widely deployed, but not insignificant.

9/ Gap in charter coverage?

"Merits of whether to isolate flows and if so how."

There are multiple functions that often get lumped under "AQM":
a) minimising a standing queue
b) desynchronising losses (/marks)
c) preventing large packet lock-out
d) detecting and policing flows with excessive rate
e) isolating flows from each other (e.g. SFQ)

a,b,c) can be done neutrally and imply no possible policy control.
d,e) depend on policy (which may or may not be hard-coded rather than configurable, e.g. all flows get equal scheduler priority).

There's been significant discussion on the list about the merits of different ways of doing flow isolation. This is the area where I think there is most latent disagreement. We have pretty good consensus already around the recommendations in Fred's doc. We will have to grasp the flow-isolation and policing nettles, so the charter ought to say we're going to.

For instance, my stance is that policy-related functions (d+e) should only be deployed at edge-policy enforcement points, not in every buffer. Altho SFQ clearly makes an associated AQM like CoDel work nicely, I preferred the direction Fred described in:
< http://www.ietf.org/mail-archive/web/aqm/current/msg00081.html>
in which there's a distinguished shared queue, then anything that starts causing delay in that queue gets either isolated in its own queue or focused policing. Rather than isolating every flow into separate queues from the start, because that requires prejudging the share of the scheduler everyone gets.

We have found that with multiple real-time video streams, they all have highly variable rates, so they multiplex really well together in a FIFO. However, if you put them through FQ or WRR, they all get forced into ruts that are always the wrong size for all of them. This isn't a problem if the sum is not often close to capacity (which is why SFQ can appear to be OK with multiple videos). However, the whole point of isolation is to protect flows when the system /is/ close to capacity.


Bob

At 18:35 11/07/2013, Jim Gettys wrote:



On Thu, Jul 11, 2013 at 12:21 PM, David Ros < David.Ros@telecom-bretagne.eu> wrote:

On 11 juil. 2013, at 18:06, gorry@erg.abdn.ac.uk wrote:

>
> I agreed that AQM has to some extent already been deployed in some places
> and this could be confusing to then redefine or obsolete this.
>

+1


> For what it's worth I don't like "smart" queueing as a name - implying
> it's sounds like a marketing term rather than a combination of "AQM"
> mark/drop and flow scheduling.

+1


>
> If SQM was short for  scheduling and queue management I may have liked the
> abbreviation more, ... let's see where this discussion ends.


Scheduling and Queue Management is fine with me...

Since we're looking for acronyms that (a) are pronounceable, (b) do not sound like a marketing gimmick, (c) match to a WG name that conveys the essence of what the WG will do, then why not simply: QMAPS? (Queue Management And Packet Scheduling).


I'm not willing to bikeshed working group names and will live with whatever people like.  I'm certainly not great at selecting names, having bound the free variable with a window system name.

Names can be important: one of the problems with the "RED" algorithm, whose initial formation was, IIRC, "Random Early Discard".  The name's connotation implied it "randomly" discarded your packets and does so sooner rather than later; not what most network operators want to hear. Kathie and Van named CoDel both because "Constant Delay" describes its intended behavior, but also because "coddling" your packets sounds warm and fuzzy, rather than nasty and random. The great unwashed fail to understand that packet drops can be good for their network's health...

I will not reply further to this thread.
                                           - Jim


David


>
> Gorry
>
>
>> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>>
>>> I think the attached updated draft charter reflects most of the
>>> feedback that we've heard so far.
>>>
>>> Note that Dave Taht suggested we might want to go with something
>>> like "Smarter Queue Management" (SQM) for the WG name, because
>>> purely AQM as a name may not capture FQ type of mechanisms that we
>>> may want to have in-scope.  I think that scoping discussion may
>>> still be going on into Berlin, but it's a good point, and likely
>>> some other people have cute ideas for a name that could capture
>>> the potential broader scope.
>>>
>>
>> Both Dave's and my experience as relative newcomers to this area is that
>> the term AQM is pretty tightly bound to mark/drop algorithms in the minds
>> of many people in the IETF, who also categorize other algorithms as
>> queuing
>> algorithms. and make a pretty strong mental distinction between them.
>>
>> As my blog post this week
>> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues ,
>> the killer combination is a cross between rapidly autotuning
>> mark/drop algorithms with what we're calling flow queueing (since it isn't
>> "fair" in the also traditional sense of TCP fair queueing at all, and may
>> not involve TCP flows necessarily either).
>>
>> So while I'd be happy to lump this all into the AQM name bucket
>> personally,
>> I do think that a name that makes clear we're considering algorithms that
>> may marry both lines of intellectual thought together will avoid confusion
>> among many who have worked in one area or the other, but not both.  "Smart
>> queue management" or SQM is the best we've come up with for a term.
>>                                                               - Jim
>>
>>
>>> --
>>> Wes Eddy
>>> MTI Systems
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

=================================================================
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




_______________________________________________
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

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_825992705==.ALT-- From ropan@cisco.com Thu Jul 11 19:05:24 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 2A5BA21E8083 for ; Thu, 11 Jul 2013 19:05:24 -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=[AWL=-0.000, 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 k6+OxKrq7lu4 for ; Thu, 11 Jul 2013 19:05:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 83A7021E8063 for ; Thu, 11 Jul 2013 19:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29912; q=dns/txt; s=iport; t=1373594719; x=1374804319; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=AOTV2iS8bX0LJxgIwQcH8xsNGFQzwpqCpJrFKC1itwk=; b=hV6JI32UnVXEcV6NELELeXlmLcW9P95HgLtdYT8aThN9RQ1lhRvUuvTs 5TZ0kAmoFb2N2f7awwby2+Um4PsRowEEbOLydIn2qQuBpbc+T1Z5oJtZw 11hCy5fSEds4+7rjOFmP7juUIQuQZ0zXPbGre48p4V25VZXpDESW8nYup I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAKZj31GtJXG//2dsb2JhbABaFoIsRDRPuSSIMoEHFnSCIwEBAQMBAQEBFw1HAQoFDQEIEQMBAgEKFgcuCxQJCAIEAQ0FCAESh24GDLcQjioFgQEgDQQHgwlsA5QFhQGQJIMRgWkIFyA X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208,217";a="230857483" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jul 2013 02:05:18 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6C25ImT004988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 02:05:18 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.152]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 21:05:17 -0500 From: "Rong Pan (ropan)" To: Bob Briscoe , Wesley Eddy Thread-Topic: [aqm] updated draft charter Thread-Index: AQHOfqL6bveF21Zpe06m41RGOs2m1JlhJSgA Date: Fri, 12 Jul 2013 02:05:17 +0000 Message-ID: In-Reply-To: <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.72.238] Content-Type: multipart/alternative; boundary="_000_BF2CBE9A994B89438F7F3B9FD58C2B7F26D319BFxmbalnx15ciscoc_" MIME-Version: 1.0 Cc: Gorry Fairhurst , "aqm@ietf.org" , Jim Gettys , David Ros Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 02:05:24 -0000 --_000_BF2CBE9A994B89438F7F3B9FD58C2B7F26D319BFxmbalnx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Bob Briscoe > Date: Friday, July 12, 2013 9:56 AM To: Wesley Eddy > Cc: Gorry Fairhurst >, Ji= m Gettys >, David Ros >, "aqm@ietf.o= rg" > Subject: Re: [aqm] updated draft charter 1/ Name suggestion: How about just "Queue Management (QMAN)"? Otherwise, if we coin the term smart queue mgmt, merely by proposing an SQM= algorithm, every idiot gets to have everyone else call his/her algo smart. 2/ Scope: "Internet routers, lower-layer switches, other middleboxes." Can we have host buffers in scope pls? This is the transport area, afterall= . 3/ "routers, ... include buffers or queues" Buffers and queues are not memb= ers of the same set (IMO). I don't think this is a picky terminology point.= Can we adopt the convention that the buffer is the fixed memory allocation= (hardware or software), and the queue is the software construct within the= buffer? It already caused confusion when the problem got called bufferbloat, so peo= ple thought we were implying the solution was small buffers, so they tune o= ut, because they rightly believe this will lead to unnecessarily high loss.= Actually, on a high speed line with high in-degree, it's good practice to = have a very large buffer to absorb bursts, as long as you have a adaptive q= ueue threshold within it that rapidly clamps a tight limit on a standing qu= eue. Same problem in next para: " Extremely large buffers have been noticed in some software and equipment. When these queues fill, ..." -> " Extremely large unmanaged buffers have been noticed in some software and equipment. When these buffers fill, ..." -> 4/ "...proactively managing queues ..." Picky: I think you mean reactively. Proactively maybe a bit ambitious. 5/ I suggest the enumerated bullets are changed to those below: "The Active Queue Management and Packet Scheduling working group works on algorithms for proactively managing queues in order to: (1) Minimise standing queues (2) help flow sources control their sending rates without unnecessary losses, e.g. through ECN (3) help minimize delays for interactive applications (4) /consider the merits of various techniques/ to protect flows from neg= ative impacts of other more aggressive or misbehaving flows Reasoning: ECN: The original text was: "(1) help flow sources control their sending rates before the onset of necessary losses, e.g. through ECN" is not accepted wisdom. What's written in RFC3168 makes sense: that marking= for ECN traffic has to start at exactly the same point as loss for non-ECN= traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy lo= ad everyone has to take losses, whether ECN or not, but I don't think that'= s what you're talking about here. Protecting flows: The question of whether/how to recommend flow isolation or not is part of c= hartered work - the outcome shouldn't be prejudged in the charter. 6/ " The AQM working group will publish Informational and Best Current Practices documents that cover the design, use, and configuration of algorithms for managing queues in Internet devices and software. " Add: The scope will include both how best to configure existing equipment /= software as well as recommendations on designing new equipment / software. 7/ " The working group will not make changes to ECN, DiffServ, or other IETF protocols, though existing ECN, DiffServ, and other mechanisms may be used within the algorithms proposed. " Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly a= ny such changes will need to be co-ordinated with the AQM WG, given the cod= e is likely to be entwined with AQM code. 8/ "Many AQM algorithms have been proposed in academic literature, but very few are widely implemented and deployed. " Is this trying to say very few types of AQM are deployed, or very few insta= nces? I think it is trying to say the latter, but that just isn't true (IMO= ). WRED is very widely deployed in enterprise networks. And RED is implemen= ted near-univerally by the main equipment vendors, and less widely deployed= , but not insignificant. 9/ Gap in charter coverage? "Merits of whether to isolate flows and if so how." There are multiple functions that often get lumped under "AQM": a) minimising a standing queue b) desynchronising losses (/marks) c) preventing large packet lock-out d) detecting and policing flows with excessive rate e) isolating flows from each other (e.g. SFQ) a,b,c) can be done neutrally and imply no possible policy control. d,e) depend on policy (which may or may not be hard-coded rather than confi= gurable, e.g. all flows get equal scheduler priority). There's been significant discussion on the list about the merits of differe= nt ways of doing flow isolation. This is the area where I think there is mo= st latent disagreement. We have pretty good consensus already around the re= commendations in Fred's doc. We will have to grasp the flow-isolation and p= olicing nettles, so the charter ought to say we're going to. For instance, my stance is that policy-related functions (d+e) should only = be deployed at edge-policy enforcement points, not in every buffer. Altho S= FQ clearly makes an associated AQM like CoDel work nicely, I preferred the = direction Fred described in: < http://www.ietf.org/mail-archive/web/aqm/current/msg00081.html> in which there's a distinguished shared queue, then anything that starts ca= using delay in that queue gets either isolated in its own queue or focused = policing. Rather than isolating every flow into separate queues from the st= art, because that requires prejudging the share of the scheduler everyone g= ets. We have found that with multiple real-time video streams, they all have hig= hly variable rates, so they multiplex really well together in a FIFO. Howev= er, if you put them through FQ or WRR, they all get forced into ruts that a= re always the wrong size for all of them. This isn't a problem if the sum i= s not often close to capacity (which is why SFQ can appear to be OK with mu= ltiple videos). However, the whole point of isolation is to protect flows w= hen the system /is/ close to capacity. >>>>> Totally Agree=85. Rong At 18:35 11/07/2013, Jim Gettys wrote: On Thu, Jul 11, 2013 at 12:21 PM, David Ros < David.Ros@telecom-bretagne.eu= > wrote: On 11 juil. 2013, at 18:06, gorry@erg.abdn.ac.uk wrote: > > I agreed that AQM has to some extent already been deployed in some places > and this could be confusing to then redefine or obsolete this. > +1 > For what it's worth I don't like "smart" queueing as a name - implying > it's sounds like a marketing term rather than a combination of "AQM" > mark/drop and flow scheduling. +1 > > If SQM was short for scheduling and queue management I may have liked th= e > abbreviation more, ... let's see where this discussion ends. Scheduling and Queue Management is fine with me... Since we're looking for acronyms that (a) are pronounceable, (b) do not sou= nd like a marketing gimmick, (c) match to a WG name that conveys the essenc= e of what the WG will do, then why not simply: QMAPS? (Queue Management And= Packet Scheduling). I'm not willing to bikeshed working group names and will live with whatever= people like. I'm certainly not great at selecting names, having bound the= free variable with a window system name. Names can be important: one of the problems with the "RED" algorithm, whose= initial formation was, IIRC, "Random Early Discard". The name's connotati= on implied it "randomly" discarded your packets and does so sooner rather t= han later; not what most network operators want to hear. Kathie and Van nam= ed CoDel both because "Constant Delay" describes its intended behavior, but= also because "coddling" your packets sounds warm and fuzzy, rather than na= sty and random. The great unwashed fail to understand that packet drops can= be good for their network's health... I will not reply further to this thread. - Jim David > > Gorry > > >> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy > wrote: >> >>> I think the attached updated draft charter reflects most of the >>> feedback that we've heard so far. >>> >>> Note that Dave Taht suggested we might want to go with something >>> like "Smarter Queue Management" (SQM) for the WG name, because >>> purely AQM as a name may not capture FQ type of mechanisms that we >>> may want to have in-scope. I think that scoping discussion may >>> still be going on into Berlin, but it's a good point, and likely >>> some other people have cute ideas for a name that could capture >>> the potential broader scope. >>> >> >> Both Dave's and my experience as relative newcomers to this area is that >> the term AQM is pretty tightly bound to mark/drop algorithms in the mind= s >> of many people in the IETF, who also categorize other algorithms as >> queuing >> algorithms. and make a pretty strong mental distinction between them. >> >> As my blog post this week >> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuin= g-traditional-aqm-is-not-enough/#more-1091argues , >> the killer combination is a cross between rapidly autotuning >> mark/drop algorithms with what we're calling flow queueing (since it isn= 't >> "fair" in the also traditional sense of TCP fair queueing at all, and ma= y >> not involve TCP flows necessarily either). >> >> So while I'd be happy to lump this all into the AQM name bucket >> personally, >> I do think that a name that makes clear we're considering algorithms tha= t >> may marry both lines of intellectual thought together will avoid confusi= on >> among many who have worked in one area or the other, but not both. "Sma= rt >> queue management" or SQM is the best we've come up with for a term. >> - Jim >> >> >>> -- >>> Wes Eddy >>> MTI Systems >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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/ I love deadlines. I like the whooshing sound they make as they fly by. -- D= ouglas Adams _______________________________________________ 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 ________________________________________________________________ Bob Briscoe, BT --_000_BF2CBE9A994B89438F7F3B9FD58C2B7F26D319BFxmbalnx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable



From: Bob Briscoe <bob.briscoe@bt.com>
Date: Friday, July 12, 2013 9:56 AM=
To: Wesley Eddy <wes@mti-systems.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Jim Gettys <<= a href=3D"mailto:jg@freedesktop.org">jg@freedesktop.org>, David Ros = <David.Ros@telecom-bret= agne.eu>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] updated draft ch= arter


1/ Name suggestion: How about just "Queue Management (QMAN)"?
Otherwise, if we coin the term smart queue mgmt, merely by proposing an SQM= algorithm, every idiot gets to have everyone else call his/her algo smart.=

2/ Scope: "Internet routers, lower-layer switches, other middleboxes.&= quot;
Can we have host buffers in scope pls? This is the transport area, afterall= .

3/ "routers, ... include buffers or queues" Buffers and queues ar= e not members of the same set (IMO). I don't think this is a picky terminol= ogy point. Can we adopt the convention that the buffer is the fixed memory = allocation (hardware or software), and the queue is the software construct within the buffer?

It already caused confusion when the problem got called bufferbloat, so peo= ple thought we were implying the solution was small buffers, so they tune o= ut, because they rightly believe this will lead to unnecessarily high loss.= Actually, on a high speed line with high in-degree, it's good practice to have a very large buffer to abs= orb bursts, as long as you have a adaptive queue threshold within it that r= apidly clamps a tight limit on a standing queue.

Same problem in next para:
" Extremely large buffers have been noticed in some software and
  equipment.  When these queues fill, ..." ->
" Extremely large unmanaged buffers have been noticed in some software= and
  equipment.  When these buffers fill, ..." ->

4/ "...proactively managing queues ..."
Picky: I think you mean reactively. Proactively maybe a bit ambitious.

5/ I suggest the enumerated bullets are changed to those below:

"The Active Queue Management and Packet Scheduling working group
  works on algorithms for proactively managing queues in
  order to:

  (1) Minimise standing queues

  (2) help flow sources control their sending rates without unnecessar= y
  losses, e.g. through ECN

  (3) help minimize delays for interactive applications

  (4) /consider the merits of various techniques/ to protect flows fro= m negative impacts of other more
  aggressive or misbehaving flows

Reasoning:

ECN: The original text was:
"(1) help flow sources control their sending rates before the
  onset of necessary losses, e.g. through ECN"
is not accepted wisdom. What's written in RFC3168 makes sense: that marking= for ECN traffic has to start at exactly the same point as loss for non-ECN= traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy lo= ad everyone has to take losses, whether ECN or not, but I don't think that's what you're talking about her= e.

Protecting flows:
The question of whether/how to recommend flow isolation or not is part of c= hartered work - the outcome shouldn't be prejudged in the charter.

6/
"  The AQM working group will publish Informational and Best Curr= ent
  Practices documents that cover the design, use, and configuration   of algorithms for managing queues in Internet devices and software.<= br> "
Add: The scope will include both how best to configure existing equipment /= software as well as recommendations on designing new equipment / software.=

7/ "  The working group will not make changes to ECN, DiffServ, o= r other
  IETF protocols, though existing ECN, DiffServ, and other mechanisms<= br>   may be used within the algorithms proposed.
"
Add: The proper place for changes to ECN & Diffserv is TSVWG, but clear= ly any such changes will need to be co-ordinated with the AQM WG, given the= code is likely to be entwined with AQM code.

8/  "Many AQM algorithms have been proposed in academic literatur= e, but
  very few are widely implemented and deployed.  "

Is this trying to say very few types of AQM are deployed, or very few insta= nces? I think it is trying to say the latter, but that just isn't true (IMO= ). WRED is very widely deployed in enterprise networks. And RED is implemen= ted near-univerally by the main equipment vendors, and less widely deployed, but not insignificant.

9/ Gap in charter coverage?

"Merits of whether to isolate flows and if so how."

There are multiple functions that often get lumped under "AQM": a) minimising a standing queue
b) desynchronising losses (/marks)
c) preventing large packet lock-out
d) detecting and policing flows with excessive rate
e) isolating flows from each other (e.g. SFQ)

a,b,c) can be done neutrally and imply no possible policy control.
d,e) depend on policy (which may or may not be hard-coded rather than confi= gurable, e.g. all flows get equal scheduler priority).

There's been significant discussion on the list about the merits of differe= nt ways of doing flow isolation. This is the area where I think there is mo= st latent disagreement. We have pretty good consensus already around the re= commendations in Fred's doc. We will have to grasp the flow-isolation and policing nettles, so the charter= ought to say we're going to.

For instance, my stance is that policy-related functions (d+e) should o= nly be deployed at edge-policy enforcement points, not in every buffer. Alt= ho SFQ clearly makes an associated AQM like CoDel work nicely, I preferred = the direction Fred described in:
< http://www.ietf.org/mail-archive/web/aqm/current/ms= g00081.html>
in which there's a distinguished shared queue, then anything that starts ca= using delay in that queue gets either isolated in its own queue or focused = policing. Rather than isolating every flow into separate queues from the st= art, because that requires prejudging the share of the scheduler everyone gets.

We have found that with multiple real-time video streams, they all have hig= hly variable rates, so they multiplex really well together in a FIFO. Howev= er, if you put them through FQ or WRR, they all get forced into ruts that a= re always the wrong size for all of them. This isn't a problem if the sum is not often close to capacity (w= hich is why SFQ can appear to be OK with multiple videos). However, the who= le point of isolation is to protect flows when the system /is/ close to cap= acity.


>>>>> Totally Agree=85.


Rong



At 18:35 11/07/2013, Jim Gettys wrote:



On Thu, Jul 11, 2013 at = 12:21 PM, David Ros < D= avid.Ros@telecom-bretagne.eu> wrote:

On 11 juil. 2013, at 18:06, gor= ry@erg.abdn.ac.uk wrote:

>
> I agreed that AQM has to some extent already been deployed in= some places
> and this could be confusing to then redefine or obsolete this= .
>

+1


> For what it's worth I don't like "smart" queueing a= s a name - implying
> it's sounds like a marketing term rather than a combination o= f "AQM"
> mark/drop and flow scheduling.

+1


>
> If SQM was short for  scheduling and queue management I = may have liked the
> abbreviation more, ... let's see where this discussion ends.<= br>

Scheduling and Queue Management is fine with me...

Since we're looking for acronyms that (a) are pronounceable, (b) do not= sound like a marketing gimmick, (c) match to a WG name that conveys the es= sence of what the WG will do, then why not simply: QMAPS? (Queue Management= And Packet Scheduling).


I'm not willing to bikeshed working group names and will live with whatever= people like.  I'm certainly not great at selecting names, having boun= d the free variable with a window system name.

Names can be important: one of the problems with the "RED" algori= thm, whose initial formation was, IIRC, "Random Early Discard".&n= bsp; The name's connotation implied it "randomly" discarded your = packets and does so sooner rather than later; not what most network operators want to hear. Kathie and Van named CoDel both because "Cons= tant Delay" describes its intended behavior, but also because "co= ddling" your packets sounds warm and fuzzy, rather than nasty and rand= om. The great unwashed fail to understand that packet drops can be good for their network's health...

I will not reply further to this thread.
            &nb= sp;            =             &nb= sp;     - Jim


David


>
> Gorry
>
>
>> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>>
>>> I think the attached updated draft charter reflects m= ost of the
>>> feedback that we've heard so far.
>>>
>>> Note that Dave Taht suggested we might want to go wit= h something
>>> like "Smarter Queue Management" (SQM) for t= he WG name, because
>>> purely AQM as a name may not capture FQ type of mecha= nisms that we
>>> may want to have in-scope.  I think that scoping= discussion may
>>> still be going on into Berlin, but it's a good point,= and likely
>>> some other people have cute ideas for a name that cou= ld capture
>>> the potential broader scope.
>>>
>>
>> Both Dave's and my experience as relative newcomers to th= is area is that
>> the term AQM is pretty tightly bound to mark/drop algorit= hms in the minds
>> of many people in the IETF, who also categorize other alg= orithms as
>> queuing
>> algorithms. and make a pretty strong mental distinction b= etween them.
>>
>> As my blog post this week
>> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-t= raditional-aqm-is-not-enough/#more-1091argues ,
>> the killer combination is a cross between rapidly autotun= ing
>> mark/drop algorithms with what we're calling flow queuein= g (since it isn't
>> "fair" in the also traditional sense of TCP fai= r queueing at all, and may
>> not involve TCP flows necessarily either).
>>
>> So while I'd be happy to lump this all into the AQM name = bucket
>> personally,
>> I do think that a name that makes clear we're considering= algorithms that
>> may marry both lines of intellectual thought together wil= l avoid confusion
>> among many who have worked in one area or the other, but = not both.  "Smart
>> queue management" or SQM is the best we've come up w= ith for a term.
>>         &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   - Jim
>>
>>
>>> --
>>> Wes Eddy
>>> MTI Systems
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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.r= ennes.enst-bretagne.fr/~dros/

I love deadlines. I like the whooshing sound they make as they fly= by. -- Douglas Adams




_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


_______________________________________________
aqm mailing list
aqm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,          &nb= sp;            =             &nb= sp;            =   BT

--_000_BF2CBE9A994B89438F7F3B9FD58C2B7F26D319BFxmbalnx15ciscoc_-- From dave.taht@gmail.com Thu Jul 11 19:12: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 8A30211E80A5 for ; Thu, 11 Jul 2013 19:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.288, 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 woHWgEhBwSry for ; Thu, 11 Jul 2013 19:12:24 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 65FE721F9CEC for ; Thu, 11 Jul 2013 19:12:24 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so19428392iea.18 for ; Thu, 11 Jul 2013 19:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6bDLbgcsU5dEcWaVhZrg9YwbR31grncNhpeWfhkNUzE=; b=pJOosM5Ya1L7OmOPJNMFr7B90EKXbuzl/Izwf6vFNqF8rAqXVCWA7OZwWB1CtvfM8V hqHwIYrrcjshiY7HWO+s5wIzz1suH2NTC92Hp+h6xY9/Q3qiA+Qb0FtIj8yIwVsSWWvv OISBlYXl/nJolEJmlgtfac8ml0X0wO6nAhg8dCiFs1y1M8U/1XYOQJetdzHSqZ16D+LN 6YeITsYRwu9clSRSKKpEi/iqqxkGl4UubinbBqo45bY7JYaTyDUnOCV5w2XK1/Kmy+qJ Izly4poNqZlhI1J8AMik/2uuaEtDryZENhu7VlNJGRY3Nl8IqFoTHTnmfM2ihzPYWXnc wwwQ== MIME-Version: 1.0 X-Received: by 10.42.133.66 with SMTP id g2mr12239759ict.49.1373595143914; Thu, 11 Jul 2013 19:12:23 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Thu, 11 Jul 2013 19:12:23 -0700 (PDT) In-Reply-To: <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> Date: Thu, 11 Jul 2013 19:12:23 -0700 Message-ID: From: Dave Taht To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wesley Eddy , Gorry Fairhurst , "aqm@ietf.org" , Jim Gettys , David Ros Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 02:12:27 -0000 On Thu, Jul 11, 2013 at 6:56 PM, Bob Briscoe wrote: > > 1/ Name suggestion: How about just "Queue Management (QMAN)"? > Otherwise, if we coin the term smart queue mgmt, merely by proposing an S= QM > algorithm, every idiot gets to have everyone else call his/her algo smart= . Heh. Like jim said, this is a bikeshed, and I'd like to stay out of it, too= . I note in trying to coin a new acronym, like "SQM", I'd said "smarter queue management", not smart, (or at least I think I did) - and I think AQM should be defined as queue length management to minimize future confusion. so QMAN works for me. There was another proposal earlier today(?) that had another attempt I thought would be confusing out of context. Feel free to bring in madison avenue. > 2/ Scope: "Internet routers, lower-layer switches, other middleboxes." > Can we have host buffers in scope pls? This is the transport area, aftera= ll. YES, PLEASE. > 3/ "routers, ... include buffers or queues" Buffers and queues are not > members of the same set (IMO). I don't think this is a picky terminology > point. Can we adopt the convention that the buffer is the fixed memory > allocation (hardware or software), and the queue is the software construc= t > within the buffer? I like it. > It already caused confusion when the problem got called bufferbloat, so I concur jim should have called it queue bloat, but it wasn't as catchy as bufferbloat. > people thought we were implying the solution was small buffers, so they t= une > out, because they rightly believe this will lead to unnecessarily high lo= ss. > Actually, on a high speed line with high in-degree, it's good practice to > have a very large buffer to absorb bursts, as long as you have a adaptive > queue threshold within it that rapidly clamps a tight limit on a standing > queue. > > Same problem in next para: > " Extremely large buffers have been noticed in some software and > equipment. When these queues fill, ..." -> > " Extremely large unmanaged buffers have been noticed in some software an= d > equipment. When these buffers fill, ..." -> s/buffers/queues for sure. > > 4/ "...proactively managing queues ..." > Picky: I think you mean reactively. Proactively maybe a bit ambitious. A proactive queue management algorithm SHOULD have support for tachyon based pre-emptive feedback. > 5/ I suggest the enumerated bullets are changed to those below: > > "The Active Queue Management and Packet Scheduling working group > works on algorithms for proactively managing queues in > order to: > > (1) Minimise standing queues > > (2) help flow sources control their sending rates without unnecessary > losses, e.g. through ECN I really remain dubious about usage of ECN on the world wide internet. If deployed widely, attacks will widely use it. > (3) help minimize delays for interactive applications > > (4) /consider the merits of various techniques/ to protect flows from > negative impacts of other more > aggressive or misbehaving flows > > Reasoning: > > ECN: The original text was: > "(1) help flow sources control their sending rates before the > onset of necessary losses, e.g. through ECN" > is not accepted wisdom. What's written in RFC3168 makes sense: that marki= ng > for ECN traffic has to start at exactly the same point as loss for non-EC= N > traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy l= oad > everyone has to take losses, whether ECN or not, but I don't think that's > what you're talking about here. > > Protecting flows: > The question of whether/how to recommend flow isolation or not is part of > chartered work - the outcome shouldn't be prejudged in the charter. I'm a little vague on your intent here. > 6/ > " The AQM working group will publish Informational and Best Current > Practices documents that cover the design, use, and configuration > of algorithms for managing queues in Internet devices and software. > " > Add: The scope will include both how best to configure existing equipment= / > software as well as recommendations on designing new equipment / software= . > > 7/ " The working group will not make changes to ECN, DiffServ, or other > IETF protocols, though existing ECN, DiffServ, and other mechanisms > may be used within the algorithms proposed. > " > Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly > any such changes will need to be co-ordinated with the AQM WG, given the > code is likely to be entwined with AQM code. I'm not sure that this scope needs to be so limited here. > 8/ "Many AQM algorithms have been proposed in academic literature, but > very few are widely implemented and deployed. " > > Is this trying to say very few types of AQM are deployed, or very few > instances? I think it is trying to say the latter, but that just isn't tr= ue > (IMO). WRED is very widely deployed in enterprise networks. And RED is > implemented near-univerally by the main equipment vendors, and less widel= y > deployed, but not insignificant. > > 9/ Gap in charter coverage? > > "Merits of whether to isolate flows and if so how." > > There are multiple functions that often get lumped under "AQM": > a) minimising a standing queue > b) desynchronising losses (/marks) > c) preventing large packet lock-out > d) detecting and policing flows with excessive rate > e) isolating flows from each other (e.g. SFQ) > > a,b,c) can be done neutrally and imply no possible policy control. > d,e) depend on policy (which may or may not be hard-coded rather than > configurable, e.g. all flows get equal scheduler priority). > > There's been significant discussion on the list about the merits of > different ways of doing flow isolation. This is the area where I think th= ere > is most latent disagreement. yep. >We have pretty good consensus already around > the recommendations in Fred's doc. We will have to grasp the flow-isolati= on > and policing nettles, so the charter ought to say we're going to. +1. > For instance, my stance is that policy-related functions (d+e) should onl= y > be deployed at edge-policy enforcement points, not in every buffer. Altho > SFQ clearly makes an associated AQM like CoDel work nicely, I preferred t= he > direction Fred described in: > < http://www.ietf.org/mail-archive/web/aqm/current/msg00081.html> > in which there's a distinguished shared queue, then anything that starts > causing delay in that queue gets either isolated in its own queue or focu= sed > policing. Rather than isolating every flow into separate queues from the > start, because that requires prejudging the share of the scheduler everyo= ne > gets. Hmm. > We have found that with multiple real-time video streams, they all have > highly variable rates, so they multiplex really well together in a FIFO. > However, if you put them through FQ or WRR, they all get forced into ruts > that are always the wrong size for all of them. This isn't a problem if t= he > sum is not often close to capacity (which is why SFQ can appear to be OK > with multiple videos). However, the whole point of isolation is to protec= t > flows when the system /is/ close to capacity. Cite? Not that I disagree, I've been ramping up at looking hard at webrtc behavior of late, just that most of my foci are focused on web, voip, and gaming traffic on the edge to date.. > > > Bob > > > At 18:35 11/07/2013, Jim Gettys wrote: > > > > On Thu, Jul 11, 2013 at 12:21 PM, David Ros < David.Ros@telecom-bretagne.= eu> > wrote: > > On 11 juil. 2013, at 18:06, gorry@erg.abdn.ac.uk wrote: > >> >> I agreed that AQM has to some extent already been deployed in some place= s >> and this could be confusing to then redefine or obsolete this. >> > > +1 > > >> For what it's worth I don't like "smart" queueing as a name - implying >> it's sounds like a marketing term rather than a combination of "AQM" >> mark/drop and flow scheduling. > > +1 > > >> >> If SQM was short for scheduling and queue management I may have liked t= he >> abbreviation more, ... let's see where this discussion ends. > > > Scheduling and Queue Management is fine with me... > > Since we're looking for acronyms that (a) are pronounceable, (b) do not > sound like a marketing gimmick, (c) match to a WG name that conveys the > essence of what the WG will do, then why not simply: QMAPS? (Queue > Management And Packet Scheduling). > > > I'm not willing to bikeshed working group names and will live with whatev= er > people like. I'm certainly not great at selecting names, having bound th= e > free variable with a window system name. > > Names can be important: one of the problems with the "RED" algorithm, who= se > initial formation was, IIRC, "Random Early Discard". The name's connotat= ion > implied it "randomly" discarded your packets and does so sooner rather th= an > later; not what most network operators want to hear. Kathie and Van named > CoDel both because "Constant Delay" describes its intended behavior, but > also because "coddling" your packets sounds warm and fuzzy, rather than > nasty and random. The great unwashed fail to understand that packet drops > can be good for their network's health... > > I will not reply further to this thread. > - Jim > > > David > > >> >> Gorry >> >> >>> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy >>> wrote: >>> >>>> I think the attached updated draft charter reflects most of the >>>> feedback that we've heard so far. >>>> >>>> Note that Dave Taht suggested we might want to go with something >>>> like "Smarter Queue Management" (SQM) for the WG name, because >>>> purely AQM as a name may not capture FQ type of mechanisms that we >>>> may want to have in-scope. I think that scoping discussion may >>>> still be going on into Berlin, but it's a good point, and likely >>>> some other people have cute ideas for a name that could capture >>>> the potential broader scope. >>>> >>> >>> Both Dave's and my experience as relative newcomers to this area is tha= t >>> the term AQM is pretty tightly bound to mark/drop algorithms in the min= ds >>> of many people in the IETF, who also categorize other algorithms as >>> queuing >>> algorithms. and make a pretty strong mental distinction between them. >>> >>> As my blog post this week >>> >>> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queui= ng-traditional-aqm-is-not-enough/#more-1091argues >>> , >>> the killer combination is a cross between rapidly autotuning >>> mark/drop algorithms with what we're calling flow queueing (since it >>> isn't >>> "fair" in the also traditional sense of TCP fair queueing at all, and m= ay >>> not involve TCP flows necessarily either). >>> >>> So while I'd be happy to lump this all into the AQM name bucket >>> personally, >>> I do think that a name that makes clear we're considering algorithms th= at >>> may marry both lines of intellectual thought together will avoid >>> confusion >>> among many who have worked in one area or the other, but not both. >>> "Smart >>> queue management" or SQM is the best we've come up with for a term. >>> - Jim >>> >>> >>>> -- >>>> Wes Eddy >>>> MTI Systems >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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/ > > I love deadlines. I like the whooshing sound they make as they fly by. -- > Douglas Adams > > > > > _______________________________________________ > 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 > > ________________________________________________________________ > Bob Briscoe, BT > > > _______________________________________________ > 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 dave.taht@gmail.com Thu Jul 11 19:24: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 3EFF711E80E0 for ; Thu, 11 Jul 2013 19:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.247, 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 M6U63pDu56dz for ; Thu, 11 Jul 2013 19:24:48 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DD28B11E80DC for ; Thu, 11 Jul 2013 19:24:47 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so19687576ieb.30 for ; Thu, 11 Jul 2013 19:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+v3B5D/O8EiBBpXVX/0yV0hzKS9p1nWuMQgimx7cu7Y=; b=qzSZjwvdjgWuvoRTkxnNrDBFU0qfphhjwkfwZiXWZRVVEKrmeSkIPFZ6Zt4XXLF1hv R42AcOW/ant3jt/Dt2RH5Aiyslnrw65L3LapGCL6vWl0tg6nmdLKTfXIl+RJeXNO5FA5 O1gSrusuaMXnOApDCTUrgA0M4dhjmjm4t+hhGi23jVwEt2yCeAxE38b1JQdYbe76yYm1 iPR9tc1sUL7uqyLUAvqwhtqrgN7V7dWx4ykEm3dL40v/jA3FkAgHwlhm6a99mu8qi8+s QxtJeCRomtpcbzgOo2I3SDTY70KanM16flJlQuvU/MiNRVC7fUwv9CBoYAWfSVV5AntF U5mA== MIME-Version: 1.0 X-Received: by 10.43.133.70 with SMTP id hx6mr12261918icc.34.1373595887486; Thu, 11 Jul 2013 19:24:47 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Thu, 11 Jul 2013 19:24:47 -0700 (PDT) In-Reply-To: <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> Date: Thu, 11 Jul 2013 19:24:47 -0700 Message-ID: From: Dave Taht To: David Ros Content-Type: text/plain; charset=ISO-8859-1 Cc: Gorry Fairhurst , Wesley Eddy , Jim Gettys , aqm@ietf.org Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 02:24:49 -0000 > Since we're looking for acronyms that (a) are pronounceable, (b) do not sound like a marketing gimmick, (c) match to a WG name that conveys the essence of what the WG will do, then why not simply: QMAPS? (Queue Management And Packet Scheduling). I didn't go for QMAPS because MAPS is rather meaningful in another context. Also in thinking about "QMAN", we are generally talking about *Network* queues here, not other queues, although certainly the kinds of issues we are addressing here have applicability to (for example) cpu scheduling. http://lwn.net/Articles/558603/ NQMAN doesn't exactly roll off the tongue and is hard on the eyes. (actually the Q is rather attractive in it's own way there but I digress) From garmitage@swin.edu.au Thu Jul 11 23:11:06 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 8E2E721F9A4B for ; Thu, 11 Jul 2013 23:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 DEKlK+o0XFA6 for ; Thu, 11 Jul 2013 23:11:00 -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 865AF21F9A43 for ; Thu, 11 Jul 2013 23:10:59 -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 r6C6Alwb025399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 16:10:57 +1000 Message-ID: <51DF9DE7.4030103@swin.edu.au> Date: Fri, 12 Jul 2013 16:10:47 +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: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> In-Reply-To: <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 06:11:06 -0000 On 07/12/2013 11:56, Bob Briscoe wrote: [..] > 3/ "routers, ... include buffers or queues" Buffers and queues are > not members of the same set (IMO). I don't think this is a picky > terminology point. Can we adopt the convention that the buffer is the > fixed memory allocation (hardware or software), and the queue is the > software construct within the buffer? The distinction would be an interesting one to make, but hasn't horse bolted on this many years ago? IMO, there's lots of history behind the notion that a buffer is the space used to absorb transient overloads (regardless of how implemented) and a queue is a either a synonym for buffer or a particular subset (e.g. a FIFO buffer). cheers, gja From gorry@erg.abdn.ac.uk Thu Jul 11 23:43: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 E3A0521F9D7B for ; Thu, 11 Jul 2013 23:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 0Q9Uky6Xtm5S for ; Thu, 11 Jul 2013 23:43:45 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD6821F9D68 for ; Thu, 11 Jul 2013 23:43:45 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6B9FC2B44A7; Fri, 12 Jul 2013 07:43:42 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 12 Jul 2013 07:43:42 +0100 Message-ID: In-Reply-To: <51DF9DE7.4030103@swin.edu.au> References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> <51DF9DE7.4030103@swin.edu.au> Date: Fri, 12 Jul 2013 07:43:42 +0100 From: gorry@erg.abdn.ac.uk To: "grenville armitage" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: aqm@ietf.org Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 06:43:50 -0000 I think Bob's proposal is a useful one as we move to active queue management. I suspect we will need to make the distinction between the two terms every document / presentation though to make sure people see the distinction. Gorry > > > On 07/12/2013 11:56, Bob Briscoe wrote: > [..] >> 3/ "routers, ... include buffers or queues" Buffers and queues are >> not members of the same set (IMO). I don't think this is a picky >> terminology point. Can we adopt the convention that the buffer is the >> fixed memory allocation (hardware or software), and the queue is the >> software construct within the buffer? > > The distinction would be an interesting one to make, but hasn't > horse bolted on this many years ago? IMO, there's lots of history > behind the notion that a buffer is the space used to absorb > transient overloads (regardless of how implemented) and a queue > is a either a synonym for buffer or a particular subset (e.g. a > FIFO buffer). > > cheers, > gja > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From garmitage@swin.edu.au Fri Jul 12 02:31: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 4003821F9C6C for ; Fri, 12 Jul 2013 02:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 b0cknw6OXgUb for ; Fri, 12 Jul 2013 02:31:31 -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 97E3421F9B80 for ; Fri, 12 Jul 2013 02:31:25 -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 r6C9V4ZS013563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 19:31:20 +1000 Message-ID: <51DFCCD8.604@swin.edu.au> Date: Fri, 12 Jul 2013 19:31:04 +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: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> <51DF9DE7.4030103@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 09:31:35 -0000 On 07/12/2013 16:43, gorry@erg.abdn.ac.uk wrote: > I think Bob's proposal is a useful one as we move to active queue management. > > I suspect we will need to make the distinction between the two terms > every document / presentation though to make sure people see the > distinction. Conceded. Certainly worth trying if it helps clarity of understanding. I was primarily wondering if trying to say "..the buffer is the fixed memory allocation..." stands much chance against years of classroom dialogue like "What does a queue do? It provides buffering....". But I don't hold a strong opinion wrt the proposed charter wording on this point. cheers, gja > > Gorry > >> >> >> On 07/12/2013 11:56, Bob Briscoe wrote: >> [..] >>> 3/ "routers, ... include buffers or queues" Buffers and queues are >>> not members of the same set (IMO). I don't think this is a picky >>> terminology point. Can we adopt the convention that the buffer is the >>> fixed memory allocation (hardware or software), and the queue is the >>> software construct within the buffer? >> >> The distinction would be an interesting one to make, but hasn't >> horse bolted on this many years ago? IMO, there's lots of history >> behind the notion that a buffer is the space used to absorb >> transient overloads (regardless of how implemented) and a queue >> is a either a synonym for buffer or a particular subset (e.g. a >> FIFO buffer). >> >> cheers, >> gja >> >> _______________________________________________ >> 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 > -- Professor Grenville Armitage Director, Centre for Advanced Internet Architectures Faculty of Information and Communication Technologies Swinburne University of Technology, Australia http://caia.swin.edu.au From swb@internet2.edu Fri Jul 12 06:16: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 90D6B21F9BFF for ; Fri, 12 Jul 2013 06:16: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 wnQIHw+Ax845 for ; Fri, 12 Jul 2013 06:15:57 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1090421F9C0F for ; Fri, 12 Jul 2013 06:15:57 -0700 (PDT) Received: from mail95-db9-R.bigfish.com (10.174.16.234) by DB9EHSOBE020.bigfish.com (10.174.14.83) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 13:15:55 +0000 Received: from mail95-db9 (localhost [127.0.0.1]) by mail95-db9-R.bigfish.com (Postfix) with ESMTP id B749630054B; Fri, 12 Jul 2013 13:15:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0811HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -13 X-BigFish: S-13(zzbb2dI98dI1432Izz1f42h1d77h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah8275dhz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1b1cn1b1bi1155h) Received: from mail95-db9 (localhost.localdomain [127.0.0.1]) by mail95-db9 (MessageSwitch) id 137363495452212_5003; Fri, 12 Jul 2013 13:15:54 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.242]) by mail95-db9.bigfish.com (Postfix) with ESMTP id F268760049; Fri, 12 Jul 2013 13:15:53 +0000 (UTC) Received: from BY2PRD0811HT001.namprd08.prod.outlook.com (157.56.237.5) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 12 Jul 2013 13:15:47 +0000 Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.91.164) with Microsoft SMTP Server (TLS) id 14.16.329.3; Fri, 12 Jul 2013 13:15:44 +0000 Message-ID: <51E0017E.40200@internet2.edu> Date: Fri, 12 Jul 2013 09:15:42 -0400 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bob Briscoe References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <20130506191725.GV23227@verdi> <6CCF558E-975C-4C86-9D67-CA431CC6FBA1@ifi.uio.no> <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> In-Reply-To: <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> 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 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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: Fri, 12 Jul 2013 13:16:02 -0000 On 07/11/13 21:22, Bob Briscoe allegedly wrote: > Fred, > > At 15:00 06/05/2013, 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. > > I'm not as much a fan of recommendation #4 as everyone else seems to be. > I think it's a wordsmithing issue, not fundamental. > > I suggest wording such as: "AQMs SHOULD allow congestion controls to > remain as effective as they are with other widely accepted AQMs or with > tail drop." > > Reasoning: An AQM can't be effective with all transports, because > congestion control is achieved by the e2e transport, not the AQM alone. Bob, that's the meaning of SHOULD: do it ... unless there's a good reason why not (and explain why not). Different transports use different algorithms. Your rephrasing looks to be closer to a MUST. > "All transports" includes: > * unresponsive transports that aren't trying to be effective, > * and delay-based transports like VEGAS & LEDBAT that don't work well in > some circumstances. To the extent that AQM applies, it should be effective. If it's not relevant, then that's a good reason not to, i.e. "SHOULD" applies. > The suggested wording makes it clear we're talking about criteria for > testing AQMs against transports that we already know are able to be > effective. Not about the AQM forcing a 'normal' congestion control > behaviour even if the congestion control doesn't want to play, or > 'normal' has been redefined. > > The reason I care about the wording here is that some may read this as a > licence to include per-flow rate policing within the AQM (cf AFD, > XCHOKe, etc). I strongly believe that per-flow rate policers SHOULD NOT > be in /every/ AQM. Is this a slippery slope argument? If we allow it at all it will infect everything and ruin our great nation? I don't believe this group is going to agree on a single algorithm. :-) Scott From wes@mti-systems.com Fri Jul 12 07:42:21 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 3584421F9BD8 for ; Fri, 12 Jul 2013 07:42:21 -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 p1S-Du7RNpVO for ; Fri, 12 Jul 2013 07:42:15 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 539D121F91CC for ; Fri, 12 Jul 2013 07:42:15 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6CEgDqe018898 for ; Fri, 12 Jul 2013 10:42:13 -0400 Received: (qmail 9960 invoked by uid 0); 12 Jul 2013 14:42:13 -0000 X-TCPREMOTEIP: 107.46.120.178 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.120.178) by 0 with ESMTPA; 12 Jul 2013 14:42:12 -0000 Message-ID: <51E015AE.8080006@mti-systems.com> Date: Fri, 12 Jul 2013 10:41:50 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: grenville armitage References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> <51DF9DE7.4030103@swin.edu.au> <51DFCCD8.604@swin.edu.au> In-Reply-To: <51DFCCD8.604@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: aqm@ietf.org Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 14:42:21 -0000 On 7/12/2013 5:31 AM, grenville armitage wrote: > > > On 07/12/2013 16:43, gorry@erg.abdn.ac.uk wrote: >> I think Bob's proposal is a useful one as we move to active queue >> management. >> >> I suspect we will need to make the distinction between the two terms >> every document / presentation though to make sure people see the >> distinction. > > Conceded. Certainly worth trying if it helps clarity of understanding. > I was primarily wondering if trying to say "..the buffer is the fixed > memory allocation..." stands much chance against years of classroom > dialogue like "What does a queue do? It provides buffering....". But > I don't hold a strong opinion wrt the proposed charter wording on > this point. > I think I agree. This is definitely a good idea to make clear in a "terminology" section or something in one of our WG documents, if we then use the words consistently following that, but given that the existing documentation in the field muddles terms, it only makes sense for the charter to define and use them with precision, if it makes a difference to the scoping and understanding of the work. That said ... in the next revision, we should try to use the right words in relevant places, but I don't think the charter is the place we want to carve any terminology in stone. -- Wes Eddy MTI Systems From bob.briscoe@bt.com Fri Jul 12 09:43: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 41C0021F9F75 for ; Fri, 12 Jul 2013 09:43:27 -0700 (PDT) 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=[AWL=0.000, 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 qg8Nr00Lf20u for ; Fri, 12 Jul 2013 09:43:20 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 99EBF21F9F77 for ; Fri, 12 Jul 2013 09:43:19 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 17:43:14 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 17:43:17 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 17:43:14 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.38.68]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6CGh8uS029097; Fri, 12 Jul 2013 17:43:09 +0100 Message-ID: <201307121643.r6CGh8uS029097@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 17:43:08 +0100 To: Scott Brim From: Bob Briscoe In-Reply-To: <51E0017E.40200@internet2.edu> References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <20130506191725.GV23227@verdi> <6CCF558E-975C-4C86-9D67-CA431CC6FBA1@ifi.uio.no> <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> <51E0017E.40200@internet2.edu> 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: "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: Fri, 12 Jul 2013 16:43:27 -0000 Scott, I think you get the point I'm making. It's only to ensure the word-smithing doesn't get misinterpreted in the future. Not the end of the world. Bob At 14:15 12/07/2013, Scott Brim wrote: >On 07/11/13 21:22, Bob Briscoe allegedly wrote: > > Fred, > > > > At 15:00 06/05/2013, 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. > > > > I'm not as much a fan of recommendation #4 as everyone else seems to be. > > I think it's a wordsmithing issue, not fundamental. > > > > I suggest wording such as: "AQMs SHOULD allow congestion controls to > > remain as effective as they are with other widely accepted AQMs or with > > tail drop." > > > > Reasoning: An AQM can't be effective with all transports, because > > congestion control is achieved by the e2e transport, not the AQM alone. > >Bob, that's the meaning of SHOULD: do it ... unless there's a good >reason why not (and explain why not). Different transports use >different algorithms. Your rephrasing looks to be closer to a MUST. > > > "All transports" includes: > > * unresponsive transports that aren't trying to be effective, > > * and delay-based transports like VEGAS & LEDBAT that don't work well in > > some circumstances. > >To the extent that AQM applies, it should be effective. If it's not >relevant, then that's a good reason not to, i.e. "SHOULD" applies. > > > The suggested wording makes it clear we're talking about criteria for > > testing AQMs against transports that we already know are able to be > > effective. Not about the AQM forcing a 'normal' congestion control > > behaviour even if the congestion control doesn't want to play, or > > 'normal' has been redefined. > > > > The reason I care about the wording here is that some may read this as a > > licence to include per-flow rate policing within the AQM (cf AFD, > > XCHOKe, etc). I strongly believe that per-flow rate policers SHOULD NOT > > be in /every/ AQM. > >Is this a slippery slope argument? If we allow it at all it will infect >everything and ruin our great nation? I don't believe this group is >going to agree on a single algorithm. :-) > >Scott ________________________________________________________________ Bob Briscoe, BT From bob.briscoe@bt.com Fri Jul 12 09:59:31 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 AA73321F9F53 for ; Fri, 12 Jul 2013 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 weuGO9kIt3I3 for ; Fri, 12 Jul 2013 09:59:26 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 584AC21F9E71 for ; Fri, 12 Jul 2013 09:59:18 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 17:59:13 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 17:59:16 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 17:59:16 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.38.68]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6CGxD5C029145; Fri, 12 Jul 2013 17:59:13 +0100 Message-ID: <201307121659.r6CGxD5C029145@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 17:59:13 +0100 To: Dave Taht From: Bob Briscoe In-Reply-To: References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_880175378==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Wesley Eddy , Gorry Fairhurst , "aqm@ietf.org" , Jim Gettys , David Ros Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 16:59:31 -0000 --=====================_880175378==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dave, One or two clarifications inline... At 03:12 12/07/2013, Dave Taht wrote: >On Thu, Jul 11, 2013 at 6:56 PM, Bob Briscoe wrote: > > 5/ I suggest the enumerated bullets are changed to those below: > > > > "The Active Queue Management and Packet Scheduling working group > > works on algorithms for proactively managing queues in > > order to: > > > > (1) Minimise standing queues > > > > (2) help flow sources control their sending rates without unnecessary > > losses, e.g. through ECN > >I really remain dubious about usage of ECN on the world wide internet. >If deployed widely, attacks will widely use it. > > > (3) help minimize delays for interactive applications > > > > (4) /consider the merits of various techniques/ to protect flows from > > negative impacts of other more > > aggressive or misbehaving flows > > > > Reasoning: > > > > ECN: The original text was: > > "(1) help flow sources control their sending rates before the > > onset of necessary losses, e.g. through ECN" > > is not accepted wisdom. What's written in RFC3168 makes sense: that marking > > for ECN traffic has to start at exactly the same point as loss for non-ECN > > traffic. Otherwise ECN traffic starves itself. Certainly, under v > heavy load > > everyone has to take losses, whether ECN or not, but I don't think that's > > what you're talking about here. > > > > Protecting flows: > > The question of whether/how to recommend flow isolation or not is part of > > chartered work - the outcome shouldn't be prejudged in the charter. > >I'm a little vague on your intent here. I've suggested adding the words "consider the merits of various techniques" in front of "protect flows from negative impacts of other more aggressive or misbehaving flows" This is a minefield, so the charter has to tread carefully, that's all. > > 7/ " The working group will not make changes to ECN, DiffServ, or other > > IETF protocols, though existing ECN, DiffServ, and other mechanisms > > may be used within the algorithms proposed. > > " > > Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly > > any such changes will need to be co-ordinated with the AQM WG, given the > > code is likely to be entwined with AQM code. > >I'm not sure that this scope needs to be so limited here. For ADs & chairs to discuss. I'm just trying to make the issue of WG demarcation explicit. > > 9/ Gap in charter coverage? [snip] > > We have found that with multiple real-time video streams, they all have > > highly variable rates, so they multiplex really well together in a FIFO. > > However, if you put them through FQ or WRR, they all get forced into ruts > > that are always the wrong size for all of them. This isn't a problem if the > > sum is not often close to capacity (which is why SFQ can appear to be OK > > with multiple videos). However, the whole point of isolation is to protect > > flows when the system /is/ close to capacity. > >Cite? Not that I disagree, I've been ramping up at looking hard at >webrtc behavior of late, just that most of my foci are focused on web, >voip, and gaming traffic on the edge to date.. Citations below. However, none of these papers talks about the problems they encountered when trying to go live with the technology. They had to give up because WRR in production networks completely unwound the 205% multiplexing efficiency they achieved between video streams. http://www.bobbriscoe.net/projects/refb/#Weighted_andor_Proportionally_Fair: The three under Equitable quality streaming (it wasn't even real-time in their case): * Mulroy, P., Appleby, S., Nilsson, M. & Crabtree, B., "The Use of MulTCP for the Delivery of Equitable Quality Video," In: Proc. Int'l Packet Video Wkshp (PV'09) IEEE (May 2009) * Crabtree, B., Nilsson, M., Mulroy, P. & Appleby, S., "Equitable quality video streaming over DSL," In: Proc. Int'l Packet Video Wkshp (PV'09) IEEE (May 2009) * Nilsson, M., Crabtree, B., Mulroy, P. & Appleby, S., "Equitable quality video streaming for IP networks," International Journal of Internet Protocol Technology 4(1):65--76 (March 2009) DOI: 10.1504/IJIPT.2009.024171 Bob ________________________________________________________________ Bob Briscoe, BT --=====================_880175378==.ALT Content-Type: text/html; charset="us-ascii" Dave,

One or two clarifications inline...

At 03:12 12/07/2013, Dave Taht wrote:
On Thu, Jul 11, 2013 at 6:56 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:
> 5/ I suggest the enumerated bullets are changed to those below:
>
> "The Active Queue Management and Packet Scheduling working group
>   works on algorithms for proactively managing queues in
>   order to:
>
>   (1) Minimise standing queues
>
>   (2) help flow sources control their sending rates without unnecessary
>   losses, e.g. through ECN

I really remain dubious about usage of ECN on the world wide internet.
If deployed widely, attacks will widely use it.

>   (3) help minimize delays for interactive applications
>
>   (4) /consider the merits of various techniques/ to protect flows from
> negative impacts of other more
>   aggressive or misbehaving flows
>
> Reasoning:
>
> ECN: The original text was:
> "(1) help flow sources control their sending rates before the
>   onset of necessary losses, e.g. through ECN"
> is not accepted wisdom. What's written in RFC3168 makes sense: that marking
> for ECN traffic has to start at exactly the same point as loss for non-ECN
> traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy load
> everyone has to take losses, whether ECN or not, but I don't think that's
> what you're talking about here.
>
> Protecting flows:
> The question of whether/how to recommend flow isolation or not is part of
> chartered work - the outcome shouldn't be prejudged in the charter.

I'm a little vague on your intent here.

I've suggested adding the words "consider the merits of various techniques" in front of "protect flows from negative impacts of other more aggressive or misbehaving flows"

This is a minefield, so the charter has to tread carefully, that's all.

> 7/ "  The working group will not make changes to ECN, DiffServ, or other
>   IETF protocols, though existing ECN, DiffServ, and other mechanisms
>   may be used within the algorithms proposed.
> "
> Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly
> any such changes will need to be co-ordinated with the AQM WG, given the
> code is likely to be entwined with AQM code.

I'm not sure that this scope needs to be so limited here.

For ADs & chairs to discuss. I'm just trying to make the issue of WG demarcation explicit.

> 9/ Gap in charter coverage?

[snip]

> We have found that with multiple real-time video streams, they all have
> highly variable rates, so they multiplex really well together in a FIFO.
> However, if you put them through FQ or WRR, they all get forced into ruts
> that are always the wrong size for all of them. This isn't a problem if the
> sum is not often close to capacity (which is why SFQ can appear to be OK
> with multiple videos). However, the whole point of isolation is to protect
> flows when the system /is/ close to capacity.

Cite? Not that I disagree, I've been ramping up at looking hard at
webrtc behavior of late, just that most of my foci are focused on web,
voip, and gaming traffic on the edge to date..

Citations below. However, none of these papers talks about the problems they encountered when trying to go live with the technology. They had to give up because WRR in production networks completely unwound the 205% multiplexing efficiency they achieved between video streams.

http://www.bobbriscoe.net/projects/refb/#Weighted_andor_Proportionally_Fair :
The three under Equitable quality streaming (it wasn't even real-time in their case):
Bob


________________________________________________________________
Bob Briscoe,                                                  BT --=====================_880175378==.ALT-- From bob.briscoe@bt.com Fri Jul 12 10:08:57 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 2A4EC11E812D for ; Fri, 12 Jul 2013 10:08:57 -0700 (PDT) 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=[AWL=0.000, 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 cFn1aENi4I97 for ; Fri, 12 Jul 2013 10:08:51 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3F71F21E80A1 for ; Fri, 12 Jul 2013 10:08:46 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 18:08:42 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 18:08:44 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 18:08:41 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.38.68]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6CH8cSI029184; Fri, 12 Jul 2013 18:08:39 +0100 Message-ID: <201307121708.r6CH8cSI029184@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 18:08:39 +0100 To: "Rong Pan (ropan)" From: Bob Briscoe In-Reply-To: References: <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 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: Fri, 12 Jul 2013 17:08:57 -0000 Rong, OK, correction accepted. Bob At 02:45 12/07/2013, Rong Pan (ropan) wrote: >Please see inline=8A. > >On 7/12/13 9:22 AM, "Bob Briscoe" wrote: > > >Fred, > > > >At 15:00 06/05/2013, 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. > > > >I'm not as much a fan of recommendation #4 as > >everyone else seems to be. I think it's a wordsmithing issue, not > >fundamental. > > > >I suggest wording such as: "AQMs SHOULD allow > >congestion controls to remain as effective as > >they are with other widely accepted AQMs or with tail drop." > > > >Reasoning: An AQM can't be effective with all > >transports, because congestion control is > >achieved by the e2e transport, not the AQM alone. "All transports" > >includes: > >* unresponsive transports that aren't trying to be effective, > >* and delay-based transports like VEGAS & LEDBAT > >that don't work well in some circumstances. > > > >The suggested wording makes it clear we're > >talking about criteria for testing AQMs against > >transports that we already know are able to be > >effective. Not about the AQM forcing a 'normal' > >congestion control behaviour even if the > >congestion control doesn't want to play, or 'normal' has been redefined. > > > >The reason I care about the wording here is that > >some may read this as a licence to include > >per-flow rate policing within the AQM (cf AFD, > >XCHOKe, etc). I strongly believe that per-flow > >rate policers SHOULD NOT be in /every/ AQM. > > > >AFD (and similar algos) still wrongly hit more > >recent hi-performance transports like Cubic > >because it is so much faster than lame Reno > >transports, even tho the Reno transports wouldn't > >be able to use the extra capacity. > > >There might be some misunderstanding about AFD. AFD that is implemented in >Cisco products is not per-flow rate policing. It is class based. Also, AFD >would not enforce fair rate among different classes. If a class does not >use up its share, the extra share would go to other queues. So in your >example of Cubic and Reno, I don't think there would be an issue. > > >Regards, > >Rong > > > > > > > >If an operator wants to deploy this flow-policing > >(please no), it is sufficient to have one on each > >path, at a 'customer edge' node, deployed as part > >of per-customer policy. Then there's a chance > >they can be turned off once the operator > >recognises they aren't helping. If we're > >successful enough to get AQM in every queue in > >the Internet, I don't want that to mean we've > >also got per-flow policers embedded in every > >queue too. Then, we're stuffed for future flexibility. > > > > > >Bob > > > >At 20:36 06/05/2013, Michael Welzl wrote: > > > >>On May 6, 2013, at 9:17 PM, John Leslie wrote: > >> > >> > 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=8A > >> > >>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." > >> > > >> > 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 > >> > >>_______________________________________________ > >>aqm mailing list > >>aqm@ietf.org > >>https://www.ietf.org/mailman/listinfo/aqm > > > >________________________________________________________________ > >Bob Briscoe, BT > > > >_______________________________________________ > >aqm mailing list > >aqm@ietf.org > >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT=20 From bob.briscoe@bt.com Fri Jul 12 10:29: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 44DF811E811E for ; Fri, 12 Jul 2013 10:29:04 -0700 (PDT) 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=[AWL=0.000, 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 EDpefhAWAiSs for ; Fri, 12 Jul 2013 10:28:58 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id A625C11E80FE for ; Fri, 12 Jul 2013 10:28:57 -0700 (PDT) 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.297.1; Fri, 12 Jul 2013 18:28:53 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 18:28:55 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 18:28:44 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.38.68]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6CHSgvq029224; Fri, 12 Jul 2013 18:28:42 +0100 Message-ID: <201307121728.r6CHSgvq029224@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 18:28:42 +0100 To: Dave Taht From: Bob Briscoe In-Reply-To: References: <8C48B86A895913448548E6D15DA7553B81F454@xmb-rcd-x09.cisco.com> <201307120128.r6C1Save026348@bagheera.jungle.bt.co.uk> 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: "Fred Baker \(fred\)" , "aqm@ietf.org" Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #1 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, 12 Jul 2013 17:29:04 -0000 Dave, At 02:49 12/07/2013, Dave Taht wrote: >Since this is a rollup email, this is a rollup in response. > >On Thu, Jul 11, 2013 at 6:28 PM, Bob Briscoe wrote: > > #3 Active Queue Management algorithms deployed SHOULD NOT require > > operational tuning > > Agree > >Agree, but I'd capitalize the REQUIRE bit, in that everything in this >world can benefit from a little tuning here and there... > >as one major example, which is in conflict with your byte-congest >draft, using a smaller quantum than the default helps on asymmetric >links in fq_codel (and pie uses a probalistic drop mechanism also >based on packet size). The smaller quantum thing has been well proven >to work on multiple shapers/schedulers going back to wondershaper. Pls elucidate or cite. INsufficient detail to understand. I thought I knew what a quantum was in a scheduler, but in these sentences I'm wondering whether you're talking about something else. > > (and see same note to Dave Taht wherein I said time as a queue threshold is > > not sufficient to get a tick in the auto-tuning box - responsiveness of the > > algo also needs to depend on how bad the queue is getting) > >The sqrt->linear drop approach is tcp friendly and currently works >well on a wide range of RTTs. It certainly seems like a worthwhile >research effort to measure and act on the slope of the curve, both up >and down, in a codel variant, in order to get better results faster. I've transferred this response over to the separate thread specifically about this (rec #2), as I think my points have been missed. >And the results of the hybrid fq_codel are interesting in that >perspective as flows do affect one another, particularly in steady >state. Right now a drop in one queue can be followed quickly by a drop >in another queue (at steady state), and that could be randomized >somewhat or fed into a feedback mechanism also. > >I do show this behavior on the rrul vs web traffic benchmark on the >slidesets I've been showing. Note that steady state is something of a >rarity outside of benchmarks. > >another thought is to periodically perturb the flow list. sigh. more research. Bob ________________________________________________________________ Bob Briscoe, BT From gorry@erg.abdn.ac.uk Fri Jul 12 11:23: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 65A0E21E80A8 for ; Fri, 12 Jul 2013 11:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.52 X-Spam-Level: X-Spam-Status: No, score=-105.52 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 zDiStVTsncQ8 for ; Fri, 12 Jul 2013 11:23:49 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD6321E80A5 for ; Fri, 12 Jul 2013 11:23:49 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 64B452B44BA; Fri, 12 Jul 2013 19:23:47 +0100 (BST) Received: from [10.10.10.79] (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPA id E37B82B44A7; Fri, 12 Jul 2013 19:23:45 +0100 (BST) References: <51DE398B.2090103@mti-systems.com> <91b91547d0e717bf6376929bb55bf81f.squirrel@www.erg.abdn.ac.uk> <02FA5F0F-C331-4000-A716-D074734F56D0@telecom-bretagne.eu> <201307120156.r6C1uCC8026410@bagheera.jungle.bt.co.uk> <201307121659.r6CGxD5C029145@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <201307121659.r6CGxD5C029145@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <971A60B9-4C72-4E2C-B7FF-B424E5962C13@erg.abdn.ac.uk> X-Mailer: iPad Mail (10B329) From: Gorry Date: Fri, 12 Jul 2013 19:23:49 +0100 To: Bob Briscoe Cc: Wesley Eddy , David Ros , Jim Gettys , Dave Taht , "aqm@ietf.org" Subject: Re: [aqm] updated 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: Fri, 12 Jul 2013 18:23:55 -0000 On this point - I agree with Bob.=20 I think diffserv and ECN changes really should be done in TSVWG. Gorry Sent from my iPad On 12 Jul 2013, at 17:59, Bob Briscoe wrote: >> > Add: The proper place for changes to ECN & Diffserv is TSVWG, but clear= ly >> > any such changes will need to be co-ordinated with the AQM WG, given th= e >> > code is likely to be entwined with AQM code. >>=20 >> I'm not sure that this scope needs to be so limited here. >=20 > For ADs & chairs to discuss. I'm just trying to make the issue of WG demar= cation explicit. From bob.briscoe@bt.com Fri Jul 12 11:27: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 7729221F9E7D for ; Fri, 12 Jul 2013 11:27:16 -0700 (PDT) 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=[AWL=0.000, 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 jpIjlBVCSg44 for ; Fri, 12 Jul 2013 11:27:10 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB0921F93F3 for ; Fri, 12 Jul 2013 11:27:09 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 19:27:00 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 19:27:03 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 19:27:02 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.38.68]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6CIR019029342; Fri, 12 Jul 2013 19:27:00 +0100 Message-ID: <201307121827.r6CIR019029342@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 19:27:00 +0100 To: Dave Taht , "Fred Baker (fred)" From: Bob Briscoe In-Reply-To: <8C48B86A895913448548E6D15DA7553B93913E@xmb-rcd-x09.cisco.c om> References: <8C48B86A895913448548E6D15DA7553B82A5E5@xmb-rcd-x09.cisco.com> <517FF171.4010306@mti-systems.com> <201307120015.r6C0FnT7026110@bagheera.jungle.bt.co.uk> <8C48B86A895913448548E6D15DA7553B93913E@xmb-rcd-x09.cisco.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: Wesley Eddy , "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: Fri, 12 Jul 2013 18:27:16 -0000 Dave & Fred, (two birds in one posting) At 02:06 12/07/2013, Fred Baker (fred) wrote: >On Jul 11, 2013, at 5:15 PM, Bob Briscoe > wrote: > > > As an output of this proposed AQM WG, I would like to see advice > that says what auto-tuning means, not just the empty word > "auto-tuning", ie. not just using time as the unit of queuing, but > also an AQM should not take a hard-coded time to respond > irrespective of how much the queuing delay has grown. > >I'm all for that. Maybe we can get the WG, if there is one, to add a >document describing that, or add text to the AQM recommendation. >Suggest text/approach? > >I'd suggest perhaps discussing this in Berlin. Fred, Altho I said it originally, I'm not sure how much we can or should write down about the basic art of controlling stuff. A standards body is good for people who want to check that product X has features a,b,&c. It's not necessarily the right place to write documents for Mr Brown in procurement to check that the subtleties of algorithm Y comply with articles d,e&f of control theory. >At 02:49 12/07/2013, Dave Taht wrote >[Bob Brisoe has copied this response across from another thread, >'cos it was written in response to this point about auto-tuning]: > >The sqrt->linear drop approach is tcp friendly and currently works >well on a wide range of RTTs. It certainly seems like a worthwhile >research effort to measure and act on the slope of the curve, both up >and down, in a codel variant, in order to get better results faster. Dave, Setting aside TCP-friendly for a minute, depending on the slope would be research yes. But let's get the basics first. The only thing that depends on queue delay (in the CoDel drop code I looked at) was when drop started and when it stopped. In between, the pattern of gaps between the drops was pre-ordained and hard coded. If the queue was growing ridiculously long (e.g. due to a flash crowd), CoDel still laboriously decreased the gap between each drop in its preordained pattern. I hope that's been improved in more recent CoDel code. This is the basic structure of an algo - I'd hardly even call it auto-tuning, it's about ensuring the intensity of the dropping within the algorithm depends on the effect it is trying to control. Similarly, the delay before dropping starts is completely independent of whether the queue has been slightly above 'target' for 'interval' or queue delay has headed off into the stratosphere during 'interval'. IOW, I would challenge that the very use of the min() function in CoDel is counter to auto-tuning (auto-controlling) principles. ________ Finally, I can't resist having a snipe at that TCP-friendly sentence. If you can justify it I would be most impressed. It looked like BS when I saw it in VJ/Nichols paper, and it still looks like BS. That sqrt is relative to the count of drops, which is nothing to do with the sqrt in the TCP formula. It's as likely to be related to mass-energy equivalence, because that's got a square term in it too. [Anyway, only Reno congestion window is proportional to 1/p^0.5. The cwnd of Cubic & Compound are proportional to 1/p^0.75 and 1/p^0.8 respectively.] Bob ________________________________________________________________ Bob Briscoe, BT From dave.taht@gmail.com Mon Jul 15 12:51:06 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 8F1C611E8233 for ; Mon, 15 Jul 2013 12:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.216, 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 ifWSGyZUl3x3 for ; Mon, 15 Jul 2013 12:51:04 -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 7217111E81F2 for ; Mon, 15 Jul 2013 12:51:04 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so26431678iea.39 for ; Mon, 15 Jul 2013 12:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KSrJa0nsIPxaREemtSq+BcT//BWgcjMmKkyBBQCHImA=; b=qW7hTxbtNhFfJl6NMQP3fGMLVGK9qtxkuNfvA1F2qmsX5qoRGqNI2VCkHAbq/H0UKc F37v0+OukXfNzsKp6vdBAFyucDVr7AjwJEI3HtUGbWYkjPcINr6od8lOZWHXH5WMv5Q+ GBiwZcguXikixl3HpyK3W0pcy+7kxmZHfWtNNgzbCaZk1L7mVkHMvV5/SnhIEuGzb2in IlpARQqxtH1edoy8crAwlS2BW52WR4LVldw6TQ6awQwBoSEp91FwKGrAy/D81ynz+NsO +MfEIu/fjrFPeld2h+VsiyO0RwIq3UVJ56vV4V1W2sALvaK8fQhAXOAmwVajy5YJjusx +RWg== MIME-Version: 1.0 X-Received: by 10.50.23.8 with SMTP id i8mr8032151igf.42.1373917862927; Mon, 15 Jul 2013 12:51:02 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Mon, 15 Jul 2013 12:51:02 -0700 (PDT) In-Reply-To: <201307121827.r6CIR019029342@bagheera.jungle.bt.co.uk> References: <8C48B86A895913448548E6D15DA7553B82A5E5@xmb-rcd-x09.cisco.com> <517FF171.4010306@mti-systems.com> <201307120015.r6C0FnT7026110@bagheera.jungle.bt.co.uk> <8C48B86A895913448548E6D15DA7553B93913E@xmb-rcd-x09.cisco.com> <201307121827.r6CIR019029342@bagheera.jungle.bt.co.uk> Date: Mon, 15 Jul 2013 15:51:02 -0400 Message-ID: From: Dave Taht To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wesley Eddy , "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: Mon, 15 Jul 2013 19:51:06 -0000 On Fri, Jul 12, 2013 at 2:27 PM, Bob Briscoe wrote: > Dave & Fred, (two birds in one posting) > > > At 02:06 12/07/2013, Fred Baker (fred) wrote: > >> On Jul 11, 2013, at 5:15 PM, Bob Briscoe >> wrote: >> >> > As an output of this proposed AQM WG, I would like to see advice that >> > says what auto-tuning means, not just the empty word "auto-tuning", ie= . not >> > just using time as the unit of queuing, but also an AQM should not tak= e a >> > hard-coded time to respond irrespective of how much the queuing delay = has >> > grown. >> >> I'm all for that. Maybe we can get the WG, if there is one, to add a >> document describing that, or add text to the AQM recommendation. Suggest >> text/approach? >> >> I'd suggest perhaps discussing this in Berlin. > > > Fred, Altho I said it originally, I'm not sure how much we can or should > write down about the basic art of controlling stuff. A standards body is > good for people who want to check that product X has features a,b,&c. It'= s > not necessarily the right place to write documents for Mr Brown in > procurement to check that the subtleties of algorithm Y comply with artic= les > d,e&f of control theory. > >> At 02:49 12/07/2013, Dave Taht wrote >> [Bob Brisoe has copied this response across from another thread, 'cos it >> was written in response to this point about auto-tuning]: >> >> The sqrt->linear drop approach is tcp friendly and currently works >> well on a wide range of RTTs. It certainly seems like a worthwhile >> research effort to measure and act on the slope of the curve, both up >> and down, in a codel variant, in order to get better results faster. > > > Dave, Setting aside TCP-friendly for a minute, depending on the slope wou= ld > be research yes. But let's get the basics first. The only thing that depe= nds > on queue delay (in the CoDel drop code I looked at) was when drop started > and when it stopped. In between, the pattern of gaps between the drops wa= s > pre-ordained and hard coded. It's subtle, but you'll notice the gap between restarting at a given drop r= ate is dynamic. This is the bit that searches for an ideal drop rate. This was heavily discussed towards the tail end of my stanford talk. > If the queue was growing ridiculously long > (e.g. due to a flash crowd), CoDel still laboriously decreased the gap > between each drop in its preordained pattern. "The queue". When you are using fair queuing "the queues", the "problematic queue" grows longer and is delayed more as it is interleaved with the other queues, thus the apparent drop rate on that flow increases not as a proportion of packets in the flow but as a proportion of the overall delays it is experiencing. > I hope that's been improved in more recent CoDel code. Codel doesn't stand alone. See last paragraph here: https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-= traditional-aqm-is-not-enough/ We've not said anything different... There are patches for various things floating around. In particular I have a version that is "tighter" but I fear it will perform badly at 1sec+ rtts. I'd like to consider ewma for managing the slope rather than the current strategy but am not there yet. I've been building up my lab to be able to look closely at longer RTT and videoconferencing issues in what we have so far. patches have been posted to the codel list. We are discussing now the nature of a more ideal replacement for the existing default queue discipline in linux, which has three fq_codel tiers in it (priority, best effort, and background) over there at the moment. Yep, further research is needed. > This is the basic > structure of an algo - I'd hardly even call it auto-tuning, it's about > ensuring the intensity of the dropping within the algorithm depends on th= e > effect it is trying to control. The goal of a queue is to absorb bursts. If it's possible within the target to drain that burst entirely, then dropping at a high rate is a bad idea. Codel will gently and eventually get there. So I agree with the statement it's about ensuring that the intensity of the dropping within the algorithm depending on the effect you are trying to control - in this case, signalling the other side of the flow to slow down with a drop or mark. ... but I'm pretty sure that's not what you meant. > Similarly, the delay before dropping starts is completely independent of > whether the queue has been slightly above 'target' for 'interval' or que= ue > delay has headed off into the stratosphere during 'interval'. IOW, As I described, yes, for certain values of stratosphere, a more robust drop= ping strategy should be tried. That said, the goal is to wait long enough for th= e signal to reach the other side... > I would > challenge that the very use of the min() function in CoDel is counter to > auto-tuning (auto-controlling) principles. > > ________ > Finally, I can't resist having a snipe at that TCP-friendly sentence. If = you > can justify it I would be most impressed. It looked like BS when I saw it= in > VJ/Nichols paper, and it still looks like BS. That sqrt is relative to th= e > count of drops, which is nothing to do with the sqrt in the TCP formula. > It's as likely to be related to mass-energy equivalence, because that's g= ot > a square term in it too. Heh. I'll leave it to kathie and van to defend their usage. I think "RTT-friendly" would have been more accurate, but that's not a defined term. Perhaps it should be? > > [Anyway, only Reno congestion window is proportional to 1/p^0.5. The cwnd= of > Cubic & Compound are proportional to 1/p^0.75 and 1/p^0.8 respectively.] > > > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From dave.taht@gmail.com Mon Jul 22 14:01:24 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 A113311E80E2 for ; Mon, 22 Jul 2013 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 zYUEI0JYazXx for ; Mon, 22 Jul 2013 14:01:24 -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 D332C21F8F07 for ; Mon, 22 Jul 2013 14:01:23 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id at20so5653852iec.28 for ; Mon, 22 Jul 2013 14:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cCoe0Pu1J414cJEw+i/lJ1xq51eQH+S2u3jk5O8K0ik=; b=v7mzokjpNkqkkPOMWn8AkTlXBDWNFelA3ZwOreaztc/IVjCv/9G+CTF1yKiteIjU2B eQLewaXcu2TCkld4aNq8kgOLc+w46mXNWJH3Vbh5FO/MY9t/4jHqE1vw6EI2xTxixaQ+ ZqWM3u96u1q/8GLJIcmHrB/lqnktBuXp1ew0a1HHkt0N9k1SxADknfqzCJZHfJdUhn9C NYBfdjEvuppKotrusRikx98JD4mYwR4dDLsNw7FZOFx/FMeUfoMDcuilBhOpVgJeWqO7 +/VHr87wIdyxgDfjmRreo5vW6LMkR9tC/mU8hCBzQkbiohTlGmO58xW1cTRZBPsbAaJ+ lR4Q== MIME-Version: 1.0 X-Received: by 10.43.133.70 with SMTP id hx6mr11855128icc.34.1374526883457; Mon, 22 Jul 2013 14:01:23 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Mon, 22 Jul 2013 14:01:23 -0700 (PDT) Date: Mon, 22 Jul 2013 14:01:23 -0700 Message-ID: From: Dave Taht To: bloat , aqm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [aqm] CS244's work on netflix streaming 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, 22 Jul 2013 21:01:24 -0000 I really love the work that stanford's CS244 does. I was reading this paper about netflix's "downward spiral" problem... http://www.stanford.edu/~huangty/imc012-huang.pdf When greg white pointed me at this wonderful followup: http://reproducingnetworkresearch.wordpress.com/2013/03/13/cs244-13-rising- from-the-depths-observing-and-implementing-improvements-in-online-video-bit rate-selection/ "The students' goal was to reproduce the research done in the Huang paper. What they found was that in the interim Netflix had fixed the problems outlined by Huang, so they reverse engineered the original Netflix rate adaptation algorithm, and then evaluated several new rate adaptation approaches. Cool stuff." Also the discussion of "remy" going on is pretty nifty. https://plus.google.com/u/0/103530621949492999968/posts/2L9e4kxo9y3 From dave.taht@gmail.com Mon Jul 22 14:54:56 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 94A5121F8D6D for ; Mon, 22 Jul 2013 14:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 ikSqCc9hm8CO for ; Mon, 22 Jul 2013 14:54:53 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C5C4421F89C3 for ; Mon, 22 Jul 2013 14:54:53 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so16576192iea.18 for ; Mon, 22 Jul 2013 14:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4fH6t1nfNLF6OAylUWje+uTzt3uDUb5vudBl/QyZcr0=; b=SwkvriS40w6WZU3AHx8k3BlKBV+ku8TJJ+g1X2F32ioMllnUUIGfHIY8JUiZQQrv7M NmJXv5iOsVWuqzIOoRDWrBpUsACvWMIObfMgkG2bvMJepgxcfMTwd3ia2Vy6z9yllxxc m3vlUqE3baCsyjb68BPBs4hVOX8WwbvmoGtVtX+NoWLU2cnsjtAuQNsyJYXTtAp1ueey okwkPDxbhKRph1tG9/G1/s0qvctT0fpRpZf5WOUu7CDO2bjQMeJwgMOlJlUeHDZHD+/O BOGl57ZVokvUhvvvmt6IHUCvzdFYN2b79J9bY6Xyp/hOGm5IOWZFWgr8zE909diXMYD6 5NOw== MIME-Version: 1.0 X-Received: by 10.50.50.202 with SMTP id e10mr11133980igo.54.1374530093298; Mon, 22 Jul 2013 14:54:53 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Mon, 22 Jul 2013 14:54:53 -0700 (PDT) In-Reply-To: <20130722212156.GA6511@thyrsus.com> References: <20130722212156.GA6511@thyrsus.com> Date: Mon, 22 Jul 2013 14:54:53 -0700 Message-ID: From: Dave Taht To: esr@thyrsus.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: aqm@ietf.org, bloat Subject: Re: [aqm] The Remy paper (was: Re: [Bloat] CS244's work on netflix streaming) 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, 22 Jul 2013 21:54:56 -0000 On Mon, Jul 22, 2013 at 2:21 PM, Eric S. Raymond wrote: > Dave Taht : >> Also the discussion of "remy" going on is pretty nifty. >> >> https://plus.google.com/u/0/103530621949492999968/posts/2L9e4kxo9y3 > > Thanks for that link. I've been mad curious what your tak on the Remy > paper was ever since I read it myself. Because while I didn't spot any > obvious bogons, you know the domain far better than I do. Well, it's a little presently computationally intensive for this decade... > The only thing about their methods that troubles me is a suspicion that t= he > generated algorithms might be overspecialized - that is, very vulnerable > to small changes in traffic statistics. They point that out too, in (for example) in fig 11. I LIKE fig 11, I keep thinking about it - although codel is designed to run against varying link rates, it makes sense to optimize for the most observed actual bandwidth, if possible, and this result shows that is possible. (if not understandable). So, what if you could generate a model showing your bandwidth range at location Z is X, optimize for that, download it and run it? I also like their presentation plot mechanism inverting the queue delay against throughput to make a "best" result up and to the right (see fig 4 and 5). I'll use this in future versions of rrul in particular. The thing is, we are exploring a very difficult subject (congestion control) with the equivalent of stone knives and bearskins. We have all this computing power lying around, serving ads! Why not use that in useful fashions? Take for comparison, the kind of work and compute resources that have been poured into physics and sigh. While they restrict their argument to e2e computation, the same techniques could apply to optimizing edge networks and interprovider interconnects, the core, calcuating better multi-path routing, and so on... for which running a model of existing traffic then implementing it and iterating fairly rapidly could be automated... I don't mind being obsoleted... "How should we design network protocols that free subnetworks and links to evolve freely, ensuring that the endpoints will adapt prop- erly no matter what the lower layers do? We believe that the best way to approach this question is to take the design of specific algo- rithmic mechanisms out of the hands of human designers (no matter how sophisticated!), and make the end-to-end algorithm be a func- tion of the desired overall behavior. " ... I'm unfond of how g+ (and now email) splits up a conversation, here's what I said on another thread of discussion: https://plus.google.com/u/0/107942175615993706558/posts/8MRTLpRyAju "My happiness at the paper is keyed on three factors: 1) identifying what a perfect algorithm could be like and the boundaries for it is inspiring as a goal, 2) and being able to study those results in search of inspiration... and 3) (if you didn't notice), just how well sfqcodel did across a wide range of benchmarks. No, it wasn't as good as specialized algos that took weeks of compute time, but it hit a sweet spot in most cases, and it ain't my fault cubic is so aggressive. I thought of the result as "kasperov vs deep blue", with clear win on the chess clock, to kasperov." (kasperov being kathie, van and eric) Now, I've been looking at bittorrent traffic of late - principal preliminary result is that traffic in slow start competes well with it, long duration traffic less so but still gets about double it's "fair share" (still don't understand the result) and under fq_codel to compete like that it drops a LOT of packets. > -- > Eric S. Raymond --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From esr@thyrsus.com Mon Jul 22 14:22: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 7784711E8150 for ; Mon, 22 Jul 2013 14:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] 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 8z2AdMFf4s3p for ; Mon, 22 Jul 2013 14:22:35 -0700 (PDT) Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2EE11E815E for ; Mon, 22 Jul 2013 14:22:34 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 1000) id 9D3AF40F29; Mon, 22 Jul 2013 17:21:56 -0400 (EDT) Date: Mon, 22 Jul 2013 17:21:56 -0400 From: "Eric S. Raymond" To: Dave Taht Message-ID: <20130722212156.GA6511@thyrsus.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 22 Jul 2013 17:23:14 -0700 Cc: aqm@ietf.org, bloat Subject: [aqm] The Remy paper (was: Re: [Bloat] CS244's work on netflix streaming) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: esr@thyrsus.com List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:22:39 -0000 Dave Taht : > Also the discussion of "remy" going on is pretty nifty. > > https://plus.google.com/u/0/103530621949492999968/posts/2L9e4kxo9y3 Thanks for that link. I've been mad curious what your tak on the Remy paper was ever since I read it myself. Because while I didn't spot any obvious bogons, you know the domain far better than I do. The only thing about their methods that troubles me is a suspicion that the generated algorithms might be overspecialized - that is, very vulnerable to small changes in traffic statistics. -- Eric S. Raymond From davec-b@rogers.com Tue Jul 23 05:30:59 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 4F43B11E80F1 for ; Tue, 23 Jul 2013 05:30:59 -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 b0wp-mk4GqHg for ; Tue, 23 Jul 2013 05:30:53 -0700 (PDT) Received: from nm23-vm5.access.bullet.mail.bf1.yahoo.com (nm23-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.164]) by ietfa.amsl.com (Postfix) with ESMTP id E416511E812A for ; Tue, 23 Jul 2013 05:30:51 -0700 (PDT) Received: from [66.196.81.166] by nm23.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jul 2013 12:30:48 -0000 Received: from [98.139.221.66] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jul 2013 12:30:48 -0000 Received: from [127.0.0.1] by smtp103.rog.mail.bf1.yahoo.com with NNFMP; 23 Jul 2013 12:30:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1374582648; bh=z4+uvNl+RLs9NAI0zvxIYefOIPWPprbjKTZPu3+t3gw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=Tz+k1C+EyCrOhWFr1P7MnrV/85yQWctXWsIWUdJbNzf2/98FKuPkGYIefnZPw7mPbXz45Nao2/SJeJUpajaYddZasD/80/uiiJz5BDufOmsYGsA4jxT/iybOOJzUX3f58J2+449dB/5jlNCMJDgx3PeR936LIPDGJu8r/jCrUfs= X-Yahoo-Newman-Id: 63091.19494.bm@smtp103.rog.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ag_Fp9QVM1l_nrV3Mw9u7Yy8vsNE6N5TyQyRfYQt4lvVhOx d7IL0w80El7Tq2.VikeRDhxz1frhow7lPTxWeJeos9yccjyhNlPg6KuCRmCZ j6xpys2t6bwlYlzdYnfN5Rdth0KLSFyoTcyZsDt7Kgx4xMIGMfEe3KT80EG9 FAxkoEl0PLQMLXIzJ_Yx56zXXTTpLclkuJN8yqMDE_mpqnM2wqLob8aduCSy Z15VBAHlfXfgOXC8rlPZR82KBlVivL9ICAIC2.dZ8dJ5vUXoTDUouuHh6onG a1Ek9fJqdtm5DxB1cryzdf3MdZOerr4EzJzDs.igDUrUZR_1VXr3fg9YXTK. UxIqKTuh71dX1uql8eq1Y.Mz9rdRMQoYustRDdu1LwZBemrLLpQIO0mhSFOF 3Pc31TDLBvvy1OWETQ6Zj3Wl81GKTY_yJgCLielaS4h0Om6cR9N5p9NqnEPa msFQWNQOBcgWwbThS4DqQdItkhB5ZaJh8NLkR2nVJFMrKGIxRlborvPga3sV CvSX8TVPhm80N8HipJDuyBOKIF0_.elBtGPzEytkuzuXQzyMFgcM9Mpufu5F ZclVGG7SA_gxAoEJs0.FDjVzFc1SEoFeMohn1ZEeYiCDy0NVuF2Z_wx6G3R_ 7ZJF8fQzETumTrv5AseRWfouH8NmxNCJV3JkdIDwoZOPT X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- X-Rocket-Received: from [10.111.100.153] (davec-b@74.213.188.46 with plain) by smtp103.rog.mail.bf1.yahoo.com with SMTP; 23 Jul 2013 05:30:47 -0700 PDT Message-ID: <51EE78FA.60201@rogers.com> Date: Tue, 23 Jul 2013 08:37:14 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: aqm@ietf.org References: <20130722212156.GA6511@thyrsus.com> In-Reply-To: <20130722212156.GA6511@thyrsus.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [aqm] The Remy paper X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: davecb@spamcop.net 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, 23 Jul 2013 13:43:27 -0000 It might be interesting to see if it generates a common family of algorithms, i.e., a family of curves, and what the parameters do to the curves. That then might be written as a single parameterized algorithm... --dave On 07/22/2013 05:21 PM, Eric S. Raymond wrote: > Dave Taht : >> Also the discussion of "remy" going on is pretty nifty. >> >> https://plus.google.com/u/0/103530621949492999968/posts/2L9e4kxo9y3 > Thanks for that link. I've been mad curious what your tak on the Remy > paper was ever since I read it myself. Because while I didn't spot any > obvious bogons, you know the domain far better than I do. > > The only thing about their methods that troubles me is a suspicion that the > generated algorithms might be overspecialized - that is, very vulnerable > to small changes in traffic statistics. -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain (416) 223-8968 From mcr@sandelman.ca Tue Jul 23 14:02: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 A2F4D11E82D6 for ; Tue, 23 Jul 2013 14:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 L712uEzjYXAV for ; Tue, 23 Jul 2013 14:02:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 40AC311E8152 for ; Tue, 23 Jul 2013 14:01:49 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 02F0520179; Tue, 23 Jul 2013 18:07:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1C8EA63A88; Tue, 23 Jul 2013 17:00:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EC22063A7C; Tue, 23 Jul 2013 17:00:12 -0400 (EDT) From: Michael Richardson To: Dave Taht In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Wed, 24 Jul 2013 06:23:35 -0700 Cc: aqm@ietf.org, bloat Subject: Re: [aqm] [Bloat] CS244's work on netflix streaming 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, 23 Jul 2013 21:02:17 -0000 After reading both papers, I think that the take home that I got is: As we show in this paper, the problem arises because it is hard to estimate bandwidth above TCP it seems that this is a service that TCP ought to be providing, and the conclusion says so. I think that it is an API issue, not a protocol issue. If TCP knows how big the window was, it knows how much data can reasonably have been sent, and since it also knows when it grew the window, it has some notion of how long the new data took to arrive. I think that the radical solution of not trying to estimate at all, but rather, to increase the rate when the buffer is full, is rather analogous to the bufferbloat problem: vendors increased the size of buffers, and allowed them to stay full, rather than decreased them until they they were underrunning. I'm curious to know what happens if the downlink to the client is bufferbloated. It seems that the long running flow ought to accumulate significant amount of traffic with the result that the video client will see a slow cwnd growth for each chunk that it requests. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From g2p.code@gmail.com Tue Jul 23 15:00: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 B6C8F11E82CF for ; Tue, 23 Jul 2013 15:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 R7n-LhcdqyM2 for ; Tue, 23 Jul 2013 15:00:44 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9F911E811D for ; Tue, 23 Jul 2013 15:00:44 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so7440580wgh.4 for ; Tue, 23 Jul 2013 15:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=wnnKnBMDsScdj8yYMhF6tzZ7kHehXGPmSn9r9SIGq5w=; b=hdWB+0wL54Rl8KkQ15ONlGv9bGy1QsrhFbRzMu7dkx9olKM7vKRYvFN5o0nx07RjGf xgSOR5GMiRQ50ItzMuJKqfznNBnG2v2qdZE6eVTNoxsSQLTy6H62Md1w4G3V96YQSV8a fKvH0IeRSuwk9FHGPZQjnUmXGkTtTRjxu+f45YBwNEKUZElBjegPZ9OrvPwW2hgCac+B zFE+Vzkc6V47Glu4DvT1C0aL7+Mm6TSiyv0q7AAbZbEKGygEjEdQ+P5thGA5p/bQ4HOD VigFVewb3PctD/OXV6WccnJ7f3ywGDhy8t1gNj5gk7EvsvZS2bvjARn7IllxZMx+SKJL DMBQ== X-Received: by 10.194.173.225 with SMTP id bn1mr24698458wjc.6.1374616842495; Tue, 23 Jul 2013 15:00:42 -0700 (PDT) Received: from ?IPv6:2a01:e35:8a2c:b230:c1a:e730:364e:ee53? ([2a01:e35:8a2c:b230:c1a:e730:364e:ee53]) by mx.google.com with ESMTPSA id nb12sm1274225wic.7.2013.07.23.15.00.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 15:00:41 -0700 (PDT) Message-ID: <51EEFD08.6080603@gmail.com> Date: Wed, 24 Jul 2013 00:00:40 +0200 From: Gabriel de Perthuis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: aqm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 24 Jul 2013 06:23:39 -0700 Subject: [aqm] Now on GMane 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, 23 Jul 2013 22:01:19 -0000 Hello, The aqm list just got added to GMane: http://dir.gmane.org/gmane.network.routing.aqm If someone with mailman access wants to import the archives, this can be done at http://gmane.org/import.php Thank you, From wes@mti-systems.com Mon Jul 29 05:43:01 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 2F01D21F8423 for ; Mon, 29 Jul 2013 05:43:01 -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 NRsqpL1-w-u4 for ; Mon, 29 Jul 2013 05:42:56 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66A21F942D for ; Mon, 29 Jul 2013 05:42:56 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6TCgsnf009681 for ; Mon, 29 Jul 2013 08:42:54 -0400 Received: (qmail 3263 invoked by uid 0); 29 Jul 2013 12:42:54 -0000 X-TCPREMOTEIP: 46.165.196.138 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?10.28.0.62?) (wes@mti-systems.com@46.165.196.138) by 0 with ESMTPA; 29 Jul 2013 12:42:53 -0000 Message-ID: <51F6633B.8000509@mti-systems.com> Date: Mon, 29 Jul 2013 08:42:35 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [aqm] AQM BoF - RTGAREA slides 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, 29 Jul 2013 12:43:01 -0000 As BoF chairs, we were asked to talk to the RTGAREA meeting at this week's IETF about the AQM BoF and what we're doing. The slides I'm planning to discuss there are: http://www.ietf.org/proceedings/87/slides/slides-87-aqm-3.pptx -- Wes Eddy MTI Systems From bob.briscoe@bt.com Mon Jul 29 09:59: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 949D621F9306 for ; Mon, 29 Jul 2013 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 j9d8W9Wcc32k for ; Mon, 29 Jul 2013 09:59:46 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 874CF21E80AF for ; Mon, 29 Jul 2013 09:51:46 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 29 Jul 2013 17:50:47 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 29 Jul 2013 17:50:47 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Mon, 29 Jul 2013 17:50:47 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.108.36]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6TGojBh009833; Mon, 29 Jul 2013 17:50:46 +0100 Message-ID: <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Jul 2013 17:50:44 +0100 To: Wesley Eddy From: Bob Briscoe In-Reply-To: <51F6633B.8000509@mti-systems.com> References: <51F6633B.8000509@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: "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 29 Jul 2013 17:00:00 -0000 Wes, #4 "Bufferbloat exists in routers, lower-layer switches, and other middleboxes " ...and hosts (altho not of such interest to RTG, this is also educating them on what we're doing) Gap: They wlil want to know whether we are talking about big iron routers, big iron switches, access nodes, home hubs, etc. So we need to say the problem is mainly in access and edge equipment but you see it everywhere. (They will want to know whether we are treading on what they perceive as their territory.) #5 "separation into multiple queues" implies particular solutions. I suggest you just say "traffic isolation". #9 The statements about RED are over-negative. It's not that it isn't an effective solution to bufferbloat if correctly configured (as all the tests so far have shown). It's that it's hard to configure. The charter reads to me is as much about advice on configuring existing stuff like RED, as it is about designing new stuff. We don't want to give the message "the only solution is to rip out everything you've already bought and buy this new stuff". HTH Bob At 13:42 29/07/2013, Wesley Eddy wrote: >As BoF chairs, we were asked to talk to the RTGAREA meeting >at this week's IETF about the AQM BoF and what we're doing. > >The slides I'm planning to discuss there are: >http://www.ietf.org/proceedings/87/slides/slides-87-aqm-3.pptx > >-- >Wes Eddy >MTI Systems >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT From spencerdawkins.ietf@gmail.com Mon Jul 29 10:28: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 B973411E8128 for ; Mon, 29 Jul 2013 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 R+c9VXA4hkNW for ; Mon, 29 Jul 2013 10:28:00 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F1E0B21E809A for ; Mon, 29 Jul 2013 10:22:31 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wy7so4921099pbc.17 for ; Mon, 29 Jul 2013 10:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=l3HzLFQ7bDVLy0+t2ydIYBOZk87FH/4a5B9g0gdmico=; b=sk3YQw9DYeWBMBaJJz1ugpXZw+k4xNQqBxI0arzHc346ysoU+hN06FQhN5NEQ80j8G UWqxAqe57c774Jg6vjaLOAHNSUzmZXy8odZLO5Qxo8bb7XkjIo0aA5J7ZB0LLl+WABTg Cjqntj27sY6y4A8tdjF1FRQzEtImfk748oaqqUiXN4Oql2N8b0JwBlJur38pJo9ugBN6 G0k8Hs9dRWPtN+1MgkEPwpEfgnfAgFpvvY8Pf6FMLZvKvSDW1aniPo3Ebfrl+75ShZcA bYJ5Igw6KmWLwQTTt6JkxzPtdX36ctkGPu0c/hSWB3ipp30MPSbmwqfjT/nejM5cYC2/ GqGg== X-Received: by 10.66.253.40 with SMTP id zx8mr70718902pac.71.1375118551035; Mon, 29 Jul 2013 10:22:31 -0700 (PDT) Received: from ?IPv6:2001:df8:0:64:6cc2:1816:867b:5a3? ([2001:df8:0:64:6cc2:1816:867b:5a3]) by mx.google.com with ESMTPSA id ry2sm77995715pbc.41.2013.07.29.10.22.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 10:22:30 -0700 (PDT) Message-ID: <51F6A4D1.2030606@gmail.com> Date: Mon, 29 Jul 2013 12:22:25 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Wesley Eddy References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> In-Reply-To: <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bob Briscoe , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 29 Jul 2013 17:28:02 -0000 On 7/29/2013 11:50 AM, Bob Briscoe wrote: > Wes, > > #4 "Bufferbloat exists in routers, lower-layer switches, and other > middleboxes " > ...and hosts (altho not of such interest to RTG, this is also > educating them on what we're doing) > > Gap: They wlil want to know whether we are talking about big iron > routers, big iron switches, access nodes, home hubs, etc. So we need > to say the problem is mainly in access and edge equipment but you see > it everywhere. (They will want to know whether we are treading on what > they perceive as their territory.) Wes, I liked the slides you've prepared. As a data point on #4, I had a very similar conversation with a co-worker for breakfast this morning. I'm pretty sure you'll get this as a question if you don't put it on your slides. Thanks, Spencer From gorry@erg.abdn.ac.uk Mon Jul 29 10:38:06 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 E49FF11E80FF for ; Mon, 29 Jul 2013 10:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.713 X-Spam-Level: X-Spam-Status: No, score=-105.713 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 nf5d-X31Dr9v for ; Mon, 29 Jul 2013 10:37:59 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id BC91D11E8109 for ; Mon, 29 Jul 2013 10:37:15 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 8E1302B44D7; Mon, 29 Jul 2013 18:37:14 +0100 (BST) Received: from [130.129.23.225] (dhcp-17e1.meeting.ietf.org [130.129.23.225]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPA id 95B8D2B4395; Mon, 29 Jul 2013 18:37:12 +0100 (BST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> From: Gorry Mime-Version: 1.0 (1.0) In-Reply-To: <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> Message-Id: <7B45DA7A-7080-4338-87C7-7ED34D394F9D@erg.abdn.ac.uk> Date: Mon, 29 Jul 2013 19:36:54 +0200 To: Bob Briscoe X-Mailer: iPad Mail (10B329) Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 29 Jul 2013 17:38:06 -0000 +1 on RED - I can't see why would be creating an impression the BOF is about= obsoleting RED, I hope it is actually about deploying AQM and understanding= how to make this work better and provide good tools - I had the feeling tha= t the text I read was a little negative, Gorry On 29 Jul 2013, at 12:50 PM, Bob Briscoe wrote: > Wes, >=20 > #4 "Bufferbloat exists in routers, lower-layer switches, and other middleb= oxes " > ...and hosts (altho not of such interest to RTG, this is also educating th= em on what we're doing) >=20 > Gap: They wlil want to know whether we are talking about big iron routers,= big iron switches, access nodes, home hubs, etc. So we need to say the prob= lem is mainly in access and edge equipment but you see it everywhere. (They w= ill want to know whether we are treading on what they perceive as their terr= itory.) >=20 > #5 "separation into multiple queues" implies particular solutions. I sugge= st you just say "traffic isolation". >=20 > #9 The statements about RED are over-negative. It's not that it isn't an e= ffective solution to bufferbloat if correctly configured (as all the tests s= o far have shown). It's that it's hard to configure. > The charter reads to me is as much about advice on configuring existing st= uff like RED, as it is about designing new stuff. We don't want to give the m= essage "the only solution is to rip out everything you've already bought and= buy this new stuff". >=20 > HTH >=20 >=20 > Bob >=20 >=20 >=20 > At 13:42 29/07/2013, Wesley Eddy wrote: >> As BoF chairs, we were asked to talk to the RTGAREA meeting >> at this week's IETF about the AQM BoF and what we're doing. >>=20 >> The slides I'm planning to discuss there are: >> http://www.ietf.org/proceedings/87/slides/slides-87-aqm-3.pptx >>=20 >> -- >> Wes Eddy >> MTI Systems >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >=20 > ________________________________________________________________ > Bob Briscoe, BT=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From dave.taht@gmail.com Mon Jul 29 11:41: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 5895121E808F for ; Mon, 29 Jul 2013 11:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 5kDZCnbtKb5g for ; Mon, 29 Jul 2013 11:41:52 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFB821E80A6 for ; Mon, 29 Jul 2013 11:41:50 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so4595670obp.22 for ; Mon, 29 Jul 2013 11:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KWuIEQleQf3xAi5m81w8qAbvBFLONcjZbPFPOaE+XSA=; b=W/m1MkA/eihHcAl14y7LAwWrsTd0PkVZmHEWxCo8hHI2+Bs9xLLlSjBtwBux0UZVvj CPrZvV6df+wQSpxJEF8CNWqq+KMITPFcGeBUa+9bFV/ZyoAiZdbdbc2abxz/ivbdTzCu GmeQ5gxbKfd7tQWLemqx7xDCNh6lo/ZVGrW3sHsODbCSvT919Px2dXtA4F+P7fC2wz9u AdXVzV/LryyI3PEDb28KIaAZojQ2wiUuSQVMsFv4fKYyHeryc5qlIb1pydFDCIFgbC07 55VUZ2AY79pQABsc15ADqtR3MxN7jFQzcjSK9COh+bMScWUu3hyTN2rgWPWs1z9VPFPz esQA== MIME-Version: 1.0 X-Received: by 10.50.23.8 with SMTP id i8mr1151627igf.42.1375123310130; Mon, 29 Jul 2013 11:41:50 -0700 (PDT) Received: by 10.64.62.106 with HTTP; Mon, 29 Jul 2013 11:41:50 -0700 (PDT) In-Reply-To: <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> Date: Mon, 29 Jul 2013 11:41:50 -0700 Message-ID: From: Dave Taht To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 29 Jul 2013 18:41:54 -0000 On Mon, Jul 29, 2013 at 9:50 AM, Bob Briscoe wrote: > Wes, > > #4 "Bufferbloat exists in routers, lower-layer switches, and other > middleboxes " > ...and hosts (altho not of such interest to RTG, this is also educating t= hem > on what we're doing) > > Gap: They wlil want to know whether we are talking about big iron routers= , > big iron switches, access nodes, home hubs, etc. So we need to say the > problem is mainly in access and edge equipment but you see it everywhere. > (They will want to know whether we are treading on what they perceive as > their territory.) > > #5 "separation into multiple queues" implies particular solutions. I sugg= est > you just say "traffic isolation". > > #9 The statements about RED are over-negative. It's not that it isn't an > effective solution to bufferbloat if correctly configured (as all the tes= ts > so far have shown). It's that it's hard to configure. It's not just that it's hard to configure. It's *impossible* to configure for links of wildly varying bandwidth such as wifi and other forms of wireless. RED was designed for fixed bandwidth p2p links, like what you got in the good ole days with a T1 line. Other forms of shared links (cable for example) also have varying link rates that are hard to respond to in RED. That said, I've got no problem with this wg generating clear guidelines on when and where and HOW to configure RED and other smarter queue management algorithms. > The charter reads to me is as much about advice on configuring existing > stuff like RED, as it is about designing new stuff. We don't want to give > the message "the only solution is to rip out everything you've already > bought and buy this new stuff". Seeing RED deployed more where it could matter (like interprovider interconnects and other fixed rate lines) would be a goodness. > HTH > > > Bob > > > > > At 13:42 29/07/2013, Wesley Eddy wrote: >> >> As BoF chairs, we were asked to talk to the RTGAREA meeting >> at this week's IETF about the AQM BoF and what we're doing. >> >> The slides I'm planning to discuss there are: >> http://www.ietf.org/proceedings/87/slides/slides-87-aqm-3.pptx >> >> -- >> Wes Eddy >> MTI Systems >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > 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 davec-b@rogers.com Mon Jul 29 12:34: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 F098E21F9C5A for ; Mon, 29 Jul 2013 12:34:37 -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 GWdw+FG3DuMI for ; Mon, 29 Jul 2013 12:34:31 -0700 (PDT) Received: from nm1-vm6.access.bullet.mail.gq1.yahoo.com (nm1-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.149]) by ietfa.amsl.com (Postfix) with ESMTP id 807D621F9B5B for ; Mon, 29 Jul 2013 12:33:39 -0700 (PDT) Received: from [216.39.60.172] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jul 2013 19:33:33 -0000 Received: from [67.195.22.106] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jul 2013 19:33:33 -0000 Received: from [127.0.0.1] by smtp102.rog.mail.gq1.yahoo.com with NNFMP; 29 Jul 2013 19:33:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1375126413; bh=Z2gUlf8ds5ECg9vIwac2Yo1Rbcpez0A640fBj8rOjRI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=OL8FEmL6cU1m2UrqcEP4S32AJzBEGTxd6bb8hAGgmKpFZbfGchPJyObI9uypEo/X+iwMnMvAk1Y+RRX15Z5DctQGTs9iuZ9hI38iXuI89qTrm8TbBFsodC4GXORRvXTDAIOByQwJTHkSObDli2VcyQSESm1sxiZ59f0mu4JN/IY= X-Yahoo-Newman-Id: 83082.87558.bm@smtp102.rog.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Ei8mMxEVM1nSCAdA2i2nwnKV.M7KYKJBAiik_dUFzuAt2Tf C6dQ8SKB4XeMKEG1THk_S03I6bTMYxU7SwcF4BwLKJcR.BNe4xccC7IDoMT0 FCfbbOzaSfMaoAzDaBmdSOaAVAHCux9EcfPAehrUsSoXvNXeKoSs3oDdzSPV 1HRaUAA7jgr8xeMILMBowNFB1Zu84JLtkMu5vM2SNg7JUurVyKvzfVy_p.on ezXXw6xFplR2aLcSzwguUFRmsgikmvmGC9ujx9rqhAgJixRJ.jMDgyO2y.6V u1sqZPp_32xZy_8OsalJCYCond5TuPfUDm9xRnGyGo0IubMyo.2ojgLkwEVq COFl72ChWzTVu53XM9BpO9TmkXSN8BEoSrzMfkICSm83DGZB0aRVsKTnoBxJ VyRkk7G7vH0f1FfB2kWVUxD93kYTfmEYrmaRrvRgplLf4yhi_7z7CkIGKtE. q9Xse11A7DcgqqJnn39Cf_h0xMwWGVIPJVZNqh35N.u8Yn9rcpIrcpKOeIPj Qa6JmvQ0rSP.SVWTIr7Bu7EN2IA-- X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- X-Rocket-Received: from [10.111.100.153] (davec-b@74.213.188.46 with plain) by smtp102.rog.mail.gq1.yahoo.com with SMTP; 29 Jul 2013 19:33:33 +0000 UTC Message-ID: <51F6C50F.4060308@rogers.com> Date: Mon, 29 Jul 2013 15:39:59 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: aqm@ietf.org References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> In-Reply-To: <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [aqm] AQM BoF - RTGAREA slides X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: davecb@spamcop.net 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, 29 Jul 2013 19:34:38 -0000 On 07/29/2013 12:50 PM, Bob Briscoe wrote: > Wes, > > #4 "Bufferbloat exists in routers, lower-layer switches, and other > middleboxes " > ...and hosts (altho not of such interest to RTG, this is also > educating them on what we're doing) > > Gap: They wlil want to know whether we are talking about big iron > routers, big iron switches, access nodes, home hubs, etc. So we need > to say the problem is mainly in access and edge equipment but you see > it everywhere. (They will want to know whether we are treading on what > they perceive as their territory.) It will occur wherever a slower-bandwidth link connects to a higher-bandwidth one, and will be most visible where the differences are substantial. A typical example might be at a home router, or at the interface between a fast machine-room backbone and a slow wide-area connection. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain (416) 223-8968 From michawe@ifi.uio.no Mon Jul 29 15:15: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 9EB7011E810E for ; Mon, 29 Jul 2013 15:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.036, 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 rALXxON+dQKn for ; Mon, 29 Jul 2013 15:15:13 -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 3BA5911E8128 for ; Mon, 29 Jul 2013 15:15:08 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V3vic-0005Bh-JM; Tue, 30 Jul 2013 00:15:06 +0200 Received: from [46.189.28.122] (helo=[10.25.11.80]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V3vic-0003ye-3a; Tue, 30 Jul 2013 00:15:06 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <51F6633B.8000509@mti-systems.com> Date: Tue, 30 Jul 2013 00:15:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1085EB97-75A1-407D-B8A5-7178C4931445@ifi.uio.no> References: <51F6633B.8000509@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 6182 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 788BD80C44A8C7F6BF45369630105CD77CDAC301 X-UiO-SPAM-Test: remote_host: 46.189.28.122 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 18 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 29 Jul 2013 22:15:17 -0000 Hi, I like the slides too, but I think that slide #5 should contain: - counteract synchronization This is in fact a goal of AQM that I had always considered to be one of = the key motivators behind RED (without that goal, it could probably have = just been ED instead :-) ). Somewhat strangely, this goal hasn't been = mentioned much recently. Is it just a simulation artifact? I don't think so. Yes we see it a lot = in simulations: http://www.icir.org/floyd/papers/phase.pdf but it also appears in reality: http://caia.swin.edu.au/pubs/ATNAC06/Jaym.pdf and it would surprise me greatly if it wasn't a much more significant = problem in more controlled environments, in particular data centers. Cheers, Michael On Jul 29, 2013, at 2:42 PM, Wesley Eddy wrote: > As BoF chairs, we were asked to talk to the RTGAREA meeting > at this week's IETF about the AQM BoF and what we're doing. >=20 > The slides I'm planning to discuss there are: > http://www.ietf.org/proceedings/87/slides/slides-87-aqm-3.pptx >=20 > --=20 > Wes Eddy > MTI Systems > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From spencerdawkins.ietf@gmail.com Mon Jul 29 15:32:13 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 ECAC621F9CCA for ; Mon, 29 Jul 2013 15:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 uo4PgB14bVnM for ; Mon, 29 Jul 2013 15:32:12 -0700 (PDT) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B4A9C21F9CC7 for ; Mon, 29 Jul 2013 15:32:11 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e52so1403526eek.2 for ; Mon, 29 Jul 2013 15:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=biqnnd2cN4/szUAzUa02icr3ogZ5qA7CKxy7R2Yl3Lo=; b=UxaLAUUC1rwP3Rhj/8apONwutJIHBoA2Jozz1CdPAHVcvy5fWIfobpsQKt5vtGZQQ8 XqNWOyTEPn/eiu65/TQVmQ8YjcQkDwRI0f6j4v8sn9Dr1Q4W+ZflbI5m31X1ScanqAgA WQXmM9830mGs7rSGfYV0ef0LHHzGvWT7CdGnIJD0Jn2I31ltGKWMqDmKhIK+/1go8VbD H20kuXV1t5K21JQSZLamdSuY3QPFosgaEFBJjSRuHVrJKfDwXHePm5bWn94Hvypu3aRd 6sSX2gF3YdnfvlU28C/ltGjAeJ9YJkQdqA2auoWR943MmxZNwRt9Dq+tfgRO/jvZCQm9 +h8Q== MIME-Version: 1.0 X-Received: by 10.15.52.5 with SMTP id o5mr62117387eew.58.1375137130701; Mon, 29 Jul 2013 15:32:10 -0700 (PDT) Received: by 10.223.84.130 with HTTP; Mon, 29 Jul 2013 15:32:10 -0700 (PDT) In-Reply-To: <1085EB97-75A1-407D-B8A5-7178C4931445@ifi.uio.no> References: <51F6633B.8000509@mti-systems.com> <1085EB97-75A1-407D-B8A5-7178C4931445@ifi.uio.no> Date: Mon, 29 Jul 2013 17:32:10 -0500 Message-ID: From: Spencer Dawkins at IETF To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c367d631854f04e2ae10d8 Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 29 Jul 2013 22:32:13 -0000 --001a11c367d631854f04e2ae10d8 Content-Type: text/plain; charset=ISO-8859-1 The first time I heard Van talk about ECN (and, I'm sure, something like RED), he said randomness was really important ... Spencer On Tuesday, July 30, 2013, Michael Welzl wrote: > Hi, > > I like the slides too, but I think that slide #5 should contain: > - counteract synchronization > > This is in fact a goal of AQM that I had always considered to be one of > the key motivators behind RED (without that goal, it could probably have > just been ED instead :-) ). Somewhat strangely, this goal hasn't been > mentioned much recently. > > Is it just a simulation artifact? I don't think so. Yes we see it a lot in > simulations: > http://www.icir.org/floyd/papers/phase.pdf > but it also appears in reality: > http://caia.swin.edu.au/pubs/ATNAC06/Jaym.pdf > and it would surprise me greatly if it wasn't a much more significant > problem in more controlled environments, in particular data centers. > > Cheers, > Michael > > > On Jul 29, 2013, at 2:42 PM, Wesley Eddy > > wrote: > > > As BoF chairs, we were asked to talk to the RTGAREA meeting > > at this week's IETF about the AQM BoF and what we're doing. > > > > The slides I'm planning to discuss there are: > > http://www.ietf.org/proceedings/87/slides/slides-87-aqm-3.pptx > > > > -- > > Wes Eddy > > MTI Systems > > _______________________________________________ > > 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 > --001a11c367d631854f04e2ae10d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The first time I heard Van talk about ECN (and, I'm sure, something lik= e RED), he said randomness=A0was really important ...


=
Spencer

On Tuesday, July 30, 2013, Michael Welzl wrote:<= br>
Hi,

I like the slides too, but I think that slide #5 should contain:
- counteract synchronization

This is in fact a goal of AQM that I had always considered to be one of the= key motivators behind RED (without that goal, it could probably have just = been ED instead =A0:-) =A0). Somewhat strangely, this goal hasn't been = mentioned much recently.

Is it just a simulation artifact? I don't think so. Yes we see it a lot= in simulations:
ht= tp://www.icir.org/floyd/papers/phase.pdf
but it also appears in reality:
http://caia.swin.edu.au/pubs/ATNAC06/Jaym.pdf
and it would surprise me greatly if it wasn't a much more significant p= roblem in more controlled environments, in particular data centers.

Cheers,
Michael


On Jul 29, 2013, at 2:42 PM, Wesley Eddy <wes@mti-sys= tems.com> wrote:

> As BoF chairs, we were asked to talk to the RTGAREA meeting
> at this week's IETF about the AQM BoF and what we're doing. >
> The slides I'm planning to discuss there are:
> http://www.ietf.org/proceedings/87/slides/slides-87-= aqm-3.pptx
>
> --
> Wes Eddy
> MTI Systems
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm
--001a11c367d631854f04e2ae10d8-- From wes@mti-systems.com Mon Jul 29 15:51: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 14BEE11E814F for ; Mon, 29 Jul 2013 15:51:04 -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 JyIC3SIudZrS for ; Mon, 29 Jul 2013 15:50:59 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 846C911E810E for ; Mon, 29 Jul 2013 15:50:54 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6TMoqpC006898 for ; Mon, 29 Jul 2013 18:50:52 -0400 Received: (qmail 6206 invoked by uid 0); 29 Jul 2013 22:50:52 -0000 X-TCPREMOTEIP: 95.211.197.1 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?10.9.0.82?) (wes@mti-systems.com@95.211.197.1) by 0 with ESMTPA; 29 Jul 2013 22:50:51 -0000 Message-ID: <51F6F1B9.4000005@mti-systems.com> Date: Mon, 29 Jul 2013 18:50:33 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: multipart/mixed; boundary="------------050509050400010406020400" Subject: [aqm] charter diff 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, 29 Jul 2013 22:51:04 -0000 This is a multi-part message in MIME format. --------------050509050400010406020400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Attached is a colorized diff from the last revision and a new charter trying to pull in the input from the last thread on this topic. I have completely punted on playing with the name for the moment, and have left it as matching the BoF and mailing list name for now. -- Wes Eddy MTI Systems --------------050509050400010406020400 Content-Type: text/plain; charset=windows-1252; name="AQM-charter-130729.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="AQM-charter-130729.txt" Active Queue Management and Packet Scheduling (AQM) (among other alternatives) Internet routers, lower-layer switches, end-host operating systems, device drivers, and many types of additional middleboxes include memory buffers in which they implement queues to hold packets that require processing or otherwise need to wait for forwarding to the next hop. The queues are intended to absorb bursts of traffic that may naturally occur, and avoid unneccessary losses. However, queues also cause latency and jitter in the eventual arrival times of packets. This can create issues and complications for interactive applications. Extremely large unmanaged buffers have been noticed in some software and equipment. When these buffers fill, interactive applications and other traffic can be severely impacted or completely broken, due to high and potentially oscillating delays. The Active Queue Management and Packet Scheduling working group (AQM) works on algorithms for managing queues in order to: (1) minimize standing queues; helping to reduce delay for interactive applications (2) help flow sources control their sending rates without unnecessary losses, e.g. through ECN (3) consider the merits of various techniques to protect flows from negative impacts of other more aggressive or misbehaving flows (4) help avoid global synchronization of flows sharing a bottleneck The AQM working group will publish Informational and Best Current Practices documents that cover the design, use, and configuration of algorithms for managing queues in Internet devices and software. The scope includes both how to best configure existing equipment and software, as well as recommendations on designing new equipment and software. The AQM working group will also publish algorithm specifications that are found to be broadly applicable and beneficial. Evaluating these algorithms shall be done in coordination with the Internet Congestion Control Research Group (ICCRG) in order to select and assess the relevant criteria, scenarios, and metrics. The working group will also explore the merits of whether to isolate flows, and mechanisms for performing this function. Note that isolation and potentially policing of flows implies some policy beyond what is required to simply minimize queues. This topic requires significant attention in the working group. AQM algorithms do not have to be implemented universally in order to be effective. Specifications will aid in producing proper implementations that avoid potential ambiguities and corner cases. "Interoperability" of algorithms and implementations of them is not the reason for creating these specifications; correctness is the primary motivation. The working group will not make changes to ECN, DiffServ, or other IETF protocols, though existing ECN, DiffServ, and other mechanisms may be used within the algorithms proposed. The proper place for changes to ECN and DiffServ is the TSVWG, but as the implementation is likely to be entwined with AQM algorithms, there is expected to be close coordination between both groups. Many AQM algorithms have been proposed in academic literature, but a smaller number are widely implemented and deployed. The 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. Goals and Milestones January 2014 Submit AQM recommendations to IESG for publication as BCP obsoleting RFC 2309 July 2014 Submit AQM evaluation guidelines to IESG for publication as Informational December 2014 Submit first algorithm specification to IESG for publication as Proposed Standard Relevant documents: Recommendations --------------- http://tools.ietf.org/html/draft-baker-aqm-recommendation Algorithms Potentially for Consideration ---------------------------------------- PIE: http://tools.ietf.org/html/draft-pan-tsvwg-pie CoDel: http://tools.ietf.org/html/draft-nichols-tsvwg-codel FavorQueue: http://arxiv.org/pdf/1103.2303v2.pdf --------------050509050400010406020400 Content-Type: text/html; charset=WINDOWS-1252; name="charter-diff.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="charter-diff.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5z aXRpb25hbC5kdGQiPg0KPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjM5cDE6IHJmY2Rp ZmYgIC0tPg0KPCEtLSA8IURPQ1RZUEUgaHRtbCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwg NC4wMSBUcmFuc2l0aW9uYWwiID4gLS0+DQo8IS0tIFN5c3RlbTogTGludXggaWV0ZmEgMi42 LjI3LjU2LTAuMS14ZW4gIzEgU01QIDIwMTAtMTItMDEgMTY6NTc6NTggKzAxMDAgeDg2XzY0 IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4IC0tPg0KPCEtLSBVc2luZyBhd2s6IC9iaW4vZ2F3 azogR05VIEF3ayAzLjEuNiAtLT4NCjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjog ZGlmZiAoR05VIGRpZmZ1dGlscykgMi44LjctY3ZzIC0tPg0KPCEtLSBVc2luZyB3ZGlmZjog L3Vzci9iaW4vd2RpZmY6IEdOVSAwLjUuMiBMMyAtLT4NCjxodG1sPjxoZWFkPiANCiAgPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9d2luZG93cy0xMjUyIj4gDQogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUt VHlwZSIgY29udGVudD0idGV4dC9jc3MiPiANCiAgPHRpdGxlPkRpZmY6IEFRTS1jaGFydGVy LTEzMDcxMS50eHQgLSBBUU0tY2hhcnRlci0xMzA3MjkudHh0PC90aXRsZT4gDQogIDxzdHls ZSB0eXBlPSJ0ZXh0L2NzcyI+IA0KICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJn aW4tcmlnaHQ6IGF1dG87IH0gDQogICAgdHIgICAgICB7IH0gDQogICAgdGQgICAgICB7IHdo aXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWdu OiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gDQogICAgdGggICAgICB7IGZvbnQtc2l6ZTog MC44NmVtOyB9IA0KICAgIC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxl OiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IH0gDQogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gDQogICAgLnJp Z2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gDQogICAgLmRpZmYgICB7IGJhY2tn cm91bmQtY29sb3I6ICNDQ0Y7IH0gDQogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29sb3I6 ICNCRkI7IH0gDQogICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0gDQog ICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0gDQogICAgLmRlbGV0ZSB7 IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7IH0gDQogICAgLnZvaWQgICB7IGJhY2tncm91bmQt Y29sb3I6ICNGRkI7IH0gDQogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gDQogICAgLmxpbmViciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gDQogICAgLmxp bmVubyB7IGNvbG9yOiByZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTog MC43ZW07IHRleHQtYWxpZ246IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSANCiAgICAuZWxp cHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSANCiAgICAubGVmdCAuY29udCB7IGJh Y2tncm91bmQtY29sb3I6ICNEREQ7IH0gDQogICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3Vu ZC1jb2xvcjogI0VFRTsgfSANCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xv cjogIzlEOTsgfSANCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RE NjsgfSANCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzBERDsgfSAN CiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSANCiAgICAu c3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsg cGFkZGluZzogMnB4IDA7IH0gDQogIDwvc3R5bGU+IA0KPC9oZWFkPiANCjxib2R5PiANCiAg PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gDQog IDx0Ym9keT48dHIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+Jm5ic3A7QVFNLWNo YXJ0ZXItMTMwNzExLnR4dCZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDtBUU0tY2hh cnRlci0xMzA3MjkudHh0Jm5ic3A7PC90aD48dGg+PC90aD48L3RyPiANCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5B Y3RpdmUgUXVldWUgTWFuYWdlbWVudCBhbmQgUGFja2V0IFNjaGVkdWxpbmcgKEFRTSk8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BY3RpdmUgUXVldWUgTWFuYWdlbWVudCBh bmQgUGFja2V0IFNjaGVkdWxpbmcgKEFRTSk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMSI+ PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPm9yPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4oYW1vbmcgb3RoZXIgYWx0ZXJuYXRpdmVzKTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+U21hcnRlciBRdWV1ZSBNYW5hZ2VtZW50IChTUU0pIChzdWdnZXN0ZWQg YnkgRGF2ZSBUYWh0KTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1l PSJkaWZmMDAwMiI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgSW50ZXJuZXQgcm91 dGVycywgbG93ZXItbGF5ZXIgc3dpdGNoZXMsIDxzcGFuIGNsYXNzPSJkZWxldGUiPm90aGVy PC9zcGFuPiBtaWRkbGVib3hlcyBpbmNsdWRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgSW50ZXJuZXQgcm91dGVycywgbG93ZXItbGF5ZXIgc3dpdGNoZXMsIDxzcGFu IGNsYXNzPSJpbnNlcnQiPmVuZC1ob3N0IG9wZXJhdGluZzwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICBidWZm ZXJzIDxzcGFuIGNsYXNzPSJkZWxldGUiPm9yPC9zcGFuPiBxdWV1ZXMgdG8gaG9sZCBwYWNr ZXRzIDxzcGFuIGNsYXNzPSJkZWxldGUiPndoZW4gdGhleSBhcmUgbm90IGltbWVkaWF0ZWx5 PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gIHN5c3RlbXMsIGRldmljZSBkcml2ZXJzLCBhbmQgbWFueSB0eXBlcyBvZiBh ZGRpdGlvbmFsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gIGFibGU8L3Nw YW4+IHRvIDxzcGFuIGNsYXNzPSJkZWxldGUiPmJlIGZvcndhcmRlZDwvc3Bhbj4gdG8gdGhl IG5leHQgaG9wLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gIG1pZGRsZWJv eGVzIGluY2x1ZGUgPHNwYW4gY2xhc3M9Imluc2VydCI+bWVtb3J5PC9zcGFuPiBidWZmZXJz IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmluIHdoaWNoIHRoZXkgaW1wbGVtZW50PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICBxdWV1ZXMgdG8gaG9s ZCBwYWNrZXRzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoYXQgcmVxdWlyZSBwcm9jZXNzaW5n IG9yIG90aGVyd2lzZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgbmVlZDwvc3Bhbj4gdG8gPHNwYW4gY2xh c3M9Imluc2VydCI+d2FpdCBmb3IgZm9yd2FyZGluZzwvc3Bhbj4gdG8gdGhlIG5leHQgaG9w LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIFRoZSBxdWV1 ZXMgYXJlIGludGVuZGVkIHRvIGFic29yYiBidXJzdHMgb2YgdHJhZmZpYyB0aGF0IG1heTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgVGhlIHF1ZXVlcyBhcmUgaW50ZW5k ZWQgdG8gYWJzb3JiIGJ1cnN0cyBvZiB0cmFmZmljIHRoYXQgbWF5PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIG5hdHVyYWxs eSBvY2N1ciwgYW5kIGF2b2lkIHVubmVjY2Vzc2FyeSBsb3NzZXMuICBIb3dldmVyLCBxdWV1 ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIG5hdHVyYWxseSBvY2N1ciwg YW5kIGF2b2lkIHVubmVjY2Vzc2FyeSBsb3NzZXMuICBIb3dldmVyLCBxdWV1ZXM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg YWxzbyBjYXVzZSBsYXRlbmN5IGFuZCBqaXR0ZXIgaW4gdGhlIGV2ZW50dWFsIGFycml2YWwg dGltZXMgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIGFsc28gY2F1c2Ug bGF0ZW5jeSBhbmQgaml0dGVyIGluIHRoZSBldmVudHVhbCBhcnJpdmFsIHRpbWVzIG9mPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gIHBhY2tldHMuICBUaGlzIGNhbiBjcmVhdGUgaXNzdWVzIGFuZCBjb21wbGljYXRpb25z IGZvciBpbnRlcmFjdGl2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgcGFj a2V0cy4gIFRoaXMgY2FuIGNyZWF0ZSBpc3N1ZXMgYW5kIGNvbXBsaWNhdGlvbnMgZm9yIGlu dGVyYWN0aXZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gIGFwcGxpY2F0aW9ucy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gIGFwcGxpY2F0aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAzIj48L2E+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICBFeHRyZW1lbHkgbGFyZ2UgYnVmZmVycyBoYXZlIGJlZW4gbm90aWNlZCBp biBzb21lIHNvZnR3YXJlIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g IEV4dHJlbWVseSBsYXJnZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij51bm1hbmFnZWQ8L3NwYW4+ IGJ1ZmZlcnMgaGF2ZSBiZWVuIG5vdGljZWQgaW4gc29tZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gIGVxdWlwbWVudC4g IFdoZW4gdGhlc2UgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+cXVldWVzPC9zcGFuPiBmaWxsLCBp bnRlcmFjdGl2ZSBhcHBsaWNhdGlvbnMgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgc29mdHdhcmUgYW5kIGVxdWlwbWVudC4gIFdoZW4gdGhlc2UgPHNwYW4gY2xh c3M9Imluc2VydCI+YnVmZmVyczwvc3Bhbj4gZmlsbCwgaW50ZXJhY3RpdmU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICBv dGhlciB0cmFmZmljIGNhbiBiZSBzZXZlcmVseSBpbXBhY3RlZCBvciBjb21wbGV0ZWx5IGJy b2tlbiwgZHVlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgYXBwbGljYXRp b25zIGFuZCBvdGhlciB0cmFmZmljIGNhbiBiZSBzZXZlcmVseSBpbXBhY3RlZCBvcjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gIHRvIGhpZ2ggYW5kIHBvdGVudGlhbGx5IG9zY2lsbGF0aW5nIGRlbGF5cy48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICBjb21wbGV0ZWx5IGJyb2tlbiwgZHVlIHRv IGhpZ2ggYW5kIHBvdGVudGlhbGx5IG9zY2lsbGF0aW5nIGRlbGF5cy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBUaGUgQWN0aXZlIFF1ZXVlIE1hbmFn ZW1lbnQgYW5kIFBhY2tldCBTY2hlZHVsaW5nIHdvcmtpbmcgZ3JvdXA8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIFRoZSBBY3RpdmUgUXVldWUgTWFuYWdlbWVudCBhbmQg UGFja2V0IFNjaGVkdWxpbmcgd29ya2luZyBncm91cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYw MDA0Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAoQVFNKSB3b3JrcyBvbiBhbGdv cml0aG1zIGZvciA8c3BhbiBjbGFzcz0iZGVsZXRlIj5wcm9hY3RpdmVseTwvc3Bhbj4gbWFu YWdpbmcgcXVldWVzIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgKEFR TSkgd29ya3Mgb24gYWxnb3JpdGhtcyBmb3IgbWFuYWdpbmcgcXVldWVzIGluIG9yZGVyIHRv OjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gIG9yZGVyIHRvOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDA1Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAoMSkgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+aGVscCBmbG93IHNvdXJjZXMgY29udHJvbCB0aGVpciBzZW5kaW5nIHJh dGVzIGJlZm9yZSB0aGU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgKDEpIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm1pbmltaXplIHN0YW5kaW5nIHF1ZXVlczsg aGVscGluZyB0byByZWR1Y2UgZGVsYXkgZm9yPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gIG9uc2V0IG9mIG5lY2Vzc2FyeSBsb3NzZXMsIGUuZy4gdGhyb3VnaCBFQ048 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgaW50ZXJhY3RpdmUgYXBwbGljYXRpb25zPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDYiPjwv YT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICgyKSBoZWxwIDxzcGFuIGNsYXNzPSJkZWxl dGUiPm1pbmltaXplIGRlbGF5cyBmb3IgaW50ZXJhY3RpdmUgYXBwbGljYXRpb25zPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICgyKSBoZWxwIDxzcGFuIGNs YXNzPSJpbnNlcnQiPmZsb3cgc291cmNlcyBjb250cm9sIHRoZWlyIHNlbmRpbmcgcmF0ZXMg d2l0aG91dDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgdW5uZWNlc3NhcnkgbG9zc2VzLCBlLmcuIHRocm91 Z2ggRUNOPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDciPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICgzKSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5oZWxwPC9zcGFuPiBwcm90ZWN0IGZsb3dzIGZy b20gbmVnYXRpdmUgaW1wYWN0cyBvZiBvdGhlciBtb3JlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgKDMpIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNvbnNpZGVyIHRoZSBt ZXJpdHMgb2YgdmFyaW91cyB0ZWNobmlxdWVzIHRvPC9zcGFuPiBwcm90ZWN0IGZsb3dzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgYWdncmVzc2l2ZSBvciBtaXNiZWhhdmluZyBmbG93czwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gIGZyb20gbmVnYXRpdmUgaW1wYWN0cyBvZiBvdGhlciBtb3Jl IGFnZ3Jlc3NpdmUgb3IgbWlzYmVoYXZpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgZmxvd3M8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgPHNwYW4gY2xhc3M9Imluc2VydCI+KDQpIGhlbHAgYXZvaWQgZ2xv YmFsIHN5bmNocm9uaXphdGlvbiBvZiBmbG93cyBzaGFyaW5nIGE8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g IGJvdHRsZW5lY2s8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgVGhlIEFRTSB3b3JraW5nIGdyb3VwIHdpbGwgcHVibGlzaCBJbmZvcm1hdGlv bmFsIGFuZCBCZXN0IEN1cnJlbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g IFRoZSBBUU0gd29ya2luZyBncm91cCB3aWxsIHB1Ymxpc2ggSW5mb3JtYXRpb25hbCBhbmQg QmVzdCBDdXJyZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gIFByYWN0aWNlcyBkb2N1bWVudHMgdGhhdCBjb3ZlciB0aGUg ZGVzaWduLCB1c2UsIGFuZCBjb25maWd1cmF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICBQcmFjdGljZXMgZG9jdW1lbnRzIHRoYXQgY292ZXIgdGhlIGRlc2lnbiwg dXNlLCBhbmQgY29uZmlndXJhdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBvZiBhbGdvcml0aG1zIGZvciBtYW5hZ2lu ZyBxdWV1ZXMgaW4gSW50ZXJuZXQgZGV2aWNlcyBhbmQgc29mdHdhcmUuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBvZiBhbGdvcml0aG1zIGZvciBtYW5hZ2luZyBxdWV1 ZXMgaW4gSW50ZXJuZXQgZGV2aWNlcyBhbmQgc29mdHdhcmUuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMDgiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGUgc2NvcGUgaW5j bHVkZXMgYm90aCBob3cgdG8gYmVzdCBjb25maWd1cmUgZXhpc3RpbmcgZXF1aXBtZW50PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICBhbmQgc29mdHdhcmUsIGFzIHdlbGwgYXMgcmVjb21tZW5kYXRpb25z IG9uIGRlc2lnbmluZyBuZXcgZXF1aXBtZW50PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICBhbmQgc29mdHdh cmUuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g IFRoZSBBUU0gd29ya2luZyBncm91cCB3aWxsIGFsc28gcHVibGlzaCBhbGdvcml0aG0gc3Bl Y2lmaWNhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIFRoZSBBUU0g d29ya2luZyBncm91cCB3aWxsIGFsc28gcHVibGlzaCBhbGdvcml0aG0gc3BlY2lmaWNhdGlv bnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgdGhhdCBhcmUgZm91bmQgdG8gYmUgYnJvYWRseSBhcHBsaWNhYmxlIGFuZCBi ZW5lZmljaWFsLiAgRXZhbHVhdGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgdGhhdCBhcmUgZm91bmQgdG8gYmUgYnJvYWRseSBhcHBsaWNhYmxlIGFuZCBiZW5lZmlj aWFsLiAgRXZhbHVhdGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICB0aGVzZSBhbGdvcml0aG1zIHNoYWxsIGJlIGRvbmUg aW4gY29vcmRpbmF0aW9uIHdpdGggdGhlIEludGVybmV0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICB0aGVzZSBhbGdvcml0aG1zIHNoYWxsIGJlIGRvbmUgaW4gY29vcmRp bmF0aW9uIHdpdGggdGhlIEludGVybmV0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIENvbmdlc3Rpb24gQ29udHJvbCBSZXNl YXJjaCBHcm91cCAoSUNDUkcpIGluIG9yZGVyIHRvIHNlbGVjdCBhbmQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIENvbmdlc3Rpb24gQ29udHJvbCBSZXNlYXJjaCBHcm91 cCAoSUNDUkcpIGluIG9yZGVyIHRvIHNlbGVjdCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgYXNzZXNzIHRoZSByZWxl dmFudCBjcml0ZXJpYSwgc2NlbmFyaW9zLCBhbmQgbWV0cmljcy48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gIGFzc2VzcyB0aGUgcmVsZXZhbnQgY3JpdGVyaWEsIHNjZW5h cmlvcywgYW5kIG1ldHJpY3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOSI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gIDxzcGFuIGNsYXNzPSJp bnNlcnQiPlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWxzbyBleHBsb3JlIHRoZSBtZXJpdHMg b2Ygd2hldGhlciB0bzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgaXNvbGF0ZSBmbG93cywgYW5kIG1lY2hh bmlzbXMgZm9yIHBlcmZvcm1pbmcgdGhpcyBmdW5jdGlvbi4gIE5vdGU8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gIHRoYXQgaXNvbGF0aW9uIGFuZCBwb3RlbnRpYWxseSBwb2xpY2luZyBvZiBmbG93cyBp bXBsaWVzIHNvbWUgcG9saWN5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICBiZXlvbmQgd2hhdCBpcyByZXF1 aXJlZCB0byBzaW1wbHkgbWluaW1pemUgcXVldWVzLiAgVGhpcyB0b3BpYzwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgcmVxdWlyZXMgc2lnbmlmaWNhbnQgYXR0ZW50aW9uIGluIHRoZSB3b3JraW5nIGdy b3VwLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgQVFNIGFsZ29yaXRobXMgZG8gbm90IGhhdmUgdG8g YmUgaW1wbGVtZW50ZWQgdW5pdmVyc2FsbHkgaW4gb3JkZXI8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gIEFRTSBhbGdvcml0aG1zIGRvIG5vdCBoYXZlIHRvIGJlIGltcGxl bWVudGVkIHVuaXZlcnNhbGx5IGluIG9yZGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIHRvIGJlIGVmZmVjdGl2ZS4gIFNw ZWNpZmljYXRpb25zIHdpbGwgYWlkIGluIHByb2R1Y2luZyBwcm9wZXI8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIHRvIGJlIGVmZmVjdGl2ZS4gIFNwZWNpZmljYXRpb25z IHdpbGwgYWlkIGluIHByb2R1Y2luZyBwcm9wZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgaW1wbGVtZW50YXRpb25zIHRo YXQgYXZvaWQgcG90ZW50aWFsIGFtYmlndWl0aWVzIGFuZCBjb3JuZXIgY2FzZXMuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhdm9p ZCBwb3RlbnRpYWwgYW1iaWd1aXRpZXMgYW5kIGNvcm5lciBjYXNlcy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIkludGVy b3BlcmFiaWxpdHkiIG9mIGFsZ29yaXRobXMgYW5kIGltcGxlbWVudGF0aW9ucyBvZiB0aGVt IGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAiSW50ZXJvcGVyYWJpbGl0 eSIgb2YgYWxnb3JpdGhtcyBhbmQgaW1wbGVtZW50YXRpb25zIG9mIHRoZW0gaXM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg bm90IHRoZSByZWFzb24gZm9yIGNyZWF0aW5nIHRoZXNlIHNwZWNpZmljYXRpb25zOyBjb3Jy ZWN0bmVzcyBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgbm90IHRoZSBy ZWFzb24gZm9yIGNyZWF0aW5nIHRoZXNlIHNwZWNpZmljYXRpb25zOyBjb3JyZWN0bmVzcyBp czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICB0aGUgcHJpbWFyeSBtb3RpdmF0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgdGhlIHByaW1hcnkgbW90aXZhdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBUaGUgd29ya2luZyBncm91cCB3aWxsIG5vdCBt YWtlIGNoYW5nZXMgdG8gRUNOLCBEaWZmU2Vydiwgb3Igb3RoZXI8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgbm90IG1ha2UgY2hh bmdlcyB0byBFQ04sIERpZmZTZXJ2LCBvciBvdGhlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBJRVRGIHByb3RvY29scywg dGhvdWdoIGV4aXN0aW5nIEVDTiwgRGlmZlNlcnYsIGFuZCBvdGhlciBtZWNoYW5pc21zPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBJRVRGIHByb3RvY29scywgdGhvdWdo IGV4aXN0aW5nIEVDTiwgRGlmZlNlcnYsIGFuZCBvdGhlciBtZWNoYW5pc21zPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwMTAiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gIG1heSBi ZSB1c2VkIHdpdGhpbiB0aGUgYWxnb3JpdGhtcyBwcm9wb3NlZC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICBtYXkgYmUgdXNlZCB3aXRoaW4gdGhlIGFsZ29yaXRobXMg cHJvcG9zZWQuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGUgcHJvcGVyIHBsYWNlIGZvcjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgY2hhbmdlcyB0byBFQ04gYW5kIERpZmZTZXJ2IGlzIHRoZSBUU1ZX RywgYnV0IGFzIHRoZSBpbXBsZW1lbnRhdGlvbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgaXMgbGlrZWx5 IHRvIGJlIGVudHdpbmVkIHdpdGggQVFNIGFsZ29yaXRobXMsIHRoZXJlIGlzIGV4cGVjdGVk IHRvIGJlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICBjbG9zZSBjb29yZGluYXRpb24gYmV0d2VlbiBib3Ro IGdyb3Vwcy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgTWFueSBBUU0gYWxnb3JpdGhtcyBoYXZlIGJlZW4gcHJvcG9zZWQgaW4gYWNhZGVt aWMgbGl0ZXJhdHVyZSwgYnV0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBN YW55IEFRTSBhbGdvcml0aG1zIGhhdmUgYmVlbiBwcm9wb3NlZCBpbiBhY2FkZW1pYyBsaXRl cmF0dXJlLCBidXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxMSI+PC9hPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dmVyeSBmZXc8L3NwYW4+IGFy ZSB3aWRlbHkgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkLiAgVGhlIGdvYWwgb2YgdGhlIHdv cmtpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5hIHNtYWxsZXIgbnVtYmVyPC9zcGFuPiBhcmUgd2lkZWx5IGltcGxlbWVudGVk IGFuZCBkZXBsb3llZC4gIFRoZSBnb2FsIG9mIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gIGdyb3VwIGlzIHRvIHBy b2R1Y2UgcmVjb21tZW5kYXRpb25zIHRoYXQgd2lsbCBhY3R1YWxseSBiZSB1c2VkLCBhbmQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICB3b3JraW5nIGdyb3VwIGlzIHRv IHByb2R1Y2UgcmVjb21tZW5kYXRpb25zIHRoYXQgd2lsbCBhY3R1YWxseSBiZSB1c2VkLDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gIGFsZ29yaXRobXMgdGhhdCB3aWxsIGFjdHVhbGx5IGJlIGltcGxlbWVudGVkLCBk ZXBsb3llZCBpbiBlcXVpcG1lbnQsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgYW5kIGFsZ29yaXRobXMgdGhhdCB3aWxsIGFjdHVhbGx5IGJlIGltcGxlbWVudGVkLCBk ZXBsb3llZCBpbiBlcXVpcG1lbnQsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIGFuZCBlbmFibGVkLiAgVG93YXJkcyB0aGVz ZSBlbmRzLCB0aGUgZ3JvdXAgYWN0aXZlbHkgZW5jb3VyYWdlczwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgYW5kIGVuYWJsZWQuICBUb3dhcmRzIHRoZXNlIGVuZHMsIHRo ZSBncm91cCBhY3RpdmVseSBlbmNvdXJhZ2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTIi PjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gIHBhcnRpY2lwYXRpb24gZnJvbSBvcGVy YXRvcnMgYW5kIGltcGxlbWVudGVycywgYW5kIHdpbGwgY29vcmRpbmF0ZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gIHBhcnRpY2lwYXRpb24gZnJvbSBvcGVyYXRvcnMg YW5kIGltcGxlbWVudGVycywgYW5kIHdpbGwgY29vcmRpbmF0ZSB3aXRoPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgd2l0 aCB0aGUgSUVURiBPUFMgYXJlYSBhbmQgb3RoZXIgcmVsZXZhbnQgcGFydHMgb2YgdGhlIElF VEYgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgdGhlIElFVEYgT1BT IGFyZWEgYW5kIG90aGVyIHJlbGV2YW50IHBhcnRzIG9mIHRoZSBJRVRGIGFuZCBJbnRlcm5l dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gIEludGVybmV0IGNvbW11bml0eS4gIFdpZGVyIHJlc2VhcmNoIGFuZCBldmFs dWF0aW9uIG9mIEFRTSBtZWNoYW5pc21zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgY29tbXVuaXR5LiAgV2lkZXIgcmVzZWFyY2ggYW5kIGV2YWx1YXRpb24gb2YgQVFN IG1lY2hhbmlzbXMgc2hhbGwgYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICBzaGFsbCBiZSBjb29yZGluYXRlZCB3aXRo IHRoZSBJUlRGL0lDQ1JHLCBhbmQgc2lnbmlmaWNhbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICBjb29yZGluYXRlZCB3aXRoIHRoZSBJUlRGL0lDQ1JHLCBhbmQgc2ln bmlmaWNhbnQgcGFydGljaXBhdGlvbiBpbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgcGFydGljaXBhdGlvbiBp biB0aGlzIFdHIGZyb20gdGhlIGFjYWRlbWljIGFuZCByZXNlYXJjaCBjb21tdW5pdHkgaXM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICBXRyBmcm9tIHRoZSBhY2FkZW1p YyBhbmQgcmVzZWFyY2ggY29tbXVuaXR5IGlzIGhpZ2hseSBkZXNpcmFibGUsIHdoZW4gaXQ8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICBoaWdobHkgZGVzaXJhYmxlLCB3aGVuIGl0IGlzIGRpcmVjdGx5IHJlbGV2YW50 IHRvIGltcGxlbWVudGF0aW9uIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gIGlzIGRpcmVjdGx5IHJlbGV2YW50IHRvIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3lt ZW50LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gIGRlcGxveW1lbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIEdvYWxz IGFuZCBNaWxlc3RvbmVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBHb2Fs cyBhbmQgTWlsZXN0b25lczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gIEphbnVhcnkgMjAxNCAgU3VibWl0IEFRTSByZWNvbW1lbmRhdGlvbnMgdG8gSUVT RyBmb3IgcHVibGljYXRpb24gYXMgQkNQIG9ic29sZXRpbmcgUkZDIDIzMDk8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIEphbnVhcnkgMjAxNCAgU3VibWl0IEFRTSByZWNv bW1lbmRhdGlvbnMgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgQkNQIG9ic29sZXRpbmcg UkZDIDIzMDk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgSnVseSAyMDE0ICAgICBTdWJtaXQgQVFNIGV2YWx1YXRpb24gZ3Vp ZGVsaW5lcyB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZvcm1hdGlvbmFsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBKdWx5IDIwMTQgICAgIFN1Ym1pdCBBUU0g ZXZhbHVhdGlvbiBndWlkZWxpbmVzIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIEluZm9y bWF0aW9uYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgRGVjZW1iZXIgMjAxNCBTdWJtaXQgZmlyc3QgYWxnb3JpdGhtIHNw ZWNpZmljYXRpb24gdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgUHJvcG9zZWQgU3RhbmRh cmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIERlY2VtYmVyIDIwMTQgU3Vi bWl0IGZpcnN0IGFsZ29yaXRobSBzcGVjaWZpY2F0aW9uIHRvIElFU0cgZm9yIHB1YmxpY2F0 aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgUmVsZXZhbnQgZG9jdW1lbnRzOjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgUmVsZXZhbnQgZG9jdW1lbnRzOjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIFJlY29tbWVuZGF0aW9uczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgUmVjb21tZW5kYXRpb25zPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCg0KICAgICA8dHI+PHRkPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZD48L3RkPjwvdHI+DQogICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIg YWxpZ249ImNlbnRlciI+PGEgbmFtZT0iZW5kIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMTIg Y2hhbmdlIGJsb2Nrcy4mbmJzcDs8L2E+PC90aD48L3RyPg0KICAgICA8dHIgY2xhc3M9InN0 YXRzIj48dGQ+PC90ZD48dGg+PGk+MjcgbGluZXMgY2hhbmdlZCBvciBkZWxldGVkPC9pPjwv dGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+NDMgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwv aT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgIDx0cj48dGQgY29sc3Bhbj0iNSIgY2xhc3M9 InNtYWxsIiBhbGlnbj0iY2VudGVyIj48YnI+VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2Vk IGJ5IHJmY2RpZmYgMS4zOXAxLiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZy b20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvPC9hPiA8L3RkPjwvdHI+DQog ICA8L3Rib2R5PjwvdGFibGU+DQogICANCiAgIA0KPC9ib2R5PjwvaHRtbD4= --------------050509050400010406020400-- From michael.scharf@alcatel-lucent.com Mon Jul 29 22:52: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 E92B211E81B9 for ; Mon, 29 Jul 2013 22:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.347 X-Spam-Level: X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.025, 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 PHi8fsfyyL4R for ; Mon, 29 Jul 2013 22:52:13 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E990F11E8174 for ; Mon, 29 Jul 2013 22:52:12 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6U5q4to015828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 00:52:05 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6U5q2rQ011176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 07:52:02 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 07:52:02 +0200 From: "Scharf, Michael (Michael)" To: Dave Taht , Bob Briscoe Thread-Topic: [aqm] AQM BoF - RTGAREA slides Thread-Index: AQHOjFlF9VbxCADZEkGBHRXN//9UNZl7vU4AgAAfCwCAANwaoA== Date: Tue, 30 Jul 2013 05:52:02 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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 Jul 2013 05:52:20 -0000 > > The charter reads to me is as much about advice on configuring=20 > > existing stuff like RED, as it is about designing new=20 > stuff. We don't=20 > > want to give the message "the only solution is to rip out=20 > everything=20 > > you've already bought and buy this new stuff". >=20 > Seeing RED deployed more where it could matter (like=20 > interprovider interconnects and other fixed rate lines) would=20 > be a goodness. I am just curious: Is there any data that shows *any* benefit of RED (or wh= atever other AQM flavor) on a 10G or 100G link? Michael From michael.scharf@alcatel-lucent.com Mon Jul 29 23:12: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 D503921F9FE1 for ; Mon, 29 Jul 2013 23:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.023, 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 nUVfO9LOuq5p for ; Mon, 29 Jul 2013 23:12:42 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4349421F9EB5 for ; Mon, 29 Jul 2013 23:12:41 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6U6Cd6J025649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 01:12:40 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6U6CcNg022883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 08:12:38 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 08:12:39 +0200 From: "Scharf, Michael (Michael)" To: Wesley Eddy , "aqm@ietf.org" Thread-Topic: [aqm] charter diff Thread-Index: AQHOjK4gpJ9ztc/950ee9wvzqnBrjZl8vR7w Date: Tue, 30 Jul 2013 06:12:37 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07832F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51F6F1B9.4000005@mti-systems.com> In-Reply-To: <51F6F1B9.4000005@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [aqm] charter diff 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 Jul 2013 06:12:49 -0000 Regarding: "The proper place for changes to ECN and DiffServ is the TSVWG" I am not sure if we need that sentence. Some (end-system-related) ECN work = is currently somewhere in the gray area between TSVWG and TCPM. Michael > -----Original Message----- > From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On=20 > Behalf Of Wesley Eddy > Sent: Tuesday, July 30, 2013 12:51 AM > To: aqm@ietf.org > Subject: [aqm] charter diff >=20 > Attached is a colorized diff from the last revision and a new=20 > charter trying to pull in the input from the last thread on=20 > this topic. >=20 > I have completely punted on playing with the name for the=20 > moment, and have left it as matching the BoF and mailing list=20 > name for now. >=20 >=20 > -- > Wes Eddy > MTI Systems > = From gorry@erg.abdn.ac.uk Tue Jul 30 02:26: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 094FE21F9C26 for ; Tue, 30 Jul 2013 02:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.3 X-Spam-Level: X-Spam-Status: No, score=-106.3 tagged_above=-999 required=5 tests=[AWL=0.072, 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 P9O5cvndDrEb for ; Tue, 30 Jul 2013 02:26:30 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA2B11E80EC for ; Tue, 30 Jul 2013 02:24:42 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id A245A2B44D6; Tue, 30 Jul 2013 10:24:39 +0100 (BST) Received: from dhcp-1504.meeting.ietf.org (dhcp-1504.meeting.ietf.org [130.129.21.4]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 780552B4096; Tue, 30 Jul 2013 10:24:38 +0100 (BST) Message-ID: <51F78655.4020007@erg.abdn.ac.uk> Date: Tue, 30 Jul 2013 11:24:37 +0200 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/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <51F6F1B9.4000005@mti-systems.com> <655C07320163294895BBADA28372AF5D07832F@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D07832F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] charter diff X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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 Jul 2013 09:26:35 -0000 Indeed - I understood that TSVWG is responsible for ECN router behaviour, not the whole ECN piece. Gorry On 30/07/2013 08:12, Scharf, Michael (Michael) wrote: > Regarding: "The proper place for changes to ECN and DiffServ is the TSVWG" > > I am not sure if we need that sentence. Some (end-system-related) ECN work is currently somewhere in the gray area between TSVWG and TCPM. > > Michael > > > >> -----Original Message----- >> From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On >> Behalf Of Wesley Eddy >> Sent: Tuesday, July 30, 2013 12:51 AM >> To: aqm@ietf.org >> Subject: [aqm] charter diff >> >> Attached is a colorized diff from the last revision and a new >> charter trying to pull in the input from the last thread on >> this topic. >> >> I have completely punted on playing with the name for the >> moment, and have left it as matching the BoF and mailing list >> name for now. >> >> >> -- >> Wes Eddy >> MTI Systems >> > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From jgunn6@csc.com Tue Jul 30 08:14: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 2FEB821E80C6 for ; Tue, 30 Jul 2013 08:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ajhE1OpcUpNn for ; Tue, 30 Jul 2013 08:14:22 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6854821F9D39 for ; Tue, 30 Jul 2013 08:14:11 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-11.tower-86.messagelabs.com!1375197249!34073384!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21757 invoked from network); 30 Jul 2013 15:14:09 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-11.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2013 15:14:09 -0000 Received: from amer-gw09.amer.csc.com (cscmail.csc.com [20.6.39.245]) by amer-mta102.csc.com (8.13.8/8.13.8) with ESMTP id r6UFBmX4032439 for ; Tue, 30 Jul 2013 11:11:48 -0400 In-Reply-To: <51DE398B.2090103@mti-systems.com> References: <51DE398B.2090103@mti-systems.com> To: "aqm@ietf.org" ,> MIME-Version: 1.0 X-KeepSent: 01475ADD:EB429431-85257BB8:005393EC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Tue, 30 Jul 2013 11:14:06 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 07/30/2013 11:07:42 AM, Serialize complete at 07/30/2013 11:07:42 AM Content-Type: multipart/alternative; boundary="=_alternative 0053BFE185257BB8_=" Subject: [aqm] AQM jabber scribe? 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 Jul 2013 15:14:29 -0000 This is a multipart message in MIME format. --=_alternative 0053BFE185257BB8_= Content-Type: text/plain; charset="US-ASCII" Is there one? Could someone at least tell us what slide we are on? Thanks Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 0053BFE185257BB8_= Content-Type: text/html; charset="US-ASCII" Is there one?

Could someone at least tell us what slide we are on?

Thanks

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 0053BFE185257BB8_=-- From swb@internet2.edu Tue Jul 30 09:33: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 3EF3121E80EE for ; Tue, 30 Jul 2013 09:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.694 X-Spam-Level: X-Spam-Status: No, score=-4.694 tagged_above=-999 required=5 tests=[AWL=1.905, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 87kAyu1+gUhs for ; Tue, 30 Jul 2013 09:33:25 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id DFC6A11E8234 for ; Tue, 30 Jul 2013 09:32:08 -0700 (PDT) Received: from mail143-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 16:32:08 +0000 Received: from mail143-tx2 (localhost [127.0.0.1]) by mail143-tx2-R.bigfish.com (Postfix) with ESMTP id 728413A00A5 for ; Tue, 30 Jul 2013 16:32:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0811HT003.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 10 X-BigFish: S10(zzda00hdc73hzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1f5fh1b1cn1b1bi1155h) Received: from mail143-tx2 (localhost.localdomain [127.0.0.1]) by mail143-tx2 (MessageSwitch) id 1375201926169227_32360; Tue, 30 Jul 2013 16:32:06 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.227]) by mail143-tx2.bigfish.com (Postfix) with ESMTP id 1BEB86023C for ; Tue, 30 Jul 2013 16:32:06 +0000 (UTC) Received: from BY2PRD0811HT003.namprd08.prod.outlook.com (157.56.237.5) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 16:32:05 +0000 Received: from dhcp-1668.meeting.ietf.org (130.129.22.104) by pod51019.outlook.com (10.255.91.166) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 30 Jul 2013 16:32:04 +0000 Message-ID: <51F7EA81.6080606@internet2.edu> Date: Tue, 30 Jul 2013 18:32:01 +0200 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.129.22.104] X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [aqm] WG name: QUEUE 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 Jul 2013 16:33:38 -0000 Since there wasn't any time to talk about the WG name in real time, I want to heartily endorse Grenville Armitage's suggestion: QUEUE -- Queue Utilisation for Enhanced User Experience From stephen@networkplumber.org Tue Jul 30 10:54: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 D653821F9AC4 for ; Tue, 30 Jul 2013 10:54:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P1nSmJEV9qA for ; Tue, 30 Jul 2013 10:54:17 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id E52A621E805D for ; Tue, 30 Jul 2013 10:54:14 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up15so5649070pbc.12 for ; Tue, 30 Jul 2013 10:54:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=hNOZVg1+ZSmR5cg33y9rMdkvksXRI+oP635mBJWwJuM=; b=cHPExexG7LMkX9/5vCXNxwYBQyve0X2/n0+ZY207GDxzvodifV2Mwq5frf3TOXlqYG syWVSUnvZBPfIrGnnyxdiPP4/+rpU+MCvUpueSP2M4Y1TAmPkcxwcKUaKQtFTeGbJvwh D5ImdPRQauj+B8umvC56mS3rNI07ChQRJJehDwyEnr34TUpct1LIrvua+XvZce9Id30g iU6pXj7Am6u+LwhqcMDTzj1QQM6W1TnC9bvy9NVXNWr73E4XW2utyxqbgg4+pMeFinKi 2O7vmKvskKDuDxTyPwWz0nBHDnI90IIlQxkzKyo+3y3hc6NTac1W4UIvRYbAhKUYsyaX qqrw== X-Received: by 10.66.21.37 with SMTP id s5mr77222342pae.103.1375206854598; Tue, 30 Jul 2013 10:54:14 -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 qc5sm673712pbc.31.2013.07.30.10.54.13 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Jul 2013 10:54:14 -0700 (PDT) Date: Tue, 30 Jul 2013 10:54:10 -0700 From: Stephen Hemminger To: "Scharf, Michael (Michael)" Message-ID: <20130730105410.063e55bf@nehalam.linuxnetplumber.net> In-Reply-To: <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.com> 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: ALoCoQmXOK7TKjJZUNbP8Vspe0EqE4oemUUFUBdd/VGXyKmXnkvcO86qor2lBZoCpGCQSKH1mdD8 Cc: Wesley Eddy , "aqm@ietf.org" , Dave Taht , Bob Briscoe Subject: Re: [aqm] AQM BoF - RTGAREA slides 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 Jul 2013 17:54:23 -0000 On Tue, 30 Jul 2013 05:52:02 +0000 "Scharf, Michael (Michael)" wrote: > > > The charter reads to me is as much about advice on configuring > > > existing stuff like RED, as it is about designing new > > stuff. We don't > > > want to give the message "the only solution is to rip out > > everything > > > you've already bought and buy this new stuff". > > > > Seeing RED deployed more where it could matter (like > > interprovider interconnects and other fixed rate lines) would > > be a goodness. > > I am just curious: Is there any data that shows *any* benefit of RED (or whatever other AQM flavor) on a 10G or 100G link? The problem is when one link is slower than the data sources, so yes. When doing 100G to 10G bridging or routing, the same issues occur but with different timing. From michawe@ifi.uio.no Tue Jul 30 13:57: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 E360821F937E for ; Tue, 30 Jul 2013 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.024, 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 LMxa+Vc+GLGe for ; Tue, 30 Jul 2013 13:57:45 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id EF42211E8141 for ; Tue, 30 Jul 2013 13:57:41 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V4GzC-0006ew-JW; Tue, 30 Jul 2013 22:57:38 +0200 Received: from [46.189.28.122] (helo=[10.25.11.80]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V4GzC-0004xc-5L; Tue, 30 Jul 2013 22:57:38 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <51F7EA81.6080606@internet2.edu> Date: Tue, 30 Jul 2013 22:57:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <099C9E70-D480-49A3-AE12-7CD7B127CD1C@ifi.uio.no> References: <51F7EA81.6080606@internet2.edu> To: Scott Brim X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 6246 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A49DD3A5A39FEEF3AE717DD60374B76E69A3B739 X-UiO-SPAM-Test: remote_host: 46.189.28.122 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 22 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: aqm@ietf.org Subject: Re: [aqm] WG name: QUEUE 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 Jul 2013 20:57:50 -0000 +1 ! But I think the acronym should really only be Q =85but expanded like below. On Jul 30, 2013, at 6:32 PM, Scott Brim wrote: > Since there wasn't any time to talk about the WG name in real time, I > want to heartily endorse Grenville Armitage's suggestion: >=20 > QUEUE -- Queue Utilisation for Enhanced User Experience >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From michael.scharf@alcatel-lucent.com Tue Jul 30 14:42: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 8AC1C11E8125 for ; Tue, 30 Jul 2013 14:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.021, 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 pISwWHVVKaS6 for ; Tue, 30 Jul 2013 14:42:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 07A9311E814F for ; Tue, 30 Jul 2013 14:42:11 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6ULg7Yr008620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 16:42:08 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6ULg5MQ012364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 23:42:06 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 23:42:05 +0200 From: "Scharf, Michael (Michael)" To: Stephen Hemminger Thread-Topic: [aqm] AQM BoF - RTGAREA slides Thread-Index: AQHOjFlF9VbxCADZEkGBHRXN//9UNZl7vU4AgAAfCwCAANwaoIAAqOkAgABf+RA= Date: Tue, 30 Jul 2013 21:42:04 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0791B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130730105410.063e55bf@nehalam.linuxnetplumber.net> In-Reply-To: <20130730105410.063e55bf@nehalam.linuxnetplumber.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Wesley Eddy , "aqm@ietf.org" , Dave Taht , Bob Briscoe Subject: Re: [aqm] AQM BoF - RTGAREA slides 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 Jul 2013 21:42:18 -0000 > > > > The charter reads to me is as much about advice on configuring=20 > > > > existing stuff like RED, as it is about designing new > > > stuff. We don't > > > > want to give the message "the only solution is to rip out > > > everything > > > > you've already bought and buy this new stuff". > > >=20 > > > Seeing RED deployed more where it could matter (like=20 > interprovider=20 > > > interconnects and other fixed rate lines) would be a goodness. > >=20 > > I am just curious: Is there any data that shows *any*=20 > benefit of RED (or whatever other AQM flavor) on a 10G or 100G link? >=20 > The problem is when one link is slower than the data sources, so yes. > When doing 100G to 10G bridging or routing, the same issues=20 > occur but with different timing. Hand-waving is simple. I was wondering about real data showing a problem at= a 10G or 100G link (and, please, no ns-2, we are in the I*E*TF). Michael From dave.taht@gmail.com Tue Jul 30 15:12: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 C978511E8183 for ; Tue, 30 Jul 2013 15:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 EWBAoZQXYK0T for ; Tue, 30 Jul 2013 15:12:52 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2D43D11E8125 for ; Tue, 30 Jul 2013 15:12:52 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so7674668obp.8 for ; Tue, 30 Jul 2013 15:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yU2U6F5R0o7M74RpuTKEl069QQbzE2rTed+Q4jdHQ8M=; b=qwpJttWO2CBo7px5ZNFLmyXr6N8bopNwkf5DCfyND2P4zPnnZDgM5oPBFkcko6K4Xh Bccgm5CAUkPoyNG4+yN2bEw3XbZ5d09IUxIzZBYaAwuLFBfaXUi73AJ350pL+9xV9kYY ieOSuorthe6Mnus8TRs5JbtCpsYskhgDdTXY7FylapoQ5cU1xsp24jfGCtp/v77c7qIg 13lFThpnb4cpYyyzRyyCRfn/mDmx/MA5yxR5fk3DO3rEuL2otAePDV4rXsxJuTOOgDTi tkf5QWw51ypeysxk7ah7D0ozTkpchmUax91sRJJN0s5yTwiZzGFEPbyOC8X28+bbxHmI prnQ== MIME-Version: 1.0 X-Received: by 10.50.65.99 with SMTP id w3mr381887igs.37.1375222370286; Tue, 30 Jul 2013 15:12:50 -0700 (PDT) Received: by 10.64.62.106 with HTTP; Tue, 30 Jul 2013 15:12:50 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D0791B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130730105410.063e55bf@nehalam.linuxnetplumber.net> <655C07320163294895BBADA28372AF5D0791B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 30 Jul 2013 15:12:50 -0700 Message-ID: From: Dave Taht To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Marius Hole , Wesley Eddy , Bob Briscoe , Stephen Hemminger , "Steinar H. Gunderson" , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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 Jul 2013 22:12:53 -0000 On Tue, Jul 30, 2013 at 2:42 PM, Scharf, Michael (Michael) wrote: >> > > > The charter reads to me is as much about advice on configuring >> > > > existing stuff like RED, as it is about designing new >> > > stuff. We don't >> > > > want to give the message "the only solution is to rip out >> > > everything >> > > > you've already bought and buy this new stuff". >> > > >> > > Seeing RED deployed more where it could matter (like >> interprovider >> > > interconnects and other fixed rate lines) would be a goodness. >> > >> > I am just curious: Is there any data that shows *any* >> benefit of RED (or whatever other AQM flavor) on a 10G or 100G link? >> >> The problem is when one link is slower than the data sources, so yes. >> When doing 100G to 10G bridging or routing, the same issues >> occur but with different timing. > > Hand-waving is simple. I was wondering about real data showing a problem = at a 10G or 100G link (and, please, no ns-2, we are in the I*E*TF). > > Michael I don't get much chance to play at speeds higher than 100Mbits. If someone wants to donate a few 10GigE devices to the yurtlab and hardware sufficient to drive them to saturation, I won't mind.... I did gather a TON of packet headers from "the gathering" gaming event earlier this year (if anyone wants a look let me know offline). On the first day they experienced a problem when they attempted to have 3 10GigE fiber ports in action. Slides 20 and 21 here show the sort of latencies that were being experienced by that line before and after it was fixed... They were pumping 10-16Gbit through their connection 24/7... ftp://ftp.gathering.org/TG/2013/Tech/TG13-Dave-Taht-preso.pdf I infer from these plots that there is at least 50ms worth of buffering hiding in the cisco line card at or near the fiber error correction layer. It didn't appear that RED could have been enabled, or it would have helped, but does suggest there be big buffers down there... They ended up just disabling the 3rd line to get to the results shown on slide 21. Steinar or Marius (cc'd) might be able to add more to this convo. A lot of good results came out of that gathering (strong recommendation: more researchers should go next year!) - notably some big performance improvements to htb and the tcp stack - and a better awareness of how to have 5000 wifi devices sharing the same space. http://technet.gathering.org/2013/03/30/wireless-part-2/ --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From michael.scharf@alcatel-lucent.com Tue Jul 30 15:48: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 66BF421E80F6 for ; Tue, 30 Jul 2013 15:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.020, 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 cpyuu8OtYSDM for ; Tue, 30 Jul 2013 15:47:58 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5B21E80E3 for ; Tue, 30 Jul 2013 15:47:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6UMdgrP004992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 17:39:44 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6UMdfLR002539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 00:39:41 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 31 Jul 2013 00:39:40 +0200 From: "Scharf, Michael (Michael)" To: Dave Taht Thread-Topic: [aqm] AQM BoF - RTGAREA slides Thread-Index: AQHOjFlF9VbxCADZEkGBHRXN//9UNZl7vU4AgAAfCwCAANwaoIAAqOkAgABf+RD//+hMAIAAI7hQ Date: Tue, 30 Jul 2013 22:39:39 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07940D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130730105410.063e55bf@nehalam.linuxnetplumber.net> <655C07320163294895BBADA28372AF5D0791B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Marius Hole , Wesley Eddy , Bob Briscoe , Stephen Hemminger , "Steinar H. Gunderson" , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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 Jul 2013 22:48:04 -0000 > >> > > > The charter reads to me is as much about advice on=20 > configuring=20 > >> > > > existing stuff like RED, as it is about designing new > >> > > stuff. We don't > >> > > > want to give the message "the only solution is to rip out > >> > > everything > >> > > > you've already bought and buy this new stuff". > >> > > > >> > > Seeing RED deployed more where it could matter (like > >> interprovider > >> > > interconnects and other fixed rate lines) would be a goodness. > >> > > >> > I am just curious: Is there any data that shows *any* > >> benefit of RED (or whatever other AQM flavor) on a 10G or=20 > 100G link? > >> > >> The problem is when one link is slower than the data=20 > sources, so yes. > >> When doing 100G to 10G bridging or routing, the same=20 > issues occur but=20 > >> with different timing. > > > > Hand-waving is simple. I was wondering about real data=20 > showing a problem at a 10G or 100G link (and, please, no=20 > ns-2, we are in the I*E*TF). > > > > Michael >=20 > I don't get much chance to play at speeds higher than=20 > 100Mbits. If someone wants to donate a few 10GigE devices to=20 > the yurtlab and hardware sufficient to drive them to=20 > saturation, I won't mind.... >=20 > I did gather a TON of packet headers from "the gathering"=20 > gaming event earlier this year (if anyone wants a look let me=20 > know offline). >=20 > On the first day they experienced a problem when they=20 > attempted to have 3 10GigE fiber ports in action. Slides 20=20 > and 21 here show the sort of latencies that were being=20 > experienced by that line before and after it was fixed...=20 > They were pumping 10-16Gbit through their connection 24/7... >=20 > ftp://ftp.gathering.org/TG/2013/Tech/TG13-Dave-Taht-preso.pdf Thanks for sharing the data. But I am not sure if I can parse slide 20 and = 21. Why is y-Axis of the order of tens of Mbit/s on a multiple 10G link? The original phrase I refer to was that "RED could matter at interprovider = connects", and I am looking for real data for that scenario. Michael= From dave.taht@gmail.com Tue Jul 30 16:01:59 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 BF9F021E80E3 for ; Tue, 30 Jul 2013 16:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 tKz8Q6gI05Zn for ; Tue, 30 Jul 2013 16:01:58 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 35B5C21F997B for ; Tue, 30 Jul 2013 16:01:58 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i4so23562oah.9 for ; Tue, 30 Jul 2013 16:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kQUBx3kT87nnqV0Pc0txh38SOAfktBeXcQeIMIdW3nc=; b=NsoOnd18i47nx8rL+pGt4VkoSlnqRa0DG+wXl3H1XNptT9W/Aq9W8pFWXksiySHOkF 1Z2IFHajE/hM9W7zC5c5ESIhHPUBhpntxxmev1Cr5sv7bl3m+t2E4JAenVOnVscHZ15s NVFIKdAbvp4JNcGnQGwYURePY2rlcbwZ1BOIfDSZsmEvFaT/MgWcBlqbzTVS5l/ot2aN eauxwFYoeMM+xLyif4Uc2dHyWPQBIh3iQ3j40y0GQ7+2QmFsUkzyp9iiza/xYUtkjsyl KnjgzZ2nlhPgAUF+yOiBiXDXjTon5kCgaHXCgb7TrgA3KtpHpBONmwTPeXe66kM2YVGh kQ7g== MIME-Version: 1.0 X-Received: by 10.42.37.203 with SMTP id z11mr22126905icd.56.1375225316982; Tue, 30 Jul 2013 16:01:56 -0700 (PDT) Received: by 10.64.62.106 with HTTP; Tue, 30 Jul 2013 16:01:56 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D07940D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130730105410.063e55bf@nehalam.linuxnetplumber.net> <655C07320163294895BBADA28372AF5D0791B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D07940D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 30 Jul 2013 16:01:56 -0700 Message-ID: From: Dave Taht To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Marius Hole , Wesley Eddy , Bob Briscoe , Stephen Hemminger , "Steinar H. Gunderson" , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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 Jul 2013 23:01:59 -0000 On Tue, Jul 30, 2013 at 3:39 PM, Scharf, Michael (Michael) wrote: >> >> > > > The charter reads to me is as much about advice on >> configuring >> >> > > > existing stuff like RED, as it is about designing new >> >> > > stuff. We don't >> >> > > > want to give the message "the only solution is to rip out >> >> > > everything >> >> > > > you've already bought and buy this new stuff". >> >> > > >> >> > > Seeing RED deployed more where it could matter (like >> >> interprovider >> >> > > interconnects and other fixed rate lines) would be a goodness. >> >> > >> >> > I am just curious: Is there any data that shows *any* >> >> benefit of RED (or whatever other AQM flavor) on a 10G or >> 100G link? >> >> >> >> The problem is when one link is slower than the data >> sources, so yes. >> >> When doing 100G to 10G bridging or routing, the same >> issues occur but >> >> with different timing. >> > >> > Hand-waving is simple. I was wondering about real data >> showing a problem at a 10G or 100G link (and, please, no >> ns-2, we are in the I*E*TF). >> > >> > Michael >> >> I don't get much chance to play at speeds higher than >> 100Mbits. If someone wants to donate a few 10GigE devices to >> the yurtlab and hardware sufficient to drive them to >> saturation, I won't mind.... >> >> I did gather a TON of packet headers from "the gathering" >> gaming event earlier this year (if anyone wants a look let me >> know offline). >> >> On the first day they experienced a problem when they >> attempted to have 3 10GigE fiber ports in action. Slides 20 >> and 21 here show the sort of latencies that were being >> experienced by that line before and after it was fixed... >> They were pumping 10-16Gbit through their connection 24/7... >> >> ftp://ftp.gathering.org/TG/2013/Tech/TG13-Dave-Taht-preso.pdf > > Thanks for sharing the data. But I am not sure if I can parse slide 20 an= d 21. Why is y-Axis of the order of tens of Mbit/s on a multiple 10G link? 'cause I was sharing it with 5000+ other users! is part of the explanation, the long tcp ramp up period and normal packet loss from going across the atlantic from norway to the west coast of the USA accounts for some of the rest, bugs for some more, and it's noisy data all along the path... The only relevant bit in those slides to this discussion was the simultaneous latency measurement in the bottommost plot (Aside from the interesting period to the tcp sawtooths over that very long link...) which showed some dark buffering somewhere deep in the line card. I've talked about the structure of the rrul test before elsewhere and on multiple presentations, but it's normal purpose is to load up a link to the best ability of the host and server, and measure latency simultaneously. Here, by accident, it showed that the lines had a problem long before it was diagnosed and fixed... > The original phrase I refer to was that "RED could matter at interprovide= r connects", and I am looking for real data for that scenario. I'd like some too! There are no doubt some members here on nanog, which might be a good place to get some. I ran this test multiple times later over the course of the event, and at no point did the line saturate 20Gbit so latencies stayed flat. So in order to see what happens at 10Gbit, some live testing with hosts sufficient to drive it and routers or switches capable of handling it, would be required. Ivy bridge hardware can run at these rates fairly easily. > Michael --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From bob.briscoe@bt.com Tue Jul 30 22:29:59 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 EDA6121F9B18 for ; Tue, 30 Jul 2013 22:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.127, 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 Z+27kg4CPOD3 for ; Tue, 30 Jul 2013 22:29:53 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id EF57621F9B14 for ; Tue, 30 Jul 2013 22:29:52 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 31 Jul 2013 06:29:50 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 31 Jul 2013 06:29:50 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Wed, 31 Jul 2013 06:29:50 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.37.1]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6V5TgwJ015731; Wed, 31 Jul 2013 06:29:43 +0100 Message-ID: <201307310529.r6V5TgwJ015731@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 31 Jul 2013 06:29:41 +0100 To: "Scharf, Michael (Michael)" From: Bob Briscoe In-Reply-To: <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu. alcatel-lucent.com> References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D07830B@FR712WXCHMBA15.zeu.alcatel-lucent.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: Wesley Eddy , Dave Taht , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 31 Jul 2013 05:30:00 -0000 Michael, The tech report behind the later papers on Data Center TCP (DCTCP) contains data from 19,000 measurements on what the delay was before and after having deployed DCTCP throughout their production Bing data centres on 1Gbps and 10Gbps links. Before (no AQM, 14ms of buffer): * 90% of the time RTT <1ms * 10% of the time RTT 1-14ms After: * with DCTCP: 99% of the time RTT < 0.08ms * with RED: 99% of the time RTT < 0.2ms Around Fig 16 is where they compare DCTCP & RED at 10Gb/s. They make the point that it was hard to config RED, because it gave only 78% utilisation if set at the recommended values for this scenario. But they tuned it up to give 92% before doing the above comparison of delay. I know this isn't inter-provider interconnects, but it fits the figures you asked for. And it confirms my point that, if you've already bought your switch, you can get RED to work to reduce delay without having to throw it away and buy another one. Bob At 06:52 30/07/2013, Scharf, Michael (Michael) wrote: > > > The charter reads to me is as much about advice on configuring > > > existing stuff like RED, as it is about designing new > > stuff. We don't > > > want to give the message "the only solution is to rip out > > everything > > > you've already bought and buy this new stuff". > > > > Seeing RED deployed more where it could matter (like > > interprovider interconnects and other fixed rate lines) would > > be a goodness. > >I am just curious: Is there any data that shows *any* benefit of RED >(or whatever other AQM flavor) on a 10G or 100G link? > >Michael ________________________________________________________________ Bob Briscoe, BT From bob.briscoe@bt.com Tue Jul 30 22:32: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 AC80A21F9B40 for ; Tue, 30 Jul 2013 22:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.102, 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 ZzD62S1zx5MC for ; Tue, 30 Jul 2013 22:32:15 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0D021F9B21 for ; Tue, 30 Jul 2013 22:32:14 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 31 Jul 2013 06:32:13 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 31 Jul 2013 06:32:12 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Wed, 31 Jul 2013 06:32:11 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.37.1]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6V5WAJU015740; Wed, 31 Jul 2013 06:32:10 +0100 Message-ID: <201307310532.r6V5WAJU015740@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 31 Jul 2013 06:32:08 +0100 To: Dave Taht From: Bob Briscoe In-Reply-To: References: <51F6633B.8000509@mti-systems.com> <201307291650.r6TGojBh009833@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] AQM BoF - RTGAREA slides 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, 31 Jul 2013 05:32:19 -0000 Dave, If you're implementing or turning on an AQM, you=20 know whether you have a variable rate link or not. My point was that we need to give useful advice=20 to different interest groups, not just push new=20 solutions without saying old ones still have sound applicability areas. Bob At 19:41 29/07/2013, Dave Taht wrote: >On Mon, Jul 29, 2013 at 9:50 AM, Bob Briscoe wrote: > > Wes, > > > > #4 "Bufferbloat exists in routers, lower-layer switches, and other > > middleboxes " > > ...and hosts (altho not of such interest to=20 > RTG, this is also educating them > > on what we're doing) > > > > Gap: They wlil want to know whether we are talking about big iron= routers, > > big iron switches, access nodes, home hubs, etc. So we need to say the > > problem is mainly in access and edge equipment but you see it= everywhere. > > (They will want to know whether we are treading on what they perceive as > > their territory.) > > > > #5 "separation into multiple queues" implies=20 > particular solutions. I suggest > > you just say "traffic isolation". > > > > #9 The statements about RED are over-negative. It's not that it isn't an > > effective solution to bufferbloat if correctly configured (as all the= tests > > so far have shown). It's that it's hard to configure. > >It's not just that it's hard to configure. It's *impossible* to >configure for links of wildly varying bandwidth such as wifi and other >forms of wireless. > >RED was designed for fixed bandwidth p2p links, like what you got in >the good ole days with a T1 line. > >Other forms of shared links (cable for example) also have varying link >rates that are hard to respond to in RED. > >That said, I've got no problem with this wg generating clear >guidelines on when and where and HOW to configure RED and other >smarter queue management algorithms. > > > The charter reads to me is as much about advice on configuring existing > > stuff like RED, as it is about designing new stuff. We don't want to= give > > the message "the only solution is to rip out everything you've already > > bought and buy this new stuff". > >Seeing RED deployed more where it could matter (like interprovider >interconnects and other fixed rate lines) would be a goodness. > > > HTH > > > > > > Bob > > > > > > > > > > At 13:42 29/07/2013, Wesley Eddy wrote: > >> > >> As BoF chairs, we were asked to talk to the RTGAREA meeting > >> at this week's IETF about the AQM BoF and what we're doing. > >> > >> The slides I'm planning to discuss there are: > >> http://www.ietf.org/proceedings/87/slides/slides-87-aqm-3.pptx > >> > >> -- > >> Wes Eddy > >> MTI Systems > >> _______________________________________________ > >> aqm mailing list > >> aqm@ietf.org > >> https://www.ietf.org/mailman/listinfo/aqm > > > > > > ________________________________________________________________ > > Bob Briscoe, BT > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > > > >-- >Dave T=E4ht > >Fixing bufferbloat with cerowrt:=20 >http://www.teklibre.com/cerowrt/subscribe.html ________________________________________________________________ Bob Briscoe, BT=20 From ghanwani@gmail.com Wed Jul 31 05:39:06 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 62C7221F9644 for ; Wed, 31 Jul 2013 05:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.214 X-Spam-Level: X-Spam-Status: No, score=-1.214 tagged_above=-999 required=5 tests=[AWL=0.536, 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 StslmSR--hO5 for ; Wed, 31 Jul 2013 05:39:05 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FF21F9D9B for ; Wed, 31 Jul 2013 05:37:08 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so559673wes.3 for ; Wed, 31 Jul 2013 05:37:07 -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=CJRy98exMdUNHqD2/1k4FFymRjEJtoWdkNNnJmSje+Q=; b=cFalEAfD/IR9CdBCyo1JKHjBi/paZnXea2Cs8STANuwtEgvZgEJfFWo3QHxuuGBV/o s6VHJg4+ekWSeVtV/0ORgdixKSDBMfXWyE9iGedEWs9k4bOfsSGZubzNe3NGLCpe1op1 OzK3D/H2SFA47k4/1iU89JMcoAZSxCAyu1DpDPaL38DRJ8gOub67XwUk8+BArw1v3j41 ehR49tlJvSNeK28BRkRQ/QWlOzyqU9M1qHsP/B/c7AyviTk0K7HSFrWZ83TqFl3pb0S6 PrNdlJ9xRIOYS+vftsDsiRxjzAYHm2ZTTiHbEAArc2/AIGNPFwtJPbsWanBcvrMmGfM4 ZsnA== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr4131034wic.60.1375274227670; Wed, 31 Jul 2013 05:37:07 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.70.73 with HTTP; Wed, 31 Jul 2013 05:37:07 -0700 (PDT) In-Reply-To: <099C9E70-D480-49A3-AE12-7CD7B127CD1C@ifi.uio.no> References: <51F7EA81.6080606@internet2.edu> <099C9E70-D480-49A3-AE12-7CD7B127CD1C@ifi.uio.no> Date: Wed, 31 Jul 2013 05:37:07 -0700 X-Google-Sender-Auth: CrTzRh2l1rghgH8Lvjvw4c0KADM Message-ID: From: Anoop Ghanwani To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c26a5ecf244904e2cdfb74 Cc: Scott Brim , "" Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 12:39:06 -0000 --001a11c26a5ecf244904e2cdfb74 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable These sound good, but they are not web-search friendly. When I search for "queue wg ietf", I get things like the RFC editor queue. Anoop On Tue, Jul 30, 2013 at 1:57 PM, Michael Welzl wrote: > +1 ! > > But I think the acronym should really only be > > Q > > =85but expanded like below. > > > On Jul 30, 2013, at 6:32 PM, Scott Brim wrote: > > > Since there wasn't any time to talk about the WG name in real time, I > > want to heartily endorse Grenville Armitage's suggestion: > > > > QUEUE -- Queue Utilisation for Enhanced User Experience > > > > _______________________________________________ > > 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 > --001a11c26a5ecf244904e2cdfb74 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
These sound good, but they are not web-search friendly. Wh= en I search for "queue wg ietf", I get things like the RFC editor= queue.

Anoop

=
On Tue, Jul 30, 2013 at 1:57 PM, Michael Welzl <= span dir=3D"ltr"><michawe@ifi.uio.no> wrote:


On Jul 30, 2013, at 6:32 PM, Scott Brim <swb@internet2.edu> wrote:

> Since there wasn't any time to talk about the WG name in real time= , I
> want to heartily endorse Grenville Armitage's suggestion:
>
> =A0QUEUE -- Queue Utilisation for Enhanced User Experience
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

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

--001a11c26a5ecf244904e2cdfb74-- From swb@internet2.edu Wed Jul 31 05:40: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 4BFC121F9E11 for ; Wed, 31 Jul 2013 05:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-2.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNRESOLVED_TEMPLATE=3.132] 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 X09lLpqgW2+X for ; Wed, 31 Jul 2013 05:40:32 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25021F9B8D for ; Wed, 31 Jul 2013 05:39:40 -0700 (PDT) Received: from mail141-db9-R.bigfish.com (10.174.16.232) by DB9EHSOBE029.bigfish.com (10.174.14.92) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 12:39:39 +0000 Received: from mail141-db9 (localhost [127.0.0.1]) by mail141-db9-R.bigfish.com (Postfix) with ESMTP id 5D80D2E01B5; Wed, 31 Jul 2013 12:39:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.149; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0810HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: S1(zzbb2dI98dIc857hzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h18c673h8275bh1de097hz2dh2a8h668h839he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail141-db9 (localhost.localdomain [127.0.0.1]) by mail141-db9 (MessageSwitch) id 1375274377405934_7022; Wed, 31 Jul 2013 12:39:37 +0000 (UTC) Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.236]) by mail141-db9.bigfish.com (Postfix) with ESMTP id 543F02C0059; Wed, 31 Jul 2013 12:39:37 +0000 (UTC) Received: from CH1PRD0810HT005.namprd08.prod.outlook.com (157.56.245.149) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 12:39:37 +0000 Received: from CH1PRD0810MB395.namprd08.prod.outlook.com ([169.254.11.97]) by CH1PRD0810HT005.namprd08.prod.outlook.com ([10.255.145.168]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 12:39:35 +0000 From: Scott Brim To: Anoop Ghanwani , Michael Welzl Thread-Topic: [aqm] WG name: QUEUE Thread-Index: Ac6NQlPy37d/ZSGlSP+jKEG71Cjw2QAJRfaAACDPyYAABEZ9AA== Date: Wed, 31 Jul 2013 12:39:35 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.110.4] Content-Type: multipart/alternative; boundary="_000_CE1ED20815F31swbinternet2edu_" MIME-Version: 1.0 X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALUMNI.DUKE.EDU$RO%1$TLS%0$FQDN%$TlsDn% Cc: "" Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 12:40:38 -0000 --_000_CE1ED20815F31swbinternet2edu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMDcvMzEvMTMgMTQ6MzcsICJBbm9vcCBHaGFud2FuaSIgPGFub29wQGFsdW1uaS5kdWtlLmVk dTxtYWlsdG86YW5vb3BAYWx1bW5pLmR1a2UuZWR1Pj4gYWxsZWdlZGx5IHdyb3RlOg0KDQpUaGVz ZSBzb3VuZCBnb29kLCBidXQgdGhleSBhcmUgbm90IHdlYi1zZWFyY2ggZnJpZW5kbHkuIFdoZW4g SSBzZWFyY2ggZm9yICJxdWV1ZSB3ZyBpZXRmIiwgSSBnZXQgdGhpbmdzIGxpa2UgdGhlIFJGQyBl ZGl0b3IgcXVldWUuDQoNCkRvIHlvdSB0aGluayB0aGF0IG1pZ2h0IGNoYW5nZSB3aGVuIHRoZXJl J3MgYSB3b3JraW5nIGdyb3VwPyAoIDotKSApDQoNCg== --_000_CE1ED20815F31swbinternet2edu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+T24gMDcvMzEv MTMgMTQ6MzcsICZxdW90O0Fub29wIEdoYW53YW5pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 YW5vb3BAYWx1bW5pLmR1a2UuZWR1Ij5hbm9vcEBhbHVtbmkuZHVrZS5lZHU8L2E+Jmd0OyBhbGxl Z2VkbHkgd3JvdGU6PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5U aGVzZSBzb3VuZCBnb29kLCBidXQgdGhleSBhcmUgbm90IHdlYi1zZWFyY2ggZnJpZW5kbHkuIFdo ZW4gSSBzZWFyY2ggZm9yICZxdW90O3F1ZXVlIHdnIGlldGYmcXVvdDssIEkgZ2V0IHRoaW5ncyBs aWtlIHRoZSBSRkMgZWRpdG9yIHF1ZXVlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvIHlvdSB0aGluayB0aGF0 IG1pZ2h0IGNoYW5nZSB3aGVuIHRoZXJlJ3MgYSB3b3JraW5nIGdyb3VwPyAoIDotKSApPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE1ED20815F31swbinternet2edu_-- From ghanwani@gmail.com Wed Jul 31 05:42:37 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 81A1221F9EFC for ; Wed, 31 Jul 2013 05:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=0.358, 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 d0OBLgqzjWyM for ; Wed, 31 Jul 2013 05:42:37 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8D21F9EEC for ; Wed, 31 Jul 2013 05:42:34 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id a12so538629wgh.18 for ; Wed, 31 Jul 2013 05:42:33 -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=ZxC2gl6MUd6RJ7Xfj2YqeCqcKRvwgZS3KmotJFlQo9A=; b=V1mEij7lQCSuP7ygsTWyRRu4c4DTkLiHP+ewRxS+C05DAvrT1B93tnZfvOuCvK84wL 9CL9enni+C34luFsx5TGNRXFXrdKciRnHDR+YuDnrAPfzO8s/N0ry8UW+nbpQmBw6m1z 9GYt6Goh/GRoUp7o202M79oYFDQ8eSXCASnpkwRQ4m1Rm5QJyTMB/ByViUFQyj3plCax WYTkPLVdXIQ74DrwG5ZVdoBZ9wpWmKWc82ND0zhclbCQr5AxZRaXjRGHtONr8g7Gsf/v BuwBWyRhrqk1rXX6bG1pL+bOxliVVWiAM4yfHmCSmxAIThW0niWXqGAqAen/HY/EiUqo 1CHQ== MIME-Version: 1.0 X-Received: by 10.180.75.16 with SMTP id y16mr4190872wiv.59.1375274553514; Wed, 31 Jul 2013 05:42:33 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.70.73 with HTTP; Wed, 31 Jul 2013 05:42:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 05:42:33 -0700 X-Google-Sender-Auth: uCq8M93dBGOJ1uCokBDpfQqNkBo Message-ID: From: Anoop Ghanwani To: Scott Brim Content-Type: multipart/alternative; boundary=f46d043c7d223b203904e2ce0ff6 Cc: "" , Michael Welzl Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 12:42:37 -0000 --f46d043c7d223b203904e2ce0ff6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 31, 2013 at 5:39 AM, Scott Brim wrote: > On 07/31/13 14:37, "Anoop Ghanwani" allegedly > wrote: > > These sound good, but they are not web-search friendly. When I search > for "queue wg ietf", I get things like the RFC editor queue. > > > Do you think that might change when there's a working group? ( :-) ) > > Valid point. --f46d043c7d223b203904e2ce0ff6 Content-Type: text/html; charset=ISO-8859-1



On Wed, Jul 31, 2013 at 5:39 AM, Scott Brim <swb@internet2.edu> wrote:
On 07/31/13 14:37, "Anoop Ghanwani" <anoop@alumni.duke.edu> allegedly wrote:

These sound good, but they are not web-search friendly. When I search for "queue wg ietf", I get things like the RFC editor queue.

Do you think that might change when there's a working group? ( :-) )

Valid point.
--f46d043c7d223b203904e2ce0ff6-- From andrewmcgr@google.com Wed Jul 31 06:15: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 854D211E8178 for ; Wed, 31 Jul 2013 06:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 50lbQEWovXu0 for ; Wed, 31 Jul 2013 06:15:50 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C881811E8100 for ; Wed, 31 Jul 2013 06:15:49 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id m15so247367qcq.28 for ; Wed, 31 Jul 2013 06:15:49 -0700 (PDT) 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; bh=6jOUUAgDcFBgR6/LuIdLnYjSek82ZDgTbkgOXQHxxdQ=; b=Y/B8LRQTB4ykCrhD+rYLWsHA8q1uUQNRURqOu9TQMjE799vBMLlyUueT4SUdMCNVsj QbQJz79NgwU1gY7BZIrEVRqi3fokMjRGbioEkIYWYb0r59h56P18ucMogYUYRnnTTb3z d1oFaHp8xRQZn97OH10jInb/Mq388Kk34cU2rewMG4OTyHgjAMy9hKYVJFYPIc19+FB9 GkeSOBUSIP7KoaoibiIiit1ctvdYXSxwPCLiwPOWqvLdlrAWVgO+2WOjxmvMY/JX0ooh 4J1zs6yMGriWRzE4qGmZlw1NTilnEqABOEZ/FmrNYyWdAItM0kl1gqfMW0t4jw38lBAt KBTw== 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=6jOUUAgDcFBgR6/LuIdLnYjSek82ZDgTbkgOXQHxxdQ=; b=QB7tPdcMWcQBxdLyBB8YEW+h0iyYl7WAXF1BEPn7HzOzcJPhxhWwZXRBjybxvXuJhb 65gZgFopluk7dIPBe2nGEvxhXkvKIRqIgx+STgZ8t3YZcfPzzFfdqHpZLHxr3/IPsAWz soLlsHsSXPLXGBAsxsYCc10aUoLFMhGGseBAZE64C6eFpwQ01aMGEpCN2uX0bJAKh3Wb 6pDThxTFaX86RiNLCqM2UJjAHQFGA5Evt37xbIxypQPMA4aWkIQ0Xor0pQLU+aBVgz/l OuM0CoFViY5Yp9rv6h9Kbzvs/iYunXhpJrQCOm5WcWSocJL5IHhVIXyRKjJd6QITxhOt T0GQ== MIME-Version: 1.0 X-Received: by 10.49.35.108 with SMTP id g12mr84901300qej.86.1375276549100; Wed, 31 Jul 2013 06:15:49 -0700 (PDT) Received: by 10.224.137.196 with HTTP; Wed, 31 Jul 2013 06:15:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 06:15:49 -0700 Message-ID: From: Andrew Mcgregor To: Anoop Ghanwani Content-Type: multipart/alternative; boundary=047d7b67853e2d8d6e04e2ce86d2 X-Gm-Message-State: ALoCoQnQIh/atJzRIfaQuGzIAJyAMgU4PHw3+1PT+6IoMPTlqdyLbuRAuwOgHF2soJo496WnrhLXr+uBD1VzcLhDyCzJmvfK7yUyJ0nPur+q0B0TN4awUsglExQzrueVTyWGdS8deC8h8w8qfQWWaATsf5ArV6nRo0/NLc6Y4do7KWujBwKBJTfmAPBWG4ahUJy5sjti3USc Cc: Scott Brim , "" , Michael Welzl Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 13:15:50 -0000 --047d7b67853e2d8d6e04e2ce86d2 Content-Type: text/plain; charset=ISO-8859-1 So I guess it should be qwg then? On 31 July 2013 05:42, Anoop Ghanwani wrote: > > > > On Wed, Jul 31, 2013 at 5:39 AM, Scott Brim wrote: > >> On 07/31/13 14:37, "Anoop Ghanwani" allegedly >> wrote: >> >> These sound good, but they are not web-search friendly. When I search >> for "queue wg ietf", I get things like the RFC editor queue. >> >> >> Do you think that might change when there's a working group? ( :-) ) >> >> Valid point. > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --047d7b67853e2d8d6e04e2ce86d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So I guess it should be qwg then?


On 31 July 2013 05:42, Anoop Gha= nwani <anoop@alumni.duke.edu> wrote:



On Wed, Jul 3= 1, 2013 at 5:39 AM, Scott Brim <swb@internet2.edu> wrote:
On 07/31/13 14:37, "Anoop Ghanwani" <anoop@alumni.duke.edu> allege= dly wrote:

These sound good, but they are not web-search friendly. Wh= en I search for "queue wg ietf", I get things like the RFC editor= queue.

Do you think that might change when there's a working group? ( :-)= )

Valid point.

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




--
Andrew McGregor=A0|<= /span>=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--047d7b67853e2d8d6e04e2ce86d2-- From swb@internet2.edu Wed Jul 31 06:18:01 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 447C021F940D for ; Wed, 31 Jul 2013 06:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, UNRESOLVED_TEMPLATE=3.132] 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 ZZjU0B6L+CWe for ; Wed, 31 Jul 2013 06:17:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2162A11E8147 for ; Wed, 31 Jul 2013 06:17:27 -0700 (PDT) Received: from mail131-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 13:17:26 +0000 Received: from mail131-ch1 (localhost [127.0.0.1]) by mail131-ch1-R.bigfish.com (Postfix) with ESMTP id 152101601A2; Wed, 31 Jul 2013 13:17:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.149; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0810HT004.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: S1(zzbb2dI98dIc857hzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h18c673h8275bh1de097hz2dh2a8h668h839he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail131-ch1 (localhost.localdomain [127.0.0.1]) by mail131-ch1 (MessageSwitch) id 137527664493499_11923; Wed, 31 Jul 2013 13:17:24 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail131-ch1.bigfish.com (Postfix) with ESMTP id 12427A0047; Wed, 31 Jul 2013 13:17:24 +0000 (UTC) Received: from CH1PRD0810HT004.namprd08.prod.outlook.com (157.56.245.149) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 13:17:23 +0000 Received: from CH1PRD0810MB395.namprd08.prod.outlook.com ([169.254.11.97]) by CH1PRD0810HT004.namprd08.prod.outlook.com ([10.255.145.167]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 13:17:23 +0000 From: Scott Brim To: Andrew Mcgregor , Anoop Ghanwani Thread-Topic: [aqm] WG name: QUEUE Thread-Index: Ac6NQlPy37d/ZSGlSP+jKEG71Cjw2QAJRfaAACDPyYAABEZ9AP//31CAgAAJTICAACHygA== Date: Wed, 31 Jul 2013 13:17:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.110.4] Content-Type: multipart/alternative; boundary="_000_CE1EDAE415F5Fswbinternet2edu_" MIME-Version: 1.0 X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALUMNI.DUKE.EDU$RO%1$TLS%0$FQDN%$TlsDn% Cc: "" , Michael Welzl Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 13:18:01 -0000 --_000_CE1EDAE415F5Fswbinternet2edu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMDcvMzEvMTMgMTU6MTUsICJBbmRyZXcgTWNncmVnb3IiIDxhbmRyZXdtY2dyQGdvb2dsZS5j b208bWFpbHRvOmFuZHJld21jZ3JAZ29vZ2xlLmNvbT4+IGFsbGVnZWRseSB3cm90ZToNCg0KU28g SSBndWVzcyBpdCBzaG91bGQgYmUgcXdnIHRoZW4/DQoNClByb25vdW5jZWQgaW4gdGhlIHVzdWFs IFdlbHNoIHdheS4NCg0K --_000_CE1EDAE415F5Fswbinternet2edu_ Content-Type: text/html; charset="utf-8" Content-ID: <7CAD1B6EB219E840A95C281C4767CBF2@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+T24gMDcvMzEv MTMgMTU6MTUsICZxdW90O0FuZHJldyBNY2dyZWdvciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFuZHJld21jZ3JAZ29vZ2xlLmNvbSI+YW5kcmV3bWNnckBnb29nbGUuY29tPC9hPiZndDsgYWxs ZWdlZGx5IHdyb3RlOjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6 MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ U28gSSBndWVzcyBpdCBzaG91bGQgYmUgcXdnIHRoZW4/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UHJvbm91bmNl ZCBpbiB0aGUgdXN1YWwgV2Vsc2ggd2F5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CE1EDAE415F5Fswbinternet2edu_-- From lars@netapp.com Wed Jul 31 07:30: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 B812A21E80EF for ; Wed, 31 Jul 2013 07:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.883 X-Spam-Level: X-Spam-Status: No, score=-8.883 tagged_above=-999 required=5 tests=[AWL=1.489, 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 HWBFoiMYXCtw for ; Wed, 31 Jul 2013 07:30:07 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C556A21E8125 for ; Wed, 31 Jul 2013 07:29:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,787,1367996400"; d="asc'?scan'208";a="77457024" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 31 Jul 2013 07:29:41 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 07:29:41 -0700 From: "Eggert, Lars" To: Scott Brim Thread-Topic: [aqm] WG name: QUEUE Thread-Index: AQHOjUMFPdOLcyGBW0qqFgiHGV33sZl+KaqAgAEGfoCAAACxgIAAANSAgAAJS4CAAABwgIAAFDIA Date: Wed, 31 Jul 2013 14:29:41 +0000 Message-ID: <2311CC8A-5505-49ED-A2FB-AC8431A2257F@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_8EE62C6B-681E-41A9-97BE-899226CE92B1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Andrew Mcgregor , Anoop Ghanwani , "" , Michael Welzl Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 14:30:17 -0000 --Apple-Mail=_8EE62C6B-681E-41A9-97BE-899226CE92B1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii LOQUS as in "Long Queus Suck" --Apple-Mail=_8EE62C6B-681E-41A9-97BE-899226CE92B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUfkfVNZcnpRveo1xAQL27AP7BsF+phVcMEk/RqaXZCQe+lhgu8+Xc2oc CxV6X8e5sBAh/zhVAniXS7pIx5CVeoRRP6J3ekuwAf3GxFyHz4MM7oZ6T71+BsaC ZlWO9tjAFn8Z6Mh0YmqBRZWyiywMa7mfOp7Kg6RMiervF4oOKyiHRM9asN0VK5dQ EsvdbbBXq1E= =+PKQ -----END PGP SIGNATURE----- --Apple-Mail=_8EE62C6B-681E-41A9-97BE-899226CE92B1-- From rs@netapp.com Wed Jul 31 08:42:24 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 52ECF21F9971 for ; Wed, 31 Jul 2013 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.056 X-Spam-Level: X-Spam-Status: No, score=-7.056 tagged_above=-999 required=5 tests=[AWL=3.315, 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 XeoS+U17t5x7 for ; Wed, 31 Jul 2013 08:42:14 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2011221F9FC8 for ; Wed, 31 Jul 2013 08:42:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,788,1367996400"; d="txt'?scan'208,217";a="271032741" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx1-out.netapp.com with ESMTP; 31 Jul 2013 08:42:14 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.107]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 08:42:13 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: Interesting work on AQM for ICCRG Thread-Index: Ac6H6cRQOKq8ZyagQTa39LuYcWZlsgA06HswAU616TA= Date: Wed, 31 Jul 2013 15:42:12 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C45FF2@SACEXCMBX02-PRD.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: multipart/mixed; boundary="_004_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_" MIME-Version: 1.0 Subject: [aqm] FW: Interesting work on AQM for ICCRG 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, 31 Jul 2013 15:42:25 -0000 --_004_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_ Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_" --_000_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI From: iccrg-bounces@irtf.org [mailto:iccrg-bounces@irtf.org] On Behalf Of A= khtar, Shahid (Shahid) Sent: Donnerstag, 25. Juli 2013 16:12 To: iccrg@irtf.org Cc: Benno, Steven (Steven); Scharf, Michael (Michael); Sharpe, Randall B (R= andy); Robinson, Dave C (Dave); David Ros; Francini, Andrea (Andrea) Subject: Re: [iccrg] Interesting work on AQM for ICCRG Hi All, This talk has been scheduled for the ICCRG in Vancouver in Nov. We will pro= vide more details at that time. Thanks. -Shahid. ________________________________ From: iccrg-bounces@irtf.org [mailto:iccrg-b= ounces@irtf.org] On Behalf Of Akhtar, Shahid (Shahid) Sent: Tuesday, July 23, 2013 4:15 PM To: iccrg@irtf.org Cc: Benno, Steven (Steven); Scharf, Michael (Michael); Sharpe, Randall B (R= andy); Robinson, Dave C (Dave); David Ros; Francini, Andrea (Andrea) Subject: [iccrg] Interesting work on AQM for ICCRG Hi All, We wanted to let to you know that we have some interesting results and were= hoping to present at this ICCRG meeting, but unfortunaley the agenda is fu= ll already. Below is an extended abstract of the work. Shahid Akhtar Alcatel-Lucent. shahid.akhtar@alcatel-lucent.com An Evaluation of Various AQM techniques on Access Networks with Realistic I= nternet Traffic Using NS2 we built a set of simulation scenarios for realistic Internet tra= ffic. We tested AQM techniques for their ability to influence end-customer = QoE. Based on data from recent measurements, there are three major types of= traffic flowing through the Internet: HTTP web traffic, HTTP adaptive stre= aming (HAS) video traffic (e.g., from Netflix), and progressive download vi= deo traffic (e.g., from YouTube). We modeled HTTP 1.1 and HTTP 2.0 web traffic using Internet statistics publ= ished by Google. We generated dynamic HAS traffic by implementing a HAS cli= ent that adjusts its rate according to network conditions. We modeled YouTu= be traffic with realtistic Pareto-based file size distribution and inter-re= quest time distribution. We used published research to convert data from the simulation traces into = typical QoE metrics for the different types of traffic: Predicted Mean Opin= ion Score (P-MOS) for HAS traffic, page load time for HTTP web traffic, and= percentage of time that 480p or 720p video can be played for YouTube traff= ic. We used realstic mixes of the three types of traffic with different loading= conditions to test various AQM techniques (several Random Early Detection = (RED) configurations and CoDel) on access networks (CO-based DSL and Cable)= under typical operating conditions. We derived the following key observations from our experiments: * Most AQM configurations improved the performance of HAS significa= ntly over Tail-Drop: AQM improves fairness and stability among HAS streams = and avoids HAS stalls (underflow) in a majority of the cases where they wou= ld occur with Tail-Drop. * Most AQM configurations improved Web traffic performance, enablin= g slightly higher throughput and significantly lower page download times (u= p to 40% reduction). * However progessive download flows like YouTube showed better perf= ormance under Tail-drop conditions - both throughput and end-user QoE metri= cs * Using HTTP 2.0 based web traffic (instead of HTTP 1.1), we found = that the page load times dramatically improved (50% lower), but there was a= reduction in HAS and YouTube performance. * The performance of one set of RED parameters consistently produce= d QoE in the top range amongst the scenarios. This indicates that it may be= possible to improve user experience using specific fixed configurations in= existing hardware. --_000_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

 <= /p>

 <= /p>

From: iccrg-bounces@irtf.org [mailto:iccrg-bounces@irtf.org= ] On Behalf Of Akhtar, Shahid (Shahid)
Sent: Donnerstag, 25. Juli 2013 16:12
To: iccrg@irtf.org
Cc: Benno, Steven (Steven); Scharf, Michael (Michael); Sharpe, Randa= ll B (Randy); Robinson, Dave C (Dave); David Ros; Francini, Andrea (Andrea)=
Subject: Re: [iccrg] Interesting work on AQM for ICCRG

 

Hi All,

 

This talk has been scheduled f= or the ICCRG in Vancouver in Nov. We will provide more details at that time= .

 

Thanks.

 

-Shahid.

 

From: iccrg-bounces@irtf.org [mailto:iccrg-bounces@irtf.org] On Behalf Of Akhtar, Shahid (Shahid)
Sent: Tuesday, July 23, 2013 4:15 PM
To: iccrg@irtf.org
Cc: Benno, Steven (Steven); Scharf, Michael (Michael); Sharpe, Randa= ll B (Randy); Robinson, Dave C (Dave); David Ros; Francini, Andrea (Andrea)=
Subject: [iccrg] Interesting work on AQM for ICCRG

Hi All,=

 

We wanted to let to you know t= hat we have some interesting results and were hoping to present at this ICC= RG meeting, but unfortunaley the agenda is full already. Below is an extended abstract of the work.

 

Shahid Akhtar

Alcatel-Lucent.

 

An Evaluation of Various AQM technique= s on Access Networks with Realistic Internet Traffic=

Using NS2 we built a set of simulation sc= enarios for realistic Internet traffic. We tested AQM techniques for their = ability to influence end-customer QoE. Based on data from recent measurements, there are three major types of traffic fl= owing through the Internet: HTTP web traffic, HTTP adaptive streaming (HAS)= video traffic (e.g., from Netflix), and progressive download video traffic= (e.g., from YouTube).

We modeled HTTP 1.1 and HTTP 2.0 web traf= fic using Internet statistics published by Google. We generated dynamic HAS= traffic by implementing a HAS client that adjusts its rate according to network conditions. We modeled YouTube traffic with realtisti= c Pareto-based file size distribution and inter-request time distribution.<= o:p>

We used published research to convert dat= a from the simulation traces into typical QoE metrics for the different typ= es of traffic: Predicted Mean Opinion Score (P-MOS) for HAS traffic, page load time for HTTP web traffic, and percentage of time t= hat 480p or 720p video can be played for YouTube traffic.=

We used realstic mixes of the three types= of traffic with different loading conditions to test various AQM technique= s (several Random Early Detection (RED) configurations and CoDel) on access networks (CO-based DSL and Cable) under typical operating= conditions.

We derived the following key observations= from our experiments:

·         Most AQM configurations improved = the performance of HAS significantly over Tail-Drop: AQM improves fairness = and stability among HAS streams and avoids HAS stalls (underflow) in a majority of the cases where they would occur with Tail-Dr= op.

·         Most AQM configurations improved = Web traffic performance, enabling slightly higher throughput and significan= tly lower page download times (up to 40% reduction).

·         However progessive download flows= like YouTube showed better performance under Tail-drop conditions - both t= hroughput and end-user QoE metrics

·         Using HTTP 2.0 based web traffic = (instead of HTTP 1.1), we found that the page load times dramatically impro= ved (50% lower), but there was a reduction in HAS and YouTube performance.

·         The performance of one set of RED= parameters consistently produced QoE in the top range amongst the scenario= s. This indicates that it may be possible to improve user experience using specific fixed configurations in existing hardware.<= /o:p>

 =

 

 

 

 

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_-- --_004_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Thu, 25 Jul 2013 14:14:26 GMT"; modification-date="Thu, 25 Jul 2013 14:14:26 GMT" Content-ID: <17C29AD09A09FF47AB3144A3BD43187C@hq.netapp.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmljY3JnIG1h aWxpbmcgbGlzdA0KaWNjcmdAaXJ0Zi5vcmcNCmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vaWNjcmcNCg== --_004_012C3117EDDB3C4781FD802A8C27DD4F25C45FF2SACEXCMBX02PRDh_-- From rs@netapp.com Wed Jul 31 08:57: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 D54E421F97E6 for ; Wed, 31 Jul 2013 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[AWL=-1.348, 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 s2XRh3J3czQS for ; Wed, 31 Jul 2013 08:57:05 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC4121F9D7A for ; Wed, 31 Jul 2013 08:57:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,788,1367996400"; d="scan'208";a="37932712" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 31 Jul 2013 08:56:57 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.107]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 08:56:56 -0700 From: "Scheffenegger, Richard" To: Michael Welzl , Scott Brim Thread-Topic: [aqm] WG name: QUEUE Thread-Index: AQHOjUMFj20J4XxAsUy/9TlXLwHzRZl+KaqAgADHKIA= Date: Wed, 31 Jul 2013 15:56:56 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C46107@SACEXCMBX02-PRD.hq.netapp.com> References: <51F7EA81.6080606@internet2.edu> <099C9E70-D480-49A3-AE12-7CD7B127CD1C@ifi.uio.no> In-Reply-To: <099C9E70-D480-49A3-AE12-7CD7B127CD1C@ifi.uio.no> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 15:57:13 -0000 Actually, I just received word that most (all) tools should handle single-c= haracter WG names. So, a Working group name "Q" - pronounced like "QUEUE", and a long name as = below, would be possible if this is agreeable... So far, the most support was for QUEUE/Q and SQM, apart from the default AQ= M, as name of the WG... Richard Scheffenegger > -----Original Message----- > From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of > Michael Welzl > Sent: Dienstag, 30. Juli 2013 22:58 > To: Scott Brim > Cc: aqm@ietf.org > Subject: Re: [aqm] WG name: QUEUE >=20 > +1 ! >=20 > But I think the acronym should really only be >=20 > Q >=20 > ...but expanded like below. >=20 >=20 > On Jul 30, 2013, at 6:32 PM, Scott Brim wrote: >=20 > > Since there wasn't any time to talk about the WG name in real time, I > > want to heartily endorse Grenville Armitage's suggestion: > > > > QUEUE -- Queue Utilisation for Enhanced User Experience > > > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From gettysjim@gmail.com Wed Jul 31 11:20:57 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 9141411E81B1 for ; Wed, 31 Jul 2013 11:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=0.720, 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 T4FGxcMcgj5P for ; Wed, 31 Jul 2013 11:20:56 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5601F11E81B3 for ; Wed, 31 Jul 2013 11:20:56 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so2209530oag.4 for ; Wed, 31 Jul 2013 11:20:48 -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=9blvp7LPt0R/l90ZnpJjZYhq0b9V6Lj/seBWe7t4QpI=; b=MuB81BlvaOxzcQiFzoBKOXnRazYNrRoPkKsAtucnx6aLUwtqXIGhKiI6ofaB68zy8Y 7nQpav0TvlYmHBtC7OhD6s7wg5roh6gTaY5RVdAofo64HYyBW6A8xQ9LnAuhzjNQfccc HsagrO38DLoln3jdbG2lkhlc5l0QaynjOIZYfZTHMzck3On0ySDW/ODqsJQ+gFfKZIZ2 6rkU5ZNPMqx3hMAL1bQaluafKk8XouuXxpVvGpMVu1rQrNK5TfEOOwjoqof0Id7qSmKg hwWWsUpU07cVgHc7G5xuGzlI4Kqk1wDiXA0W3uQBnkBcmfMjToU8dqTM/wUSQdA1IgHv cdzQ== MIME-Version: 1.0 X-Received: by 10.60.52.16 with SMTP id p16mr25037695oeo.29.1375294848231; Wed, 31 Jul 2013 11:20:48 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.144.67 with HTTP; Wed, 31 Jul 2013 11:20:48 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C46107@SACEXCMBX02-PRD.hq.netapp.com> References: <51F7EA81.6080606@internet2.edu> <099C9E70-D480-49A3-AE12-7CD7B127CD1C@ifi.uio.no> <012C3117EDDB3C4781FD802A8C27DD4F25C46107@SACEXCMBX02-PRD.hq.netapp.com> Date: Wed, 31 Jul 2013 20:20:48 +0200 X-Google-Sender-Auth: 7hPkYI78ZczDNEUeOROyfPDX8JA Message-ID: From: Jim Gettys To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=001a11330b22e3f06e04e2d2c80e Cc: Scott Brim , "aqm@ietf.org" , Michael Welzl Subject: Re: [aqm] WG name: QUEUE 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, 31 Jul 2013 18:20:57 -0000 --001a11330b22e3f06e04e2d2c80e Content-Type: text/plain; charset=ISO-8859-1 Would those who care for this round of bikeshedding go out to the shed and come back and tell us what the name is? For those unfamiliar with this commonly used (among open source software developers) term, see: http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality - Jim On Wed, Jul 31, 2013 at 5:56 PM, Scheffenegger, Richard wrote: > Actually, I just received word that most (all) tools should handle > single-character WG names. > > So, a Working group name "Q" - pronounced like "QUEUE", and a long name as > below, would be possible if this is agreeable... > > So far, the most support was for QUEUE/Q and SQM, apart from the default > AQM, as name of the WG... > > > Richard Scheffenegger > > > -----Original Message----- > > From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of > > Michael Welzl > > Sent: Dienstag, 30. Juli 2013 22:58 > > To: Scott Brim > > Cc: aqm@ietf.org > > Subject: Re: [aqm] WG name: QUEUE > > > > +1 ! > > > > But I think the acronym should really only be > > > > Q > > > > ...but expanded like below. > > > > > > On Jul 30, 2013, at 6:32 PM, Scott Brim wrote: > > > > > Since there wasn't any time to talk about the WG name in real time, I > > > want to heartily endorse Grenville Armitage's suggestion: > > > > > > QUEUE -- Queue Utilisation for Enhanced User Experience > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --001a11330b22e3f06e04e2d2c80e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Wou= ld those who care for this round of=A0bikeshedding go out to the shed and c= ome back and tell us what the name is?

For those = unfamiliar with this commonly used (among open source software developers) = term, see:=A0http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality=
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 - Jim
=


On Wed, Jul 31, 2013 at 5:56 PM, Scheffenegger, Richard &= lt;rs@netapp.com>= wrote:
Actually, I just received word that most (all) tools should handle single-c= haracter WG names.

So, a Working group name "Q" - pronounced like "QUEUE",= and a long name as below, would be possible if this is agreeable...

So far, the most support was for QUEUE/Q and SQM, apart from the default AQ= M, as name of the WG...


Richard Scheffenegger

> -----Original Message-----
> From: aqm-bounces@ietf.org= [mailto:aqm-bounces@ietf.org] = On Behalf Of
> Michael Welzl
> Sent: Dienstag, 30. Juli 2013 22:58
> To: Scott Brim
> Cc: aqm@ietf.org
> Subject: Re: [aqm] WG name: QUEUE
>
> +1 !
>
> But I think the acronym should really only be
>
> Q
>
> ...but expanded like below.
>
>
> On Jul 30, 2013, at 6:32 PM, Scott Brim <swb@internet2.edu> wrote:
>
> > Since there wasn't any time to talk about the WG name in real= time, I
> > want to heartily endorse Grenville Armitage's suggestion:
> >
> > =A0QUEUE -- Queue Utilisation for Enhanced User Experience
> >
> > _______________________________________________
> > 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
_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

--001a11330b22e3f06e04e2d2c80e-- From rs@netapp.com Wed Jul 31 11:37: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 89A7521F9EA2 for ; Wed, 31 Jul 2013 11:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-1.551, BAYES_00=-2.599, 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 jiBwsc22hJUE for ; Wed, 31 Jul 2013 11:37:35 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 76A7A21F9E35 for ; Wed, 31 Jul 2013 11:37:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,788,1367996400"; d="scan'208,217";a="37967498" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 31 Jul 2013 11:37:35 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.107]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 11:37:35 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: Draft AQM BoF minutes Thread-Index: Ac6OHPVQsch1AwBiTfqVX6bX6hLy1w== Date: Wed, 31 Jul 2013 18:37:34 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C465FE@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F25C465FESACEXCMBX02PRDh_" MIME-Version: 1.0 Subject: [aqm] Draft AQM BoF minutes 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, 31 Jul 2013 18:37:39 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F25C465FESACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, the minutes of the AQM BoF are available http://www.ietf.org/proceedings/87= /minutes/minutes-87-aqm. Please let us chairs know if something is missing, or if there are correcti= ons to make. The chairs would like to thank Gorry for his excellent work on taking the m= inutes. There have been comments by a few people who haven't given their names or w= here their names were hard to understand. Please let me know if you know on= e of them making comments so that we can update the notes. Richard Scheffenegger AQM BoF co-chair --_000_012C3117EDDB3C4781FD802A8C27DD4F25C465FESACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
the minutes of the AQM BoF are available http://www= .ietf.org/proceedings/87/minutes/minutes-87-aqm.
Please let us chairs know if something is missing, or if there are cor= rections to make.
 
The chairs would like to thank Gorry for his excellent work on taking = the minutes.
 
There have been comments by a few people who haven’t given their= names or where their names were hard to understand. Please let me know if = you know one of them making comments so that we can update the notes.
 
Richard Scheffenegger
AQM BoF co-chair
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F25C465FESACEXCMBX02PRDh_--