From nobody Tue Jul 1 02:15:23 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878791B27EA; Tue, 1 Jul 2014 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW7ryGv7N58H; Tue, 1 Jul 2014 02:15:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7175B1A00E1; Tue, 1 Jul 2014 02:15:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701091519.13796.89481.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 02:15:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/C2FQP1gkyBhpOSGDvyQv0ZsdJwE Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-recommendation-06.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 09:15:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. Title : IETF Recommendations Regarding Active Queue Management Authors : Fred Baker Godred Fairhurst Filename : draft-ietf-aqm-recommendation-06.txt Pages : 27 Date : 2014-07-01 Abstract: This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. The note largely repeats the recommendations of RFC 2309, updated after fifteen years of experience and new research. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-aqm-recommendation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 1 07:18:45 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDBB1A058E for ; Tue, 1 Jul 2014 07:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NI6UxNLBVu8 for ; Tue, 1 Jul 2014 07:18:38 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A191A0538 for ; Tue, 1 Jul 2014 07:18:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,581,1400050800"; d="scan'208";a="173374816" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 01 Jul 2014 07:18:22 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 1 Jul 2014 07:18:22 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 1 Jul 2014 07:18:21 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::b0c8:2b85:3071:3540%21]) with mapi id 15.00.0847.030; Tue, 1 Jul 2014 07:18:09 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: [aqm] AQM conference call transcript Thread-Index: Ac+VN2QTGfo2gi3XS56fuB6znLAw/w== Date: Tue, 1 Jul 2014 14:18:08 +0000 Message-ID: <5da8e25c06a749809a084105a803702b@hioexcmbx05-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.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/tDK0m7aZb8V4tN97I3ZyS_sI7es Cc: "Bob Briscoe \(bob.briscoe@bt.com\)" Subject: Re: [aqm] AQM conference call transcript X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 14:18:42 -0000 For those who couldn't participate in the AQM WG confcall last week, here i= s a transcript of the topics discussed at that time (also for the search en= gines to index and have a stable reference later on): Meeting minutes of the AQM conference call 24. June 2014, 13:00 Eastern Daylight Time Participants: Spencer Dawkins (responsible AD) Wes Eddy (WG co-chair) Richard Scheffenegger (WG co-chair) Dave Robinson John Leslie Nicolas Kuhn Dave T=E4ht Greg White Fred Baker Gorry Fairhurst Rong Pan Preethi Natarajan Anil Agarwal(?) 2 unidentified parties Agenda Bashing - no objections Discussion of aqm-recommendations *) References to internet congestion collapse in the introduction - consensus in the WG that latency reduction is the main objective=20 - as this is an update to a BCP, need to keep historic references Dave: Lot of Wifi expiricence congestion collapse, but on L2; AQM doesn't h= andle=20 that Slide - Comments 1:=20 Dave: channeling Bob, looking 1st para; Put a period after 1st sentence and= cut=20 until 2nd sentenace 1st para. Gorry: torn between preserving orinal text, or just intro to what we have t= o=20 say. John: is it possible to talk without reference to congestive collapse? in t= his=20 document Dave: it's the purpose of the end to end protocol to be sensitive to conges= tion=20 collapse. AQM is not there to prevent that. Fred: its not there to fix, but to help.=20 John: Congestion collapse had to do with sites sending more when there was= =20 congestion. Therefore congestion Collapse. Dave: I was kind of proposing putting a period after service degradation, a= nd=20 removing the internet meltdown and related stuff to a later portion of the= =20 document. Wes: That may be ok, but we need a bit of context as this grew out of 2309,= =20 which was more about routers participating in actively preventing congestio= n=20 collapse. And now the goals of AQM have morphed additionally to reduce late= ncy.=20 Tracing that bit of history would help tie things together.=20 John: Good point, but it doesn't belong in the introduction. Dave: Control latency, should be predominant in the document. Gorry: we need more text to do this. Not everyone has the same view. We sta= rted=20 off from 2309, and if we change this we have to be careful. Fred: It would be good for the WG to decide what they want this draft to sa= y.=20 Give us text in order to say that and decide it's done. Doc already in the = works=20 for more than 1 year. Wes: The meat of the doc are not disputed and this indicates they are prett= y=20 good. We just need to walk people into this. Dave: Has anyone given this to a CTO and asked what they think? They are th= e=20 ultimate audiences for this. Gorry: Equally we haven't given this to a PhD student to=20 John: I suppose I'm a CTO. I have to admit, I don't understand it very well= . Dave: That's one; A goal of this docuemnt is to convince people that we nee= d AQM=20 on everything. It needs to have a hook.=20 John: I though the hook had to do with reducing latency, but maybe I'm=20 misreading it. Dave: No, the hook is latency, and not congestive collapse. Wes: The hook has evolved over time, from 2309 congestion collapse, to what= it=20 is now, latency. State this in a sentence, that this fact has changed. If w= e do=20 this early on in the document, it help people not get confused when it talk= s=20 about both things. Wes: I could suggest some text that I think that address what Dave and John= , and=20 maybe even for Bob too, have said. At least it should help drive the discus= sion=20 to a conclusion. Gorry: Text would be great. =3D=3D> Wes provide text for intro. Slide: Comments 2 Gorry: Think we covered that just ago. Wes: This is at the extreme end of take all the stuff about congestion coll= apse=20 out. It's strongly relative to what we just discussed. There needs to be a= =20 bridge between 2309 focus on collapse, and what we are not working on. If w= e get=20 the first one right, we get this one for free. Dave: This my hope to. Gorry: I think so to. We have changed the wording in certain place, and wil= l=20 read ok with a better introduction. Dave: I have a problem that I disagree with Bob on this front. I agree stro= ngly=20 with moving the focus. Having a seperate historical section that talks a bi= t to=20 congestion collapse is fine by me for fixing the intro. Gorry: A seperate section, involving which text? Dave: As i mentioned early, moving that part of text into a historical sect= ion.=20 If Bob cares about this kind of text, he should provide the text. Dave: Do we want to have a historical section or a section that talks to=20 congestion collapse later in the document? Fred: What might make sense is a change in the "what problem are we solving= "=20 section, that is two parts. One of them being that in the earlier internet,= on=20 slower links and when under attack, we are talking about congestive collaps= e.=20 Describe what is,and how that deals with things. And seperately describing = the=20 issue of latency. Dave: When we have some DOS attack, some level of filtering redirects that= =20 traffic and it is not handled by an AQM. Nothing scary in the intro seems t= o be=20 simpler, thinking about the intended audience. I signed off on the docuemtn= as=20 it was. Wes: You are just trying to tweak it, not blocking Fred: Really helpful would be to make constructive assistance. Nothing that= we=20 seems to satisfy them. Dave: My take on this: rework the intro and get this for free. Gorry: I have no concerns splitting the intro into 2 sections speaking abou= t=20 congestion collapse and latency if that was clearer. Richard: We shouldn't really remove the prior text about congestion collaps= e, as=20 this is an update to a prior docuemnt. I think seperating this into two sec= tions=20 is a good way forward. Gorry: SOunds like a plan. wes: sounds good. Fred: If we can have this in the next 2 weeks, we can have this in time for= the=20 next IETF Wes: I commit to sending this later this week. - Slide Comment flow fairness Dave: There is some new text somewhere.=20 Gorry: We addressed this, it's sorted. - Slide 2a AQM must work without fairness mechanism Richard: Is this sorted out as well? Gorry: If the SFQ_Codel people are happy with the changes, I'm happy with t= hem.=20 They should be happy. Dave: There are quite a few opinions here. Text reads good. Specific compla= int=20 here was that section 4 was not successful.=20 Wes: In the DIFF there is a significant new addition. There is a bullet in = sec=20 4.1, that is "allow for combination with other mechanisms" Fred: Which they always have. Wes: I like the idea of dealing with that in a seperate document (queuing) = that=20 the WG might adopt later on. Keep this draft as it is. Dave: There is a typo... hard to spot. Early in the doc there is a list of = all=20 the different mechanisms. To me they are an important component to a soluti= on.=20 They are very different from fair queuing, I don't know where that shuold b= e=20 discussed. Fred: I think they are seperate discussions. They address a different class= of=20 problem. I'm fond of schedulers, but they are not AQM. Dave: Agree, ie. scheduling for rate limiting need to be in a different doc= . Fred: Scheduling for rate limitation makes it non work conserving, vs. work= =20 conserving queue by class. To me, what you want is a separate document that= =20 describes schedulers, and that is one attribute that a scheduler might have= .=20 there is an entire list of attributes that a scheduler might have. Dave: From my view, this is the most desired feature to differentiate the=20 services people are selling. It's not relevant to the AQM discussion. I jus= t=20 finished reviewing this. I'm completely happy here. I brought it up because= rate=20 limitation wasn't in 2nd para of sec 4.1 Gorry: Do we just want to add "and can be used for rate limiting"? Fred: I'm not opposed, I can probably come up with a long list. My question= is,=20 what do the words "such as" mean here... Seems fairly open ended as it is. = Where=20 do you stop, but I'm not opposed. Dave: I'm going to request: Rate Limitation, Priority Queuing, Classful Que= uing,=20 Fair Queuing. Fred: Ok. If we agree that after that we are done, then fine. Dave: is there not a SHOULD here? Gorry: Does this section need RFC2119 keywords in? Dave: I believe AQMs MUST allow a tie in with scheduling algorithms. Fred: I would disagree with that. To me: MUST - if you don't do that, somet= hing=20 will break. And this is what breaks in the next sentence. If I really like = to=20 say that, but cann't tell what may break, I use the word SHOULD.=20 Dave: Fine. I think the 2nd bullet is enough. Gorry: I think so to, and i tried to avoid RFC2119 keywords for the reasons= =20 mentioned by Fred. Dave: SFQ_Codel defers a few idea to the SFQ portion, that could be done in= the=20 AQM, but are better to do in the SFQ portion. Dave: I don't see anything else here. Wes: I think we got consensus on the call. Dave: I do have a structural point. Conclusion and recommendations, when yo= u get=20 to 4.2.1. It's kind of descriptive of what ECN is. It seems to be describin= g=20 what ECN is elsewhere, and turning it into a recommendation here. Does tha= t=20 make sense? Fred: The recommendation here is the 1st sentence of the 3rd para: Please b= e=20 able to do it. Dave: Ok, and this is why. Fred: Pretty much. ECN and drop as a signal are pretty comparable. The=20 difference is, that ECN doesn't have a loss... The measured effect on traff= ic is=20 about the same. Richard: A point Bob was very paramount about was a recommendation if AQM d= oes=20 both, ECN and drop, the parameters should be configured seperately. Dave: There was a significant penalty in CPU cycles to actually do that. So= we=20 didn't do it. Fred: That's a particular implementation. I don't know how that relates to= =20 recommendation to somebody else that implements this in the future. By the = way,=20 I believe we address the seperate configuaration in the penultimate paragra= ph. Dave: that captures the point from my perspective. I don't think that we wi= ll=20 end up with anything in the codebase that will allow this. Gorry: Thats ok, this is a BCP, which about the future. It's not about=20 documenting what has been going on. Fred: I can say, that in our codebase, we have had seperable configuration = for=20 15 years. There is more than one codebase here. Dave: As long as it's a MAY I'm fine. Richard: I also think this section addresses Bob's concern. - Slide 3 Comment: Scope Gorry: We added one, at the beginning. Dave: I believe AQM technology is needed wherevery you have a fast to slow= =20 transition. Gorry: A bottleneck. Fred: I would further argue that a fast to slow transition can be many inpu= ts of=20 one speed to a single output of the same speed. We see that inside input-qu= eued=20 switches. John: I apologize, but I just don't understand what you have as a statement= of=20 scope. I have yet to see version 5. I started this call very confused about= =20 statement of scope and I'm not doing any better. Wes: At the begining of Sec 2, there is a new paragraph. I think it was add= ed to=20 address this. Fred/Gorry: Yes. Wes: John, when you had time to read that section, let us know if it clarif= ys=20 the situation or not. John: At first read, it leaves me wondering where the line gets drawn. this= is a=20 very general statement. I guess you are saying it applies to wireless situa= tions=20 as well as ethernet and other mechnasims. But it doesn't clarify to me that= it's=20 the case where you have more data coming in the line than you can send out.= I=20 think this is what you want to say, but it doesn't say it anywhere. Dave: We need a set of paragraphs early on, that make people want to go out= and=20 enable this everywhere.=20 John: Do we have a place to the effect where more bits come in than go out? Fred: I don't think we want to say it in those terms. The key thing that AQ= M=20 tries to control is a growth in latency, or a growth in standing queue dept= h.=20 So, mean latency and mean queue depth. So I think I would state it in terms= of=20 latency and queue depth. Which actually this does. This is applicable anywh= ere=20 where standing loads can be absorbed, and standing increases in latency and= =20 queue depth can be observed. John: I'm not really ready to say what I wanted to add, but I do want it to= be=20 clear that this is what it's saying. Fred: We continually try to respond to open ended comments and people come = back=20 saying they don't like it.. You need to tell us what you like. John: Unfortunately, that would have been easier if I had seen version 5 be= fore=20 this meeting started. Wes: As a Chair I can state, that from the WG charter and scope, this parag= raph=20 is pretty consistent with what we set out to do in the WG. In my opinion, i= t=20 hits the mark. Dave: I already stated: Our goal should be AQM in every buffer. I think Bob= =20 tried to create a mission statement there, and I object to that. Gorry: A lot of these sentences were in the previous document, and we tries= to=20 [...] Other people to offer new sentences, but this is what we are putting = to=20 the WG for the moment, on that particular point. Dave: Should have signed up to the conf call... Wes: After the WG LC, there is IETF LC. There is no shortage of opportunity= =20 where Bob can comment on this, even when it leaves the WG. Richard: There is little point in discussion this point as long as Bob is n= ot=20 here, to donate text as to what he had in mind. - Slide Comment 4 - Synchronization and Lockout Gorry: We added seperate points to discuss this, and I think that should fi= x it. Dave: Where is this? Richard: End of section 2, 3 bullets. Gorry: There is a seperate bullet that mentiones lock out and synchronizati= on=20 individually. Dave: typo! Gorry: The main point on this is, that people realize that lock out and=20 synchronization are not the same thing. To make that clearer, we put them i= n two=20 separate paragraphs. Dave: Can I send some citations for these? I'm not sure people have seen an= d=20 understand global synchronization. Gorry: Do you have a paper. =3D=3D> Dave: I take an action item to go looking for references to these t= wo=20 paragraphs. Gorry: The RFC Editor will prefer papers or long-standing URLs, not regular= web=20 sites. [00:51:15] Wes: There is a Sally Floyd paper on synchronization that is quite good. Fred: There is that one. There is also a paper from someone funded by Cisco= , but=20 he hasn't published yet, at the Victoria University in Wellington NZ. Basci= ally=20 he measured it. Found instances of it etc. I asked him for a pointer to tha= t=20 paper, I'll get it some day. Gorry: If you can send the reference that would be good. Richard: So, the action is then with Dave to provide some references here. Fred: This is not too hard to figure out, if you think about it. A TCP can = be=20 thought ouf as a wave function. What happens when you run two wave function= s in=20 parallel - sometimes they add up. That's what TCP synchronization is, not t= oo=20 hard. Wes: The Sally Floyd paper called upon traffic phase effects.=20 Fred: If you send us a reference to the necessary information, we can link = to=20 that. Wes: Sure -- Slide Comment 5; Lockout Richard: Is there additional text necessary? Dave: At the moment I cann't think of any. The thing that has come up recen= tly=20 on the packet scheduling debate is avoiding head of line blocking for ACK=20 clocking is really a huge win. But I think this belongs in the scheduling p= aper=20 not the AQM paper. And AQM does reduce head of line blocking for ACK clocki= ng.=20 Fred, what do you think about the ACK clocking issue, reducing latency on o= ne=20 portion of the path improves ACK clocking on the reverse path. Fred: I'm not sure I understand Dave: This is not directly related to lock out, but reducing latency. There= =20 might be an additional bullet point, improving ACK clocking. Richard: An additional point here in section 2 Dave: yes Fred: You are looking for motivation for the statement in 4.2? Implicit lat= ency=20 is a signal for congestion... Dave: yes, possible Gorry: If you think so, can you send 2-3 sentences? Dave: Ok, if it doesn't make it, I'm easy still. -- Slide Comment 6,=20 Gorry: We just fixed it. it's ok Richard: I've seen those references. Wes: No furhter comment Dave: I'ven't read the conex thing. Sure that I find something that raises = my=20 blood pressure. Wes: IMHO, citations were added and comments addressed. -- Slide Comment 7-9, Wes: These are pretty minor. In v5 there is still one reference screwed up. Gorry: Forgot to check in that version of XML Wes: No 8 & 9, dave those are yours. Fred: There is an issue with No 8; The RFC editor, by policy, would like to= not=20 include URLs as they change. Dave: My problem is that much of that exists in a dusty library somewhere, = and I=20 would really like people to read it. Provide them online and searchable wou= ld=20 address this. Fred: You'd have to talk to the RFC editor about the policy. Wes: We can have a WG wiki page, using IETF tools, and provide these there. Dave: On point 7, there has been a bunch of recent research, in particular= =20 Stanford. Can't remember the name of the paper. They did a lot of research = on=20 the actual behaviour of flows on real 10G Eth links, and it "prooves" that = you=20 only need 20 packets of buffering, to handle the 10 000s of flows typically= =20 running though a 10G Eth link.=20 Fred: I'm familiar with that paper, I disagree. That might be true in backb= one=20 carriers, but that particular carrier has one of the best engineered backbo= nes.=20 I'm not convinced that this is generally true for the Internet. I certainly= =20 don't see that anywhere I'm looking Dave: I tend to agree with you, but haven't seen anyone trying to refute th= at=20 paper. They make a very compelling argument for it.=20 Fred: Cisco looked very hard at that. Would reduce our cost, and have memor= y=20 sellable as add-on. Dave: If you can find that paper, I would like to review it again. Poke hol= es in=20 it some day. For point 9, again that bursty loss problem is something that= =20 scheduling solves. It's very easily seen.=20 Gorry: Is this an AQM problem or scheduling? I can see this a scheduling is= sue. Dave: It's addressed in the PIE-DOCSIS implementation. They try very hard n= ot=20 doing back to back drops. Is stopping back to back drops a goal of AQM? Ron: For DOCSIS, they wanted to have good performance during max rate. But = in=20 the real internet, where so many bursty traffic are colliding with each oth= er, I=20 don't think this phenomena exists link in DOCSIS.=20 Dave: Another argument: You get huge bursts in the home induced by Wifi, up= to=20 32 packets all at once.=20 Fred: You realize they do that by design? Dave: By design, but it also induces problems. Fred: The problem they are working around - and this is worse in 802.11ac -= it=20 has a separate relationship with each device, as opposed to simply sending = into=20 the air. As a result devices are at different speeds, distances, prob of lo= ss,=20 emulating A or G etc. That means retraining the radio each time it picks a= =20 different device. And if it does that for every packet, it can spend 90% of= =20 capacity training the radio. So they do a form of deadline scheduling. Pack= et=20 get accumulated for a little while, and then send in a burst. When the capa= city=20 is there to waste on training the radio, it can send single packets. Under = load,=20 you get bursts of packets.=20 Dave: Going from the AP to the station is one problem. Coming from the stat= ion=20 to the AP you have very few flows. In that case, bursty loss does hurt. So,= =20 should we mention bursty loss as a problem, and the answer is probably yes. Greg: May I correct a misconception of the DOCSIS PIE implmentation? We act= ually=20 don't prevent back to back drops. What we do, we calculate a desired drop=20 probability. When you implement this, you effectively flip a bias point bac= k and=20 forth. If they are indepentent you have the potential, over a small number = of=20 packets, a deviation from the desired drop probability. We tries to bound t= hat=20 variability. So, we don't explicitly prevent back to back drops, if the=20 probability is high enough, there will be back to back drops. What we do is= =20 prevent large swings in the effective probability, relative to the disired = one. Dave: I get it, and I like it. Greg: The motivation really was when you got a really small number of sessi= ons,=20 you roll the dice badly, and you drop a lot more packets than you intended = to.=20 So it's a burstly loss condition we were concerned about most. This applies= to=20 the opposite direction also, when you don't drop near as many packets as yo= u=20 like to.=20 Wes: So, do our editors have a path forward on this? Richard: Dave, are you very insistent on having text on bursty loss in this= =20 document? Dave: I'll write some text. If it works, great, if it doesn't make it, I'm = cool=20 too. Gorry: Send the text to us and we will see if the text will fit.=20 --- Agenda review --- Evaluation draft Slide 1 Dave: What has driving me to this front has been to make video conferencing= work=20 well in the presence of load. So, I don't see that on your bullet points. I= =20 would like to have video conferncing and netflix style traffic. But does it= =20 belong to the eval suite, not the eval guidelines? Richard: I think that's what Nicolas wanted to show, that the document has = been=20 split on guidelines, and how to apply those guidelines to specific scenario= s and=20 suites. Dave: Back to slide 4. The point I want to make is that everyone, including= =20 myself is continuing to make this mistake of focussing on long running TCP= =20 flows. We need to stop. I think it was Freds data showing 19 packets medium= flow=20 size. Fred: Yeah, in the sample i took. Dave: I think your sample is probably pretty accurate. By and large you hav= e 1-2=20 big, fat flows, and the rest is short, 20-100 packets.=20 Preethi: The majority of problems cause by bufferbloat is because of these = long=20 lived, elephant flows. They drive up buffer utilization, not the samll come= -and- go flows. If all is small flows, there is no bufferbloat problem.=20 Dave: Yes and no; a typical web page downloads 15 flows at the same time,=20 injection 20 medium packets, thats 300 packet more or less at the same time= .=20 Thats a short burst of bufferbloat.=20 Preethi: From my understanding of the AQM is not to hurt those short lived= =20 flows, it's only to handle those long lived ones. It's not that you start=20 dropping when the buffer is over a certain point, it is working on relative= ly=20 longer timescales, not a short term burst. A short time burst has to be han= dled=20 by buffer sizing, not by queue management.=20 Dave: An AQM should not do too much harm.=20 Rong (?): That is true, but it's not that long lived elephant flows are not= =20 relevant. They are the elephant in the room that we need to affect. They ne= ed to=20 be regulated in a nice way, so that they don't occupy the majority of the=20 buffer. Of course we should make sure that when these mice come, we don't d= o=20 harm, correct. There is a short term and long term evaluation in my opinion= .=20 Preethi(?): There is a supplement in the TOC where we define the type of=20 traffic. But we won't be going into the details of how many flow, how many= =20 packets. That will be in a seperate docuemnt, here we are more high level. = We=20 would like to keep it that way to arrive at a concensus on the high level m= oving=20 forward. Dave: In that case I would move up the bullet points below various TCP flav= ours.=20 They are more interrelated with RTT and RTT fairness. I'm still reacting to= 50=20 non-bidirectional flows being used as a benchmark in the new secondary=20 docuement. We are not talking about that today. Preethi: It's not only about long lived TCP flows, but various kinds of mix= ed=20 traffix. It's going to be there in the document at a very high level. Richard: Please bring the detailed discussion the list, also for broader=20 participation. Also to encourage people to read the new version. Wes: Yes, on the mailing list. I think the feedback is good to hear and wou= ld be=20 great to continue this discussion on the WG list. Thanks Nicholas. I think = this=20 clarifies the state of the document, and opens the gates on some feedback o= n=20 that. We further wanted to talk about the idea of adopting some algorithms= =20 specification. We mentioned this on the mailing list a while back, and got = a=20 couple of positive responses, but not as many as I would thought we'd get. = Our=20 logic here as chairs is, we know a lot of people are working on algorithms,= we=20 don't know how long people are going to be working on algorithms. We would = like=20 to get some of this work done before people move on to other work. We would= like=20 to contribute to that in the WG and help them improve their work, and have = some=20 of these published as RFC. From the list, there are several algorithms we s= een=20 already come in, and there are many more people are working on. We don't ha= ve=20 very strict threshold of what it takes to get an algorithm adopted. We were= =20 floating a proposal that asks for multiple groups outside the editors of th= e=20 specification itself that saying that they are interested and that it solve= s a=20 particular use case they have in the real world. And that they would expiri= ement=20 with it, and contribute feedback on the specification. So, is the working g= roup=20 ready to do this? Dave: I've put the fq_codel draft in the hope that it gets some comments, s= o=20 far, two comments. Fred, why do you call it sfq rather than fq implementati= on? Fred: Probably no good reason. I can change that if that's an issue.=20 Dave: Just seems to be confusing. I would like to see more eyeballs on the= =20 fq_codel draft, same thing for the codel draft. Wes: Actually, I've looked at all of them in the list, and I think all of t= hem=20 are pretty well written and good starting points to have an IETF spec. The= =20 problem is, I don't want to start adopting algorithm drafts, if there aren'= t=20 enough experts outside the editors to contribute to each other's specificat= ion.=20 Like you said Dave, you only got a few comments on the documents you submit= ted,=20 and I would have expected there to be a lot more.=20 Dave: I was just hoping thats it's so well written that there are no commen= ts=20 needed. I thing it should get out in front of more eyeball, in particular w= ith=20 the RMCAT WG.=20 Richard: How about the bar to have at least one group outside the editors r= eview=20 an algorithm and perhaps even expirience implementing it, before we as WG=20 consider adopting it. Is that reasonable, or would that be too restrictive?= With=20 PIE and CODEL I believe we do have a very solid understanding including the= =20 variants. There have been lengthy discussions even before the WG started. S= o=20 these two seem to be in a very good shape from fulfilling that threshold. B= ut=20 how about additional ones? Dave: Additional algorithms to the three on the table here? Richard: Yes. Dave: I happen to like QFQ, I've heard about there may be coming an FQ_PIE.= I'm=20 not sure what you are asking. I would like WGs whose problem we are trying = to=20 solve to have input in the process, and taking input from them in terms of = what=20 kind of tests there will be. I like the suite that the RMCAT group was comi= ng up=20 with.=20 Wes: I don't know about a specific WG. When we were forming this (AQM) WG, = the=20 entire routing area was concerned, what we were doing. Let's rephrase the=20 question: Is there anyone here that thinks the WG is not ready to start ado= pting=20 algorithms? That we need to pause? The original plan in the chartering=20 discussion was we work out this evaluation scenario anf guidelines, and tha= t we=20 would converge on that before we were to pick algorithms. We are trying to = maybe=20 parallelise the work with this proposal. Dave: I have no objections ever to more eyeballs.=20 Gorry: Are you asking, can we start to take the two proposals we have on th= e=20 table more seriously because they are becoming WG items? Wes: There is more than two. And once it's clear we are adopting some specs= ,=20 there may even be more that show up.=20 Gorry: There are? Wes: Well, what we are asking is essentially, do we think it's time to open= the=20 door to adopting specs as WG drafts? Gorry: Yeah, and how are we going to control the rest? There are other=20 algorithms that are widely deployed, in particular vendor's networks for=20 instance. Wes: When we floated this originally, I think the criteria was, that we wou= ld=20 like to see that there are multiple groups contributing feedback to the spe= c and=20 saying they are going to work with it in reality for some use case it's int= ented=20 to meet. And that there have to be people other than the editors willing to= work=20 with it. And if you can meet that threshold, then it would be acceptable to= poll=20 the WG for adoption on a particular specification. Gorry: Do you think it's possible to encourage people that currently have=20 written drafts to try and do that? And if they do, these particular drafts = can=20 progress? Wes: Well, we are trying to chart a path, to help these authors and editors= out=20 on specs in order the help them to progress. I think everyone understands t= hat=20 we can't just accept them all with further ado. We have to have some kind o= f=20 process, otherwise it's chaos. So we are searching for a process really. Fred: I think we need to determine what we mean when we say we have adopted= =20 something. If we adopt exactly one, that begins to sound like an IETF=20 recommendation that everyone should do that one. That was the mistake we ma= de=20 frankly, with RED. We said, everybody has to do one thing. Having two thing= s,=20 one of which is head drop and one of which is tail drop, that really doesn'= t=20 bother me. That kind of gives you two classes of algorithms. But then you a= re=20 saying as a WG is that not everybody needs to do exactly this, but rather h= ere=20 is an example of what people should do. It might even be worthwhile to have= a=20 one paragraph RFC that says that. This is the class of recommendation that = we=20 are making. I think we as a WG need to discuss what kind of recommendation = we=20 want to make. If the kind of recommendation is that we think there is a cla= ss of=20 algorithms that we know that these work in research and operation, then I t= hink=20 it's a different recommendation than the kind of thing that we did with RED= .=20 Wes: Yes, so when I sent an email about this I think I said that we need an= =20 applicatibility statement in them. For a particular deployment scenario may= be,=20 or use case, or even implementation requirement. Fred: I understand that there is a gotcha with those kinds of statements.=20 Suppose somebody comes up with a new example. And that new example might be= ,=20 should I do this in access points, should I do this on photonic links. Supp= ose=20 somebody comes up with a use case that hasn't been listed. Then the questio= n=20 becomes, should I use this one, should I use that one, should I use a third= one?=20 There is no applicability statement saying what to do. That actually raises= more=20 questions than it solves. Also, I think Dave will agree with me on this, bo= th of=20 the algorithms that are on the table could be used more or less interchange= ably,=20 and should be applicable in a wide variety of cases. I don't know if an=20 applicability statement would say, in this case, choose PIE, in that case c= hoose=20 CODEL. It would say, this is applicable in the set of cases that are under= =20 consideration by the AQM WG, or something like that. I'm not sure if an=20 applicability statement gets you where you want to go. Wes: Well, no. Perhaps you are right, you can almost come up with an=20 inapplicability statement, if there are cases where we know they are not=20 particular appropriate, that would be easier to say from simulations or=20 expirience. Fred: And those things I don't think we actually know. We know in those use= =20 cases we tried them, they help.=20 Dave: All in favour in more deployments and more testing. More exposure to = more=20 use cases. Need to learn more stuff.=20 Richard: What worries me is an overflow of different algorithms. So, say, a= PhD=20 student comes up with a clever idea, makes some simulations and declares=20 victory, and wants his algorithm adopted by the AQM WG. I guess what I'm as= king=20 for is the WG to decide, what kind of gatekeeper or gating requirements do = we=20 put up, before we allow a draft to become a WG document, in order to limit = the=20 influx of algorithms that ask for official IETF approval.=20 Gorry: One we could ask is deployment expirience, which several algorithms= =20 already have.=20 Fred: Well yeah. And this comment is an outcome from the expirience we've h= ad=20 with the DiffServ: Some way of clarifying that it's significantly different= from=20 an algorithm that is already on the table. With DiffServ we had a long lis= t of=20 people that came and wanted to pitch in my paper, i put this command in fro= nt of=20 that command instead of after, and therefore it's different and please reco= gnize=20 my code. Kind of drove us crazy for some while. The distinction between hea= d=20 drop and tail drop is a really big distinction. Being able to argue that my= new=20 proposal is significantly different in some interesting way. Richard: Good! Sounds like an interesting propsal. Wes: Yes, we can take the feedback here and draw some kind of concrete prop= osal=20 for moving forward on algorithm specs and get it out on the list, and walk= =20 through it in toronto face to face. This is also something we want our AD t= o=20 support us on, if we are going to do it.=20 Richard: I believe this concludes our meeting. The planned agenda for toron= to is=20 still that we want to review the update to 2309bis. revision -06 should be= =20 coming up before the toronto meeting. Then we would want to spend again the= =20 majority of time to discuss the evaluation guidelines and the scenarios. An= d=20 after discussing the adoption of AQM mechansisms with our ADs, how we plan = to=20 move forward on that front. Dave: I have made this suggestion before, I'm perfectly happy to drop it. I= had=20 in mind to talk to the case for comprehensive Queue management. Not just AQ= M,=20 but packet scheduling, rate limiting, and policing. In order to try and pro= vide=20 some context for what we are trying to decide in moving forward. I had no=20 feedback on that proposal, and I'm ok to drop it. Wes: Is it something you are asking for agenda time in toronto? Dave: If I get agenda time for it, i'll talk to it.=20 Wes: Ok. Richard: So, we have a 2hr slot, there should be plenty of time. Dave: Alright!=20 Wes: I will correspond with you offline to that. Dave: Ok. Wes: Is there anything else that people think we should focus on in toronto= ? In=20 terms of 2309bis, I hope we can confirm that it's ready to go off to the AD= for=20 IETF LC and moving forward. If that is all, I think we can conclude the mee= ting=20 here. Dave: See you again in a couple weeks. Wes: Ok, hope to see you all in Toronto. Richard Scheffenegger From nobody Tue Jul 1 14:27:58 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC011A0646 for ; Tue, 1 Jul 2014 14:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCie82C2qB_g for ; Tue, 1 Jul 2014 14:27:53 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC61A0451 for ; Tue, 1 Jul 2014 14:27:52 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s61LRpuC003457 for ; Tue, 1 Jul 2014 17:27:51 -0400 Received: (qmail 26908 invoked by uid 0); 1 Jul 2014 21:27:51 -0000 X-TCPREMOTEIP: 107.46.221.18 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.221.18) by 0 with ESMTPA; 1 Jul 2014 21:27:51 -0000 Message-ID: <53B327C0.6020407@mti-systems.com> Date: Tue, 01 Jul 2014 17:27:28 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/7HP587g5co5Rr_7fpLEty9eFom4 Subject: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 21:27:55 -0000 There has been a bit of discussion last week about draft-ietf-aqm-recommendation and how to improve the text near the beginning, that leads to and sets context for the actual recommendations. John Leslie noticed that some of the things Bob Briscoe had mentioned stem from trying to work from RFC 2309 as the starting point. We have been planning to Obsolete and replace 2309 with this document. John suggested instead to let it live on, and have this new one only Update it, and has suggested specific changes that could be edited in, if this were the case. I think we need to make a conscious on-list decision about this, and decide to either confirm that Obsoleting 2309 is correct, or to change course. Others can amplify or correct these, but I think the points for each would be: Obsoleting 2309 - 2309 was an IRTF document from a closed RG, and we now can make a stronger statement as an IETF group with a BCP - 2309 is a bit RED-centric, and we now think that people should be looking at things other than RED Not-Obsoleting 2309 (e.g. Updating 2309) - 2309 is a snapshot in history of the E2E RG's thinking - 2309 is mostly oriented towards AQM as a mitigation for congestion collapse, whereas now we're more interested in reducing latency Please share any thoughts you have on this, and what should be done. -- Wes Eddy MTI Systems From nobody Tue Jul 1 17:24:48 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB71A0402 for ; Tue, 1 Jul 2014 17:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWfCGo5SgBbd for ; Tue, 1 Jul 2014 17:24:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDCF1A03F7 for ; Tue, 1 Jul 2014 17:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3374; q=dns/txt; s=iport; t=1404260686; x=1405470286; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QWrnSSkrnqpmN3808c44lMiPCFsOZMPPnjWPQYxYPQw=; b=jc0ngEhjL7PZhnJaYHtdD5oBMc9zTqQt192bVCZ1PAfJYMbDdD4GKY0q 1RvyS/vtd5O2zXIOu2W11yXh42wNxhxQ+wiJHFt/GlIC0pO5/Bvar4Tpm 2ppycH2+O0AiQB/PUKV2v5HH4tFcFsj2gFhDBwG8WcIHhj7A/GOAG0LN5 w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAH1Qs1OtJV2b/2dsb2JhbABagw2BLMYIAYEQFnWEAwEBAQR5EAIBCA4KLjIlAgQOBQ6INMUYF4t7gyQHgy2BFgWSFoFDhw2UA4NCgjA X-IronPort-AV: E=Sophos;i="5.01,585,1400025600"; d="asc'?scan'208";a="57610182" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 02 Jul 2014 00:24:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s620OiDg020907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 00:24:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 19:24:44 -0500 From: "Fred Baker (fred)" To: Wesley Eddy Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPlYwGczg4KKPJMkmSfvKglm3RAw== Date: Wed, 2 Jul 2014 00:24:44 +0000 Message-ID: <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> References: <53B327C0.6020407@mti-systems.com> In-Reply-To: <53B327C0.6020407@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_9FF006CD-EDCE-4F46-A963-07758E365D30"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/axeFP7wexBvnY06RXmBUU3l-FVs Cc: "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 00:24:47 -0000 --Apple-Mail=_9FF006CD-EDCE-4F46-A963-07758E365D30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 1, 2014, at 2:27 PM, Wesley Eddy wrote: > John Leslie noticed that some of the things Bob Briscoe had > mentioned stem from trying to work from RFC 2309 as the starting > point. We have been planning to Obsolete and replace 2309 with > this document. John suggested instead to let it live on, and > have this new one only Update it, and has suggested specific > changes that could be edited in, if this were the case. >=20 > I think we need to make a conscious on-list decision about this, > and decide to either confirm that Obsoleting 2309 is correct, or > to change course. >=20 > Others can amplify or correct these, but I think the points for > each would be: >=20 > Obsoleting 2309 > - 2309 was an IRTF document from a closed RG, and we now can make > a stronger statement as an IETF group with a BCP > - 2309 is a bit RED-centric, and we now think that people should > be looking at things other than RED >=20 > Not-Obsoleting 2309 (e.g. Updating 2309) > - 2309 is a snapshot in history of the E2E RG's thinking > - 2309 is mostly oriented towards AQM as a mitigation for congestion > collapse, whereas now we're more interested in reducing latency >=20 > Please share any thoughts you have on this, and what should be done. I=92ll give you my view, which I just gave you privately. The changes that have been requested include at least: - remove the word =93RED=94 from the document. The operators find = RED difficult to use and as a result don=92t turn it on. They would like = alternative algorithm(s) that require at most minimal parameterization, = ideally none at all. - add ECN - add scheduling, which 2309 explicitly didn=92t address - update references We also have discussed additional recommendations beyond =93everyone = deploy RED=94 and =93we need more research=94. If you count affected lines in the document, just removing the word = =93RED=94 affects 154 of the 955 lines in the document. Then we go into = the rest of the changes. I=92m not sure in what way that can be = described as an =93update=94. Note that I=92m not arguing that John=92s calling my baby ugly. He is, = but that=92s another matter :-). He sent you some proposed text to = replace sections 1-3, which I think the working group needs to see, as = that=92s the text you=92re calling an =93update=94 as opposed to = =93obsoleting=94 the document. If the consensus is to replace the = existing sections 1-3 with his text, so be it. But it=92s still a huge = change from 2309. Since one doesn=92t have to read 2309 to understand = this document, I don=92t see how it=92s an =93update=94. --Apple-Mail=_9FF006CD-EDCE-4F46-A963-07758E365D30 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 iD8DBQFTs1FLbjEdbHIsm0MRAmvkAKDxsK1sFZa0TMVLBN8L3DioLhp7PACeJH04 u5AxCqxmxxqtQq2vZYCa0LQ= =MZEN -----END PGP SIGNATURE----- --Apple-Mail=_9FF006CD-EDCE-4F46-A963-07758E365D30-- From nobody Wed Jul 2 02:58:20 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D881B27E5 for ; Wed, 2 Jul 2014 02:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yET2MeUTDcm1 for ; Wed, 2 Jul 2014 02:58:17 -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 CBED01B27E0 for ; Wed, 2 Jul 2014 02:58:16 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 002B22B44A5; Wed, 2 Jul 2014 10:58:15 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1DFA22B4271 for ; Wed, 2 Jul 2014 10:58:15 +0100 (BST) Message-ID: <53B3D7B6.90607@erg.abdn.ac.uk> Date: Wed, 02 Jul 2014 10:58:14 +0100 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:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: aqm@ietf.org References: <20140701091519.13796.89481.idtracker@ietfa.amsl.com> In-Reply-To: <20140701091519.13796.89481.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/oZwdXxl7zgx32RemrdhcKPFQe2E Subject: Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-06.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Jul 2014 09:58:18 -0000 To keep things clear, we published a new revision of the AQM recommendations (-06) after the conference call for which Richard sent notes. Our hope is that this provides a firm basis for any further discussion. The editors are asking the group to read this and note any errors. There remains some on-going discussion about whether this now should move RFC2309 to Historic, or not. This issue needs to be resolved before we finalize the introduction. Let's hope we can conclude this soon. Best wishes, Gorry On 01/07/2014 10:15, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. > > Title : IETF Recommendations Regarding Active Queue Management > Authors : Fred Baker > Godred Fairhurst > Filename : draft-ietf-aqm-recommendation-06.txt > Pages : 27 > Date : 2014-07-01 > > Abstract: > This memo presents recommendations to the Internet community > concerning measures to improve and preserve Internet performance. It > presents a strong recommendation for testing, standardization, and > widespread deployment of active queue management (AQM) in network > devices, to improve the performance of today's Internet. It also > urges a concerted effort of research, measurement, and ultimate > deployment of AQM mechanisms to protect the Internet from flows that > are not sufficiently responsive to congestion notification. > > The note largely repeats the recommendations of RFC 2309, updated > after fifteen years of experience and new research. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-aqm-recommendation-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From nobody Wed Jul 2 09:08:00 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4601B2822 for ; Wed, 2 Jul 2014 09:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFi5Q-1R4OTo for ; Wed, 2 Jul 2014 09:07:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FDE1B2983 for ; Wed, 2 Jul 2014 09:07:57 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s62G7pgl028607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Jul 2014 11:07:52 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s62G7pxj020636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 12:07:51 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 2 Jul 2014 12:07:51 -0400 From: "Akhtar, Shahid (Shahid)" To: Wesley Eddy , "aqm@ietf.org" Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPlXNyKMd3TljdqEmo9Kk73/l3opuM9BLA Date: Wed, 2 Jul 2014 16:07:50 +0000 Message-ID: References: <53B327C0.6020407@mti-systems.com> In-Reply-To: <53B327C0.6020407@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/-gzGJbI7qZSz80kbY9PpPADMWm0 Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 16:07:59 -0000 Hi Wes, Can you share the update/text that John Leslie had suggested which Fred men= tions in his comment. Thanks, -Shahid. -----Original Message----- From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Wesley Eddy Sent: Tuesday, July 01, 2014 4:27 PM To: aqm@ietf.org Subject: [aqm] Obsoleting RFC 2309 There has been a bit of discussion last week about draft-ietf-aqm-recommend= ation and how to improve the text near the beginning, that leads to and set= s context for the actual recommendations. John Leslie noticed that some of the things Bob Briscoe had mentioned stem = from trying to work from RFC 2309 as the starting point. We have been plan= ning to Obsolete and replace 2309 with this document. John suggested inste= ad to let it live on, and have this new one only Update it, and has suggest= ed specific changes that could be edited in, if this were the case. I think we need to make a conscious on-list decision about this, and decide= to either confirm that Obsoleting 2309 is correct, or to change course. Others can amplify or correct these, but I think the points for each would = be: Obsoleting 2309 - 2309 was an IRTF document from a closed RG, and we now can make a stronger statement as an IETF group with a BCP - 2309 is a bit RED-centric, and we now think that people should be looking at things other than RED Not-Obsoleting 2309 (e.g. Updating 2309) - 2309 is a snapshot in history of the E2E RG's thinking - 2309 is mostly oriented towards AQM as a mitigation for congestion collapse, whereas now we're more interested in reducing latency Please share any thoughts you have on this, and what should be done. -- Wes Eddy MTI Systems _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm From nobody Wed Jul 2 12:10:26 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D849A1B2A52 for ; Wed, 2 Jul 2014 12:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko1zOOdhpNqw for ; Wed, 2 Jul 2014 12:10:13 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E091B2A6A for ; Wed, 2 Jul 2014 12:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10818; q=dns/txt; s=iport; t=1404328205; x=1405537805; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0z28WVwT2d+TB93aJ04RrKD/SCyuoiEvLcu/5Dr+CEA=; b=lnVot7lbDkY25FlQHYU+RCRT0ppU0wqrc3AmeBz/jhLgy5UoVzIbwK6Q VQs/b7g7FA1XizjtaZjR6A2m9dqb10Crj9Mci1WTTA2RVvGjl0APVx8o6 n+1V3OOjPWSnC0k/+nqO2f8WwIJcGME0LLHfXOey+F+OpnVSyYNlIgjyc c=; X-Files: aqm-recommendation_Section1-3.txt, signature.asc : 8821, 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPVXtFOtJA2D/2dsb2JhbABagw2BLMYcAYEHFnWEAwEBAQMBeQULAgEIRjIlAgQOBQ6ILAjHZReLfYJOVweDLYEWBZIcgUOCMIRelAqDQ4FvQQ X-IronPort-AV: E=Sophos;i="5.01,590,1400025600"; d="asc'?txt'?scan'208";a="57832470" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 02 Jul 2014 19:10:04 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s62JA4J5009714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 19:10:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 14:10:04 -0500 From: "Fred Baker (fred)" To: "Akhtar, Shahid (Shahid)" Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPlik6mp4QKvFyoUCTRNWwatklfQ== Date: Wed, 2 Jul 2014 19:10:03 +0000 Message-ID: <7DE7F45E-7345-4F1F-B933-42A16B260337@cisco.com> References: <53B327C0.6020407@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_B53A5BE4-18C1-418D-850E-0B74667F90AC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/nXUD1AlW-coqWUVGU-WWEHCYi7g Cc: Wesley Eddy , "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 19:10:19 -0000 --Apple-Mail=_B53A5BE4-18C1-418D-850E-0B74667F90AC Content-Type: multipart/mixed; boundary="Apple-Mail=_7C7A47D9-08F9-40E4-BAFD-961438848B8C" --Apple-Mail=_7C7A47D9-08F9-40E4-BAFD-961438848B8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2014, at 9:07 AM, Akhtar, Shahid (Shahid) = wrote: > Hi Wes, >=20 > Can you share the update/text that John Leslie had suggested which = Fred mentions in his comment. >=20 > Thanks, >=20 > -Shahid. I have attached the text John sent yesterday. It is derived from -05. I = *think* he would like to replace sections 1-3 of = draft-ietf-aqm-recommendations with the content of that text, and then = reconsider the additional text in -06 to see if it is still required and = if so where it might go. --Apple-Mail=_7C7A47D9-08F9-40E4-BAFD-961438848B8C Content-Disposition: attachment; filename=aqm-recommendation_Section1-3.txt Content-Type: text/plain; name="aqm-recommendation_Section1-3.txt" Content-Transfer-Encoding: 7bit 1. Introduction RFC 2309 introduces the concept of "Active Queue Management" and describes one AQM algorithm. Since 1998, other AQM algorithms have come into use. This document updates RFC 2309 where needed, and gives recommendations for future AQM algorithms. Section 3 of RFC 2309 describes Random Early Detection ("RED"). Similar algorithms are specified for other non-TCP transports. RFC 2309 makes recommendations for "routers." Today these same recommendations apply to a number of other network devices, including switches, tunnel endpoints, Network Address Transform ("NAT") devices, and other middleboxes, which pass packets, whether unchanged or modified, into outgoing queues. A number of AQM procedures are described in the literature with different characteristics. This document does not recommend any of them in particular, but does make recommendations that ideally would affect the choice of procedure used in a given implementation. Methods such as congestion exposure (ConEx) [RFC6789] offer a framework [CONEX] that can update network devices to alleviate the effects of unresponsive flows. The discussion in this memo applies to "best-effort" traffic, which is to say, traffic generated by applications that accept the occasional loss, duplication, or reordering of traffic in flight. It also applies to other traffic, such as real-time traffic that can adapt its sending rate to reduce loss and/or delay. It is most effective when the adaption occurs on time scales of a single Round Trip Time (RTT) or a small number of RTTs, for elastic traffic [RFC1633]. [RFC2309] resulted from past discussions of end-to-end performance, Internet congestion, and Random Early Discard (RED) in the End-to-End Research Group of the Internet Research Task Force (IRTF). This update results from experience with this and other algorithms, and the AQM discussion within the IETF[AQM-WG]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The Need For Active Queue Management Active Queue Management (AQM) is a method that allows network devices to control the queue length or the mean time that a packet spends in a queue. Although AQM can be applied across a range of deployment enviroments, the recommendations in this document are directed to use in the general Internet. It is expected that the principles and guidance are also applicable to a wide range of environments, but may require tuning for specific types of link/network (e.g. to accommodate the traffic patterns found in data centres, the challenges of wireless infrastructure, or the higher delay encountered on satellite Internet links). Section 2 of RFC 2309 discusses "tail drop" -- dropping the most-recently-received packet, as well as "drop front on full" and "random-drop-on-full". The reader may wish to review that Section. Congestion control, like other end-to-end mechanisms, introduces a control loop between hosts. Sessions that share a common network bottleneck can therefore become synchronised, introducing periodic disruption (e.g. jitter/loss). "lock-out" is often also the result of synchronization or other timing effects. AQM can be combined with a scheduling mechanism that divides network traffic between multiple queues (Section 2.1). The probability of network control loop synchronisation can be reduced by introducing randomness in the AQM functions used by network devices that trigger congestion avoidance at the sending host. 2.1. AQM and Multiple Queues A network device may use per-flow or per-class queuing with a scheduling algorithm to either prioritise certain applications or classes of traffic, or to provide isolation between different traffic flows within a common class. For example, a router may maintain per- flow state to achieve general fairness by a per-flow scheduling algorithm such as various forms of Fair Queueing (FQ) [Dem90], including Weighted Fair Queuing (WFQ), Stochastic Fairness Queueing (SFQ) [McK90] Deficit Round Robin (DRR) [Shr96] and/or a Class-Based Queue scheduling algorithm such as CBQ [Floyd95]. Hierarchical queues may also be used e.g., as a part of a Hierarchical Token Bucket (HTB), or Hierarchical Fair Service Curve (HFSC) [Sto97] . These methods are also used to realise a range of Quality of Service (QoS) behaviours designed to + meet the need of traffic classes (e.g. using the integrated or differentiated service models). Using a combination of AQM and scheduling between multiple queues has been shown to offer good results in experimental and some types of operational use. 2.2. AQM and Explicit Congestion Marking (ECN) An AQM method may use Explicit Congestion Notification (ECN) [RFC3168] instead of dropping to mark packets under mild or moderate congestion. ECN-marking can allow a network device to signal congestion at a point before a transport experiences congestion loss or additional queuing delay [ECN-Benefit]. Section 4.2.1 describes some of the benefits of using ECN with AQM. 2.3. AQM and Buffer Size It is important to differentiate the choice of buffer size for a queue in a switch/router or other network device, and the threshold(s) and other parameters that determine how and when an AQM algorithm operates. One the one hand, the optimum buffer size is a function of operational requirements and should generally be sized to be sufficient to buffer the largest normal traffic burst that is expected. This size depends on the number and burstiness of traffic arriving at the queue and the rate at which traffic leaves the queue. Different types of traffic and deployment scenarios will lead to different requirements. AQM frees a designer from having to the limit buffer space to achieve acceptable performance, allowing allocation of sufficient buffering to satisfy the needs of the particular traffic pattern. On the other hand, the choice of AQM algorithm and associated parameters is a function of the way in which congestion is experienced and the required reaction to achieve acceptable performance. This latter topic is the primary topic of the following sections. 3. Managing Aggressive Flows Section 4 of RFC 2309 discusses the management of aggressive flows. Since RFC 2309 was written in 1998, the concept of "TCP-friendly" has generally replaced the concept of "TCP-compatible." In this document a flow is known as "TCP-friendly" when it has a congestion response that approximates the average response expected of a TCP flow. One example method of a TCP-friendly scheme is the TCP-Friendly Rate Control algorithm [RFC5348]. In this document, the term is used more generally to describe this and other algorithms that meet these goals. A TCP-friendly flow responds to congestion notification within a small number of path Round Trip Times (RTT), and in steady-state it uses no more capacity than a conformant TCP running under comparable conditions (drop rate, RTT, packet size, etc.). The User Datagram Protocol (UDP) [RFC0768] provides a minimal, best-effort transport to applications and upper-layer protocols (both simply called "applications" in the remainder of this document) and does not itself establish a degree of fairness [RFC5405]. Some applications (e.g. current web browsers) open a large number of short TCP flows for a single session. This can lead to each individual flow spending the majority of time in the exponential TCP slow start phase, rather than in TCP congestion avoidance. The resulting traffic aggregate can therefore be much less responsive than a single standard TCP flow. An RTP/UDP video flow that uses an adaptive codec but responds incompletely to indications of congestion or responds over an excessively long time period may not be responsive to congestion signals in a timeframe comparable to a small number of end-to-end transmission delays. However, over a longer timescale, perhaps seconds in duration, they con moderate their speed, or increase their speed if they determine capacity to be available. Tunneled traffic aggregates carrying multiple (short) TCP flows can be more aggressive than standard bulk TCP. Applications (e.g. web browsers and peer-to-peer file-sharing) have exploited this by opening multiple connections to the same endpoint. --Apple-Mail=_7C7A47D9-08F9-40E4-BAFD-961438848B8C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_7C7A47D9-08F9-40E4-BAFD-961438848B8C-- --Apple-Mail=_B53A5BE4-18C1-418D-850E-0B74667F90AC 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 iD8DBQFTtFkJbjEdbHIsm0MRAmaZAJ0YTTtkFGDWJ3timQbSn25p8WQ7KgCfUwiY FhNP0jMuBZD5vqYd8H7YlWE= =vwzo -----END PGP SIGNATURE----- --Apple-Mail=_B53A5BE4-18C1-418D-850E-0B74667F90AC-- From nobody Wed Jul 2 12:36:20 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244621B299E for ; Wed, 2 Jul 2014 12:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFpuDtudJHWp for ; Wed, 2 Jul 2014 12:36:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8641A03A9 for ; Wed, 2 Jul 2014 12:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13820; q=dns/txt; s=iport; t=1404329774; x=1405539374; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GQrWhpiLafI8NP9aCuAoXgJtHHhtPAtQ4hO09CUJ7bA=; b=gHDBinua/qdgG7zPncevjsetplc04U6J9rLGMVZ8Wb9StV6QJ1VM/lRL BAg+FPZff3YwH2urVll/9w+PHudZiEqQ9lExcyAf9/H5eA48toK6Zn1mh UTBOoPtVhv4pWGEpPJ16VRZa9IfcmcVAjmQqsc5BVcydI3efAZ2im2J4A s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALJetFOtJA2N/2dsb2JhbABagw1SWsYdAYEHFnWEAwEBAQMBaAoHEAIBCBguMiUCBA4FDogsCA3HWRMEiWWCGIJDCwUCAU8Hgy2BFgWFaIw0gUOHDpQKg0OBb0E X-IronPort-AV: E=Sophos;i="5.01,590,1400025600"; d="asc'?scan'208";a="337306949" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 02 Jul 2014 19:36:13 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s62JaBaL030465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 19:36:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 14:36:11 -0500 From: "Fred Baker (fred)" To: "aqm@ietf.org" Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPlizgckGgt/l6XU+i7KdZ+owQVg== Date: Wed, 2 Jul 2014 19:36:11 +0000 Message-ID: References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> In-Reply-To: <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_0C145BBC-2077-49D7-AF54-97B5DD2E490B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/vrrMnX36vywCq9DNBdhokt6w7BA Cc: Wesley Eddy , John Leslie Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 19:36:16 -0000 --Apple-Mail=_0C145BBC-2077-49D7-AF54-97B5DD2E490B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) wrote: >=20 > On Jul 1, 2014, at 2:27 PM, Wesley Eddy wrote: >> John Leslie noticed that some of the things Bob Briscoe had >> mentioned stem from trying to work from RFC 2309 as the starting >> point. We have been planning to Obsolete and replace 2309 with >> this document. John suggested instead to let it live on, and >> have this new one only Update it, and has suggested specific >> changes that could be edited in, if this were the case. >>=20 >> I think we need to make a conscious on-list decision about this, >> and decide to either confirm that Obsoleting 2309 is correct, or >> to change course. >>=20 >> Others can amplify or correct these, but I think the points for >> each would be: >>=20 >> Obsoleting 2309 >> - 2309 was an IRTF document from a closed RG, and we now can make >> a stronger statement as an IETF group with a BCP >> - 2309 is a bit RED-centric, and we now think that people should >> be looking at things other than RED >>=20 >> Not-Obsoleting 2309 (e.g. Updating 2309) >> - 2309 is a snapshot in history of the E2E RG's thinking >> - 2309 is mostly oriented towards AQM as a mitigation for congestion >> collapse, whereas now we're more interested in reducing latency >>=20 >> Please share any thoughts you have on this, and what should be done. >=20 > I=92ll give you my view, which I just gave you privately. >=20 > The changes that have been requested include at least: > - remove the word =93RED=94 from the document. The operators find = RED difficult to use and as a result don=92t turn it on. They would like = alternative algorithm(s) that require at most minimal parameterization, = ideally none at all. > - add ECN > - add scheduling, which 2309 explicitly didn=92t address > - update references >=20 > We also have discussed additional recommendations beyond =93everyone = deploy RED=94 and =93we need more research=94. >=20 > If you count affected lines in the document, just removing the word = =93RED=94 affects 154 of the 955 lines in the document. Then we go into = the rest of the changes. I=92m not sure in what way that can be = described as an =93update=94. Gorry, Wesley, Richard, John, and I have been having a fairly lively = conversation in private mail. Let me pull out of it a few comments I = have made. John can make his points, and others can make theirs. Note = that the following are not, properly speaking, forwarded email; they are = taken from email exchanges, but edited to make them make sense in the = present context. = --------------------------------------------------------------------------= ------ As I said yesterday, I am scratching my head on what it means to = "obsolete" or "update" a document, and how that might relate to this = note. To my small mind, if I have a specification that updates another = specification, I have to read the older specification, and then I have = to read the newer one and do what it says in the part of the older that = it updates. If one specification has obsoleted another, the older = specification is only of historical interest. When I said that in private email, John replied "That is correct -- iff = you are setting out to implement the older spec." The only reason I would have to not implement the older spec is if it = were obsolete. It is was merely updated, I am by definition implementing = the older spec, with some changes. Let me give you an example. If I decide to implement TCP, I start with https://tools.ietf.org/html/rfc0793 0793 Transmission Control Protocol. J. Postel. September 1981. (Format: TXT=3D172710 bytes) (Obsoletes RFC0761) (Updated by = RFC1122, RFC3168, RFC6093, RFC6528) (Also STD0007) (Status: INTERNET = STANDARD) and also read 1122, 3168, 6093, and 6528. Those clean up some basic = stuff, add ECN, change Urgent, and add a variant on a SYN Cookie. If I = don't do those, I haven't got a correct implementation of TCP. But I was = setting out to implement the protocol defined in RFC 793, TCP. Those = documents updated 793. However, if I decide to implement=20 https://tools.ietf.org/html/rfc5681 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. September 2009. (Format: TXT=3D44339 bytes) (Obsoletes RFC2581) (Status: DRAFT STANDARD) I don't have to read RFC 2581. Everything that was in 2581 that I need = to know will be found in 5681. I'm only implementing 5681, not 2581. I = might read it for interest's sake, or as a historian, but as an = implementor it is unnecessary. = --------------------------------------------------------------------------= ------ If I understand him correctly, one of the things John is pushing back on = is obsoleting RED as an algorithm; his view, if I understand it, is that = if you can figure out what parameters to give RED, it works just fine. = On that point, I would generally agree; in my experience, RED has two = important parameters, which are min-threshold and max-threshold. The = mean latency through a queue will generally be governed by and = approximate min-threshold, so one wants to set it just deep enough to = accomplish ones latency goals, and max-threshold is derived from the = underlying hardware.=20 However, the operational commentary on RED in twvarea, tsvwg, and over = time has been that "just deep enough to accomplish ones latency goals" = is fuzzy enough to be difficult to use. CoDel was developed, in part, to = make the latency goal an explicit algorithmic factor; if part of the = delay in a transmission system is, for example, channel acquisition = delay (think about the behavior of busy conference WiFi systems), it = would be nice to have that factored into the calculation as well as = actual queue depth (which is corollary to but not necessarily indicative = of latency). Other algorithms, of which PIE is an example, work with = queue depth as a corollary to latency, and adjust their understanding of = the relationship dynamically. Gorry and I have separately commented, in that private conversation, = that obsoleting RFC 2309 doesn't obsolete RED as an algorithm, nor does = it say that RED is a bad algorithm. It replaces the recommendation of = 2309, which is that=20 o RECOMMENDATION 1: Internet routers should implement some active queue management mechanism to manage queue lengths, reduce end-to-end latency, reduce packet dropping, and avoid lock-out phenomena within the Internet. The default mechanism for managing queue lengths to meet these goals in FIFO queues is Random Early Detection (RED) [RED93]. Unless a developer has reasons to provide another equivalent mechanism, we recommend that RED be used. =20 16 years following the publication of RFC 2309, it turns out that we = have issues, but the issues are not the management of queue lengths, = reduction of packet dropping, and avoidance of lock-out phenomena within = the Internet. RED, by the way, never did reduce packet loss; it drops = the same number of packets, but attempts to desynchronize them and = achieve a certain goal using them. What we *are* trying to do is reduce = queuing delay and by extension that component of end to end latency. And it turns out that there are now better algorithms than RED. I would go one step further here, and whether this comment belongs in = the draft or not is not important to me. There are two reasons one might = standardize something. The most common one, and the one that motivates = most IETF work, is interoperability of separate implementations that = have to communicate. OSPF and IS-IS, for example, need to be specified = down to the gnat's eyelash, including the "alternate Tuesday rules" that = make different implementations make the same choice when more than one = choice could reasonably and validly be made, to guarantee = interoperability. That consideration doesn't apply here; TCP will = interpret signals from the network including ECN and packet loss even if = the network doesn't realize that they are signals. The only requirement = that could be described using the term "interoperability" is that the = TCP/SCTP/whatever receiving the signals should as a result do the right = thing. The other is so that everyone agrees on what an algorithm does, = why it does it, and where it should be implemented. BCP 38, for example, = can be implemented in several ways, but because it is standardized as a = recommendation, we know what we are trying to achieve when we implement = it. What we are obsoleting, at minimum, is the recommendation that RED be = the default algorithm. What we instead recommend is that each = implementation implement some form of AQM to achieve certain purposes. = That statement alone could be an update to 2309 if 2309 made its = recommendation regarding RED in one place. However, it is throughout the = document. Hence, a change to 2309's statement regarding RED is a = pervasive change affecting every section of it. = --------------------------------------------------------------------------= ------ The other thing I think John is trying to preserve - and John, I'm = looking for your correction here - is 2309's report on research. There = has been ongoing research since 2309 was written, but a large portion of = the relevant research predates and is reported in 2309. So we have been = asked for an updated bibliography in this document, and the updates = haven't been as large as one might expect from an active research field. = I think John would like to continue to point to 2309's description of = the motivating and underlying research. On that, I go two ways. First, as a historical review of the research = the original recommendation was based on, 2309 is unsurpassed. Second, I = think we do need to motivate the updated recommendations we make, which = include for example the implementation of ECN. For that reason, we need = to point to at least some research. We have been asked, by the = proponents of fq_codel, to also mention scheduling. 2309 left that out = and said why it left that out. draft-baker-aqm-sfq-implementation is my = further reflections on the interaction between scheduling, which has to = do with the distribution of service across competing sessions, and AQM, = which has to do with latency; they two don't necessarily get along as = well with each other as one might expect. In this document, we have = tried to say that we don't have a problem with scheduling = implementations, but we think AQM might be applied differently to = different traffic classes in the same queuing system. = draft-geib-tsvwg-diffserv-intercon, for example, contemplates four = traffic classes, one of which is engineered to RFCs 3246/3247, one of = which allows for a shallow queue without AQM for UDP-based applications, = one of which allows for a deeper queue with AQM for "preferred" elastic = traffic, and one of which is simply the default class, which one might = expect AQM in but would bear the brunt of traffic loss should it occur.=20= To my mind, we're going quite a bit further than "just remove RED"; we = are doing things 2309 said it didn't want to do, and adding capabilities = that 2309 didn't consider. = --------------------------------------------------------------------------= ------ In any event, RFC 2309 remains in the historical record, which is to say = the RFC series. It's a great document. But when we send someone to = figure out what to implement in an AQM implementation, I don't think we = are going to send them there. This document, plus the set of algorithms = that we wind up recommending,are a complete replacement. So I don't see = it as an update. I see it as making 2309 "historical" or "obsoleted by" = this document. = --------------------------------------------------------------------------= ------ Which brings me back to John's proposed text. I'm frankly curious what = the working group's thought on that is. If the working group wants to = replace the existing sections 1-3 with that or an updated version of = that, so be it. I'm willing to see John added as a co-author or = co-editor and the text dropped in. If the working group prefers the = existing text, I'm OK with that. If there are glaring holes, they need = to be filled in. What I'm not OK with is a continuation of the current dinking with the = document. I don't think we have dramatically improved the document since = last November, although we have done a lot of work on it to respond to = working group comments. It feels to me like we, as a working group, have = lost our way. =46rom this point on, *I* think we need to ask ourselves = whether any given change we make materially improves the document or = merely dinks with the text. And we should limit changes to material = improvements. --Apple-Mail=_0C145BBC-2077-49D7-AF54-97B5DD2E490B 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 iD8DBQFTtF8pbjEdbHIsm0MRAkqNAJ9XCT5Vn1NxGF+eW4AShxjQjvHfDgCg97oJ DcE7NRfTMcYb1bv1b7vZyIg= =G9xS -----END PGP SIGNATURE----- --Apple-Mail=_0C145BBC-2077-49D7-AF54-97B5DD2E490B-- From nobody Wed Jul 2 13:44:05 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74BF1B2986 for ; Wed, 2 Jul 2014 13:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2VZCOsXSAtA for ; Wed, 2 Jul 2014 13:44:00 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D227C1B2984 for ; Wed, 2 Jul 2014 13:43:59 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 62A1FC94C0; Wed, 2 Jul 2014 16:43:56 -0400 (EDT) Date: Wed, 2 Jul 2014 16:43:56 -0400 From: John Leslie To: "aqm@ietf.org" Message-ID: <20140702204356.GE85889@verdi> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/BPsxdfB7I6OZzTxA2XrG2yUJg3w Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 20:44:04 -0000 Fred Baker (fred) wrote: > On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) wrote: >> On Jul 1, 2014, at 2:27 PM, Wesley Eddy wrote: >> >>> John Leslie noticed that some of the things Bob Briscoe had >>> mentioned stem from trying to work from RFC 2309 as the starting >>> point. We have been planning to Obsolete and replace 2309 with >>> this document. John suggested instead to let it live on, and >>> have this new one only Update it, and has suggested specific >>> changes that could be edited in, if this were the case. Briefly, this started with a promise I made to Fred to review aqm-recommendation from the viewpoint of a CTO. I did so, ending up with a heck-of-a-lot of red ink on the document. I noticed that the red ink was heavily concentrated in Sections 1 through 3, which for the most part restated nearly verbatim the language of 2309. Thus I wrote to Wes, asking why we had to "obsolete" 2309 instead of "update" it. >>> I think we need to make a conscious on-list decision about this, >>> and decide to either confirm that Obsoleting 2309 is correct, or >>> to change course. >>>=20 >>> Others can amplify or correct these, but I think the points for >>> each would be: >>>=20 >>> Obsoleting 2309 >>> - 2309 was an IRTF document from a closed RG, and we now can make >>> a stronger statement as an IETF group with a BCP Any BCP we publish will do that. >>> - 2309 is a bit RED-centric, and we now think that people should >>> be looking at things other than RED I agree; but the way to accomplish that is to state it clearly in the BCP we publish, not expect people to guess that's what we meant to do by declaring it obsolete. >>> Not-Obsoleting 2309 (e.g. Updating 2309) >>> - 2309 is a snapshot in history of the E2E RG's thinking >>> - 2309 is mostly oriented towards AQM as a mitigation for congestion >>> collapse, whereas now we're more interested in reducing latency I agree with these, of course... [Fred replied:] >>=20 >> The changes that have been requested include at least: >> - remove the word 'RED' from the document... That wouldn't accomplish what they want -- even if aqm-rec obsoletes 2309. We have to say that RED is no longer recommended. >> The operators find RED difficult to use and as a result don't turn >> it on. I support saying this, in as many words. >> They would like alternative algorithm(s) that require at most >> minimal parameterization, ideally none at all. Likewise. >> - add ECN Likewise. >> - add scheduling, which 2309 explicitly didn?t address This is a bit more difficult, but I'd be glad to see it. >> - update references This sounds like more trouble than it's worth. If we write a 2309bis, we really ought to do it; but I thought we had decided against that. >> We also have discussed additional recommendations beyond >> 'everyone deploy RED' and 'we need more research'. Indeed, we must do that to follow our charter. >> If you count affected lines in the document, just removing the word >> 'RED' affects 154 of the 955 lines in the document. Then we go into >> the rest of the changes. I'm not sure in what way that can be >> described as an 'update'. Fred makes my point: trying for a 2309bis by blindly making those changes proves to be completely impractical. Thus, I supplied Wes with an example of a rewrite of Sections 1 through 3 that referred to 2309 as an Informative Reference to lay the background for what we actually recommend. I'll post that to the list separately: it's a bit long-winded, but nowhere nearly as long-winded as the current Sections 1 through 3; and IMHO it's quite a bit easier for a CTO to read. > Gorry, Wesley, Richard, John, and I have been having a fairly lively > conversation in private mail.i I quite agree with Fred that this deserves to go on-list. And I give Fred 100% permission to quote anything I wrote (with a possible exception for where I was quoting someone else). > Let me pull out of it a few comments I have made. John can make his > points, and others can make theirs. Note that the following are not, > properly speaking, forwarded email; they are taken from emaili > exchanges, but edited to make them make sense in the present context. >=20 > -------------------------------------------------------------------------= ----- This seems like a good point to break: we're already over 100 lines. I promise to come back to this right after posting my example Sections 1 through 3. -- John Leslie From nobody Wed Jul 2 13:54:57 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C661B2A81 for ; Wed, 2 Jul 2014 13:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfMwl2O8HLiK for ; Wed, 2 Jul 2014 13:54:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D695C1B28A8 for ; Wed, 2 Jul 2014 13:54:51 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E24BBC94A8; Wed, 2 Jul 2014 16:54:48 -0400 (EDT) Date: Wed, 2 Jul 2014 16:54:48 -0400 From: John Leslie To: "aqm@ietf.org" Message-ID: <20140702205448.GF85889@verdi> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/WDSLhK7qvy9uzAa4PQ_aMA6YuEk Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 20:54:56 -0000 This is the example-rewrite of Sections 1 through 3 I provided to Wes. There would be other changes to other sections (though I'm not pushing for any in particular right now). It includes the majority of new text from version -05, but not any changes since then. The idea is simply to explicitly reference 2309 for any text which was copied from it. I didn't attempt to cover every small wording change -- these would require explaining the context of the change, and IMHO are better covered by explicit statements of the reason for such changes. I'd be happy to see text for cases where someone thinks that change is needed as background for our recommendations, not just as an improvement to the text of 2309. Feel free to comment on what's missing (other than changes since version -05). *************************** cut here *************************** 1. Introduction RFC 2309 introduces the concept of "Active Queue Management" and describes one AQM algorithm. Since 1998, other AQM algorithms have come into use. This document updates RFC 2309 where needed, and gives recommendations for future AQM algorithms. Section 3 of RFC 2309 describes Random Early Detection ("RED"). Similar algorithms are specified for other non-TCP transports. =20 RFC 2309 makes recommendations for "routers." Today these same recommendations apply to a number of other network devices, including switches, tunnel endpoints, Network Address Transform ("NAT") devices, and other middleboxes, which pass packets, whether unchanged or modified, into outgoing queues. A number of AQM procedures are described in the literature with different characteristics. This document does not recommend any of them in particular, but does make recommendations that ideally would affect the choice of procedure used in a given implementation. Methods such as congestion exposure (ConEx) [RFC6789] offer a framework [CONEX] that can update network devices to alleviate the effects of unresponsive flows. The discussion in this memo applies to "best-effort" traffic, which is to say, traffic generated by applications that accept the occasional loss, duplication, or reordering of traffic in flight. It also applies to other traffic, such as real-time traffic that can adapt its sending rate to reduce loss and/or delay. It is most effective when the adaption occurs on time scales of a single Round Trip Time (RTT) or a small number of RTTs, for elastic traffic [RFC1633]. [RFC2309] resulted from past discussions of end-to-end performance, Internet congestion, and Random Early Discard (RED) in the End-to-End Research Group of the Internet Research Task Force (IRTF). This update results from experience with this and other algorithms, and the AQM discussion within the IETF[AQM-WG]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The Need For Active Queue Management Active Queue Management (AQM) is a method that allows network devices to control the queue length or the mean time that a packet spends in a queue. Although AQM can be applied across a range of deployment enviroments, the recommendations in this document are directed to use in the general Internet. It is expected that the principles and guidance are also applicable to a wide range of environments, but may require tuning for specific types of link/network (e.g. to accommodate the traffic patterns found in data centres, the challenges of wireless infrastructure, or the higher delay encountered on satellite Internet links). Section 2 of RFC 2309 discusses "tail drop" -- dropping the most-recently-received packet, as well as "drop front on full" and "random-drop-on-full". The reader may wish to review that Section. Congestion control, like other end-to-end mechanisms, introduces a control loop between hosts. Sessions that share a common network bottleneck can therefore become synchronised, introducing periodic disruption (e.g. jitter/loss). "lock-out" is often also the result of synchronization or other timing effects. AQM can be combined with a scheduling mechanism that divides network traffic between multiple queues (Section 2.1). The probability of network control loop synchronisation can be reduced by introducing randomness in the AQM functions used by network devices that trigger congestion avoidance at the sending host. 2.1. AQM and Multiple Queues A network device may use per-flow or per-class queuing with a scheduling algorithm to either prioritise certain applications or classes of traffic, or to provide isolation between different traffic flows within a common class. For example, a router may maintain per- flow state to achieve general fairness by a per-flow scheduling algorithm such as various forms of Fair Queueing (FQ) [Dem90], including Weighted Fair Queuing (WFQ), Stochastic Fairness Queueing (SFQ) [McK90] Deficit Round Robin (DRR) [Shr96] and/or a Class-Based Queue scheduling algorithm such as CBQ [Floyd95]. Hierarchical queues may also be used e.g., as a part of a Hierarchical Token Bucket (HTB), or Hierarchical Fair Service Curve (HFSC) [Sto97] . These methods are also used to realise a range of Quality of Service (QoS) behaviours designed to + meet the need of traffic classes (e.g. using the integrated or differentiated service models). Using a combination of AQM and scheduling between multiple queues has been shown to offer good results in experimental and some types of operational use. 2.2. AQM and Explicit Congestion Marking (ECN) An AQM method may use Explicit Congestion Notification (ECN) [RFC3168] instead of dropping to mark packets under mild or moderate congestion. ECN-marking can allow a network device to signal congestion at a point before a transport experiences congestion loss or additional queuing delay [ECN-Benefit]. Section 4.2.1 describes some of the benefits of using ECN with AQM. 2.3. AQM and Buffer Size It is important to differentiate the choice of buffer size for a queue in a switch/router or other network device, and the threshold(s) and other parameters that determine how and when an AQM algorithm operates. One the one hand, the optimum buffer size is a function of operational requirements and should generally be sized to be sufficient to buffer the largest normal traffic burst that is expected. This size depends on the number and burstiness of traffic arriving at the queue and the rate at which traffic leaves the queue. Different types of traffic and deployment scenarios will lead to different requirements. AQM frees a designer from having to the limit buffer space to achieve acceptable performance, allowing allocation of sufficient buffering to satisfy the needs of the particular traffic pattern. On the other hand, the choice of AQM algorithm and associated parameters is a function of the way in which congestion is experienced and the required reaction to achieve acceptable performance. This latter topic is the primary topic of the following sections. 3. Managing Aggressive Flows Section 4 of RFC 2309 discusses the management of aggressive flows. Since RFC 2309 was written in 1998, the concept of "TCP-friendly" has generally replaced the concept of "TCP-compatible." In this document a flow is known as "TCP-friendly" when it has a congestion response that approximates the average response expected of a TCP flow. One example method of a TCP-friendly scheme is the TCP-Friendly Rate Control algorithm [RFC5348]. In this document, the term is used more generally to describe this and other algorithms that meet these goals. A TCP-friendly flow responds to congestion notification within a small number of path Round Trip Times (RTT), and in steady-state it uses no more capacity than a conformant TCP running under comparable conditions (drop rate, RTT, packet size, etc.). The User Datagram Protocol (UDP) [RFC0768] provides a minimal, best-effort transport to applications and upper-layer protocols (both simply called "applications" in the remainder of this document) and does not itself establish a degree of fairness [RFC5405]. Some applications (e.g. current web browsers) open a large number of short TCP flows for a single session. This can lead to each individual flow spending the majority of time in the exponential TCP slow start phase, rather than in TCP congestion avoidance. The resulting traffic aggregate can therefore be much less responsive than a single standard TCP flow. An RTP/UDP video flow that uses an adaptive codec but responds incompletely to indications of congestion or responds over an excessively long time period may not be responsive to congestion signals in a timeframe comparable to a small number of end-to-end transmission delays. However, over a longer timescale, perhaps seconds in duration, they con moderate their speed, or increase their speed if they determine capacity to be available. Tunneled traffic aggregates carrying multiple (short) TCP flows can be more aggressive than standard bulk TCP. Applications (e.g. web browsers and peer-to-peer file-sharing) have exploited this by opening multiple connections to the same endpoint. *************************** cut here *************************** -- John Leslie Fred Baker (fred) wrote: > From: "Fred Baker (fred)" > To: "aqm@ietf.org" > CC: Wesley Eddy , John Leslie > Subject: Re: [aqm] Obsoleting RFC 2309 > Date: Wed, 2 Jul 2014 19:36:11 +0000 >=20 >=20 > On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) wrote: >=20 > >=20 > > On Jul 1, 2014, at 2:27 PM, Wesley Eddy wrote: > >> John Leslie noticed that some of the things Bob Briscoe had > >> mentioned stem from trying to work from RFC 2309 as the starting > >> point. We have been planning to Obsolete and replace 2309 with > >> this document. John suggested instead to let it live on, and > >> have this new one only Update it, and has suggested specific > >> changes that could be edited in, if this were the case. > >>=20 > >> I think we need to make a conscious on-list decision about this, > >> and decide to either confirm that Obsoleting 2309 is correct, or > >> to change course. > >>=20 > >> Others can amplify or correct these, but I think the points for > >> each would be: > >>=20 > >> Obsoleting 2309 > >> - 2309 was an IRTF document from a closed RG, and we now can make > >> a stronger statement as an IETF group with a BCP > >> - 2309 is a bit RED-centric, and we now think that people should > >> be looking at things other than RED > >>=20 > >> Not-Obsoleting 2309 (e.g. Updating 2309) > >> - 2309 is a snapshot in history of the E2E RG's thinking > >> - 2309 is mostly oriented towards AQM as a mitigation for congestion > >> collapse, whereas now we're more interested in reducing latency > >>=20 > >> Please share any thoughts you have on this, and what should be done. > >=20 > > I?ll give you my view, which I just gave you privately. > >=20 > > The changes that have been requested include at least: > > - remove the word ?RED? from the document. The operators find RED di= fficult to use and as a result don?t turn it on. They would like alternativ= e algorithm(s) that require at most minimal parameterization, ideally none = at all. > > - add ECN > > - add scheduling, which 2309 explicitly didn?t address > > - update references > >=20 > > We also have discussed additional recommendations beyond ?everyone depl= oy RED? and ?we need more research?. > >=20 > > If you count affected lines in the document, just removing the word ?RE= D? affects 154 of the 955 lines in the document. Then we go into the rest o= f the changes. I?m not sure in what way that can be described as an ?update= ?. >=20 > Gorry, Wesley, Richard, John, and I have been having a fairly lively conv= ersation in private mail. Let me pull out of it a few comments I have made.= John can make his points, and others can make theirs. Note that the follow= ing are not, properly speaking, forwarded email; they are taken from email = exchanges, but edited to make them make sense in the present context. >=20 > -------------------------------------------------------------------------= ------- > As I said yesterday, I am scratching my head on what it means to "obsolet= e" or "update" a document, and how that might relate to this note. >=20 > To my small mind, if I have a specification that updates another specific= ation, I have to read the older specification, and then I have to read the = newer one and do what it says in the part of the older that it updates. If = one specification has obsoleted another, the older specification is only of= historical interest. >=20 > When I said that in private email, John replied "That is correct -- iff y= ou are setting out to implement the older spec." >=20 > The only reason I would have to not implement the older spec is if it wer= e obsolete. It is was merely updated, I am by definition implementing the o= lder spec, with some changes. >=20 > Let me give you an example. If I decide to implement TCP, I start with >=20 > https://tools.ietf.org/html/rfc0793 > 0793 Transmission Control Protocol. J. Postel. September 1981. > (Format: TXT=3D172710 bytes) (Obsoletes RFC0761) (Updated by RFC1122, > RFC3168, RFC6093, RFC6528) (Also STD0007) (Status: INTERNET STANDARD) >=20 > and also read 1122, 3168, 6093, and 6528. Those clean up some basic stuff= , add ECN, change Urgent, and add a variant on a SYN Cookie. If I don't do = those, I haven't got a correct implementation of TCP. But I was setting out= to implement the protocol defined in RFC 793, TCP. Those documents updated= 793. >=20 > However, if I decide to implement=20 >=20 > https://tools.ietf.org/html/rfc5681 > 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. > September 2009. (Format: TXT=3D44339 bytes) (Obsoletes RFC2581) > (Status: DRAFT STANDARD) >=20 > I don't have to read RFC 2581. Everything that was in 2581 that I need to= know will be found in 5681. I'm only implementing 5681, not 2581. I might = read it for interest's sake, or as a historian, but as an implementor it is= unnecessary. > -------------------------------------------------------------------------= ------- > If I understand him correctly, one of the things John is pushing back on = is obsoleting RED as an algorithm; his view, if I understand it, is that if= you can figure out what parameters to give RED, it works just fine. On tha= t point, I would generally agree; in my experience, RED has two important p= arameters, which are min-threshold and max-threshold. The mean latency thro= ugh a queue will generally be governed by and approximate min-threshold, so= one wants to set it just deep enough to accomplish ones latency goals, and= max-threshold is derived from the underlying hardware.=20 >=20 > However, the operational commentary on RED in twvarea, tsvwg, and over ti= me has been that "just deep enough to accomplish ones latency goals" is fuz= zy enough to be difficult to use. CoDel was developed, in part, to make the= latency goal an explicit algorithmic factor; if part of the delay in a tra= nsmission system is, for example, channel acquisition delay (think about th= e behavior of busy conference WiFi systems), it would be nice to have that = factored into the calculation as well as actual queue depth (which is corol= lary to but not necessarily indicative of latency). Other algorithms, of wh= ich PIE is an example, work with queue depth as a corollary to latency, and= adjust their understanding of the relationship dynamically. >=20 > Gorry and I have separately commented, in that private conversation, that= obsoleting RFC 2309 doesn't obsolete RED as an algorithm, nor does it say = that RED is a bad algorithm. It replaces the recommendation of 2309, which = is that=20 >=20 > o RECOMMENDATION 1: >=20 > Internet routers should implement some active queue management > mechanism to manage queue lengths, reduce end-to-end latency, > reduce packet dropping, and avoid lock-out phenomena within the > Internet. >=20 > The default mechanism for managing queue lengths to meet these > goals in FIFO queues is Random Early Detection (RED) [RED93]. > Unless a developer has reasons to provide another equivalent > mechanism, we recommend that RED be used. > =20 > 16 years following the publication of RFC 2309, it turns out that we have= issues, but the issues are not the management of queue lengths, reduction = of packet dropping, and avoidance of lock-out phenomena within the Internet= . RED, by the way, never did reduce packet loss; it drops the same number o= f packets, but attempts to desynchronize them and achieve a certain goal us= ing them. What we *are* trying to do is reduce queuing delay and by extensi= on that component of end to end latency. >=20 > And it turns out that there are now better algorithms than RED. >=20 > I would go one step further here, and whether this comment belongs in the= draft or not is not important to me. There are two reasons one might stand= ardize something. The most common one, and the one that motivates most IETF= work, is interoperability of separate implementations that have to communi= cate. OSPF and IS-IS, for example, need to be specified down to the gnat's = eyelash, including the "alternate Tuesday rules" that make different implem= entations make the same choice when more than one choice could reasonably a= nd validly be made, to guarantee interoperability. That consideration doesn= 't apply here; TCP will interpret signals from the network including ECN an= d packet loss even if the network doesn't realize that they are signals. Th= e only requirement that could be described using the term "interoperability= " is that the TCP/SCTP/whatever receiving the signals should as a result do= the right thing. The other is so that everyone agrees on what an algorithm= does, why it does it, and where it should be implemented. BCP 38, for exam= ple, can be implemented in several ways, but because it is standardized as = a recommendation, we know what we are trying to achieve when we implement i= t. >=20 > What we are obsoleting, at minimum, is the recommendation that RED be the= default algorithm. What we instead recommend is that each implementation i= mplement some form of AQM to achieve certain purposes. That statement alone= could be an update to 2309 if 2309 made its recommendation regarding RED i= n one place. However, it is throughout the document. Hence, a change to 230= 9's statement regarding RED is a pervasive change affecting every section o= f it. > -------------------------------------------------------------------------= ------- > The other thing I think John is trying to preserve - and John, I'm lookin= g for your correction here - is 2309's report on research. There has been o= ngoing research since 2309 was written, but a large portion of the relevant= research predates and is reported in 2309. So we have been asked for an up= dated bibliography in this document, and the updates haven't been as large = as one might expect from an active research field. I think John would like = to continue to point to 2309's description of the motivating and underlying= research. >=20 > On that, I go two ways. First, as a historical review of the research the= original recommendation was based on, 2309 is unsurpassed. Second, I think= we do need to motivate the updated recommendations we make, which include = for example the implementation of ECN. For that reason, we need to point to= at least some research. We have been asked, by the proponents of fq_codel,= to also mention scheduling. 2309 left that out and said why it left that o= ut. draft-baker-aqm-sfq-implementation is my further reflections on the int= eraction between scheduling, which has to do with the distribution of servi= ce across competing sessions, and AQM, which has to do with latency; they t= wo don't necessarily get along as well with each other as one might expect.= In this document, we have tried to say that we don't have a problem with s= cheduling implementations, but we think AQM might be applied differently to= different traffic classes in the same queuing system. draft-geib-tsvwg-dif= fserv-intercon, for example, contemplates four traffic classes, one of whic= h is engineered to RFCs 3246/3247, one of which allows for a shallow queue = without AQM for UDP-based applications, one of which allows for a deeper qu= eue with AQM for "preferred" elastic traffic, and one of which is simply th= e default class, which one might expect AQM in but would bear the brunt of = traffic loss should it occur.=20 >=20 > To my mind, we're going quite a bit further than "just remove RED"; we ar= e doing things 2309 said it didn't want to do, and adding capabilities that= 2309 didn't consider. > -------------------------------------------------------------------------= ------- >=20 > In any event, RFC 2309 remains in the historical record, which is to say = the RFC series. It's a great document. But when we send someone to figure o= ut what to implement in an AQM implementation, I don't think we are going t= o send them there. This document, plus the set of algorithms that we wind u= p recommending,are a complete replacement. So I don't see it as an update. = I see it as making 2309 "historical" or "obsoleted by" this document. >=20 > -------------------------------------------------------------------------= ------- >=20 > Which brings me back to John's proposed text. I'm frankly curious what th= e working group's thought on that is. If the working group wants to replace= the existing sections 1-3 with that or an updated version of that, so be i= t. I'm willing to see John added as a co-author or co-editor and the text d= ropped in. If the working group prefers the existing text, I'm OK with that= . If there are glaring holes, they need to be filled in. >=20 > What I'm not OK with is a continuation of the current dinking with the do= cument. I don't think we have dramatically improved the document since last= November, although we have done a lot of work on it to respond to working = group comments. It feels to me like we, as a working group, have lost our w= ay. From this point on, *I* think we need to ask ourselves whether any give= n change we make materially improves the document or merely dinks with the = text. And we should limit changes to material improvements. >=20 >=20 >=20 >=20 From nobody Wed Jul 2 15:03:27 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3001B2ADD for ; Wed, 2 Jul 2014 15:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTjty4pGPe3M for ; Wed, 2 Jul 2014 15:03:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 21C631A037D for ; Wed, 2 Jul 2014 15:03:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A9F6AC94C7; Wed, 2 Jul 2014 18:03:13 -0400 (EDT) Date: Wed, 2 Jul 2014 18:03:13 -0400 From: John Leslie To: "aqm@ietf.org" Message-ID: <20140702220313.GG85889@verdi> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/514uitGfUN6hvTjDtdq3R4o5i8E Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 22:03:25 -0000 Fred Baker (fred) wrote: > On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) wrote: >=20 > As I said yesterday, I am scratching my head on what it means to > "obsolete" or "update" a document, and how that might relate to this note. Fred is not alone! The IESG keeps coming back to that! > To my small mind, if I have a specification that updates another > specification, I have to read the older specification, and then > I have to read the newer one and do what it says in the part of the > older that it updates. If one specification has obsoleted another, > the older specification is only of historical interest. >=20 > When I said that in private email, John replied > "That is correct -- iff you are setting out to implement the older spec." Exactly. If you are implementing the newer spec, you have to read the older one if, and only if, it is listed among the Normative References. At the time I wrote that, it didn't occur to me that anyone today would be told to "implement 2309". > The only reason I would have to not implement the older spec is if > it were obsolete. It is was merely updated, I am by definition > implementing the older spec, with some changes. This confused me at the time... It still confuses me. > Let me give you an example. If I decide to implement TCP, I start with >=20 > https://tools.ietf.org/html/rfc0793 > 0793 Transmission Control Protocol. J. Postel. September 1981. > (Format: TXT=3D172710 bytes) (Obsoletes RFC0761) (Updated by RFC1122, > RFC3168, RFC6093, RFC6528) (Also STD0007) (Status: INTERNET STANDARD) >=20 > and also read 1122, 3168, 6093, and 6528. Those clean up some basic > stuff, add ECN, change Urgent, and add a variant on a SYN Cookie. > If I don't do those, I haven't got a correct implementation of TCP. (Many folks claim to have a "correct implementation of TCP" without implementing all those. :^( We have no way of policing this -- but we do from time to time try to produce a TCP-roadmap kind of document.) > But I was setting out to implement the protocol defined in RFC 793, > TCP. Those documents updated 793. (TCP, IMHO, is the worst case among RFCs!) > However, if I decide to implement=20 >=20 > https://tools.ietf.org/html/rfc5681 > 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. > September 2009. (Format: TXT=3D44339 bytes) (Obsoletes RFC2581) > (Status: DRAFT STANDARD) >=20 > I don't have to read RFC 2581. Everything that was in 2581 that I > need to know will be found in 5681. I'm only implementing 5681, > not 2581. I might read it for interest's sake, or as a historian, > but as an implementor it is unnecessary. The same would be true if 5681 merely updated 2581 but didn't list it as a normative reference. (Of course, if 5681 weren't a DRAFT STANDARD it might not be succeptible to implementation under those conditions.) But what Fred says is correct. It's just that "implementing AQM-REC" has a defined meaning, while "implementing 2309" is hopelessly vague -- since 2309 mostly discusses research, and only lists RED as an example. > If I understand him correctly, one of the things John is pushing back > on is obsoleting RED as an algorithm; I am saying that obsoleting RED seems premature. > his view, if I understand it, is that if you can figure out what > parameters to give RED, it works just fine. I'm saying that's a widespread belief. > On that point, I would generally agree; in my experience, RED has > two important parameters, which are min-threshold and max-threshold. > The mean latency through a queue will generally be governed by and > approximate min-threshold, so one wants to set it just deep enough > to accomplish ones latency goals, and max-threshold is derived from > the underlying hardware.=20 Yes, but actually my point is that folks are shipping varieties of RED; and we're unlikely to change that by any classification of 2309. > However, the operational commentary on RED in twvarea, tsvwg, and > over time has been that "just deep enough to accomplish ones latency > goals" is fuzzy enough to be difficult to use. I absolutely agree! > CoDel was developed, in part, to make the latency goal an explicit > algorithmic factor; if part of the delay in a transmission system is, > for example, channel acquisition delay (think about the behavior of > busy conference WiFi systems), it would be nice to have that factored > into the calculation as well as actual queue depth (which is > corollary to but not necessarily indicative of latency). I agree on the goals, and agree that CoDel was a step in that direction. > Other algorithms, of which PIE is an example, work with queue depth > as a corollary to latency, and adjust their understanding of the > relationship dynamically. Agreed. > Gorry and I have separately commented, in that private conversation, > that obsoleting RFC 2309 doesn't obsolete RED as an algorithm, > nor does it say that RED is a bad algorithm. It replaces the > recommendation of 2309, which is that=20 >=20 > o RECOMMENDATION 1: >=20 > Internet routers should implement some active queue management > mechanism to manage queue lengths, reduce end-to-end latency, > reduce packet dropping, and avoid lock-out phenomena within the > Internet. > > The default mechanism for managing queue lengths to meet these > goals in FIFO queues is Random Early Detection (RED) [RED93]. > Unless a developer has reasons to provide another equivalent > mechanism, we recommend that RED be used. More exactly, AQM-REC replaces that (whether or not 2309 is obsoleted). > 16 years following the publication of RFC 2309, it turns out that we > have issues, but the issues are not the management of queue lengths, > reduction of packet dropping, and avoidance of lock-out phenomena > within the Internet. I'm not sure I agree there -- but the problems certainly _have_ changed and we ought to describe at least some of the changes. > RED, by the way, never did reduce packet loss; it drops the same > number of packets, but attempts to desynchronize them and achieve > a certain goal using them. A perfect example of why we want to avoid AQM-REC being 2309bis. A 2309bis would have to discuss this! > What we *are* trying to do is reduce queuing delay and by extension > that component of end to end latency. I completely agree. > And it turns out that there are now better algorithms than RED. I also agree there -- I'm just not convinced we're ready which to recommend. > I would go one step further here, and whether this comment belongs in > the draft or not is not important to me. There are two reasons one > might standardize something. The most common one, and the one that > motivates most IETF work, is interoperability of separate > implementations that have to communicate. OSPF and IS-IS, for example, > need to be specified down to the gnat's eyelash, including the > "alternate Tuesday rules" that make different implementations make > the same choice when more than one choice could reasonably and > validly be made, to guarantee interoperability. Yes. > That consideration doesn't apply here; TCP will interpret signals > from the network including ECN and packet loss even if the network > doesn't realize that they are signals. The only requirement that > could be described using the term "interoperability" is that the > TCP/SCTP/whatever receiving the signals should as a result do the > right thing. There are bunches of things within TCP where interoperation is a matter of hoping for the best. :^( But standardizing several of the possible choices still helps. > The other is so that everyone agrees on what an algorithm does, why > it does it, and where it should be implemented. (Fred is an optimist! ;^) > BCP 38, for example, can be implemented in several ways, but because > it is standardized as a recommendation, we know what we are trying > to achieve when we implement it. Yes, even this helps. > What we are obsoleting, at minimum, is the recommendation that RED > be the default algorithm. What we instead recommend is that each > implementation implement some form of AQM to achieve certain purposes. IMHO that's already done, even if we neither obsolete no update 2309. > That statement alone could be an update to 2309 if 2309 made its > recommendation regarding RED in one place. However, it is throughout > the document. Hence, a change to 2309's statement regarding RED is > a pervasive change affecting every section of it. It doesn't matter how pervasive the change -- it only matters that the intent of the update is stated clearly enough. > The other thing I think John is trying to preserve - and John, I'm > looking for your correction here - is 2309's report on research. I do believe that that report deserves to be preserved. I see no reason to declare it obsolete. But my concern is that we avoid the rathole of trying to update it while obsoleting 2309 itself. > There has been ongoing research since 2309 was written, but a large > portion of the relevant research predates and is reported in 2309. Agreed. > So we have been asked for an updated bibliography in this document, I'm _really_ tempted to "Just say No!" here. Such an updated bibliography would indeed be useful, but its utility doesn't depend on doing it here; and it feels like part of that rathole I want to avoid. > and the updates haven't been as large as one might expect from an > active research field. Are you surprised? > I think John would like to continue to point to 2309's description > of the motivating and underlying research. Yes. > On that, I go two ways. First, as a historical review of the research > the original recommendation was based on, 2309 is unsurpassed. > Second, I think we do need to motivate the updated recommendations > we make, which include for example the implementation of ECN. For > that reason, we need to point to at least some research. Indeed! But it isn't the same research "updated bibliography" implies. > We have been asked, by the proponents of fq_codel, to also mention > scheduling. 2309 left that out and said why it left that out. This is an area for "Send text!" > draft-baker-aqm-sfq-implementation is my further reflections on the > interaction between scheduling, which has to do with the distribution > of service across competing sessions, and AQM, which has to do with > latency; they two don't necessarily get along as well with each other > as one might expect. (My expectations were pretty low to start with! ;^) > In this document, we have tried to say that we don't have a problem > with scheduling implementations, but we think AQM might be applied > differently to different traffic classes in the same queuing system. Talking "scheduling" _will_ confuse that CTO... > draft-geib-tsvwg-diffserv-intercon, for example, contemplates four > traffic classes, one of which is engineered to RFCs 3246/3247, > one of which allows for a shallow queue without AQM for UDP-based > applications, one of which allows for a deeper queue with AQM for > "preferred" elastic traffic, and one of which is simply the default > class, which one might expect AQM in but would bear the brunt of > traffic loss should it occur.=20 I don't think we're prepared to say very much about that... > To my mind, we're going quite a bit further than "just remove RED"; > we are doing things 2309 said it didn't want to do, and adding > capabilities that 2309 didn't consider. And I agree we should be doing that. > In any event, RFC 2309 remains in the historical record, which is to > say the RFC series. It's a great document. But when we send someone > to figure out what to implement in an AQM implementation, I don't > think we are going to send them there. It would be strange to send anyone to a 16-year-old Individual Informational RFC instead of an IETF BCP. > This document, plus the set of algorithms that we wind up recommending, > are a complete replacement. I don't think AQM-REQ version -05 quite makes it there. And I want to stop trying. > So I don't see it as an update. I see it as making 2309 "historical" > or "obsoleted by" this document. Those are different categories. "Historical" is typically handled by an IESG management item nowadays. "Obsoleted-by" implies that everything of current importance is covered in the new document. Personally, I wouldn't try for that. But once AQM-REC is published as a BCP, I certainly wouldn' oppose an IESG management item to move 2309 to "historic". > -------------------------------------------------------------------------= --- >=20 > Which brings me back to John's proposed text. I'm frankly curious what > the working group's thought on that is. If the working group wants to > replace the existing sections 1-3 with that or an updated version of > that, so be it. I'm willing to see John added as a co-author or > co-editor and the text dropped in. If the working group prefers the > existing text, I'm OK with that. If there are glaring holes, they need > to be filled in. (For many years I resisted authoring an RFC; but I won't resist now.) "Glaring", I'm afraid, is in the eye of the beholder. I don't mean to bring up holes in AQM-REC as a 2309bis; but others keep mentioning them, and they sure look like holes to me. :^( > What I'm not OK with is a continuation of the current dinking with > the document. I don't think we have dramatically improved the document > since last November, I'm mostly with Fred here: I _want_ to stop dinking with it! > although we have done a lot of work on it to respond to working group > comments. It feels to me like we, as a working group, have lost our > way. From this point on, *I* think we need to ask ourselves whether > any given change we make materially improves the document or merely > dinks with the text. And we should limit changes to material improvements. I mostly agree. That's why I'm proposing a material change in approach, to greatly reduce the area for dinking. -- John Leslie From nobody Thu Jul 3 00:55:02 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654441A01BE for ; Thu, 3 Jul 2014 00:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecejJysAfx0l for ; Thu, 3 Jul 2014 00:54:56 -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 4149A1A008D for ; Thu, 3 Jul 2014 00:54:56 -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 BAD1E2B40E1; Thu, 3 Jul 2014 08:54:54 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 3 Jul 2014 08:54:54 +0100 Message-ID: <2de4d08c1dff0eca315203f8d801e660.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20140702220313.GG85889@verdi> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> Date: Thu, 3 Jul 2014 08:54:54 +0100 From: gorry@erg.abdn.ac.uk To: "John Leslie" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/NLn8LTNZhqMIpmZp9mTtpVbjps4 Cc: "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 07:55:00 -0000 Just to keep people on the same page, the latest version is -06. > Fred Baker (fred) wrote: >> On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) wrote: >> >> As I said yesterday, I am scratching my head on what it means to >> "obsolete" or "update" a document, and how that might relate to this >> note. > > Fred is not alone! The IESG keeps coming back to that! > I think we need AD advice on this. >> To my small mind, if I have a specification that updates another >> specification, I have to read the older specification, and then >> I have to read the newer one and do what it says in the part of the >> older that it updates. If one specification has obsoleted another, >> the older specification is only of historical interest. >> >> When I said that in private email, John replied >> "That is correct -- iff you are setting out to implement the older >> spec." > > Exactly. If you are implementing the newer spec, you have to read > the older one if, and only if, it is listed among the Normative > References. > > At the time I wrote that, it didn't occur to me that anyone today > would be told to "implement 2309". > >> The only reason I would have to not implement the older spec is if >> it were obsolete. It is was merely updated, I am by definition >> implementing the older spec, with some changes. > > This confused me at the time... It still confuses me. > >> Let me give you an example. If I decide to implement TCP, I start with >> >> https://tools.ietf.org/html/rfc0793 >> 0793 Transmission Control Protocol. J. Postel. September 1981. >> (Format: TXT=172710 bytes) (Obsoletes RFC0761) (Updated by RFC1122, >> RFC3168, RFC6093, RFC6528) (Also STD0007) (Status: INTERNET >> STANDARD) >> >> and also read 1122, 3168, 6093, and 6528. Those clean up some basic >> stuff, add ECN, change Urgent, and add a variant on a SYN Cookie. >> If I don't do those, I haven't got a correct implementation of TCP. > > (Many folks claim to have a "correct implementation of TCP" without > implementing all those. :^( We have no way of policing this -- but we > do from time to time try to produce a TCP-roadmap kind of document.) > >> But I was setting out to implement the protocol defined in RFC 793, >> TCP. Those documents updated 793. > > (TCP, IMHO, is the worst case among RFCs!) > >> However, if I decide to implement >> >> https://tools.ietf.org/html/rfc5681 >> 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. >> September 2009. (Format: TXT=44339 bytes) (Obsoletes RFC2581) >> (Status: DRAFT STANDARD) >> >> I don't have to read RFC 2581. Everything that was in 2581 that I >> need to know will be found in 5681. I'm only implementing 5681, >> not 2581. I might read it for interest's sake, or as a historian, >> but as an implementor it is unnecessary. > > The same would be true if 5681 merely updated 2581 but didn't list > it as a normative reference. (Of course, if 5681 weren't a DRAFT > STANDARD it might not be succeptible to implementation under those > conditions.) > > But what Fred says is correct. > > It's just that "implementing AQM-REC" has a defined meaning, > while "implementing 2309" is hopelessly vague -- since 2309 mostly > discusses research, and only lists RED as an example. > So this an RFC that is informational, but, t does recommends use of RED as THE way to do AQM. If people support this as the current recommendation - then they should speak, this is not the consensus I hear. >> If I understand him correctly, one of the things John is pushing back >> on is obsoleting RED as an algorithm; > > I am saying that obsoleting RED seems premature. > We've been through this several times, and the new draft does not do this. The intention was to remove the recommendation that RED is THE way to do AQM. >> his view, if I understand it, is that if you can figure out what >> parameters to give RED, it works just fine. > > I'm saying that's a widespread belief. > I'm suggesting this is consistent with the intention of the new document. I for one would be happy to edit if we have a specific proposal of a change. >> On that point, I would generally agree; in my experience, RED has >> two important parameters, which are min-threshold and max-threshold. >> The mean latency through a queue will generally be governed by and >> approximate min-threshold, so one wants to set it just deep enough >> to accomplish ones latency goals, and max-threshold is derived from >> the underlying hardware. > > Yes, but actually my point is that folks are shipping varieties of > RED; and we're unlikely to change that by any classification of 2309. > Indeed - but same point: I do not see what you write as the intention of the new BCP. We are speaking here in my mind about the recommendation that RED is the best current practice. >> However, the operational commentary on RED in twvarea, tsvwg, and >> over time has been that "just deep enough to accomplish ones latency >> goals" is fuzzy enough to be difficult to use. > > I absolutely agree! > >> CoDel was developed, in part, to make the latency goal an explicit >> algorithmic factor; if part of the delay in a transmission system is, >> for example, channel acquisition delay (think about the behavior of >> busy conference WiFi systems), it would be nice to have that factored >> into the calculation as well as actual queue depth (which is >> corollary to but not necessarily indicative of latency). > > I agree on the goals, and agree that CoDel was a step in that > direction. > >> Other algorithms, of which PIE is an example, work with queue depth >> as a corollary to latency, and adjust their understanding of the >> relationship dynamically. > > Agreed. > >> Gorry and I have separately commented, in that private conversation, >> that obsoleting RFC 2309 doesn't obsolete RED as an algorithm, >> nor does it say that RED is a bad algorithm. It replaces the >> recommendation of 2309, which is that >> >> o RECOMMENDATION 1: >> >> Internet routers should implement some active queue management >> mechanism to manage queue lengths, reduce end-to-end latency, >> reduce packet dropping, and avoid lock-out phenomena within the >> Internet. >> >> The default mechanism for managing queue lengths to meet these >> goals in FIFO queues is Random Early Detection (RED) [RED93]. >> Unless a developer has reasons to provide another equivalent >> mechanism, we recommend that RED be used. > > More exactly, AQM-REC replaces that (whether or not 2309 is > obsoleted). > >> 16 years following the publication of RFC 2309, it turns out that we >> have issues, but the issues are not the management of queue lengths, >> reduction of packet dropping, and avoidance of lock-out phenomena >> within the Internet. > > I'm not sure I agree there -- but the problems certainly _have_ > changed and we ought to describe at least some of the changes. > If you do not agree, could you propose new text? >> RED, by the way, never did reduce packet loss; it drops the same >> number of packets, but attempts to desynchronize them and achieve >> a certain goal using them. > > A perfect example of why we want to avoid AQM-REC being 2309bis. > A 2309bis would have to discuss this! > >> What we *are* trying to do is reduce queuing delay and by extension >> that component of end to end latency. > > I completely agree. > >> And it turns out that there are now better algorithms than RED. > > I also agree there -- I'm just not convinced we're ready which > to recommend. > To understand this comment, I think it is useful to know which recommendation(s) you have questions on? >> I would go one step further here, and whether this comment belongs in >> the draft or not is not important to me. There are two reasons one >> might standardize something. The most common one, and the one that >> motivates most IETF work, is interoperability of separate >> implementations that have to communicate. OSPF and IS-IS, for example, >> need to be specified down to the gnat's eyelash, including the >> "alternate Tuesday rules" that make different implementations make >> the same choice when more than one choice could reasonably and >> validly be made, to guarantee interoperability. > > Yes. > >> That consideration doesn't apply here; TCP will interpret signals >> from the network including ECN and packet loss even if the network >> doesn't realize that they are signals. The only requirement that >> could be described using the term "interoperability" is that the >> TCP/SCTP/whatever receiving the signals should as a result do the >> right thing. > > There are bunches of things within TCP where interoperation is > a matter of hoping for the best. :^( But standardizing several of the > possible choices still helps. > >> The other is so that everyone agrees on what an algorithm does, why >> it does it, and where it should be implemented. > > (Fred is an optimist! ;^) > >> BCP 38, for example, can be implemented in several ways, but because >> it is standardized as a recommendation, we know what we are trying >> to achieve when we implement it. > > Yes, even this helps. > >> What we are obsoleting, at minimum, is the recommendation that RED >> be the default algorithm. What we instead recommend is that each >> implementation implement some form of AQM to achieve certain purposes. > > IMHO that's already done, even if we neither obsolete no update 2309. > >> That statement alone could be an update to 2309 if 2309 made its >> recommendation regarding RED in one place. However, it is throughout >> the document. Hence, a change to 2309's statement regarding RED is >> a pervasive change affecting every section of it. > > It doesn't matter how pervasive the change -- it only matters that > the intent of the update is stated clearly enough. > >> The other thing I think John is trying to preserve - and John, I'm >> looking for your correction here - is 2309's report on research. > > I do believe that that report deserves to be preserved. I see no > reason to declare it obsolete. But my concern is that we avoid the > rathole of trying to update it while obsoleting 2309 itself. > Well that I thought was the intention. >> There has been ongoing research since 2309 was written, but a large >> portion of the relevant research predates and is reported in 2309. > > Agreed. > >> So we have been asked for an updated bibliography in this document, > > I'm _really_ tempted to "Just say No!" here. Such an updated > bibliography would indeed be useful, but its utility doesn't depend > on doing it here; and it feels like part of that rathole I want to > avoid. > >> and the updates haven't been as large as one might expect from an >> active research field. > > Are you surprised? > >> I think John would like to continue to point to 2309's description >> of the motivating and underlying research. > > Yes. > >> On that, I go two ways. First, as a historical review of the research >> the original recommendation was based on, 2309 is unsurpassed. >> Second, I think we do need to motivate the updated recommendations >> we make, which include for example the implementation of ECN. For >> that reason, we need to point to at least some research. > > Indeed! But it isn't the same research "updated bibliography" implies. > >> We have been asked, by the proponents of fq_codel, to also mention >> scheduling. 2309 left that out and said why it left that out. > > This is an area for "Send text!" > >> draft-baker-aqm-sfq-implementation is my further reflections on the >> interaction between scheduling, which has to do with the distribution >> of service across competing sessions, and AQM, which has to do with >> latency; they two don't necessarily get along as well with each other >> as one might expect. > > (My expectations were pretty low to start with! ;^) > >> In this document, we have tried to say that we don't have a problem >> with scheduling implementations, but we think AQM might be applied >> differently to different traffic classes in the same queuing system. > > Talking "scheduling" _will_ confuse that CTO... > >> draft-geib-tsvwg-diffserv-intercon, for example, contemplates four >> traffic classes, one of which is engineered to RFCs 3246/3247, >> one of which allows for a shallow queue without AQM for UDP-based >> applications, one of which allows for a deeper queue with AQM for >> "preferred" elastic traffic, and one of which is simply the default >> class, which one might expect AQM in but would bear the brunt of >> traffic loss should it occur. > > I don't think we're prepared to say very much about that... > >> To my mind, we're going quite a bit further than "just remove RED"; >> we are doing things 2309 said it didn't want to do, and adding >> capabilities that 2309 didn't consider. > > And I agree we should be doing that. > >> In any event, RFC 2309 remains in the historical record, which is to >> say the RFC series. It's a great document. But when we send someone >> to figure out what to implement in an AQM implementation, I don't >> think we are going to send them there. > > It would be strange to send anyone to a 16-year-old Individual > Informational RFC instead of an IETF BCP. > >> This document, plus the set of algorithms that we wind up recommending, >> are a complete replacement. > > I don't think AQM-REQ version -05 quite makes it there. And I want > to stop trying. > What about version -06? >> So I don't see it as an update. I see it as making 2309 "historical" >> or "obsoleted by" this document. > > Those are different categories. "Historical" is typically handled by > an IESG management item nowadays. "Obsoleted-by" implies that everything > of current importance is covered in the new document. Personally, I > wouldn't try for that. > > But once AQM-REC is published as a BCP, I certainly wouldn' oppose > an IESG management item to move 2309 to "historic". > >> ---------------------------------------------------------------------------- >> >> Which brings me back to John's proposed text. I'm frankly curious what >> the working group's thought on that is. If the working group wants to >> replace the existing sections 1-3 with that or an updated version of >> that, so be it. I'm willing to see John added as a co-author or >> co-editor and the text dropped in. If the working group prefers the >> existing text, I'm OK with that. If there are glaring holes, they need >> to be filled in. > > (For many years I resisted authoring an RFC; but I won't resist now.) > > "Glaring", I'm afraid, is in the eye of the beholder. I don't mean > to bring up holes in AQM-REC as a 2309bis; but others keep mentioning > them, and they sure look like holes to me. :^( > >> What I'm not OK with is a continuation of the current dinking with >> the document. I don't think we have dramatically improved the document >> since last November, > > I'm mostly with Fred here: I _want_ to stop dinking with it! > >> although we have done a lot of work on it to respond to working group >> comments. It feels to me like we, as a working group, have lost our >> way. From this point on, *I* think we need to ask ourselves whether >> any given change we make materially improves the document or merely >> dinks with the text. And we should limit changes to material >> improvements. > > I mostly agree. That's why I'm proposing a material change in approach, > to greatly reduce the area for dinking. > > -- > John Leslie > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --- Gorry From nobody Thu Jul 3 01:00:43 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E51B1A0115 for ; Thu, 3 Jul 2014 01:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMkfJyAfiBms for ; Thu, 3 Jul 2014 00:59:55 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4ABB1A008D for ; Thu, 3 Jul 2014 00:59:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F3653A1; Thu, 3 Jul 2014 09:59:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404374393; bh=lEoTN0S3iq1zSuxNnYDRPXZtKED10I2UxyP3AbU/sCE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IlNGt90GbIs2ph3nUpCSrTVx8KCgwef//xbolrp50vJUQFxdYwuVnNHxc/POe+irj otdnlQFO2iGBBkiFsMwwaeqTUZ1QH07XiHlVYnyqytLBAqR4ScEETn7XQWpuV8UBaR 4r6HUKf5tatwhBmWcFIcRRBWtLfpFfvnG+MbCE0E= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EF4F29F; Thu, 3 Jul 2014 09:59:53 +0200 (CEST) Date: Thu, 3 Jul 2014 09:59:53 +0200 (CEST) From: Mikael Abrahamsson To: John Leslie In-Reply-To: <20140702220313.GG85889@verdi> Message-ID: References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/NixKpZqKbuvzoGj51ikCYQ9sK78 Cc: "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 08:00:01 -0000 On Wed, 2 Jul 2014, John Leslie wrote: > I am saying that obsoleting RED seems premature. The first thing that came to my mind, is that recommending RED is something I would like to stop doing, instead I would like to recommend something else. What this means in terms of status of 2309, I have no idea. For instance 7141 updates 2309, if we obsoleted 2309, what would that mean to 7141? > Yes, but actually my point is that folks are shipping varieties of > RED; and we're unlikely to change that by any classification of 2309. My thinking here was that people perhaps could stop implementing RED when they do new products, so in 2020 an implementor feels no need to implement RED-functionality, but instead only implements whatever we come up with here. By doing a BCP, I think we would achieve that? > But once AQM-REC is published as a BCP, I certainly wouldn' oppose > an IESG management item to move 2309 to "historic". Sounds reasonable. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 3 01:15:48 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2461A03C5 for ; Thu, 3 Jul 2014 01:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTSDRz1wrvVn for ; Thu, 3 Jul 2014 01:15:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF521A03C3 for ; Thu, 3 Jul 2014 01:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2402; q=dns/txt; s=iport; t=1404375343; x=1405584943; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m/y6u/4Po5wI8V+K9MB98zISV1G5JFfM6Sjdu4caLcQ=; b=mwnM83ETop6rWsxF3sOxu4YYeTKxOnyd76yxRmpU9gvRIut+D7nwFz95 3CFi7LtbcwFf5iIyRUUj8YBceLiAp77VpE6yNJB8+iNdHeVt3go57eqmx bNeETJaFQ3q/SK9/tvy4HV8JD2PFbVV2fM8swTnd+MS28cbTH+aKwlMxh g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAJoQtVOtJA2F/2dsb2JhbABagw2BLMYdAYEJFnWEAwEBAQMBZxIFCwIBCA4fGTIlAgQOBQ6ILAjHeReLfYMlBwqDI4EWAQSSHIFDhw6UCoNDgjA X-IronPort-AV: E=Sophos;i="5.01,593,1400025600"; d="asc'?scan'208";a="57992899" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 03 Jul 2014 08:15:42 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s638Fgbk016370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 08:15:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 03:15:41 -0500 From: "Fred Baker (fred)" To: Mikael Abrahamsson Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPlpb6WC+SECkBS0WFZxFT4VTpMg== Date: Thu, 3 Jul 2014 08:15:41 +0000 Message-ID: <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.202] Content-Type: multipart/signed; boundary="Apple-Mail=_4193B7D7-FC7F-48AA-870B-A1D941E66DF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/8Aetol4eT-8pngD4vw68MLdmJv4 Cc: John Leslie , "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 08:15:45 -0000 --Apple-Mail=_4193B7D7-FC7F-48AA-870B-A1D941E66DF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 3, 2014, at 12:59 AM, Mikael Abrahamsson = wrote: > For instance 7141 updates 2309, if we obsoleted 2309, what would that = mean to 7141? Well, for one thing, it affects one of -06=92s references. Oops > [Byte-pkt] > and Internet Engineering Task Force, Work in Progress, > "Byte and Packet Congestion Notification (draft-ietf- > tsvwg-byte-pkt-congest)", July 2013. should point to 7141. It=92s a normative reference. We also carried the = recommendation into the draft: > 4.4. AQM algorithms SHOULD respond to measured congestion, not > application profiles. >=20 > ... >=20 > An AQM algorithm should not deliberately try to prejudice the size = of > packet that performs best (i.e. Preferentially drop/mark based = only > on packet size). Procedures for selecting packets to mark/drop > SHOULD observe the actual or projected time that a packet is in a > queue (bytes at a rate being an analog to time). When an AQM > algorithm decides whether to drop (or mark) a packet, it is > RECOMMENDED that the size of the particular packet should not be > taken into account [Byte-pkt]. That was a pretty early change - I think in the initial set of = recommendations I proposed. We might, however, need to rethink the wording there. What we=92re = trying to say, following 7141, is that one shouldn=92t try to target = data packets or some such thing. A packet is a packet; if the time comes = to hit one, hit the one you=92re looking at. But now that I read it, I = could imagine someone thinking that means we can=92t measure bit rates, = only packet rates. Mumble. --Apple-Mail=_4193B7D7-FC7F-48AA-870B-A1D941E66DF6 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 iD8DBQFTtREsbjEdbHIsm0MRAqabAJsFtrnRNB9HQZ/LMRiGJffVCLWz5gCg5omG 4fXMwYiX9AiJqN4zTSMJHsQ= =8MGo -----END PGP SIGNATURE----- --Apple-Mail=_4193B7D7-FC7F-48AA-870B-A1D941E66DF6-- From nobody Thu Jul 3 10:11:39 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9171B27CF for ; Thu, 3 Jul 2014 10:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeGbMjZPoBft for ; Thu, 3 Jul 2014 10:11:29 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C391E1B299D for ; Thu, 3 Jul 2014 10:11:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 43482C94BE; Thu, 3 Jul 2014 13:11:27 -0400 (EDT) Date: Thu, 3 Jul 2014 13:11:27 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20140703171127.GI85889@verdi> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/DTBepBeHeGQ876yX-8mwptySNRQ Cc: "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 17:11:38 -0000 Mikael Abrahamsson wrote: > > The first thing that came to my mind, is that recommending RED is > something I would like to stop doing, instead I would like to recommend > something else. What this means in terms of status of 2309, I have no > idea. There are several different ways to accomplish this, but basically, _any_ BCP we publish will trump that recommendation of 2309. I merely am recommending that we state our intent clearly. > For instance 7141 updates 2309, if we obsoleted 2309, what would that mean > to 7141? Although I'm pretty familiar with 7141, I wanted to re-read it before responding. It's not an easy read, at 41 pages, largely in academic-paper style. (In fact, this reading did nothing to change my answer, but I'm cautious about such things.) 7141 is tolerably clear about what portion of 2309 it "updates" and it lists 2309 in its Normative References. As phrased, Mikael's question asks what would be different if AQM-REC _obsoletes_ rather than _updates_ 2309 -- with respect to interpretation of 7141 itself. The answer to that question is: most likely no difference at all. A Normative Reference, by definition, is something which must be read to understand the RFC referencing it. This need-to-read survives any future classification of the referenced RFC to obsolete or historic. There's a separate question (not asked) of what it would mean if AQM both obsoleted 2309 and listed it as a Normative reference. This is not fully-settled: I believe the RFC Editor tries to avoid such cases. > My thinking here was that people perhaps could stop implementing RED when > they do new products, so in 2020 an implementor feels no need to implement > RED-functionality, but instead only implements whatever we come up with > here. By doing a BCP, I think we would achieve that? Actually, IMHO, we'd achieve that even if we never mentioned 2309 at all. But it is clearly easier for future implementors if we state that intent clearly in AQM-REC, regardless of metadata about "update", "obsolete", or "historic", which are after all merely aids to readers: not part of the RFCs themselves. -- John Leslie From nobody Thu Jul 3 10:22:54 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22A51B2B3B for ; Thu, 3 Jul 2014 10:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEq-EJFXmWTY for ; Thu, 3 Jul 2014 10:22:48 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2241A0515 for ; Thu, 3 Jul 2014 10:22:48 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E4E65C94C3; Thu, 3 Jul 2014 13:22:45 -0400 (EDT) Date: Thu, 3 Jul 2014 13:22:45 -0400 From: John Leslie To: "aqm@ietf.org" Message-ID: <20140703172245.GJ85889@verdi> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/NZ4Na-vwHAANeGpDGr6xIVw5AOI Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 17:22:51 -0000 Fred Baker (fred) wrote: >=20 > ... We also carried the recommendation into the draft: >=20 >> 4.4. AQM algorithms SHOULD respond to measured congestion, not >> application profiles. >>=20 >> ... >> An AQM algorithm should not deliberately try to prejudice the size of >> packet that performs best (i.e. Preferentially drop/mark based only >> on packet size). Procedures for selecting packets to mark/drop >> SHOULD observe the actual or projected time that a packet is in a >> queue (bytes at a rate being an analog to time). When an AQM >> algorithm decides whether to drop (or mark) a packet, it is >> RECOMMENDED that the size of the particular packet should not be >> taken into account [Byte-pkt]. >=20 > ... > We might, however, need to rethink the wording there. What we're trying > to say, following 7141, is that one shouldn't try to target data packets > or some such thing. A packet is a packet; if the time comes to hit one, > hit the one you're looking at. That's the way I read it... > But now that I read it, I could imagine someone thinking that means we > can't measure bit rates, only packet rates. Mumble. I can't see that interpretation as reasonable, given the phrase ] (bytes at a rate being an analog to time). It would be possible for someone to argue that restating a recommendation from another document weakens both statements; but I disagree: We should clearly state what we mean in this document, and I believe this wording does so. -- John Leslie From nobody Sun Jul 6 11:55:49 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9350C1A0A83 for ; Sun, 6 Jul 2014 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL26HC78LohI for ; Sun, 6 Jul 2014 11:55:45 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321A01A0546 for ; Sun, 6 Jul 2014 11:55:45 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id va2so3607334obc.5 for ; Sun, 06 Jul 2014 11:55:44 -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=XJ8aVMCvtL/RJ1XyCjYEDdb1YuGmAkdlbhkw93nUYP8=; b=SgznwYpVk3dWxqBObBaFWYORNnEMhH5S4jnRJRwt7n4RE3MhifDHma8LGwyYaiwus0 18xBEk4Zc7Vxx0XLNQDB/9//pZ4ujzqj2PevM1a2IN2EePki8NJ51SvEVm+xloBARDPw Wq8PWAZVNJjHJIDar6CYcOQBAXaq3ozadn7JTFB8AKzkV+2KBqalQp15e8sqiDQl4aKe M5eNX0+yRgscS/JrAhfn6PvwrrqIgLK48iyDlZHNGCWArrhaCLbgEQltPFF5baz0oyZ2 uVMGEsZI3e9DT/xRxVrl+i8EOcHFYAlG5BazW1MwB0hquE40NnXduKUFmKr1JJETqguq 146A== MIME-Version: 1.0 X-Received: by 10.182.95.68 with SMTP id di4mr2941633obb.87.1404672944684; Sun, 06 Jul 2014 11:55:44 -0700 (PDT) Received: by 10.202.129.70 with HTTP; Sun, 6 Jul 2014 11:55:44 -0700 (PDT) Received: by 10.202.129.70 with HTTP; Sun, 6 Jul 2014 11:55:44 -0700 (PDT) In-Reply-To: <8FC7F9FA-958B-4086-8C09-273B68FA426F@simula.no> References: <20140704115053.31382.46495.idtracker@ietfa.amsl.com> <8FC7F9FA-958B-4086-8C09-273B68FA426F@simula.no> Date: Sun, 6 Jul 2014 11:55:44 -0700 Message-ID: From: Dave Taht To: David Ros Content-Type: multipart/alternative; boundary=089e0153821ce4c43904fd8ae7f0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/cKdO6JcNBIEnF9qPA-DcRG3dw-Q Cc: iccrg@irtf.org, Mirja Kuehlewind , aqm@ietf.org Subject: Re: [aqm] [iccrg] Fwd: New Version Notification for draft-irtf-iccrg-tcpeval-01.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 06 Jul 2014 18:55:47 -0000 --089e0153821ce4c43904fd8ae7f0 Content-Type: text/plain; charset=UTF-8 I like what I see here. I will have a few suggestions for the text after the (USA) holiday... On Jul 4, 2014 5:11 AM, "David Ros" wrote: > Dear all, > > After a long hiatus, we have finally posted an update to the TCP > evaluation suite. Comments are welcome. > > Besides mostly editorial fixes, the main changes wrt version -00 that > David Hayes presented in Berlin (*) concern parameter values for several > scenarios (some have been fixed, some have been added). > > (*) We just realised version -00 never got posted to the IETF datatracker, > so there was only a "privately-hosted" version online; we've just fixed > this omission. Our apologies. > > Thanks, > > David (as individual) > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-irtf-iccrg-tcpeval-01.txt > > Date: 4 Jul 2014 13:50:53 GMT+2 > > To: Lachlan L.H. Andrew , "Lachlan L.H. > Andrew" , David Hayes , > Sally Floyd , David Ros , "David Ros" < > dros@simula.no>, "Sally Floyd" , "David Hayes" < > davihay@ifi.uio.no> > > > > > > A new version of I-D, draft-irtf-iccrg-tcpeval-01.txt > > has been successfully submitted by David Ros and posted to the > > IETF repository. > > > > Name: draft-irtf-iccrg-tcpeval > > Revision: 01 > > Title: Common TCP Evaluation Suite > > Document date: 2014-07-04 > > Group: iccrg > > Pages: 34 > > URL: > http://www.ietf.org/internet-drafts/draft-irtf-iccrg-tcpeval-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-irtf-iccrg-tcpeval/ > > Htmlized: http://tools.ietf.org/html/draft-irtf-iccrg-tcpeval-01 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-irtf-iccrg-tcpeval-01 > > > > Abstract: > > This document presents an evaluation test suite for the initial > > assessment of proposed TCP modifications. The goal of the test suite > > is to allow researchers to quickly and easily evaluate their proposed > > TCP extensions in simulators and testbeds using a common set of well- > > defined, standard test cases, in order to compare and contrast > > proposals against standard TCP as well as other proposed > > modifications. This test suite is not intended to result in an > > exhaustive evaluation of a proposed TCP modification or new > > congestion control mechanism. Instead, the focus is on quickly and > > easily generating an initial evaluation report that allows the > > networking community to understand and discuss the behavioral aspects > > of a new proposal, in order to guide further experimentation that > > will be needed to fully investigate the specific aspects of such > > proposal. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg > --089e0153821ce4c43904fd8ae7f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I like what I see here. I will have a few suggestions for th= e text after the (USA) holiday...

On Jul 4, 2014 5:11 AM, "David Ros" &l= t;dros@simula.no> wrote:
Dear all,

After a long hiatus, we have finally posted an update to the TCP evaluation= suite. Comments are welcome.

Besides mostly editorial fixes, the main changes wrt version -00 that David= Hayes presented in Berlin (*) concern parameter values for several scenari= os (some have been fixed, some have been added).

(*) We just realised version -00 never got posted to the IETF datatracker, = so there was only a "privately-hosted" version online; we've = just fixed this omission. Our apologies.

Thanks,

David (as individual)


Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-irtf-iccrg-tcpeval-01.txt<= br> > Date: 4 Jul 2014 13:50:53 GMT+2
> To: Lachlan L.H. Andrew <lachlan.andrew@monash.edu>, "Lachlan L.H. Andrew" <<= a href=3D"mailto:lachlan.andrew@monash.edu">lachlan.andrew@monash.edu&g= t;, David Hayes <davihay@ifi.uio.n= o>, Sally Floyd <floyd@acm.org>, David Ros <dros@simula.no&= gt;, "David Ros" <dros@simul= a.no>, "Sally Floyd" <= floyd@acm.org>, "David Hayes" <davihay@ifi.uio.no>
>
>
> A new version of I-D, draft-irtf-iccrg-tcpeval-01.txt
> has been successfully submitted by David Ros and posted to the
> IETF repository.
>
> Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-irtf-iccrg-tcpeval
> Revision: =C2=A0 =C2=A0 01
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Common T= CP Evaluation Suite
> Document date: =C2=A0 =C2=A0 =C2=A0 =C2=A02014-07-04
> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iccrg > Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A034
> URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttp://www.ietf.org/internet-drafts/draft-irtf-iccrg-tcpeval-01.txt
> Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.= ietf.org/doc/draft-irtf-iccrg-tcpeval/
> Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/dr= aft-irtf-iccrg-tcpeval-01
> Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.= ietf.org/rfcdiff?url2=3Ddraft-irtf-iccrg-tcpeval-01
>
> Abstract:
> =C2=A0 This document presents an evaluation test suite for the initial=
> =C2=A0 assessment of proposed TCP modifications. =C2=A0The goal of the= test suite
> =C2=A0 is to allow researchers to quickly and easily evaluate their pr= oposed
> =C2=A0 TCP extensions in simulators and testbeds using a common set of= well-
> =C2=A0 defined, standard test cases, in order to compare and contrast<= br> > =C2=A0 proposals against standard TCP as well as other proposed
> =C2=A0 modifications. =C2=A0This test suite is not intended to result = in an
> =C2=A0 exhaustive evaluation of a proposed TCP modification or new
> =C2=A0 congestion control mechanism. =C2=A0Instead, the focus is on qu= ickly and
> =C2=A0 easily generating an initial evaluation report that allows the<= br> > =C2=A0 networking community to understand and discuss the behavioral a= spects
> =C2=A0 of a new proposal, in order to guide further experimentation th= at
> =C2=A0 will be needed to fully investigate the specific aspects of suc= h
> =C2=A0 proposal.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

_______________________________________________
iccrg mailing list
iccrg@irtf.org
h= ttps://www.irtf.org/mailman/listinfo/iccrg
--089e0153821ce4c43904fd8ae7f0-- From nobody Mon Jul 7 00:03:57 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F8B1A0B01 for ; Mon, 7 Jul 2014 00:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBsxGy0mV_f9 for ; Mon, 7 Jul 2014 00:03:54 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88CD1A01DD for ; Mon, 7 Jul 2014 00:03:54 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6773qsN021154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Jul 2014 02:03:53 -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 s6773mFb001882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Jul 2014 09:03:51 +0200 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.172]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 7 Jul 2014 09:03:49 +0200 From: "LAUTENSCHLAEGER, Wolfram (Wolfram)" To: "aqm@ietf.org" Thread-Topic: New Version Notification for draft-lauten-aqm-gsp-01.txt Thread-Index: AQHPl4EtM+HunvV6LUa476YvkMhyLZuUKNzQ Date: Mon, 7 Jul 2014 07:03:49 +0000 Message-ID: <0A452E1DADEF254C9A7AC1969B878128094579@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <20140704121139.13437.94859.idtracker@ietfa.amsl.com> In-Reply-To: <20140704121139.13437.94859.idtracker@ietfa.amsl.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.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/Rbq38OqVYHCSCkts9hrJTVdJ_kc Subject: [aqm] WG: New Version Notification for draft-lauten-aqm-gsp-01.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 07:03:56 -0000 RGVhciBhbGwsDQoNCkkgcG9zdGVkIGFuIHVwZGF0ZWQgZHJhZnQgb24gR2xvYmFsIFN5bmNocm9u aXphdGlvbiBQcm90ZWN0aW9uIChHU1ApLg0KDQpJbml0aWFsbHkgZm9jdXNlZCBvbiBnbG9iYWwg c3luY2hyb25pemF0aW9uIGFsb25lLCBpdCB0dXJucyBvdXQgdGhhdA0KR1NQIGVzc2VudGlhbGx5 IHBlcmZvcm1zIGF0IHRoZSBzYW1lIGxldmVsIGFzIHRoZSBvdGhlciBBUU1zLg0KDQpNYWpvciBj aGFuZ2VzIGFyZSB3cnQgDQotIGEgbW9yZSBkZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUgcGFy YW1ldGVyIGFkYXB0YXRpb24gYWxnb3JpdGhtDQotIGFuIGFkZGl0aW9uYWwgc2VjdGlvbiBvbiBk ZWxheSBiYXNlZCBvcGVyYXRpb24NCg0KQ29tbWVudHMgYXJlIGhpZ2hseSB3ZWxjb21lLg0KDQpU aGFua3MsDQoNCldvbGZyYW0gTGF1dGVuc2NobGFlZ2VyDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNo ZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5kZXQ6IEZyZWl0YWcsIDQuIEp1bGkgMjAx NCAxNDoxMg0KQW46IExBVVRFTlNDSExBRUdFUiwgV29sZnJhbSAoV29sZnJhbSk7IExBVVRFTlND SExBRUdFUiwgV29sZnJhbSAoV29sZnJhbSkNCkJldHJlZmY6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtbGF1dGVuLWFxbS1nc3AtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWxhdXRlbi1hcW0tZ3NwLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBXb2xmcmFtIExhdXRlbnNjaGxhZWdlciBhbmQgcG9zdGVkIHRvIHRoZQ0K SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbGF1dGVuLWFxbS1nc3ANClJldmlzaW9u OgkwMQ0KVGl0bGU6CQlHbG9iYWwgU3luY2hyb25pemF0aW9uIFByb3RlY3Rpb24gZm9yIFBhY2tl dCBRdWV1ZXMNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDQNCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGF1dGVuLWFxbS1nc3AtMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGF1dGVuLWFxbS1n c3AvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGF1 dGVuLWFxbS1nc3AtMDENCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1sYXV0ZW4tYXFtLWdzcC0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoZSBjb25n ZXN0aW9uIGF2b2lkYW5jZSBwcm9jZXNzZXMgb2Ygc2V2ZXJhbCB0cmFuc21pc3Npb24gY2FwYWNp dHkNCiAgIHNoYXJpbmcgVENQIGZsb3dzIHRlbmQgdG8gYmUgc3luY2hyb25pemVkIGFtb25nIGVh Y2ggb3RoZXIsIHNvIHRoYXQNCiAgIHRoZSByYXRlIHZhcmlhdGlvbnMgb2YgdGhlIGluZGl2aWR1 YWwgZmxvd3MgZG8gbm90IGNvbXBlbnNhdGUuIEluDQogICBjb250cmFyeSwgdGhleSBhY2N1bXVs YXRlIGludG8gbGFyZ2UgdmFyaWF0aW9ucyBvZiB0aGUgd2hvbGUNCiAgIGFnZ3JlZ2F0ZS4gVGhl IGVmZmVjdCBpcyBrbm93biBhcyBnbG9iYWwgc3luY2hyb25pemF0aW9uLiBMYXJnZQ0KICAgcXVl dWluZyBidWZmZXIgZGVtYW5kIGFuZCBsYXJnZSBsYXRlbmN5IGFuZCBqaXR0ZXIgYXJlIHRoZQ0K ICAgY29uc2VxdWVuY2VzLiBHbG9iYWwgU3luY2hyb25pemF0aW9uIFByb3RlY3Rpb24gKEdTUCkg aXMgYW4gZXh0ZW5zaW9uDQogICBvZiByZWd1bGFyIHRhaWwgZHJvcCBwYWNrZXQgcXVldWluZyBz Y2hlbWVzIHRoYXQgcHJldmVudHMgZ2xvYmFsDQogICBzeW5jaHJvbml6YXRpb24uIEZvciBsYXJn ZSB0cmFmZmljIGFnZ3JlZ2F0ZXMgdGhlIGRlLWNvcnJlbGF0aW9uDQogICBiZXR3ZWVuIHRoZSBp bmRpdmlkdWFsIGZsb3cgdmFyaWF0aW9ucyByZWR1Y2VzIGJ1ZmZlciBkZW1hbmQgYW5kDQogICBw YWNrZXQgc29qb3VybiB0aW1lIGJ5IGFuIG9yZGVyIG9mIG1hZ25pdHVkZSBhbmQgbW9yZS4gRXZl biB0aG91Z2gNCiAgIHF1aXRlIHNpbXBsZSwgdGhlIHNvbHV0aW9uIGhhcyBhIHRoZW9yZXRpY2Fs IGJhY2tncm91bmQgYW5kIGlzIG5vdA0KICAgaGV1cmlzdGljLiBJdCBoYXMgYmVlbiB0ZXN0ZWQg d2l0aCBhIExpbnV4IGtlcm5lbCBpbXBsZW1lbnRhdGlvbiBhbmQNCiAgIHNob3dzIGVxdWl2YWxl bnQgcGVyZm9ybWFuY2UgYXMgb3RoZXIgcmVsZXZhbnQgQVFNIHNjaGVtZXMuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sun Jul 13 15:15:53 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C231A0199 for ; Sun, 13 Jul 2014 15:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPmg7Z_OxOc7 for ; Sun, 13 Jul 2014 15:15:48 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83BB1A0197 for ; Sun, 13 Jul 2014 15:15:48 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X6S3f-00057w-4K for aqm@ietf.org; Mon, 14 Jul 2014 00:15:47 +0200 Received: from 089144238029.atnat0047.highway.bob.at ([89.144.238.29] helo=[192.168.0.102]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X6S3d-0000s6-Tn for aqm@ietf.org; Mon, 14 Jul 2014 00:15:47 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 14 Jul 2014 00:15:43 +0200 To: "aqm@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 6 sum msgs/h 4 total rcpts 18319 max rcpts/h 44 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: 34E57A0ED5A79B34E028DC5588F0A150CA2A12E6 X-UiO-SPAM-Test: remote_host: 89.144.238.29 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/DmOB9IVmYwin43TCz6BR4ziNDoM Subject: [aqm] =?utf-8?b?ZHJhZnTigJB3ZWx6bOKAkGVjbuKAkGJlbmVmaXRzLTAx?= X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 13 Jul 2014 22:15:50 -0000 Hi, Could we get 5-10 mins on the agenda to discuss = draft=E2=80=90welzl=E2=80=90ecn=E2=80=90benefits-01? Cheers, Michael From nobody Mon Jul 14 00:05:55 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EBE1A0328 for ; Mon, 14 Jul 2014 00:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIh6mZohfmKs for ; Mon, 14 Jul 2014 00:05:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96301A0326 for ; Mon, 14 Jul 2014 00:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1405321552; x=1406531152; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=24JqKKx1YQp+ZaV4D1yjbNAe6DLV5RxJOAys+I1DHDA=; b=RjsTOULpg7qtexoAYO6ulApZKluPhaotzOdV/widDO3LI1y1NPLknj1G Kjy6agetRo016RreeqUn1H0CwwiOAxQ17qWrR0rke+OBMVSAVUOyYopn4 r+GU+q+R6zRlsiwSwPI1pEZZN9SAaiO7EbNOlJ214O7Uq+rsmR4ebI9c/ U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAI+Aw1OtJV2d/2dsb2JhbABZgw6BLMkHAYEVFnWEBAEBAwFnEgULAgEIRjIlAgQOBQ6ILAjHFheMHIMvB4MtgRYBBJIvgUWHGpQdg0SCMA X-IronPort-AV: E=Sophos;i="5.01,656,1400025600"; d="asc'?scan'208";a="336668439" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 14 Jul 2014 07:05:51 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6E75p25000804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 07:05:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 02:05:51 -0500 From: "Fred Baker (fred)" To: John Leslie Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPnzIL13zFWXB1Z06RTeDcUCAGfQ== Date: Mon, 14 Jul 2014 07:05:50 +0000 Message-ID: References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> <20140703172245.GJ85889@verdi> In-Reply-To: <20140703172245.GJ85889@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_B0955AB5-2F1A-48C4-90EB-E66AD05C105E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/6uq7k_jUhd4JtCk0RG9VVWXri9U Cc: "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 07:05:54 -0000 --Apple-Mail=_B0955AB5-2F1A-48C4-90EB-E66AD05C105E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 3, 2014, at 10:22 AM, John Leslie wrote: > It would be possible for someone to argue that restating a = recommendation > from another document weakens both statements; but I disagree: We = should > clearly state what we mean in this document, and I believe this = wording > does so. The argument for putting it in there started from the fact that we are = obsoleting 2309, as stated in the charter. I would understand a document = that updates 2309 to be in a strange state if 2309 is itself made = historic or obsolete. So we carried the recommendation into this = document so it wouldn=92t get lost. --Apple-Mail=_B0955AB5-2F1A-48C4-90EB-E66AD05C105E 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 iD8DBQFTw4FMbjEdbHIsm0MRAh3UAKC201fk7mHt0R/1C3768AWcDUW+6ACfVqqM 5z6gyIkCjb7RzWCJx+ne+OU= =yfeT -----END PGP SIGNATURE----- --Apple-Mail=_B0955AB5-2F1A-48C4-90EB-E66AD05C105E-- From nobody Mon Jul 14 11:09:06 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98311A0010 for ; Mon, 14 Jul 2014 11:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl7VkWtYWfW4 for ; Mon, 14 Jul 2014 11:09:00 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1B71A000F for ; Mon, 14 Jul 2014 11:09:00 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6EI8vsi018327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jul 2014 13:08:57 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s6EI8u3M022724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 14:08:56 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 14 Jul 2014 14:08:56 -0400 From: "Akhtar, Shahid (Shahid)" To: "Fred Baker (fred)" , John Leslie Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPnzIL13zFWXB1Z06RTeDcUCAGfZuf14Cw Date: Mon, 14 Jul 2014 18:08:55 +0000 Message-ID: References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> <20140703172245.GJ85889@verdi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/B5IMfOzujeCnorGeH0WGPh9LeQ8 Cc: "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 18:09:03 -0000 Hi Fred, All, Let me an additional thought to this issue. Given that (W)RED has been deployed extensively in operators' networks, and= most vendors are still shipping equipment with (W)RED, concern is that obs= oleting 2309 would discourage research on trying to find good configuration= s to make (W)RED work. We had previously given a presentation at the ICCRG on why RED can still pr= ovide value to operators (http://www.ietf.org/proceedings/88/slides/slides-= 88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this study = much better, but I cannot share a link to it until the proceedings are avai= lable. One of the major reasons why operators chose not to deploy (W)RED was a num= ber of studies and research which gave operators conflicting messages on th= e value of (W)RED and appropriate parameters to use. Some of these are ment= ioned in the presentation above.=20 In it we show that the previous studies which showed low value for RED used= web traffic which had very small file sizes (of the order of 5-10 packets)= , which reduces the effectives of all AQMs which work by dropping or ECN ma= rking of flows to indicate congestion. Today's traffic is composed of mostl= y multi-media traffic like HAS or video progressive download which has much= larger file sizes and can be controlled much better with AQMs and in our r= esearch we show that RED can be quite effective with this traffic, with lit= tle tuning needed for typical residential access flows. Prefer John's proposal of updating 2309 rather than obsoleting, but if we c= an have some text in Fred's draft acknowledging the large deployment of (W)= RED and the need to still find good configurations - that may work. I can v= olunteer to provide that text. -Shahid. -----Original Message----- From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Monday, July 14, 2014 2:06 AM To: John Leslie Cc: aqm@ietf.org Subject: Re: [aqm] Obsoleting RFC 2309 On Jul 3, 2014, at 10:22 AM, John Leslie wrote: > It would be possible for someone to argue that restating a=20 > recommendation from another document weakens both statements; but I=20 > disagree: We should clearly state what we mean in this document, and I=20 > believe this wording does so. The argument for putting it in there started from the fact that we are obso= leting 2309, as stated in the charter. I would understand a document that u= pdates 2309 to be in a strange state if 2309 is itself made historic or obs= olete. So we carried the recommendation into this document so it wouldn't g= et lost. From nobody Mon Jul 14 11:23:30 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02C91A0021 for ; Mon, 14 Jul 2014 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkt-nXeDUX5I for ; Mon, 14 Jul 2014 11:23:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9966A1A001B for ; Mon, 14 Jul 2014 11:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4346; q=dns/txt; s=iport; t=1405362205; x=1406571805; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lkPwKD64hcp3uaowQTvVEIKtLTyFSRV9VKGo9UrN/F0=; b=TAzkfmaVOqDOKaT3l9O4waMdbrKRSfOtUwCZF9SqMSLOOefqPNZEwj4/ J+m9UfeTLAmsXpGIP0QK/FTDz/GhKNPti5+8GsK+vYwYcw5muTqhGWBiv +IHyrXSg5pBid7IXvTYjJV0HQa5N+SjSz5ONK314fxmPnErOBQli8rEUS o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALcexFOtJA2F/2dsb2JhbABZgw5SWsFKCodDAYEYFnWEAwEBAQIBAQEBAWQHCwUHBAIBCBEEAQEBJwcnCxQJCAIEDgUJBYgsCA3IIheMHIMvBwaDJ4EWBZIvgUWCf4QblB6DRGyBRA X-IronPort-AV: E=Sophos;i="5.01,659,1400025600"; d="asc'?scan'208";a="339914035" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 14 Jul 2014 18:23:24 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6EINO2L019616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 18:23:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 13:23:24 -0500 From: "Fred Baker (fred)" To: "Akhtar, Shahid (Shahid)" Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPn5CyX3uNzugEEEaP0aMhxfrXKQ== Date: Mon, 14 Jul 2014 18:23:23 +0000 Message-ID: <9FF3152D-822D-4E15-8094-CE4E6C59C8A3@cisco.com> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> <20140703172245.GJ85889@verdi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_0396FC11-A4BB-4365-A15C-D91E27D2140A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/imTrvTcaeFPBJ3PxKXzKI71HcE0 Cc: John Leslie , "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 18:23:27 -0000 --Apple-Mail=_0396FC11-A4BB-4365-A15C-D91E27D2140A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 14, 2014, at 11:08 AM, Akhtar, Shahid (Shahid) = wrote: > Hi Fred, All, >=20 > Let me an additional thought to this issue. >=20 > Given that (W)RED has been deployed extensively in operators' = networks, and most vendors are still shipping equipment with (W)RED, = concern is that obsoleting 2309 would discourage research on trying to = find good configurations to make (W)RED work. Well, note that we=92re not saying to pull RED out of the network; we=92re= saying to not make it the default. Note that even in the networks you = mention, (W)RED is not the default configuration; you have to give it = several parameters, and therefore have to actively turn it on. > We had previously given a presentation at the ICCRG on why RED can = still provide value to operators = (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We = have a paper at Globecom 2014 that explains this study much better, but = I cannot share a link to it until the proceedings are available. >=20 > One of the major reasons why operators chose not to deploy (W)RED was = a number of studies and research which gave operators conflicting = messages on the value of (W)RED and appropriate parameters to use. Some = of these are mentioned in the presentation above.=20 >=20 > In it we show that the previous studies which showed low value for RED = used web traffic which had very small file sizes (of the order of 5-10 = packets), which reduces the effectives of all AQMs which work by = dropping or ECN marking of flows to indicate congestion. Today's traffic = is composed of mostly multi-media traffic like HAS or video progressive = download which has much larger file sizes and can be controlled much = better with AQMs and in our research we show that RED can be quite = effective with this traffic, with little tuning needed for typical = residential access flows. >=20 > Prefer John's proposal of updating 2309 rather than obsoleting, but if = we can have some text in Fred's draft acknowledging the large deployment = of (W)RED and the need to still find good configurations - that may = work. I can volunteer to provide that text. The existing draft doesn=92t mention any specific AQM algorithms. It = seems to me that the more consistent approach would be to write a short = draft documenting WRED, that the WG could pass along as informational or = experimental on the basis of not meeting the requirements of being = self-configuring/tuning, at the same time as it passes along others as = PS or whatever. > -Shahid. >=20 > -----Original Message----- > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker (fred) > Sent: Monday, July 14, 2014 2:06 AM > To: John Leslie > Cc: aqm@ietf.org > Subject: Re: [aqm] Obsoleting RFC 2309 >=20 >=20 > On Jul 3, 2014, at 10:22 AM, John Leslie wrote: >=20 >> It would be possible for someone to argue that restating a=20 >> recommendation from another document weakens both statements; but I=20= >> disagree: We should clearly state what we mean in this document, and = I=20 >> believe this wording does so. >=20 > The argument for putting it in there started from the fact that we are = obsoleting 2309, as stated in the charter. I would understand a document = that updates 2309 to be in a strange state if 2309 is itself made = historic or obsolete. So we carried the recommendation into this = document so it wouldn't get lost. >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --Apple-Mail=_0396FC11-A4BB-4365-A15C-D91E27D2140A 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 iD8DBQFTxCAYbjEdbHIsm0MRAhv2AJ0S+OhE1H3gZaLfFSJTYXdw2uGn+QCfQRMj pKPyI0P3KhZ0M+pJU0L+FTE= =4xDI -----END PGP SIGNATURE----- --Apple-Mail=_0396FC11-A4BB-4365-A15C-D91E27D2140A-- From nobody Mon Jul 14 12:00:15 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF531A0066 for ; Mon, 14 Jul 2014 12:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEib__S1X2F3 for ; Mon, 14 Jul 2014 12:00:03 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D394A1A005E for ; Mon, 14 Jul 2014 12:00:02 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id va2so2735849obc.40 for ; Mon, 14 Jul 2014 12:00:02 -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=5hTwuIakJtcOKVmLe5uf/OzEfhWz5jo22OlyXoZDEBA=; b=DtODNg8sfnW4JkDtkZvnGxnqS5oICK2jqjN5KoP21lv3BgiE95lgHdUi1C8cnt+BNu j7+3XfZ5PlGSeMfsMWqr8bVwwdk0yWT+lqWhgpND5cBpFNVlNLGHbNTxnGLCNh51+0P9 /ZDVJIsRjqv6+Rh0d7rlcOApl4JxJx0pCG/2awhrCx8Ka6KmIYO34pzQsPAstpNF+Q38 WjkRolTwQckAvc1tKpiCKpZJJQCgSFgTGcYRSj+GOJS3EAKpkeuE+Wstp1LdTIA5spSy AlGylYTalN4pfcnxlYXe7H/tn6DTiXiun1Czr/34sYS6Eq+MAxJuqLzk0XstxCPSWFRU 11QA== MIME-Version: 1.0 X-Received: by 10.60.144.169 with SMTP id sn9mr2377496oeb.75.1405364402197; Mon, 14 Jul 2014 12:00:02 -0700 (PDT) Received: by 10.202.93.195 with HTTP; Mon, 14 Jul 2014 12:00:02 -0700 (PDT) In-Reply-To: References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> <20140703172245.GJ85889@verdi> Date: Mon, 14 Jul 2014 12:00:02 -0700 Message-ID: From: Dave Taht To: "Akhtar, Shahid (Shahid)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/FiR2hgSp1r5E7F73YAhu5BEDpLE Cc: "aqm@ietf.org" , "Fred Baker \(fred\)" , John Leslie Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 19:00:09 -0000 On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) wrote: > Hi Fred, All, > > Let me an additional thought to this issue. > > Given that (W)RED has been deployed extensively in operators' networks, a= nd most vendors are still shipping equipment with (W)RED, concern is that o= bsoleting 2309 would discourage research on trying to find good configurati= ons to make (W)RED work. > > We had previously given a presentation at the ICCRG on why RED can still = provide value to operators (http://www.ietf.org/proceedings/88/slides/slide= s-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this stud= y much better, but I cannot share a link to it until the proceedings are av= ailable. My problem with with the above preso and no doubt the resulting study is that it doesn't appear cover the classic, most basic, bufferbloat scenario, which is "1 stream up, 1 stream down, one ping (or some form of voip-like traffic)" and usually on an edge network with asymmetric bandwidth. It's not clear from the study that this is a 8mbit down 1mbit up DSL network (?), nor is it clear if RED is being applied in both directions or only one direction onl? (and the results you get from an asymmetric network are quite interesting, particularly in the face of any cross traffic at all) And I do keep hoping that someone will do a study of how prevalent fq is on dsl devices, I keep accumulating anecdotal data that it's fairly common. > One of the major reasons why operators chose not to deploy (W)RED was a n= umber of studies and research which gave operators conflicting messages on = the value of (W)RED and appropriate parameters to use. Some of these are me= ntioned in the presentation above. > > In it we show that the previous studies which showed low value for RED us= ed web traffic which had very small file sizes (of the order of 5-10 packet= s), which reduces the effectives of all AQMs which work by dropping or ECN = marking of flows to indicate congestion. Today's traffic is composed of mos= tly multi-media traffic like HAS or video progressive download which has mu= ch larger file sizes and can be controlled much better with AQMs and in our= research we show that RED can be quite effective with this traffic, with l= ittle tuning needed for typical residential access flows. I tend to disagree with this, (well, not the trendline to big video flows) but my own studies are focused on retaining high performance gaming, voip, and videoconferencing traffic in the face of things like HAS video traffic. I would be much happier about your study had you also run that sort of traffic while testing your video downloads and aqms... and why is it so hard to get folk to try sfq_codel, etc, while they try everything else? > > Prefer John's proposal of updating 2309 rather than obsoleting, but if we= can have some text in Fred's draft acknowledging the large deployment of (= W)RED and the need to still find good configurations - that may work. I can= volunteer to provide that text. > > -Shahid. > > -----Original Message----- > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker (fred) > Sent: Monday, July 14, 2014 2:06 AM > To: John Leslie > Cc: aqm@ietf.org > Subject: Re: [aqm] Obsoleting RFC 2309 > > > On Jul 3, 2014, at 10:22 AM, John Leslie wrote: > >> It would be possible for someone to argue that restating a >> recommendation from another document weakens both statements; but I >> disagree: We should clearly state what we mean in this document, and I >> believe this wording does so. > > The argument for putting it in there started from the fact that we are ob= soleting 2309, as stated in the charter. I would understand a document that= updates 2309 to be in a strange state if 2309 is itself made historic or o= bsolete. So we carried the recommendation into this document so it wouldn't= get lost. > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Mon Jul 14 12:01:44 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8C81A006F for ; Mon, 14 Jul 2014 12:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEyu1nnhLHmy for ; Mon, 14 Jul 2014 12:01:30 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E979D1A0092 for ; Mon, 14 Jul 2014 12:01:27 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id nu7so4762282obb.9 for ; Mon, 14 Jul 2014 12:01:27 -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=tu72WrehMsDWwEpPGwY62I1lNir4ZXJ1WZD2kZEf2Jo=; b=FytbraVoGjMPEp6wp1RZzsXDHjQ2gk3XmgNMEpwrBABTRtPUHHqabEi2UNIRJpWctG JUk+ThKjUWHK5bgVQDK6hDzLs5mG0SrY54X2aEpknNboJGu/ntnpGbKVRyZ12TyKPUj9 RVKoWwqNfOjM9s3hOE9g+N7XZEWRNQGPjzzK/OL8SBv+7rbloPhoMGOed4Ap5KYKtbVR XQL4ftJDCl68jIHPvducZ2tG4Sowxeh2Z4hTXJmPpK3e8XPzp88HrUGBggc8s3dImHYt 86jaSqaodx8clm4P5gg6p/tq4EaABtykXbOcVMRMnMqT8taXXXbuKDMWoK16qLPJetj0 TcpA== MIME-Version: 1.0 X-Received: by 10.60.144.169 with SMTP id sn9mr2386688oeb.75.1405364487435; Mon, 14 Jul 2014 12:01:27 -0700 (PDT) Received: by 10.202.93.195 with HTTP; Mon, 14 Jul 2014 12:01:27 -0700 (PDT) In-Reply-To: <9FF3152D-822D-4E15-8094-CE4E6C59C8A3@cisco.com> References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> <20140703172245.GJ85889@verdi> <9FF3152D-822D-4E15-8094-CE4E6C59C8A3@cisco.com> Date: Mon, 14 Jul 2014 12:01:27 -0700 Message-ID: From: Dave Taht To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/Tw0kENVfs7_gBMYO_-FbItudw7Q Cc: "Akhtar, Shahid \(Shahid\)" , John Leslie , "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 19:01:38 -0000 On Mon, Jul 14, 2014 at 11:23 AM, Fred Baker (fred) wrote: > > On Jul 14, 2014, at 11:08 AM, Akhtar, Shahid (Shahid) wrote: > >> Hi Fred, All, >> >> Let me an additional thought to this issue. >> >> Given that (W)RED has been deployed extensively in operators' networks, = and most vendors are still shipping equipment with (W)RED, concern is that = obsoleting 2309 would discourage research on trying to find good configurat= ions to make (W)RED work. > > Well, note that we=E2=80=99re not saying to pull RED out of the network; = we=E2=80=99re saying to not make it the default. Note that even in the netw= orks you mention, (W)RED is not the default configuration; you have to give= it several parameters, and therefore have to actively turn it on. > >> We had previously given a presentation at the ICCRG on why RED can still= provide value to operators (http://www.ietf.org/proceedings/88/slides/slid= es-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this stu= dy much better, but I cannot share a link to it until the proceedings are a= vailable. >> >> One of the major reasons why operators chose not to deploy (W)RED was a = number of studies and research which gave operators conflicting messages on= the value of (W)RED and appropriate parameters to use. Some of these are m= entioned in the presentation above. >> >> In it we show that the previous studies which showed low value for RED u= sed web traffic which had very small file sizes (of the order of 5-10 packe= ts), which reduces the effectives of all AQMs which work by dropping or ECN= marking of flows to indicate congestion. Today's traffic is composed of mo= stly multi-media traffic like HAS or video progressive download which has m= uch larger file sizes and can be controlled much better with AQMs and in ou= r research we show that RED can be quite effective with this traffic, with = little tuning needed for typical residential access flows. >> >> Prefer John's proposal of updating 2309 rather than obsoleting, but if w= e can have some text in Fred's draft acknowledging the large deployment of = (W)RED and the need to still find good configurations - that may work. I ca= n volunteer to provide that text. > > The existing draft doesn=E2=80=99t mention any specific AQM algorithms. I= t seems to me that the more consistent approach would be to write a short d= raft documenting WRED, that the WG could pass along as informational or exp= erimental on the basis of not meeting the requirements of being self-config= uring/tuning, at the same time as it passes along others as PS or whatever. I strongly support a good, consistent set of recommendations for how, when, and where to use and not use WRED. > >> -Shahid. >> >> -----Original Message----- >> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker (fred) >> Sent: Monday, July 14, 2014 2:06 AM >> To: John Leslie >> Cc: aqm@ietf.org >> Subject: Re: [aqm] Obsoleting RFC 2309 >> >> >> On Jul 3, 2014, at 10:22 AM, John Leslie wrote: >> >>> It would be possible for someone to argue that restating a >>> recommendation from another document weakens both statements; but I >>> disagree: We should clearly state what we mean in this document, and I >>> believe this wording does so. >> >> The argument for putting it in there started from the fact that we are o= bsoleting 2309, as stated in the charter. I would understand a document tha= t updates 2309 to be in a strange state if 2309 is itself made historic or = obsolete. So we carried the recommendation into this document so it wouldn'= t get lost. >> >> _______________________________________________ >> 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 > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Tue Jul 15 10:46:08 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3BB1A0B13 for ; Tue, 15 Jul 2014 10:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtncqcAsAZlb for ; Tue, 15 Jul 2014 10:46:06 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF76D1A0AAC for ; Tue, 15 Jul 2014 10:46:05 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6FHk1hu007736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jul 2014 12:46:02 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s6FHk0gk013476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 13:46:00 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 15 Jul 2014 13:46:00 -0400 From: "Akhtar, Shahid (Shahid)" To: "Fred Baker (fred)" Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPnzIL13zFWXB1Z06RTeDcUCAGfZuf14CwgABOjoCAATHKkA== Date: Tue, 15 Jul 2014 17:45:59 +0000 Message-ID: References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> <20140703172245.GJ85889@verdi> <9FF3152D-822D-4E15-8094-CE4E6C59C8A3@cisco.com> In-Reply-To: <9FF3152D-822D-4E15-8094-CE4E6C59C8A3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/xMg3dYypuO0fiQPLHJeX3Q53WBo Cc: John Leslie , "aqm@ietf.org" Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2014 17:46:07 -0000 Fred, Per you last text below, are you asking for a short informational draft whe= re we describe our experiments and summarize our configuration guidelines s= pecifically for RED in access downlinks. Is this what you mean by "document= ing WRED"? -Shahid. -----Original Message----- From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Monday, July 14, 2014 1:23 PM To: Akhtar, Shahid (Shahid) Cc: John Leslie; aqm@ietf.org Subject: Re: [aqm] Obsoleting RFC 2309 On Jul 14, 2014, at 11:08 AM, Akhtar, Shahid (Shahid) wrote: > Hi Fred, All, >=20 > Let me an additional thought to this issue. >=20 > Given that (W)RED has been deployed extensively in operators' networks, a= nd most vendors are still shipping equipment with (W)RED, concern is that o= bsoleting 2309 would discourage research on trying to find good configurati= ons to make (W)RED work. Well, note that we're not saying to pull RED out of the network; we're sayi= ng to not make it the default. Note that even in the networks you mention, = (W)RED is not the default configuration; you have to give it several parame= ters, and therefore have to actively turn it on. > We had previously given a presentation at the ICCRG on why RED can still = provide value to operators (http://www.ietf.org/proceedings/88/slides/slide= s-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this stud= y much better, but I cannot share a link to it until the proceedings are av= ailable. >=20 > One of the major reasons why operators chose not to deploy (W)RED was a n= umber of studies and research which gave operators conflicting messages on = the value of (W)RED and appropriate parameters to use. Some of these are me= ntioned in the presentation above.=20 >=20 > In it we show that the previous studies which showed low value for RED us= ed web traffic which had very small file sizes (of the order of 5-10 packet= s), which reduces the effectives of all AQMs which work by dropping or ECN = marking of flows to indicate congestion. Today's traffic is composed of mos= tly multi-media traffic like HAS or video progressive download which has mu= ch larger file sizes and can be controlled much better with AQMs and in our= research we show that RED can be quite effective with this traffic, with l= ittle tuning needed for typical residential access flows. >=20 > Prefer John's proposal of updating 2309 rather than obsoleting, but if we= can have some text in Fred's draft acknowledging the large deployment of (= W)RED and the need to still find good configurations - that may work. I can= volunteer to provide that text. The existing draft doesn't mention any specific AQM algorithms. It seems to= me that the more consistent approach would be to write a short draft docum= enting WRED, that the WG could pass along as informational or experimental = on the basis of not meeting the requirements of being self-configuring/tuni= ng, at the same time as it passes along others as PS or whatever. > -Shahid. >=20 > -----Original Message----- > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker (fred) > Sent: Monday, July 14, 2014 2:06 AM > To: John Leslie > Cc: aqm@ietf.org > Subject: Re: [aqm] Obsoleting RFC 2309 >=20 >=20 > On Jul 3, 2014, at 10:22 AM, John Leslie wrote: >=20 >> It would be possible for someone to argue that restating a=20 >> recommendation from another document weakens both statements; but I >> disagree: We should clearly state what we mean in this document, and=20 >> I believe this wording does so. >=20 > The argument for putting it in there started from the fact that we are ob= soleting 2309, as stated in the charter. I would understand a document that= updates 2309 to be in a strange state if 2309 is itself made historic or o= bsolete. So we carried the recommendation into this document so it wouldn't= get lost. >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Tue Jul 15 10:46:13 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46101A0AAC for ; Tue, 15 Jul 2014 10:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsU6oWNzq11H for ; Tue, 15 Jul 2014 10:46:09 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609D01A0AD5 for ; Tue, 15 Jul 2014 10:46:09 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6FHk5Xa010357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jul 2014 12:46:06 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s6FHk5PU011281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 13:46:05 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 15 Jul 2014 13:46:05 -0400 From: "Akhtar, Shahid (Shahid)" To: Dave Taht Thread-Topic: [aqm] Obsoleting RFC 2309 Thread-Index: AQHPnzIL13zFWXB1Z06RTeDcUCAGfZuf14CwgABYywCAASkzMA== Date: Tue, 15 Jul 2014 17:46:04 +0000 Message-ID: References: <53B327C0.6020407@mti-systems.com> <528D6422-868A-4CEC-AE7A-8B0C3E78EE77@cisco.com> <20140702220313.GG85889@verdi> <3C482E01-B9C7-4E9E-B841-15B042C3462A@cisco.com> <20140703172245.GJ85889@verdi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/rvNpc0cfOxzS9-duSvjM-VbCF6w Cc: "aqm@ietf.org" , "Fred Baker \(fred\)" , John Leslie Subject: Re: [aqm] Obsoleting RFC 2309 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2014 17:46:11 -0000 RGF2ZSwNCg0KVGhlIG1lc3NhZ2Ugb2YgdGhlIHJlc3VsdHMgdGhhdCB3ZSBwcmVzZW50ZWQgaW4g Tm92ZW1iZXIgaXMgdGhhdCBpdCBpcyBwb3NzaWJsZSwgd2l0aCBjdXJyZW50bHkgZGVwbG95ZWQg YWNjZXNzIGhhcmR3YXJlLCB0byBjb25maWd1cmUgUkVEIHNvIHRoYXQgaXQgY29uc2lzdGVudGx5 IGltcHJvdmVzIHRoZSBlbmQgdXNlciBleHBlcmllbmNlIG9mIGNvbW1vbiBuZXR3b3JrIHNlcnZp Y2VzIG92ZXIgVGFpbC1Ecm9wICh3aGljaCBpcyBtb3N0IG9mdGVuIGNvbmZpZ3VyZWQpLCBhbmQg dGhhdCB0aGlzIGltcHJvdmVtZW50IGNhbiBiZSBhY2hpZXZlZCB3aXRoIGEgZml4ZWQgc2V0IG9m IFJFRCBjb25maWd1cmF0aW9uIGd1aWRlbGluZXMuIA0KDQpXZSBkaWQgbm90IHJ1biBleHBlcmlt ZW50cyB3aXRoIHNmcV9jb2RlbCBiZWNhdXNlIGl0IGlzIG5vdCBkZXBsb3llZCBpbiBhY2Nlc3Mg bmV0d29ya3MgdG9kYXkuIFdlIHJhbiBleHBlcmltZW50cyB3aXRoIHBsYWluIENvRGVsIHRvIHVu ZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHdlbGwtY29uZmlndXJlZCBSRUQgYW5k IGEgbW9yZSByZWNlbnQgc2luZ2xlLWJ1Y2tldCBBUU0gaW4gb3VyIHRhcmdldCBzY2VuYXJpb3Ms IGFuZCBhcyByZXBvcnRlZCwgZGlkbid0IG9ic2VydmUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMg aW4gYXBwbGljYXRpb24gUW9FLg0KDQpBZGRpdGlvbmFsIGlubGluZSBjbGFyaWZpY2F0aW9ucyBi ZWxvdy4NCg0KLVNoYWhpZC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERh dmUgVGFodCBbbWFpbHRvOmRhdmUudGFodEBnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCBKdWx5 IDE0LCAyMDE0IDI6MDAgUE0NClRvOiBBa2h0YXIsIFNoYWhpZCAoU2hhaGlkKQ0KQ2M6IEZyZWQg QmFrZXIgKGZyZWQpOyBKb2huIExlc2xpZTsgYXFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Fx bV0gT2Jzb2xldGluZyBSRkMgMjMwOQ0KDQpPbiBNb24sIEp1bCAxNCwgMjAxNCBhdCAxMTowOCBB TSwgQWtodGFyLCBTaGFoaWQgKFNoYWhpZCkgPHNoYWhpZC5ha2h0YXJAYWxjYXRlbC1sdWNlbnQu Y29tPiB3cm90ZToNCj4gSGkgRnJlZCwgQWxsLA0KPg0KPiBMZXQgbWUgYW4gYWRkaXRpb25hbCB0 aG91Z2h0IHRvIHRoaXMgaXNzdWUuDQo+DQo+IEdpdmVuIHRoYXQgKFcpUkVEIGhhcyBiZWVuIGRl cGxveWVkIGV4dGVuc2l2ZWx5IGluIG9wZXJhdG9ycycgbmV0d29ya3MsIGFuZCBtb3N0IHZlbmRv cnMgYXJlIHN0aWxsIHNoaXBwaW5nIGVxdWlwbWVudCB3aXRoIChXKVJFRCwgY29uY2VybiBpcyB0 aGF0IG9ic29sZXRpbmcgMjMwOSB3b3VsZCBkaXNjb3VyYWdlIHJlc2VhcmNoIG9uIHRyeWluZyB0 byBmaW5kIGdvb2QgY29uZmlndXJhdGlvbnMgdG8gbWFrZSAoVylSRUQgd29yay4NCj4NCj4gV2Ug aGFkIHByZXZpb3VzbHkgZ2l2ZW4gYSBwcmVzZW50YXRpb24gYXQgdGhlIElDQ1JHIG9uIHdoeSBS RUQgY2FuIHN0aWxsIHByb3ZpZGUgdmFsdWUgdG8gb3BlcmF0b3JzIChodHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzg4L3NsaWRlcy9zbGlkZXMtODgtaWNjcmctMC5wZGYpLiBXZSBoYXZl IGEgcGFwZXIgYXQgR2xvYmVjb20gMjAxNCB0aGF0IGV4cGxhaW5zIHRoaXMgc3R1ZHkgbXVjaCBi ZXR0ZXIsIGJ1dCBJIGNhbm5vdCBzaGFyZSBhIGxpbmsgdG8gaXQgdW50aWwgdGhlIHByb2NlZWRp bmdzIGFyZSBhdmFpbGFibGUuDQoNCk15IHByb2JsZW0gd2l0aCB0aGUgYWJvdmUgcHJlc28gYW5k IG5vIGRvdWJ0IHRoZSByZXN1bHRpbmcgc3R1ZHkgaXMgdGhhdCBpdCBkb2Vzbid0IGFwcGVhciBj b3ZlciB0aGUgY2xhc3NpYywgbW9zdCBiYXNpYywgYnVmZmVyYmxvYXQgc2NlbmFyaW8sIHdoaWNo IGlzDQoNCiIxIHN0cmVhbSB1cCwgMSBzdHJlYW0gZG93biwgb25lIHBpbmcgKG9yIHNvbWUgZm9y bSBvZiB2b2lwLWxpa2UgdHJhZmZpYykiIGFuZCB1c3VhbGx5IG9uIGFuIGVkZ2UgbmV0d29yayB3 aXRoIGFzeW1tZXRyaWMgYmFuZHdpZHRoLg0KDQpTQTogV2UgdHJpZWQgdG8gY292ZXIgdGhlIHR5 cGljYWwgZXhwZWN0ZWQgdHJhZmZpYyBvdmVyIHRoZSBJbnRlcm5ldC4gTW9zdCBvZiB0aGUgdHJh ZmZpYyBpcyBub3cgSEFTIHRyYWZmaWMgKGFzIHBlciB0aGUgc2FuZHZpbmUgcmVwb3J0KSwgc28g aWYgb25seSBhIHNpbmdsZSBzdHJlYW0gaXMgcHJlc2VudCwgaXQgaXMgbGlrZWx5IHRvIGJlIEhB Uy4gVGhlIGNsb3Nlc3QgYXBwcm94aW1hdGlvbiBvZiBhIGNvbnRpbnVvdXMgVENQIHN0cmVhbSwg YXMgeW91IG1lbnRpb24sIHdvdWxkIGJlIGEgcHJvZ3Jlc3NpdmUgZG93bmxvYWQgd2hpY2ggY2Fu IGxhc3QgbG9uZyBlbm91Z2ggdG8gbG9vayBjb250aW51b3VzLiBUaGVzZSB3ZXJlIG1vZGVsZWQg dG9nZXRoZXIgd2l0aCBvdGhlciB0eXBlcyBvZiB0cmFmZmljLg0KDQpJdCdzIG5vdCBjbGVhciBm cm9tIHRoZSBzdHVkeSB0aGF0IHRoaXMgaXMgYSA4bWJpdCBkb3duIDFtYml0IHVwIERTTCBuZXR3 b3JrICg/KSwgDQoNClNBOiBJbiB0aGUgc3R1ZHkgcHJlc2VudGVkLCBJdCB3YXMgOE0gZG93biBh bmQgMS42TSB1cCAtIHNsaWRlIDkNCg0Kbm9yIGlzIGl0IGNsZWFyIGlmIFJFRCBpcyBiZWluZyBh cHBsaWVkIGluIGJvdGggZGlyZWN0aW9ucyBvciBvbmx5IG9uZSBkaXJlY3Rpb24gb25sPyAgDQoN ClNBOiBBUU1zIChpbmNsdWRpbmcgUkVEKSB3ZXJlIG9ubHkgYXBwbGllZCBpbiBkb3duc3RyZWFt IGRpcmVjdGlvbiAtIHNsaWRlIDkNCg0KKGFuZCB0aGUgcmVzdWx0cyB5b3UgZ2V0IGZyb20gYW4g YXN5bW1ldHJpYyBuZXR3b3JrIGFyZSBxdWl0ZSBpbnRlcmVzdGluZywgcGFydGljdWxhcmx5IGlu IHRoZSBmYWNlIG9mIGFueSBjcm9zcyB0cmFmZmljIGF0IGFsbCkNCg0KU0E6IEkgYW0gbm90IHN1 cmUgd2hhdCB5b3UgbWVhbiBieSBjcm9zcy10cmFmZmljLCB0aGUgRFNMIGxpbmsgb25seSBnb2Vz IHRvIG9uZSByZXNpZGVuY2UgKG9yIGJ1c2luZXNzKS4gVGhlIHR5cGljYWwgdHJhZmZpYyB0byB0 aGF0IHdhcyBtb2RlbGVkLg0KDQpBbmQgSSBkbyBrZWVwIGhvcGluZyB0aGF0IHNvbWVvbmUgd2ls bCBkbyBhIHN0dWR5IG9mIGhvdyBwcmV2YWxlbnQgZnEgaXMgb24gZHNsIGRldmljZXMsIEkga2Vl cCBhY2N1bXVsYXRpbmcgYW5lY2RvdGFsIGRhdGEgdGhhdCBpdCdzIGZhaXJseSBjb21tb24uDQoN Cj4gT25lIG9mIHRoZSBtYWpvciByZWFzb25zIHdoeSBvcGVyYXRvcnMgY2hvc2Ugbm90IHRvIGRl cGxveSAoVylSRUQgd2FzIGEgbnVtYmVyIG9mIHN0dWRpZXMgYW5kIHJlc2VhcmNoIHdoaWNoIGdh dmUgb3BlcmF0b3JzIGNvbmZsaWN0aW5nIG1lc3NhZ2VzIG9uIHRoZSB2YWx1ZSBvZiAoVylSRUQg YW5kIGFwcHJvcHJpYXRlIHBhcmFtZXRlcnMgdG8gdXNlLiBTb21lIG9mIHRoZXNlIGFyZSBtZW50 aW9uZWQgaW4gdGhlIHByZXNlbnRhdGlvbiBhYm92ZS4NCj4NCj4gSW4gaXQgd2Ugc2hvdyB0aGF0 IHRoZSBwcmV2aW91cyBzdHVkaWVzIHdoaWNoIHNob3dlZCBsb3cgdmFsdWUgZm9yIFJFRCB1c2Vk IHdlYiB0cmFmZmljIHdoaWNoIGhhZCB2ZXJ5IHNtYWxsIGZpbGUgc2l6ZXMgKG9mIHRoZSBvcmRl ciBvZiA1LTEwIHBhY2tldHMpLCB3aGljaCByZWR1Y2VzIHRoZSBlZmZlY3RpdmVzIG9mIGFsbCBB UU1zIHdoaWNoIHdvcmsgYnkgZHJvcHBpbmcgb3IgRUNOIG1hcmtpbmcgb2YgZmxvd3MgdG8gaW5k aWNhdGUgY29uZ2VzdGlvbi4gVG9kYXkncyB0cmFmZmljIGlzIGNvbXBvc2VkIG9mIG1vc3RseSBt dWx0aS1tZWRpYSB0cmFmZmljIGxpa2UgSEFTIG9yIHZpZGVvIHByb2dyZXNzaXZlIGRvd25sb2Fk IHdoaWNoIGhhcyBtdWNoIGxhcmdlciBmaWxlIHNpemVzIGFuZCBjYW4gYmUgY29udHJvbGxlZCBt dWNoIGJldHRlciB3aXRoIEFRTXMgYW5kIGluIG91ciByZXNlYXJjaCB3ZSBzaG93IHRoYXQgUkVE IGNhbiBiZSBxdWl0ZSBlZmZlY3RpdmUgd2l0aCB0aGlzIHRyYWZmaWMsIHdpdGggbGl0dGxlIHR1 bmluZyBuZWVkZWQgZm9yIHR5cGljYWwgcmVzaWRlbnRpYWwgYWNjZXNzIGZsb3dzLg0KDQpJIHRl bmQgdG8gZGlzYWdyZWUgd2l0aCB0aGlzLCAod2VsbCwgbm90IHRoZSB0cmVuZGxpbmUgdG8gYmln IHZpZGVvDQpmbG93cykgYnV0IG15IG93biBzdHVkaWVzIGFyZSBmb2N1c2VkIG9uIHJldGFpbmlu ZyBoaWdoIHBlcmZvcm1hbmNlIGdhbWluZywgdm9pcCwgYW5kIHZpZGVvY29uZmVyZW5jaW5nIHRy YWZmaWMgaW4gdGhlIGZhY2Ugb2YgdGhpbmdzIGxpa2UgSEFTIHZpZGVvIHRyYWZmaWMuIEkgd291 bGQgYmUgbXVjaCBoYXBwaWVyIGFib3V0IHlvdXIgc3R1ZHkgaGFkIHlvdSBhbHNvIHJ1biB0aGF0 IHNvcnQgb2YgdHJhZmZpYyB3aGlsZSB0ZXN0aW5nIHlvdXIgdmlkZW8gZG93bmxvYWRzIGFuZCBh cW1zLi4uIGFuZCB3aHkgaXMgaXQgc28gaGFyZCB0byBnZXQgZm9sayB0byB0cnkgc2ZxX2NvZGVs LCBldGMsIHdoaWxlIHRoZXkgdHJ5IGV2ZXJ5dGhpbmcgZWxzZT8NCg0KU0E6IFdlIGRpZCBub3Qg bW9kZWwgc21hbGxlciBmbG93cyAoaW4gdGVybXMgb2YgdGhyb3VnaHB1dCkuIFNtYWxsIFVEUCBm bG93cywgd2hpY2ggSSBhc3N1bWUgYWxsL21vc3Qgb2YgdGhlIGFib3ZlIHdvdWxkIGZhbGwgaW4s IHdvdWxkIGJlbmVmaXQgc2lnbmlmaWNhbnRseSB3aXRoIFJFRCAtIHNsaWRlIDEzIHNob3dzIG11 Y2ggbG93ZXIgYXZlcmFnZSBxdWV1ZSBsZW5ndGggd2l0aCBSRUQuIE90aGVyIHN0dWRpZXMgaGF2 ZSBzaG93biB0aGF0IHNtYWxsIFVEUCBmbG93cyB3aXRoIGxvdHMgb2YgVENQIHRyYWZmaWMgYmVu ZWZpdCBzaWduaWZpY2FudGx5IHdpdGggUkVEIGFjaGlldmluZyBsb3dlciBwYWNrZXQgbG9zcyAo TS4gTWF5cyBldCBhbCwg4oCcUmVhc29ucyBub3QgdG8gZGVwbG95IFJFROKAnSkuIA0KDQo+DQo+ IFByZWZlciBKb2huJ3MgcHJvcG9zYWwgb2YgdXBkYXRpbmcgMjMwOSByYXRoZXIgdGhhbiBvYnNv bGV0aW5nLCBidXQgaWYgd2UgY2FuIGhhdmUgc29tZSB0ZXh0IGluIEZyZWQncyBkcmFmdCBhY2tu b3dsZWRnaW5nIHRoZSBsYXJnZSBkZXBsb3ltZW50IG9mIChXKVJFRCBhbmQgdGhlIG5lZWQgdG8g c3RpbGwgZmluZCBnb29kIGNvbmZpZ3VyYXRpb25zIC0gdGhhdCBtYXkgd29yay4gSSBjYW4gdm9s dW50ZWVyIHRvIHByb3ZpZGUgdGhhdCB0ZXh0Lg0KPg0KPiAtU2hhaGlkLg0KDQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGFxbSBbbWFpbHRvOmFxbS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRnJlZCBCYWtlciAoZnJlZCkNCj4gU2VudDogTW9uZGF5LCBK dWx5IDE0LCAyMDE0IDI6MDYgQU0NCj4gVG86IEpvaG4gTGVzbGllDQo+IENjOiBhcW1AaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFthcW1dIE9ic29sZXRpbmcgUkZDIDIzMDkNCj4NCj4NCj4gT24g SnVsIDMsIDIwMTQsIGF0IDEwOjIyIEFNLCBKb2huIExlc2xpZSA8am9obkBqbGMubmV0PiB3cm90 ZToNCj4NCj4+IEl0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBzb21lb25lIHRvIGFyZ3VlIHRoYXQg cmVzdGF0aW5nIGEgDQo+PiByZWNvbW1lbmRhdGlvbiBmcm9tIGFub3RoZXIgZG9jdW1lbnQgd2Vh a2VucyBib3RoIHN0YXRlbWVudHM7IGJ1dCBJDQo+PiBkaXNhZ3JlZTogV2Ugc2hvdWxkIGNsZWFy bHkgc3RhdGUgd2hhdCB3ZSBtZWFuIGluIHRoaXMgZG9jdW1lbnQsIGFuZCANCj4+IEkgYmVsaWV2 ZSB0aGlzIHdvcmRpbmcgZG9lcyBzby4NCj4NCj4gVGhlIGFyZ3VtZW50IGZvciBwdXR0aW5nIGl0 IGluIHRoZXJlIHN0YXJ0ZWQgZnJvbSB0aGUgZmFjdCB0aGF0IHdlIGFyZSBvYnNvbGV0aW5nIDIz MDksIGFzIHN0YXRlZCBpbiB0aGUgY2hhcnRlci4gSSB3b3VsZCB1bmRlcnN0YW5kIGEgZG9jdW1l bnQgdGhhdCB1cGRhdGVzIDIzMDkgdG8gYmUgaW4gYSBzdHJhbmdlIHN0YXRlIGlmIDIzMDkgaXMg aXRzZWxmIG1hZGUgaGlzdG9yaWMgb3Igb2Jzb2xldGUuIFNvIHdlIGNhcnJpZWQgdGhlIHJlY29t bWVuZGF0aW9uIGludG8gdGhpcyBkb2N1bWVudCBzbyBpdCB3b3VsZG4ndCBnZXQgbG9zdC4NCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gYXFt IG1haWxpbmcgbGlzdA0KPiBhcW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hcW0NCg0KDQoNCi0tDQpEYXZlIFTDpGh0DQoNCk5TRlc6IGh0dHBzOi8v dzIuZWZmLm9yZy9DZW5zb3JzaGlwL0ludGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8w Mjk2X2luZGVjZW50LmFydGljbGUNCg== From nobody Tue Jul 15 14:00:14 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349801A00A3 for ; Tue, 15 Jul 2014 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vviR1jbeV3HK for ; Tue, 15 Jul 2014 14:00:03 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39941A0A8E for ; Tue, 15 Jul 2014 14:00:02 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id uy5so6153888obc.25 for ; Tue, 15 Jul 2014 14:00:02 -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:cc:content-type :content-transfer-encoding; bh=qIL6bCBIbq18xqsaO6IVGMGFAMGba4UQ+nmIUhJuC8A=; b=l+5NtOm5UM1imuSnBRQEjF6vzofHDtiZnM45BwrmZOhbO0IInuneGDT2QlKpqLs9j/ 3981uI4Cu46qVG6ZOEGmZSDjUr8d/MwgKFAmEpg0mToqM49yed+xxzB/U5h/NxF2cOR5 kbzT1/ohAAZUYCQRTDh09nrSta4j5f1LXyqsp3PPCpJoFqo/lLrkbpUnjQc+eJUxUpk6 3Ews4sMny6iM8Bt2VCLdXtoLxF3IYdCDA+1JBm7fqKxwo7SMGlvSs47aSJ/XrFWgirkc epzC1+9huPQ+06tIrawsQm/jhwzEGntEez0XXq3HYw5cPjUT6RMovTb/y0F8xat482++ ymdQ== MIME-Version: 1.0 X-Received: by 10.60.101.165 with SMTP id fh5mr29014060oeb.39.1405458001927; Tue, 15 Jul 2014 14:00:01 -0700 (PDT) Received: by 10.202.93.195 with HTTP; Tue, 15 Jul 2014 14:00:01 -0700 (PDT) Date: Tue, 15 Jul 2014 14:00:01 -0700 Message-ID: From: Dave Taht To: "Akhtar, Shahid (Shahid)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/J6RABeoIk2fRnh8VFb4txPcSGCU Cc: "aqm@ietf.org" , "Fred Baker \(fred\)" , John Leslie Subject: [aqm] Sane analysis of "typical traffic" X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2014 21:00:12 -0000 changing the title as this is not relevant to the aqm document... ... but to an attitude that is driving me absolutely crazy. On Tue, Jul 15, 2014 at 10:46 AM, Akhtar, Shahid (Shahid) wrote: > Dave, > > The message of the results that we presented in November is that it is po= ssible, with currently deployed access hardware, to configure RED so that i= t consistently improves the end user experience of common network services = over Tail-Drop (which is most often configured), and that this improvement = can be achieved with a fixed set of RED configuration guidelines. > > We did not run experiments with sfq_codel because it is not deployed in a= ccess networks today. We ran experiments with plain CoDel to understand the= difference between a well-configured RED and a more recent single-bucket A= QM in our target scenarios, and as reported, didn't observe significant dif= ferences in application QoE. Your "application" was a bunch of video streams. Not web traffic, not voip, not, gaming, not bittorrent, not a family of four doing a combination of these things, nor a small business that isn't going to use HAS at all. Please don't over generalize your results. "RED proven suitable for family of couch potatoes surfing the internet and watching 4 movies at once over the internet but not 5, at 8mbit/sec" might have been a better title for this paper. In this fictional family, just one kid under the stair, trying to do something useful, interactive and/or fun, can both wreck the couch potatoes' internet experience, and have his own, wrecked also. > > Additional inline clarifications below. > > -Shahid. > > -----Original Message----- > From: Dave Taht [mailto:dave.taht@gmail.com] > Sent: Monday, July 14, 2014 2:00 PM > To: Akhtar, Shahid (Shahid) > Cc: Fred Baker (fred); John Leslie; aqm@ietf.org > Subject: Re: [aqm] Obsoleting RFC 2309 > > On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) wrote: >> Hi Fred, All, >> >> Let me an additional thought to this issue. >> >> Given that (W)RED has been deployed extensively in operators' networks, = and most vendors are still shipping equipment with (W)RED, concern is that = obsoleting 2309 would discourage research on trying to find good configurat= ions to make (W)RED work. >> >> We had previously given a presentation at the ICCRG on why RED can still= provide value to operators (http://www.ietf.org/proceedings/88/slides/slid= es-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this stu= dy much better, but I cannot share a link to it until the proceedings are a= vailable. > > My problem with the above preso and no doubt the resulting study is that = it doesn't appear cover the classic, most basic, bufferbloat scenario, whic= h is > > "1 stream up, 1 stream down, one ping (or some form of voip-like traffic)= " and usually on an edge network with asymmetric bandwidth. Two additional analyses of use from the download perspective might be Arris's analysis of the benefits of red and fq over cable head ends: http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf and the cable labs work which focused more on the effects of traffic going upstream which has been discussed fairly extensively here. > SA: We tried to cover the typical expected traffic over the Internet. I don't know where you get your data, but my measured edge traffic looks nothing like yours. Sure bandwidth wise, theres the netflix spike 3 hours out of the day but the rest sure isn't HAS. >Most of the traffic is now HAS traffic (as per the sandvine report), so if= only a single stream is present, it is likely to be HAS. >The closest approximation of a continuous TCP stream, as you mention, woul= d be a progressive download which can last long enough to look continuous. = These were modeled together with other types of traffic. You keep saying, download, download, download. I am saying merely please ALWAYS try an upload at the same time you are testing downloads - be it videoconferencing (which can easily use up that 1.6mbit link), a youtube upload, a rsync backup, a scp, anything... It needent be the crux of your paper! But adding several tests of that sort does need to inform your total modeling experience. If you do that much, you we get a feel for how present day systems interact with things like ack clocking which will do very interesting things to your "downstream to the couch potato" performance metrics. > > It's not clear from the study that this is a 8mbit down 1mbit up DSL netw= ork (?), > > SA: In the study presented, It was 8M down and 1.6M up - slide 9 Thx. > > nor is it clear if RED is being applied in both directions or only one di= rection onl? > > SA: AQMs (including RED) were only applied in downstream direction - slid= e 9 Are you going to follow up with stuff that looks at the upstream direction? > (and the results you get from an asymmetric network are quite interesting= , particularly in the face of any cross traffic at all) > > SA: I am not sure what you mean by cross-traffic, the DSL link only goes = to one residence (or business). The typical traffic to that was modeled. I do need a consistent name for this that matches people's expectations. Does not cross traffic make sense in a DSL context? Competing? I mean someone doing *anything* that involves sending data upstream other than tiny tcp acks. > And I do keep hoping that someone will do a study of how prevalent fq is = on dsl devices, I keep accumulating anecdotal data that it's fairly common. > >> One of the major reasons why operators chose not to deploy (W)RED was a = number of studies and research which gave operators conflicting messages on= the value of (W)RED and appropriate parameters to use. Some of these are m= entioned in the presentation above. >> >> In it we show that the previous studies which showed low value for RED u= sed web traffic which had very small file sizes (of the order of 5-10 packe= ts), which reduces the effectives of all AQMs which work by dropping or ECN= marking of flows to indicate congestion. Today's traffic is composed of mo= stly multi-media traffic like HAS or video progressive download which has m= uch larger file sizes and can be controlled much better with AQMs and in ou= r research we show that RED can be quite effective with this traffic, with = little tuning needed for typical residential access flows. I agree, incidentally, that RED is OK for fat non-interactive video flows over tcp. And I approve of people coming up with ways to tune it properly for all sorts of environments and fully documenting how to do it. > > I tend to disagree with this, (well, not the trendline to big video > flows) but my own studies are focused on retaining high performance gamin= g, voip, and videoconferencing traffic in the face of things like HAS video= traffic. I would be much happier about your study had you also run that so= rt of traffic while testing your video downloads and aqms... and why is it = so hard to get folk to try sfq_codel, etc, while they try everything else? > > SA: We did not model smaller flows (in terms of throughput). Small LATENCY, damn it. >UDP flows, which I assume all/most of the above would fall in, would benef= it significantly with RED - slide 13 shows much lower average queue length = with RED. Average queue length is valueless, according to Kathy and Van - and a few other people, including me. >Other studies have shown that small UDP flows with lots of TCP traffic ben= efit significantly with RED achieving lower packet loss (M. Mays et al, =E2= =80=9CReasons not to deploy RED=E2=80=9D). Hmm... you really, really, really need to spend some time playing with real traffic over real, asymmetric networks that goes in both directions. >> >> Prefer John's proposal of updating 2309 rather than obsoleting, but if w= e can have some text in Fred's draft acknowledging the large deployment of = (W)RED and the need to still find good configurations - that may work. I ca= n volunteer to provide that text. >> >> -Shahid. > >> >> -----Original Message----- >> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker (fred) >> Sent: Monday, July 14, 2014 2:06 AM >> To: John Leslie >> Cc: aqm@ietf.org >> Subject: Re: [aqm] Obsoleting RFC 2309 >> >> >> On Jul 3, 2014, at 10:22 AM, John Leslie wrote: >> >>> It would be possible for someone to argue that restating a >>> recommendation from another document weakens both statements; but I >>> disagree: We should clearly state what we mean in this document, and >>> I believe this wording does so. >> >> The argument for putting it in there started from the fact that we are o= bsoleting 2309, as stated in the charter. I would understand a document tha= t updates 2309 to be in a strange state if 2309 is itself made historic or = obsolete. So we carried the recommendation into this document so it wouldn'= t get lost. >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > > > -- > Dave T=C3=A4ht > > NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_029= 6_indecent.article --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Thu Jul 17 08:51:32 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC5D1A0176 for ; Thu, 17 Jul 2014 08:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoYMbVeYdzge for ; Thu, 17 Jul 2014 08:51:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAA11A0181 for ; Thu, 17 Jul 2014 08:51:27 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6HFpMlf027627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jul 2014 10:51:22 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s6HFpLNe007913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 11:51:21 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 17 Jul 2014 11:51:21 -0400 From: "Akhtar, Shahid (Shahid)" To: Dave Taht Thread-Topic: Sane analysis of "typical traffic" Thread-Index: AQHPoG/ULXO7Rl7nmkK3OLORb2+X5ZukVedA Date: Thu, 17 Jul 2014 15:51:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/t5trwc-gt7fCgcUJS8hCruUcfYo Cc: "aqm@ietf.org" , "Fred Baker \(fred\)" , John Leslie Subject: Re: [aqm] Sane analysis of "typical traffic" X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2014 15:51:31 -0000 RGF2ZSwNCg0KV2ViIHRyYWZmaWMgd2FzIHBhcnQgb2YgdGhlIHN0dWR5IC0geW91IHNob3VsZCBi ZSBhYmxlIHRvIHNlZSBwYWdlIGxvYWQgdGltZXMgb24gc2xpZGUgMTINCg0KTG93ZXIgbGV2ZWxz IG9mIHRyYWZmaWMgd2VyZSBhbHNvIHRlc3RlZCAoc2xpZGVzIDExLDEyKSwgaG93ZXZlciB0aGUg aGlnaGVzdCBpbXBhY3Qgb2YgQVFNIHdhcyBvYnNlcnZlZCBhdCBoaWdoIHRyYWZmaWMgbGV2ZWxz DQoNCldlIGluY2x1ZGVkIHRoZSBsYXJnZXN0IGNvbXBvbmVudHMgb2YgSW50ZXJuZXQgdHJhZmZp YyAoSEFTLCBXZWIgVHJhZmZpYywgVmlkZW8gUHJvZ3Jlc3NpdmUgZG93bmxvYWQpIHdoaWNoIGNv bnN0aXR1dGUgb3ZlciA3NSUgb2YgYWxsIHRyYWZmaWMgKGh0dHBzOi8vd3d3LnNhbmR2aW5lLmNv bS9kb3dubG9hZHMvZ2VuZXJhbC9nbG9iYWwtaW50ZXJuZXQtcGhlbm9tZW5hLzIwMTQvMWgtMjAx NC1nbG9iYWwtaW50ZXJuZXQtcGhlbm9tZW5hLXJlcG9ydC5wZGYpIGF0IHBlYWsgaG91cg0KDQpU aGUgc3R1ZHkgcHJlc2VudGVkIGluIE5vdiB3YXMgb3VyIGluaXRpYWwgd29yayBhbmQgaXMgbm90 IHRoZSBvbmx5IGNvbXBvbmVudCBpbiBkZXZlbG9wbWVudCBvZiBhbnkgY29uZmlndXJhdGlvbiBn dWlkZWxpbmVzDQoNCi1TaGFoaWQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBEYXZlIFRhaHQgW21haWx0bzpkYXZlLnRhaHRAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXks IEp1bHkgMTUsIDIwMTQgNDowMCBQTQ0KVG86IEFraHRhciwgU2hhaGlkIChTaGFoaWQpDQpDYzog RnJlZCBCYWtlciAoZnJlZCk7IEpvaG4gTGVzbGllOyBhcW1AaWV0Zi5vcmcNClN1YmplY3Q6IFNh bmUgYW5hbHlzaXMgb2YgInR5cGljYWwgdHJhZmZpYyINCg0KY2hhbmdpbmcgdGhlIHRpdGxlIGFz IHRoaXMgaXMgbm90IHJlbGV2YW50IHRvIHRoZSBhcW0gZG9jdW1lbnQuLi4NCg0KLi4uIGJ1dCB0 byBhbiBhdHRpdHVkZSB0aGF0IGlzIGRyaXZpbmcgbWUgYWJzb2x1dGVseSBjcmF6eS4NCg0KT24g VHVlLCBKdWwgMTUsIDIwMTQgYXQgMTA6NDYgQU0sIEFraHRhciwgU2hhaGlkIChTaGFoaWQpIDxz aGFoaWQuYWtodGFyQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+IERhdmUsDQo+DQo+IFRo ZSBtZXNzYWdlIG9mIHRoZSByZXN1bHRzIHRoYXQgd2UgcHJlc2VudGVkIGluIE5vdmVtYmVyIGlz IHRoYXQgaXQgaXMgcG9zc2libGUsIHdpdGggY3VycmVudGx5IGRlcGxveWVkIGFjY2VzcyBoYXJk d2FyZSwgdG8gY29uZmlndXJlIFJFRCBzbyB0aGF0IGl0IGNvbnNpc3RlbnRseSBpbXByb3ZlcyB0 aGUgZW5kIHVzZXIgZXhwZXJpZW5jZSBvZiBjb21tb24gbmV0d29yayBzZXJ2aWNlcyBvdmVyIFRh aWwtRHJvcCAod2hpY2ggaXMgbW9zdCBvZnRlbiBjb25maWd1cmVkKSwgYW5kIHRoYXQgdGhpcyBp bXByb3ZlbWVudCBjYW4gYmUgYWNoaWV2ZWQgd2l0aCBhIGZpeGVkIHNldCBvZiBSRUQgY29uZmln dXJhdGlvbiBndWlkZWxpbmVzLg0KPg0KPiBXZSBkaWQgbm90IHJ1biBleHBlcmltZW50cyB3aXRo IHNmcV9jb2RlbCBiZWNhdXNlIGl0IGlzIG5vdCBkZXBsb3llZCBpbiBhY2Nlc3MgbmV0d29ya3Mg dG9kYXkuIFdlIHJhbiBleHBlcmltZW50cyB3aXRoIHBsYWluIENvRGVsIHRvIHVuZGVyc3RhbmQg dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHdlbGwtY29uZmlndXJlZCBSRUQgYW5kIGEgbW9yZSBy ZWNlbnQgc2luZ2xlLWJ1Y2tldCBBUU0gaW4gb3VyIHRhcmdldCBzY2VuYXJpb3MsIGFuZCBhcyBy ZXBvcnRlZCwgZGlkbid0IG9ic2VydmUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgaW4gYXBwbGlj YXRpb24gUW9FLg0KDQpZb3VyICJhcHBsaWNhdGlvbiIgd2FzIGEgYnVuY2ggb2YgdmlkZW8gc3Ry ZWFtcy4gTm90IHdlYiB0cmFmZmljLCBub3Qgdm9pcCwgbm90LCBnYW1pbmcsIG5vdCBiaXR0b3Jy ZW50LCBub3QgYSBmYW1pbHkgb2YgZm91ciBkb2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZXNlIHRo aW5ncywgbm9yIGEgc21hbGwgYnVzaW5lc3MgdGhhdCBpc24ndCBnb2luZyB0byB1c2UgSEFTIGF0 IGFsbC4NCg0KUGxlYXNlIGRvbid0IG92ZXIgZ2VuZXJhbGl6ZSB5b3VyIHJlc3VsdHMuICJSRUQg cHJvdmVuIHN1aXRhYmxlIGZvciBmYW1pbHkgb2YgY291Y2ggcG90YXRvZXMgc3VyZmluZyB0aGUg aW50ZXJuZXQgYW5kIHdhdGNoaW5nIDQgbW92aWVzIGF0IG9uY2Ugb3ZlciB0aGUgaW50ZXJuZXQg YnV0IG5vdCA1LCBhdCA4bWJpdC9zZWMiIG1pZ2h0IGhhdmUgYmVlbiBhIGJldHRlciB0aXRsZSBm b3IgdGhpcyBwYXBlci4NCg0KSW4gdGhpcyBmaWN0aW9uYWwgZmFtaWx5LCBqdXN0IG9uZSBraWQg dW5kZXIgdGhlIHN0YWlyLCB0cnlpbmcgdG8gZG8gc29tZXRoaW5nIHVzZWZ1bCwgaW50ZXJhY3Rp dmUgYW5kL29yIGZ1biwgY2FuIGJvdGggd3JlY2sgdGhlIGNvdWNoIHBvdGF0b2VzJyBpbnRlcm5l dCBleHBlcmllbmNlLCBhbmQgaGF2ZSBoaXMgb3duLCB3cmVja2VkIGFsc28uDQoNCj4NCj4gQWRk aXRpb25hbCBpbmxpbmUgY2xhcmlmaWNhdGlvbnMgYmVsb3cuDQo+DQo+IC1TaGFoaWQuDQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhdmUgVGFodCBbbWFpbHRvOmRh dmUudGFodEBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCAyOjAwIFBN DQo+IFRvOiBBa2h0YXIsIFNoYWhpZCAoU2hhaGlkKQ0KPiBDYzogRnJlZCBCYWtlciAoZnJlZCk7 IEpvaG4gTGVzbGllOyBhcW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcW1dIE9ic29sZXRp bmcgUkZDIDIzMDkNCj4NCj4gT24gTW9uLCBKdWwgMTQsIDIwMTQgYXQgMTE6MDggQU0sIEFraHRh ciwgU2hhaGlkIChTaGFoaWQpIDxzaGFoaWQuYWtodGFyQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3Jv dGU6DQo+PiBIaSBGcmVkLCBBbGwsDQo+Pg0KPj4gTGV0IG1lIGFuIGFkZGl0aW9uYWwgdGhvdWdo dCB0byB0aGlzIGlzc3VlLg0KPj4NCj4+IEdpdmVuIHRoYXQgKFcpUkVEIGhhcyBiZWVuIGRlcGxv eWVkIGV4dGVuc2l2ZWx5IGluIG9wZXJhdG9ycycgbmV0d29ya3MsIGFuZCBtb3N0IHZlbmRvcnMg YXJlIHN0aWxsIHNoaXBwaW5nIGVxdWlwbWVudCB3aXRoIChXKVJFRCwgY29uY2VybiBpcyB0aGF0 IG9ic29sZXRpbmcgMjMwOSB3b3VsZCBkaXNjb3VyYWdlIHJlc2VhcmNoIG9uIHRyeWluZyB0byBm aW5kIGdvb2QgY29uZmlndXJhdGlvbnMgdG8gbWFrZSAoVylSRUQgd29yay4NCj4+DQo+PiBXZSBo YWQgcHJldmlvdXNseSBnaXZlbiBhIHByZXNlbnRhdGlvbiBhdCB0aGUgSUNDUkcgb24gd2h5IFJF RCBjYW4gc3RpbGwgcHJvdmlkZSB2YWx1ZSB0byBvcGVyYXRvcnMgKGh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvODgvc2xpZGVzL3NsaWRlcy04OC1pY2NyZy0wLnBkZikuIFdlIGhhdmUg YSBwYXBlciBhdCBHbG9iZWNvbSAyMDE0IHRoYXQgZXhwbGFpbnMgdGhpcyBzdHVkeSBtdWNoIGJl dHRlciwgYnV0IEkgY2Fubm90IHNoYXJlIGEgbGluayB0byBpdCB1bnRpbCB0aGUgcHJvY2VlZGlu Z3MgYXJlIGF2YWlsYWJsZS4NCj4NCj4gTXkgcHJvYmxlbSB3aXRoIHRoZSBhYm92ZSBwcmVzbyBh bmQgbm8gZG91YnQgdGhlIHJlc3VsdGluZyBzdHVkeSBpcyANCj4gdGhhdCBpdCBkb2Vzbid0IGFw cGVhciBjb3ZlciB0aGUgY2xhc3NpYywgbW9zdCBiYXNpYywgYnVmZmVyYmxvYXQgDQo+IHNjZW5h cmlvLCB3aGljaCBpcw0KPg0KPiAiMSBzdHJlYW0gdXAsIDEgc3RyZWFtIGRvd24sIG9uZSBwaW5n IChvciBzb21lIGZvcm0gb2Ygdm9pcC1saWtlIHRyYWZmaWMpIiBhbmQgdXN1YWxseSBvbiBhbiBl ZGdlIG5ldHdvcmsgd2l0aCBhc3ltbWV0cmljIGJhbmR3aWR0aC4NCg0KVHdvIGFkZGl0aW9uYWwg YW5hbHlzZXMgb2YgdXNlIGZyb20gdGhlIGRvd25sb2FkIHBlcnNwZWN0aXZlIG1pZ2h0IGJlIEFy cmlzJ3MgYW5hbHlzaXMgb2YgdGhlIGJlbmVmaXRzIG9mIHJlZCBhbmQgZnEgb3ZlciBjYWJsZSBo ZWFkIGVuZHM6DQoNCmh0dHA6Ly9zbmFwb24ubGFiLmJ1ZmZlcmJsb2F0Lm5ldC9+ZC90cmltZmF0 L0Nsb29uYW5fUGFwZXIucGRmDQoNCmFuZCB0aGUgY2FibGUgbGFicyB3b3JrIHdoaWNoIGZvY3Vz ZWQgbW9yZSBvbiB0aGUgZWZmZWN0cyBvZiB0cmFmZmljIGdvaW5nIHVwc3RyZWFtIHdoaWNoIGhh cyBiZWVuIGRpc2N1c3NlZCBmYWlybHkgZXh0ZW5zaXZlbHkgaGVyZS4NCg0KPiBTQTogV2UgdHJp ZWQgdG8gY292ZXIgdGhlIHR5cGljYWwgZXhwZWN0ZWQgdHJhZmZpYyBvdmVyIHRoZSBJbnRlcm5l dC4NCg0KSSBkb24ndCBrbm93IHdoZXJlIHlvdSBnZXQgeW91ciBkYXRhLCBidXQgbXkgbWVhc3Vy ZWQgZWRnZSB0cmFmZmljIGxvb2tzIG5vdGhpbmcgbGlrZSB5b3Vycy4gU3VyZSBiYW5kd2lkdGgg d2lzZSwgdGhlcmVzIHRoZSBuZXRmbGl4IHNwaWtlIDMgaG91cnMgb3V0IG9mIHRoZSBkYXkgYnV0 IHRoZSByZXN0IHN1cmUgaXNuJ3QgSEFTLg0KDQoNCj5Nb3N0IG9mIHRoZSB0cmFmZmljIGlzIG5v dyBIQVMgdHJhZmZpYyAoYXMgcGVyIHRoZSBzYW5kdmluZSByZXBvcnQpLCBzbyBpZiBvbmx5IGEg c2luZ2xlIHN0cmVhbSBpcyBwcmVzZW50LCBpdCBpcyBsaWtlbHkgdG8gYmUgSEFTLg0KDQo+VGhl IGNsb3Nlc3QgYXBwcm94aW1hdGlvbiBvZiBhIGNvbnRpbnVvdXMgVENQIHN0cmVhbSwgYXMgeW91 IG1lbnRpb24sIHdvdWxkIGJlIGEgcHJvZ3Jlc3NpdmUgZG93bmxvYWQgd2hpY2ggY2FuIGxhc3Qg bG9uZyBlbm91Z2ggdG8gbG9vayBjb250aW51b3VzLiBUaGVzZSB3ZXJlIG1vZGVsZWQgdG9nZXRo ZXIgd2l0aCBvdGhlciB0eXBlcyBvZiB0cmFmZmljLg0KDQpZb3Uga2VlcCBzYXlpbmcsIGRvd25s b2FkLCBkb3dubG9hZCwgZG93bmxvYWQuIEkgYW0gc2F5aW5nIG1lcmVseSBwbGVhc2UgQUxXQVlT IHRyeSBhbiB1cGxvYWQgYXQgdGhlIHNhbWUgdGltZSB5b3UgYXJlIHRlc3RpbmcgZG93bmxvYWRz DQotIGJlIGl0IHZpZGVvY29uZmVyZW5jaW5nICh3aGljaCBjYW4gZWFzaWx5IHVzZSB1cCB0aGF0 IDEuNm1iaXQgbGluayksIGEgeW91dHViZSB1cGxvYWQsIGEgcnN5bmMgYmFja3VwLCBhIHNjcCwg YW55dGhpbmcuLi4NCg0KSXQgbmVlZGVudCBiZSB0aGUgY3J1eCBvZiB5b3VyIHBhcGVyISBCdXQg YWRkaW5nIHNldmVyYWwgdGVzdHMgb2YgdGhhdCBzb3J0IGRvZXMgbmVlZCB0byBpbmZvcm0geW91 ciB0b3RhbCBtb2RlbGluZyBleHBlcmllbmNlLg0KDQpJZiB5b3UgZG8gdGhhdCBtdWNoLCB5b3Ug d2UgZ2V0IGEgZmVlbCBmb3IgaG93IHByZXNlbnQgZGF5IHN5c3RlbXMgaW50ZXJhY3Qgd2l0aCB0 aGluZ3MgbGlrZSBhY2sgY2xvY2tpbmcgd2hpY2ggd2lsbCBkbyB2ZXJ5IGludGVyZXN0aW5nIHRo aW5ncyB0byB5b3VyICJkb3duc3RyZWFtIHRvIHRoZSBjb3VjaCBwb3RhdG8iIHBlcmZvcm1hbmNl IG1ldHJpY3MuDQoNCj4NCj4gSXQncyBub3QgY2xlYXIgZnJvbSB0aGUgc3R1ZHkgdGhhdCB0aGlz IGlzIGEgOG1iaXQgZG93biAxbWJpdCB1cCBEU0wgDQo+IG5ldHdvcmsgKD8pLA0KPg0KPiBTQTog SW4gdGhlIHN0dWR5IHByZXNlbnRlZCwgSXQgd2FzIDhNIGRvd24gYW5kIDEuNk0gdXAgLSBzbGlk ZSA5DQoNClRoeC4NCg0KDQo+DQo+IG5vciBpcyBpdCBjbGVhciBpZiBSRUQgaXMgYmVpbmcgYXBw bGllZCBpbiBib3RoIGRpcmVjdGlvbnMgb3Igb25seSBvbmUgZGlyZWN0aW9uIG9ubD8NCj4NCj4g U0E6IEFRTXMgKGluY2x1ZGluZyBSRUQpIHdlcmUgb25seSBhcHBsaWVkIGluIGRvd25zdHJlYW0g ZGlyZWN0aW9uIC0gDQo+IHNsaWRlIDkNCg0KQXJlIHlvdSBnb2luZyB0byBmb2xsb3cgdXAgd2l0 aCBzdHVmZiB0aGF0IGxvb2tzIGF0IHRoZSB1cHN0cmVhbSBkaXJlY3Rpb24/DQoNCj4gKGFuZCB0 aGUgcmVzdWx0cyB5b3UgZ2V0IGZyb20gYW4gYXN5bW1ldHJpYyBuZXR3b3JrIGFyZSBxdWl0ZSAN Cj4gaW50ZXJlc3RpbmcsIHBhcnRpY3VsYXJseSBpbiB0aGUgZmFjZSBvZiBhbnkgY3Jvc3MgdHJh ZmZpYyBhdCBhbGwpDQo+DQo+IFNBOiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgY3Jv c3MtdHJhZmZpYywgdGhlIERTTCBsaW5rIG9ubHkgZ29lcyB0byBvbmUgcmVzaWRlbmNlIChvciBi dXNpbmVzcykuIFRoZSB0eXBpY2FsIHRyYWZmaWMgdG8gdGhhdCB3YXMgbW9kZWxlZC4NCg0KSSBk byBuZWVkIGEgY29uc2lzdGVudCBuYW1lIGZvciB0aGlzIHRoYXQgbWF0Y2hlcyBwZW9wbGUncyBl eHBlY3RhdGlvbnMuIERvZXMgbm90IGNyb3NzIHRyYWZmaWMgbWFrZSBzZW5zZSBpbiBhIERTTCBj b250ZXh0Pw0KQ29tcGV0aW5nPw0KDQpJIG1lYW4gc29tZW9uZSBkb2luZyAqYW55dGhpbmcqIHRo YXQgaW52b2x2ZXMgc2VuZGluZyBkYXRhIHVwc3RyZWFtIG90aGVyIHRoYW4gdGlueSB0Y3AgYWNr cy4NCg0KPiBBbmQgSSBkbyBrZWVwIGhvcGluZyB0aGF0IHNvbWVvbmUgd2lsbCBkbyBhIHN0dWR5 IG9mIGhvdyBwcmV2YWxlbnQgZnEgaXMgb24gZHNsIGRldmljZXMsIEkga2VlcCBhY2N1bXVsYXRp bmcgYW5lY2RvdGFsIGRhdGEgdGhhdCBpdCdzIGZhaXJseSBjb21tb24uDQo+DQo+PiBPbmUgb2Yg dGhlIG1ham9yIHJlYXNvbnMgd2h5IG9wZXJhdG9ycyBjaG9zZSBub3QgdG8gZGVwbG95IChXKVJF RCB3YXMgYSBudW1iZXIgb2Ygc3R1ZGllcyBhbmQgcmVzZWFyY2ggd2hpY2ggZ2F2ZSBvcGVyYXRv cnMgY29uZmxpY3RpbmcgbWVzc2FnZXMgb24gdGhlIHZhbHVlIG9mIChXKVJFRCBhbmQgYXBwcm9w cmlhdGUgcGFyYW1ldGVycyB0byB1c2UuIFNvbWUgb2YgdGhlc2UgYXJlIG1lbnRpb25lZCBpbiB0 aGUgcHJlc2VudGF0aW9uIGFib3ZlLg0KPj4NCj4+IEluIGl0IHdlIHNob3cgdGhhdCB0aGUgcHJl dmlvdXMgc3R1ZGllcyB3aGljaCBzaG93ZWQgbG93IHZhbHVlIGZvciBSRUQgdXNlZCB3ZWIgdHJh ZmZpYyB3aGljaCBoYWQgdmVyeSBzbWFsbCBmaWxlIHNpemVzIChvZiB0aGUgb3JkZXIgb2YgNS0x MCBwYWNrZXRzKSwgd2hpY2ggcmVkdWNlcyB0aGUgZWZmZWN0aXZlcyBvZiBhbGwgQVFNcyB3aGlj aCB3b3JrIGJ5IGRyb3BwaW5nIG9yIEVDTiBtYXJraW5nIG9mIGZsb3dzIHRvIGluZGljYXRlIGNv bmdlc3Rpb24uIFRvZGF5J3MgdHJhZmZpYyBpcyBjb21wb3NlZCBvZiBtb3N0bHkgbXVsdGktbWVk aWEgdHJhZmZpYyBsaWtlIEhBUyBvciB2aWRlbyBwcm9ncmVzc2l2ZSBkb3dubG9hZCB3aGljaCBo YXMgbXVjaCBsYXJnZXIgZmlsZSBzaXplcyBhbmQgY2FuIGJlIGNvbnRyb2xsZWQgbXVjaCBiZXR0 ZXIgd2l0aCBBUU1zIGFuZCBpbiBvdXIgcmVzZWFyY2ggd2Ugc2hvdyB0aGF0IFJFRCBjYW4gYmUg cXVpdGUgZWZmZWN0aXZlIHdpdGggdGhpcyB0cmFmZmljLCB3aXRoIGxpdHRsZSB0dW5pbmcgbmVl ZGVkIGZvciB0eXBpY2FsIHJlc2lkZW50aWFsIGFjY2VzcyBmbG93cy4NCg0KSSBhZ3JlZSwgaW5j aWRlbnRhbGx5LCB0aGF0IFJFRCBpcyBPSyBmb3IgZmF0IG5vbi1pbnRlcmFjdGl2ZSB2aWRlbyBm bG93cyBvdmVyIHRjcC4gQW5kIEkgYXBwcm92ZSBvZiBwZW9wbGUgY29taW5nIHVwIHdpdGggd2F5 cyB0byB0dW5lIGl0IHByb3Blcmx5IGZvciBhbGwgc29ydHMgb2YgZW52aXJvbm1lbnRzIGFuZCBm dWxseSBkb2N1bWVudGluZyBob3cgdG8gZG8gaXQuDQoNCj4NCj4gSSB0ZW5kIHRvIGRpc2FncmVl IHdpdGggdGhpcywgKHdlbGwsIG5vdCB0aGUgdHJlbmRsaW5lIHRvIGJpZyB2aWRlbw0KPiBmbG93 cykgYnV0IG15IG93biBzdHVkaWVzIGFyZSBmb2N1c2VkIG9uIHJldGFpbmluZyBoaWdoIHBlcmZv cm1hbmNlIGdhbWluZywgdm9pcCwgYW5kIHZpZGVvY29uZmVyZW5jaW5nIHRyYWZmaWMgaW4gdGhl IGZhY2Ugb2YgdGhpbmdzIGxpa2UgSEFTIHZpZGVvIHRyYWZmaWMuIEkgd291bGQgYmUgbXVjaCBo YXBwaWVyIGFib3V0IHlvdXIgc3R1ZHkgaGFkIHlvdSBhbHNvIHJ1biB0aGF0IHNvcnQgb2YgdHJh ZmZpYyB3aGlsZSB0ZXN0aW5nIHlvdXIgdmlkZW8gZG93bmxvYWRzIGFuZCBhcW1zLi4uIGFuZCB3 aHkgaXMgaXQgc28gaGFyZCB0byBnZXQgZm9sayB0byB0cnkgc2ZxX2NvZGVsLCBldGMsIHdoaWxl IHRoZXkgdHJ5IGV2ZXJ5dGhpbmcgZWxzZT8NCj4NCj4gU0E6IFdlIGRpZCBub3QgbW9kZWwgc21h bGxlciBmbG93cyAoaW4gdGVybXMgb2YgdGhyb3VnaHB1dCkuIFNtYWxsDQoNCkxBVEVOQ1ksIGRh bW4gaXQuDQoNCj5VRFAgZmxvd3MsIHdoaWNoIEkgYXNzdW1lIGFsbC9tb3N0IG9mIHRoZSBhYm92 ZSB3b3VsZCBmYWxsIGluLCB3b3VsZCBiZW5lZml0IHNpZ25pZmljYW50bHkgd2l0aCBSRUQgLSBz bGlkZSAxMyBzaG93cyBtdWNoIGxvd2VyIGF2ZXJhZ2UgcXVldWUgbGVuZ3RoIHdpdGggUkVELg0K DQpBdmVyYWdlIHF1ZXVlIGxlbmd0aCBpcyB2YWx1ZWxlc3MsIGFjY29yZGluZyB0byBLYXRoeSBh bmQgVmFuIC0gYW5kIGEgZmV3IG90aGVyIHBlb3BsZSwgaW5jbHVkaW5nIG1lLg0KDQo+T3RoZXIg c3R1ZGllcyBoYXZlIHNob3duIHRoYXQgc21hbGwgVURQIGZsb3dzIHdpdGggbG90cyBvZiBUQ1Ag dHJhZmZpYyBiZW5lZml0IHNpZ25pZmljYW50bHkgd2l0aCBSRUQgYWNoaWV2aW5nIGxvd2VyIHBh Y2tldCBsb3NzIChNLiBNYXlzIGV0IGFsLCDigJxSZWFzb25zIG5vdCB0byBkZXBsb3kgUkVE4oCd KS4NCg0KSG1tLi4uIHlvdSByZWFsbHksIHJlYWxseSwgcmVhbGx5IG5lZWQgdG8gc3BlbmQgc29t ZSB0aW1lIHBsYXlpbmcgd2l0aCByZWFsIHRyYWZmaWMgb3ZlciByZWFsLCBhc3ltbWV0cmljIG5l dHdvcmtzIHRoYXQgZ29lcyBpbiBib3RoIGRpcmVjdGlvbnMuDQoNCj4+DQo+PiBQcmVmZXIgSm9o bidzIHByb3Bvc2FsIG9mIHVwZGF0aW5nIDIzMDkgcmF0aGVyIHRoYW4gb2Jzb2xldGluZywgYnV0 IGlmIHdlIGNhbiBoYXZlIHNvbWUgdGV4dCBpbiBGcmVkJ3MgZHJhZnQgYWNrbm93bGVkZ2luZyB0 aGUgbGFyZ2UgZGVwbG95bWVudCBvZiAoVylSRUQgYW5kIHRoZSBuZWVkIHRvIHN0aWxsIGZpbmQg Z29vZCBjb25maWd1cmF0aW9ucyAtIHRoYXQgbWF5IHdvcmsuIEkgY2FuIHZvbHVudGVlciB0byBw cm92aWRlIHRoYXQgdGV4dC4NCj4+DQo+PiAtU2hhaGlkLg0KPg0KPj4NCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBhcW0gW21haWx0bzphcW0tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEZyZWQgQmFrZXIgDQo+PiAoZnJlZCkNCj4+IFNlbnQ6IE1vbmRheSwg SnVseSAxNCwgMjAxNCAyOjA2IEFNDQo+PiBUbzogSm9obiBMZXNsaWUNCj4+IENjOiBhcW1AaWV0 Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbYXFtXSBPYnNvbGV0aW5nIFJGQyAyMzA5DQo+Pg0KPj4N Cj4+IE9uIEp1bCAzLCAyMDE0LCBhdCAxMDoyMiBBTSwgSm9obiBMZXNsaWUgPGpvaG5AamxjLm5l dD4gd3JvdGU6DQo+Pg0KPj4+IEl0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBzb21lb25lIHRvIGFy Z3VlIHRoYXQgcmVzdGF0aW5nIGEgDQo+Pj4gcmVjb21tZW5kYXRpb24gZnJvbSBhbm90aGVyIGRv Y3VtZW50IHdlYWtlbnMgYm90aCBzdGF0ZW1lbnRzOyBidXQgSQ0KPj4+IGRpc2FncmVlOiBXZSBz aG91bGQgY2xlYXJseSBzdGF0ZSB3aGF0IHdlIG1lYW4gaW4gdGhpcyBkb2N1bWVudCwgYW5kIA0K Pj4+IEkgYmVsaWV2ZSB0aGlzIHdvcmRpbmcgZG9lcyBzby4NCj4+DQo+PiBUaGUgYXJndW1lbnQg Zm9yIHB1dHRpbmcgaXQgaW4gdGhlcmUgc3RhcnRlZCBmcm9tIHRoZSBmYWN0IHRoYXQgd2UgYXJl IG9ic29sZXRpbmcgMjMwOSwgYXMgc3RhdGVkIGluIHRoZSBjaGFydGVyLiBJIHdvdWxkIHVuZGVy c3RhbmQgYSBkb2N1bWVudCB0aGF0IHVwZGF0ZXMgMjMwOSB0byBiZSBpbiBhIHN0cmFuZ2Ugc3Rh dGUgaWYgMjMwOSBpcyBpdHNlbGYgbWFkZSBoaXN0b3JpYyBvciBvYnNvbGV0ZS4gU28gd2UgY2Fy cmllZCB0aGUgcmVjb21tZW5kYXRpb24gaW50byB0aGlzIGRvY3VtZW50IHNvIGl0IHdvdWxkbid0 IGdldCBsb3N0Lg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBhcW0gbWFpbGluZyBsaXN0DQo+PiBhcW1AaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXFtDQo+DQo+DQo+DQo+IC0tDQo+IERh dmUgVMOkaHQNCj4NCj4gTlNGVzogDQo+IGh0dHBzOi8vdzIuZWZmLm9yZy9DZW5zb3JzaGlwL0lu dGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2X2kNCj4gbmRlY2VudC5hcnRpY2xl DQoNCg0KDQotLQ0KRGF2ZSBUw6RodA0KDQpOU0ZXOiBodHRwczovL3cyLmVmZi5vcmcvQ2Vuc29y c2hpcC9JbnRlcm5ldF9jZW5zb3JzaGlwX2JpbGxzL3J1c3NlbGxfMDI5Nl9pbmRlY2VudC5hcnRp Y2xlDQo= From nobody Thu Jul 17 09:30:38 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1471B27DF for ; Thu, 17 Jul 2014 09:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELE6defi3z2T for ; Thu, 17 Jul 2014 09:30:08 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E931B27DA for ; Thu, 17 Jul 2014 09:30:07 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so3291652iec.39 for ; Thu, 17 Jul 2014 09:30:06 -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=HHK/WNouNtWFUpcLRlkE9jIZrYJA+TXV/EMatKlDVYY=; b=pEQ5OaIsMUxRh9D8YW2F3Ar04Ff3CuaqXBxw7n+ensf2v5FyJkfPY8pmUNYJQ/2kgv bktA/lShhzuuj1XJ4XJYJ/Xc1+r9Ax5GQfjdk8H4pzjsE71EnCOE8enh8cpApDxOzZGK OyWvKd0BkepelKuHQH2mhezXiHwRVmxb5HjmDvfVWEX/wUu65c3GdJS7i60eBmgZRaB0 BH7ZqyxyaAHat6PKDhwGXvx37rslD/R0IcqGbrNPaEE50VAp4iqe/cdYah8mp6JqBF2S +m/1aMM6azvZAzwrW1+OvgS6iGPUyQUT8IYw1b/jkYXyPf1yWlFRFCc9lEw33M1S4RiQ CkOQ== MIME-Version: 1.0 X-Received: by 10.182.96.71 with SMTP id dq7mr46545373obb.42.1405614606227; Thu, 17 Jul 2014 09:30:06 -0700 (PDT) Received: by 10.202.93.195 with HTTP; Thu, 17 Jul 2014 09:30:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Jul 2014 09:30:06 -0700 Message-ID: From: Dave Taht To: "Akhtar, Shahid (Shahid)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/NwBDEM9j6ebvBu0i3_yvpBouzQs Cc: "aqm@ietf.org" , "Fred Baker \(fred\)" , John Leslie Subject: Re: [aqm] Sane analysis of "typical traffic" X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2014 16:30:12 -0000 On Thu, Jul 17, 2014 at 8:51 AM, Akhtar, Shahid (Shahid) wrote: > Dave, > > Web traffic was part of the study - you should be able to see page load t= imes on slide 12 > > Lower levels of traffic were also tested (slides 11,12), however the high= est impact of AQM was observed at high traffic levels > > We included the largest components of Internet traffic (HAS, Web Traffic,= Video Progressive download) which constitute over 75% of all traffic (http= s://www.sandvine.com/downloads/general/global-internet-phenomena/2014/1h-20= 14-global-internet-phenomena-report.pdf) at peak hour I continually am mind-blown by statistical legerdemain. Just look at the size of the ps3/ps4/xbox gamer market for example. I don't care about the amount of traffic at all. I care that in a all-night aming session or a hour long videconference that the relatively sparse latency sensitive packets get through - in both directions - regardless of what else is going on on the network. > The study presented in Nov was our initial work and is not the only compo= nent in development of any configuration guidelines Got any gamers helping write your specs? > > -Shahid. > > -----Original Message----- > From: Dave Taht [mailto:dave.taht@gmail.com] > Sent: Tuesday, July 15, 2014 4:00 PM > To: Akhtar, Shahid (Shahid) > Cc: Fred Baker (fred); John Leslie; aqm@ietf.org > Subject: Sane analysis of "typical traffic" > > changing the title as this is not relevant to the aqm document... > > ... but to an attitude that is driving me absolutely crazy. > > On Tue, Jul 15, 2014 at 10:46 AM, Akhtar, Shahid (Shahid) wrote: >> Dave, >> >> The message of the results that we presented in November is that it is p= ossible, with currently deployed access hardware, to configure RED so that = it consistently improves the end user experience of common network services= over Tail-Drop (which is most often configured), and that this improvement= can be achieved with a fixed set of RED configuration guidelines. >> >> We did not run experiments with sfq_codel because it is not deployed in = access networks today. We ran experiments with plain CoDel to understand th= e difference between a well-configured RED and a more recent single-bucket = AQM in our target scenarios, and as reported, didn't observe significant di= fferences in application QoE. > > Your "application" was a bunch of video streams. Not web traffic, not voi= p, not, gaming, not bittorrent, not a family of four doing a combination of= these things, nor a small business that isn't going to use HAS at all. > > Please don't over generalize your results. "RED proven suitable for famil= y of couch potatoes surfing the internet and watching 4 movies at once over= the internet but not 5, at 8mbit/sec" might have been a better title for t= his paper. > > In this fictional family, just one kid under the stair, trying to do some= thing useful, interactive and/or fun, can both wreck the couch potatoes' in= ternet experience, and have his own, wrecked also. > >> >> Additional inline clarifications below. >> >> -Shahid. >> >> -----Original Message----- >> From: Dave Taht [mailto:dave.taht@gmail.com] >> Sent: Monday, July 14, 2014 2:00 PM >> To: Akhtar, Shahid (Shahid) >> Cc: Fred Baker (fred); John Leslie; aqm@ietf.org >> Subject: Re: [aqm] Obsoleting RFC 2309 >> >> On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) wrote: >>> Hi Fred, All, >>> >>> Let me an additional thought to this issue. >>> >>> Given that (W)RED has been deployed extensively in operators' networks,= and most vendors are still shipping equipment with (W)RED, concern is that= obsoleting 2309 would discourage research on trying to find good configura= tions to make (W)RED work. >>> >>> We had previously given a presentation at the ICCRG on why RED can stil= l provide value to operators (http://www.ietf.org/proceedings/88/slides/sli= des-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this st= udy much better, but I cannot share a link to it until the proceedings are = available. >> >> My problem with the above preso and no doubt the resulting study is >> that it doesn't appear cover the classic, most basic, bufferbloat >> scenario, which is >> >> "1 stream up, 1 stream down, one ping (or some form of voip-like traffic= )" and usually on an edge network with asymmetric bandwidth. > > Two additional analyses of use from the download perspective might be Arr= is's analysis of the benefits of red and fq over cable head ends: > > http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf > > and the cable labs work which focused more on the effects of traffic goin= g upstream which has been discussed fairly extensively here. > >> SA: We tried to cover the typical expected traffic over the Internet. > > I don't know where you get your data, but my measured edge traffic looks = nothing like yours. Sure bandwidth wise, theres the netflix spike 3 hours o= ut of the day but the rest sure isn't HAS. > > >>Most of the traffic is now HAS traffic (as per the sandvine report), so i= f only a single stream is present, it is likely to be HAS. > >>The closest approximation of a continuous TCP stream, as you mention, wou= ld be a progressive download which can last long enough to look continuous.= These were modeled together with other types of traffic. > > You keep saying, download, download, download. I am saying merely please = ALWAYS try an upload at the same time you are testing downloads > - be it videoconferencing (which can easily use up that 1.6mbit link), a = youtube upload, a rsync backup, a scp, anything... > > It needent be the crux of your paper! But adding several tests of that so= rt does need to inform your total modeling experience. > > If you do that much, you we get a feel for how present day systems intera= ct with things like ack clocking which will do very interesting things to y= our "downstream to the couch potato" performance metrics. > >> >> It's not clear from the study that this is a 8mbit down 1mbit up DSL >> network (?), >> >> SA: In the study presented, It was 8M down and 1.6M up - slide 9 > > Thx. > > >> >> nor is it clear if RED is being applied in both directions or only one d= irection onl? >> >> SA: AQMs (including RED) were only applied in downstream direction - >> slide 9 > > Are you going to follow up with stuff that looks at the upstream directio= n? > >> (and the results you get from an asymmetric network are quite >> interesting, particularly in the face of any cross traffic at all) >> >> SA: I am not sure what you mean by cross-traffic, the DSL link only goes= to one residence (or business). The typical traffic to that was modeled. > > I do need a consistent name for this that matches people's expectations. = Does not cross traffic make sense in a DSL context? > Competing? > > I mean someone doing *anything* that involves sending data upstream other= than tiny tcp acks. > >> And I do keep hoping that someone will do a study of how prevalent fq is= on dsl devices, I keep accumulating anecdotal data that it's fairly common= . >> >>> One of the major reasons why operators chose not to deploy (W)RED was a= number of studies and research which gave operators conflicting messages o= n the value of (W)RED and appropriate parameters to use. Some of these are = mentioned in the presentation above. >>> >>> In it we show that the previous studies which showed low value for RED = used web traffic which had very small file sizes (of the order of 5-10 pack= ets), which reduces the effectives of all AQMs which work by dropping or EC= N marking of flows to indicate congestion. Today's traffic is composed of m= ostly multi-media traffic like HAS or video progressive download which has = much larger file sizes and can be controlled much better with AQMs and in o= ur research we show that RED can be quite effective with this traffic, with= little tuning needed for typical residential access flows. > > I agree, incidentally, that RED is OK for fat non-interactive video flows= over tcp. And I approve of people coming up with ways to tune it properly = for all sorts of environments and fully documenting how to do it. > >> >> I tend to disagree with this, (well, not the trendline to big video >> flows) but my own studies are focused on retaining high performance gami= ng, voip, and videoconferencing traffic in the face of things like HAS vide= o traffic. I would be much happier about your study had you also run that s= ort of traffic while testing your video downloads and aqms... and why is it= so hard to get folk to try sfq_codel, etc, while they try everything else? >> >> SA: We did not model smaller flows (in terms of throughput). Small > > LATENCY, damn it. > >>UDP flows, which I assume all/most of the above would fall in, would bene= fit significantly with RED - slide 13 shows much lower average queue length= with RED. > > Average queue length is valueless, according to Kathy and Van - and a few= other people, including me. > >>Other studies have shown that small UDP flows with lots of TCP traffic be= nefit significantly with RED achieving lower packet loss (M. Mays et al, = =E2=80=9CReasons not to deploy RED=E2=80=9D). > > Hmm... you really, really, really need to spend some time playing with re= al traffic over real, asymmetric networks that goes in both directions. > >>> >>> Prefer John's proposal of updating 2309 rather than obsoleting, but if = we can have some text in Fred's draft acknowledging the large deployment of= (W)RED and the need to still find good configurations - that may work. I c= an volunteer to provide that text. >>> >>> -Shahid. >> >>> >>> -----Original Message----- >>> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker >>> (fred) >>> Sent: Monday, July 14, 2014 2:06 AM >>> To: John Leslie >>> Cc: aqm@ietf.org >>> Subject: Re: [aqm] Obsoleting RFC 2309 >>> >>> >>> On Jul 3, 2014, at 10:22 AM, John Leslie wrote: >>> >>>> It would be possible for someone to argue that restating a >>>> recommendation from another document weakens both statements; but I >>>> disagree: We should clearly state what we mean in this document, and >>>> I believe this wording does so. >>> >>> The argument for putting it in there started from the fact that we are = obsoleting 2309, as stated in the charter. I would understand a document th= at updates 2309 to be in a strange state if 2309 is itself made historic or= obsolete. So we carried the recommendation into this document so it wouldn= 't get lost. >>> >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >> >> >> >> -- >> Dave T=C3=A4ht >> >> NSFW: >> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_i >> ndecent.article > > > > -- > Dave T=C3=A4ht > > NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_029= 6_indecent.article --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Thu Jul 17 16:14:03 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04601A0379 for ; Thu, 17 Jul 2014 16:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnzmCeOKgOrg for ; Thu, 17 Jul 2014 16:14:00 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685081A0334 for ; Thu, 17 Jul 2014 16:14:00 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id j17so1873625oag.12 for ; Thu, 17 Jul 2014 16:13:59 -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 :content-transfer-encoding; bh=rJeNtppy1VQzAs7+lA4Va/Kef+4nIjI7F17JM4LJ9ik=; b=g3LRud+CT0p2NqMFwfOZ+6TPIvUbqrN6S27gAM2rXzjehDwVgeyUqlRB4t3KzZkG6o v+jGhqxXEC9xKfntPOMPl5TneDXy32ACJNoUPv0kI2e39hn8KDvfta9V3gNVvDVA7HU2 qzyrdZdqEJIbC1Upcwi9l4OevfF04MxAlpjy26mxJSB5akQl5mFp2VGpl39LWDf7EN1t zjXRwZMZzaQWRAGMnaDxhthosT87VS+qgua3uqGK0PBtGxgASFbJxYCV1aoYRU65biY0 U/n9guCQCXqs+aN77BJAGuT0NMxlhml8J8JxI1lp1iSopr+KY0xflAPDF4v1wUOjgQYs 7QaQ== MIME-Version: 1.0 X-Received: by 10.60.23.65 with SMTP id k1mr863519oef.20.1405638839678; Thu, 17 Jul 2014 16:13:59 -0700 (PDT) Received: by 10.202.93.195 with HTTP; Thu, 17 Jul 2014 16:13:59 -0700 (PDT) Date: Thu, 17 Jul 2014 16:13:59 -0700 Message-ID: From: Dave Taht To: "aqm@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/aVKGZ-mycp65_saM5VVsLxlN3-M Subject: [aqm] To heck with aqm and simple packet scheduling X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2014 23:14:01 -0000 It is truly remarkable what can be done with a central clock and a network a hundred meters wide. http://fastpass.mit.edu/Fastpass-SIGCOMM14-Perry.pdf --=20 Dave T=C3=A4ht From nobody Fri Jul 18 17:42:26 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A581A02F3 for ; Fri, 18 Jul 2014 17:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRO76r9-uECs for ; Fri, 18 Jul 2014 17:42:23 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036201A02EE for ; Fri, 18 Jul 2014 17:42:22 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id o6so4450289oag.38 for ; Fri, 18 Jul 2014 17:42:22 -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 :content-transfer-encoding; bh=tYa8ZJGFqrS89Vy/lf4R9zmwermdKMsU9ZbauWD8HKo=; b=niYaU+niaGjj4LaKNmKTdj8WK1CyE2YmGd2xznDXJ1jFmJVQVP35568UYkoxbqjoeS gTr7gsIZ4zt1y2fsDLXHb6GwzCRumr1pAFdwY8Fy/k52GVAqreWZ9Ewpj2sst2jwRmIr xY4SyPoUNSA0FiwDGJOYZ9o49r/TckL903gh3XMSRduiTF7Cwe43fh6hRQGkpTJaG3gH coqVMKynmrmTseyYNCHFKf0qARyn7pf+bl9TKevIGm0eX8E3MN1XA0G8lmwGVtJXkbjr 0g1OC8dG9/e0XB92iMnZQCQmH+bIl+m93QhcnDRgxM7YFiU1J90Ib+gdUhf9UZ8gXmZB VA3g== MIME-Version: 1.0 X-Received: by 10.182.96.71 with SMTP id dq7mr12218893obb.42.1405730541998; Fri, 18 Jul 2014 17:42:21 -0700 (PDT) Received: by 10.202.93.195 with HTTP; Fri, 18 Jul 2014 17:42:21 -0700 (PDT) Date: Fri, 18 Jul 2014 17:42:21 -0700 Message-ID: From: Dave Taht To: "aqm@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/8PNVe2_oH8UFa3gaG9TKmlMQi3c Subject: [aqm] Possibly valuable cite? X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 00:42:24 -0000 Was this the paper now cited in the aqm draft? Right author, at least... http://www.eecs.berkeley.edu/~sylvia/cs268-2014/papers//FQ1989.pdf " [Dem90] Demers, A., Keshav, S., and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience", SIGCOMM Symposium proceedings on Communications architectures and protocols , 1990." --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Sun Jul 20 07:32:37 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F971A0AEA for ; Sun, 20 Jul 2014 07:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peaDFNtlsC0U for ; Sun, 20 Jul 2014 07:32:33 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F451A0AE7 for ; Sun, 20 Jul 2014 07:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7187; q=dns/txt; s=iport; t=1405866753; x=1407076353; h=from:to:subject:date:message-id:references:mime-version; bh=yv/D+Wrn81nuq+fZW3jUbrWyab4tJXb+R8ufUdoYx5U=; b=AJmiudW6Ws7/MWW5wDD1K1Z3/PuwhpR2+JFLUcUzClJ6dsEagFKcOFh7 p/tyYAaq9LE4ZNvVa+HvAldZUkpGLhubSShU0DrmgdDhpZmIZc/etJLGW NgPsIyh/M0k0AGYxUlh1g2Hgq5i/dLTCUXahMwtY1PH2UqczYlx0pIOUa c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAADSy1OtJV2U/2dsb2JhbABZgw5SVwSCdMIoh0SBBhZ2hAMBAQEDASNbCwIBGQMBAisCAjIUBwIIAgQTDgaIJggNqiOWexMEjzoegnI2gRgFkkCBRYcglC+DRGyBRQ X-IronPort-AV: E=Sophos;i="5.01,695,1400025600"; d="asc'?scan'208";a="62421133" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 20 Jul 2014 14:32:32 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6KEWWId026289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 20 Jul 2014 14:32:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 20 Jul 2014 09:32:31 -0500 From: "Fred Baker (fred)" To: "aqm@ietf.org" Thread-Topic: Updated IESG Statement on Designating RFCs as Historic Thread-Index: AQHPpCaCpcDlpcR5ckmKkzXrOP/5SQ== Date: Sun, 20 Jul 2014 14:32:31 +0000 Message-ID: <0B53885B-D5CE-44E1-8972-D56868251A39@cisco.com> References: <20140720142510.5682.2262.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.143] Content-Type: multipart/signed; boundary="Apple-Mail=_C20EC9DA-1BF1-43D1-AD1F-4D2DAF7C6577"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/z2UoLMd1m-q8Y9s54qWiRLbme94 Subject: [aqm] Fwd: Updated IESG Statement on Designating RFCs as Historic X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Jul 2014 14:32:35 -0000 --Apple-Mail=_C20EC9DA-1BF1-43D1-AD1F-4D2DAF7C6577 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Begin forwarded message: > From: IESG Secretary > Subject: Updated IESG Statement on Designating RFCs as Historic=20 > Date: July 20, 2014 at 10:25:10 AM EDT > To: IETF Announcement List > Reply-To: >=20 > Date: 20 July 2014 >=20 > RFC 2026 defines a "Historic" status for documents: >=20 > A specification that has been superseded by a more recent=20 > specification or is for any other reason considered to be obsolete=20= > is assigned to the "Historic" level. >=20 > However, the only instructions in 2026 for its use are in section 6, = and=20 > those are to move full "Internet Standard" status documents to=20 > "Historic" status, thereby "retiring" the technology in the standard.=20= > This differs from the "Obsoletes:" header that is put on documents as=20= > per RFC 2223. The "Obsoletes:" header indicates a replacement version = of=20 > the same technology, rather than a retirement of the technology = itself.=20 > Using "Obsoletes:" is simply a matter of indicating this in the header=20= > of the RFC. Moving a document to "Historic" status requires a specific=20= > IETF-=C2=ADwide Last Call and a formal action of the IESG. >=20 > - A document is obsolete when there is a newer version that replaces=20= > it. RFC 821 is obsoleted by RFC 2821, which is, in turn, obsoleted=20= > by RFC 5321. The technology that RFC 821 describes =E2=80=94 SMTP = =E2=80=94 is still=20 > current technology, but the documentation of it in RFC 821 is=20 > obsolete. >=20 > - A document is labelled Historic when what it describes is no longer=20= > considered current: no longer recommended for use. >=20 > We have reclassified RFCs as Historic through different mechanisms and=20= > with different documentation over time. All reclassifications have=20 > suffered from a common problem: there is no direct reference from the=20= > RFC that has been made Historic to the explanation of why that action=20= > was taken. >=20 > There now exists a new type of document, "status-change" documents, to=20= > fill this gap. These documents are kept in the datatracker, are not=20 > Internet drafts, and are not published as RFCs, but they are archival=20= > documents that are linked to the RFCs whose status is changed. Much as=20= > an Internet draft that requests Historic status might be named "draft- > jones-9191-to-historic", a status-change document requesting that = action=20 > might be "status-change-9191-to-historic. Such status change documents=20= > are created by an Area Director, and can be requested by individuals = or=20 > working groups. >=20 > A major advantage of a status-change document is that it adds=20 > traceability: when the now-Historic RFC is displayed in the = datatracker,=20 > there is a pointer directly to the status-change document, making the=20= > explanation more readily accessible. See RFC 5617 for an example: >=20 > =E2=80=8Bhttps://datatracker.ietf.org/doc/rfc5617/ >=20 > Note the line in the header that says "Status changed by=20 > status-change-adsp-rfc5617-to-historic". >=20 > The current process, then, of moving an RFC to Historic status is to=20= > follow one of these, depending upon the level of documentation and=20 > discussion of the documentation required: >=20 > 1. An AD creates a status-change document containing a relatively=20 > brief explanation of the reason for the status change. A four-week=20= > last call is issued for the status-change document, after which the > IESG evaluates and ballots on the status change. If the change is=20= > approved, the documentation for the change remains in the status- > change document, which is readily available through the = datatracker. >=20 > This method is best when the explanation is not extensive and does=20= > not need much documentation development. The discussion about=20 > whether the action itself is correct may, of course, still be=20 > extensive. >=20 > 2. An individual or a working group posts an Internet Draft = containing=20 > an explanation of the reason for the status change. The I-D is=20 > discussed and iterated as usual for I-Ds. At some point, it is sent=20= > to an appropriate AD to request publication. The AD creates a=20 > status-change document, with an explanation that points to the I-D.=20= > The I-D and the status-change are then last-called together, after=20= > which the IESG evaluates and ballots on both. If the change is=20 > approved, the content of the I-D is moved into the status-change=20 > document, and the I-D is marked as "dead", having served its=20 > purpose. >=20 > This method is best when the explanation is not extensive, but = needs=20 > document discussion and development. >=20 > 3. As #2 above, except that the I-D might also contain other=20 > information. In this case, after IESG approval the I-D is sent to=20= > the RFC Editor. When the RFC is published, the status-change=20 > document is changed to point to the RFC instead of the I-D. >=20 > This method is best when the explanation is extensive, the=20 > explanation is part of another piece of work that involves=20 > publication of an RFC, or, in exceptional cases, when the consensus=20= > of the community or of the IESG is that having the information in = an=20 > RFC is important. >=20 > All cases involve a status-change document, which provides the = mechanics=20 > for separately approving the Historic RFC's status change and for = tying=20 > the explanation to the Historic RFC. In all cases, the approval of the=20= > status-change document will result in a "Protocol Action" or "Document=20= > Action" announcement. >=20 > An RFC may be published directly as Historic, with no earlier status = to=20 > change (see, for example, RFC 4870). This is usually done to document=20= > ideas that were considered and discarded, or protocols that were = already=20 > historic when it was decided to document them. Those publications are=20= > handled as are any other RFCs. As there is no status change, no = status=C2=AD- > change document is used. >=20 > Documents having Historic status means that those documents are "not=20= > Internet Standards in any sense," as per RFC 2026.=20 >=20 --Apple-Mail=_C20EC9DA-1BF1-43D1-AD1F-4D2DAF7C6577 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 iD8DBQFTy9L+bjEdbHIsm0MRAlMnAJ9JIPhP1OHDAskkjzLRwvMk7mKUcgCfd+Nz qIAV7MKZYHrl6vzepqSdPws= =jTkt -----END PGP SIGNATURE----- --Apple-Mail=_C20EC9DA-1BF1-43D1-AD1F-4D2DAF7C6577-- From nobody Sun Jul 20 12:21:55 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ADF1B29AC for ; Sun, 20 Jul 2014 12:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5L8GCHSniOW for ; Sun, 20 Jul 2014 12:21:46 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEBAB1B2984 for ; Sun, 20 Jul 2014 12:21:45 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id w7so5029559qcr.34 for ; Sun, 20 Jul 2014 12:21:45 -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=8fTB1OM+9srsjM8DoluWXE4rZdWQiD52pLMsTjBjlV8=; b=oWHd8yEVPb3Ewq9aia//sF5XVWDRbSjL2JYxjpgTxgynVXNLjoZAsLl1SBktqp6XUG drNbYygp3rmo0fjeef/4SxNyLwLmXMbHgf+PNlpr2+xlpevuv9D6FNSzzgReWASAu1p4 /agbE2mM3/v7A97QgXTpJQMb1ULxC6jrI7q9BFXO894f3285Nv6zcN/1P9BppIJmED5d GNNox4mvOgPvZw6IezwA6wGPg0G2nyK8imj2IByQzOAO1cVzZZmfwnDzawau+irhde0K wzTG9jypuldqTSiKt6BLD+Z3rD11/Hooniwnv7Qb3GUTkg5PNqMdiHfqQqUEyIvarNlu Jj+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8fTB1OM+9srsjM8DoluWXE4rZdWQiD52pLMsTjBjlV8=; b=JlrM9pxs94gmTJKm+Q5egWcW/ze28YwT1Uz7gI+8n5LF8cbMqVEGkKY/XUene6QMAX aWmVqdOh4PuoYw2popom6QoLpYg6SoV1apo6nTQcwBtBbAmlDGsEW+ipmvt9+TPheCbP uJYfzohSRsIhNwvtgUSrFnbt5RiUwheFDa8BX3VySGG4MgcKGNqwF72F0k2b/MRBq/bf 9+cGRnRQBdHi7+FRYkb2A6FbzflAncT8Vv4fIicHbvqlWcl8L7zLEoSjHH8B8JGjXbyF DoZgbVTJ/NC4IxTSLeEMwmwETpQONzolI0VrdyuE6Xd45SVZUw7J5mr69VO4/r4aH3y1 2fMQ== X-Gm-Message-State: ALoCoQkK0virhBGQKbvq0MP2aJlMITQUmzfIHebsEUwWBK5OVbk+RzWGcNhTnbdp6GZu2ICajFaz MIME-Version: 1.0 X-Received: by 10.140.104.161 with SMTP id a30mr30790288qgf.19.1405884104943; Sun, 20 Jul 2014 12:21:44 -0700 (PDT) Received: by 10.224.201.2 with HTTP; Sun, 20 Jul 2014 12:21:44 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Jul 2014 12:21:44 -0700 Message-ID: From: Andrew Mcgregor To: Dave Taht Content-Type: multipart/alternative; boundary=001a11354864abfabe04fea4e6aa Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/lkVEiEtwa3mfWD7O8WhGa04W0Gc Cc: "Akhtar, Shahid \(Shahid\)" , John Leslie , "aqm@ietf.org" , "Fred Baker \(fred\)" Subject: Re: [aqm] Sane analysis of "typical traffic" X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Jul 2014 19:21:49 -0000 --001a11354864abfabe04fea4e6aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Traffic volume has basically nothing to do with traffic value. Consider the DNS... a tiny fraction of upstream traffic must work in order for anything else to work. Similarly, a VoIP call is a tiny amount of traffic, but rather sensitive to loss. Games can be quite chatty, but even so they are sensitive to latency variability (latency compensation works much better if the latency is fairly consistent). Whereas, if my HD video stream downgrades one codec notch, that will halve the bandwidth and I will barely notice the difference. On asymmetric DSL, the upstream value is usually much higher than downstream... if I send anything but ACKs I probably care a lot about whatever that traffic is. On 17 July 2014 09:30, Dave Taht wrote: > On Thu, Jul 17, 2014 at 8:51 AM, Akhtar, Shahid (Shahid) > wrote: > > Dave, > > > > Web traffic was part of the study - you should be able to see page load > times on slide 12 > > > > Lower levels of traffic were also tested (slides 11,12), however the > highest impact of AQM was observed at high traffic levels > > > > We included the largest components of Internet traffic (HAS, Web > Traffic, Video Progressive download) which constitute over 75% of all > traffic ( > https://www.sandvine.com/downloads/general/global-internet-phenomena/2014= /1h-2014-global-internet-phenomena-report.pdf) > at peak hour > > I continually am mind-blown by statistical legerdemain. > > Just look at the size of the ps3/ps4/xbox gamer market for example. I > don't care about the amount of traffic at all. I care that in a > all-night aming session or a hour long videconference that the > relatively sparse latency sensitive packets get through - in both > directions - regardless of what else is going on on the network. > > > The study presented in Nov was our initial work and is not the only > component in development of any configuration guidelines > > Got any gamers helping write your specs? > > > > > -Shahid. > > > > -----Original Message----- > > From: Dave Taht [mailto:dave.taht@gmail.com] > > Sent: Tuesday, July 15, 2014 4:00 PM > > To: Akhtar, Shahid (Shahid) > > Cc: Fred Baker (fred); John Leslie; aqm@ietf.org > > Subject: Sane analysis of "typical traffic" > > > > changing the title as this is not relevant to the aqm document... > > > > ... but to an attitude that is driving me absolutely crazy. > > > > On Tue, Jul 15, 2014 at 10:46 AM, Akhtar, Shahid (Shahid) < > shahid.akhtar@alcatel-lucent.com> wrote: > >> Dave, > >> > >> The message of the results that we presented in November is that it is > possible, with currently deployed access hardware, to configure RED so th= at > it consistently improves the end user experience of common network servic= es > over Tail-Drop (which is most often configured), and that this improvemen= t > can be achieved with a fixed set of RED configuration guidelines. > >> > >> We did not run experiments with sfq_codel because it is not deployed i= n > access networks today. We ran experiments with plain CoDel to understand > the difference between a well-configured RED and a more recent > single-bucket AQM in our target scenarios, and as reported, didn't observ= e > significant differences in application QoE. > > > > Your "application" was a bunch of video streams. Not web traffic, not > voip, not, gaming, not bittorrent, not a family of four doing a combinati= on > of these things, nor a small business that isn't going to use HAS at all. > > > > Please don't over generalize your results. "RED proven suitable for > family of couch potatoes surfing the internet and watching 4 movies at on= ce > over the internet but not 5, at 8mbit/sec" might have been a better title > for this paper. > > > > In this fictional family, just one kid under the stair, trying to do > something useful, interactive and/or fun, can both wreck the couch > potatoes' internet experience, and have his own, wrecked also. > > > >> > >> Additional inline clarifications below. > >> > >> -Shahid. > >> > >> -----Original Message----- > >> From: Dave Taht [mailto:dave.taht@gmail.com] > >> Sent: Monday, July 14, 2014 2:00 PM > >> To: Akhtar, Shahid (Shahid) > >> Cc: Fred Baker (fred); John Leslie; aqm@ietf.org > >> Subject: Re: [aqm] Obsoleting RFC 2309 > >> > >> On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) < > shahid.akhtar@alcatel-lucent.com> wrote: > >>> Hi Fred, All, > >>> > >>> Let me an additional thought to this issue. > >>> > >>> Given that (W)RED has been deployed extensively in operators' > networks, and most vendors are still shipping equipment with (W)RED, > concern is that obsoleting 2309 would discourage research on trying to fi= nd > good configurations to make (W)RED work. > >>> > >>> We had previously given a presentation at the ICCRG on why RED can > still provide value to operators ( > http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We have > a paper at Globecom 2014 that explains this study much better, but I cann= ot > share a link to it until the proceedings are available. > >> > >> My problem with the above preso and no doubt the resulting study is > >> that it doesn't appear cover the classic, most basic, bufferbloat > >> scenario, which is > >> > >> "1 stream up, 1 stream down, one ping (or some form of voip-like > traffic)" and usually on an edge network with asymmetric bandwidth. > > > > Two additional analyses of use from the download perspective might be > Arris's analysis of the benefits of red and fq over cable head ends: > > > > http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf > > > > and the cable labs work which focused more on the effects of traffic > going upstream which has been discussed fairly extensively here. > > > >> SA: We tried to cover the typical expected traffic over the Internet. > > > > I don't know where you get your data, but my measured edge traffic look= s > nothing like yours. Sure bandwidth wise, theres the netflix spike 3 hours > out of the day but the rest sure isn't HAS. > > > > > >>Most of the traffic is now HAS traffic (as per the sandvine report), so > if only a single stream is present, it is likely to be HAS. > > > >>The closest approximation of a continuous TCP stream, as you mention, > would be a progressive download which can last long enough to look > continuous. These were modeled together with other types of traffic. > > > > You keep saying, download, download, download. I am saying merely pleas= e > ALWAYS try an upload at the same time you are testing downloads > > - be it videoconferencing (which can easily use up that 1.6mbit link), = a > youtube upload, a rsync backup, a scp, anything... > > > > It needent be the crux of your paper! But adding several tests of that > sort does need to inform your total modeling experience. > > > > If you do that much, you we get a feel for how present day systems > interact with things like ack clocking which will do very interesting > things to your "downstream to the couch potato" performance metrics. > > > >> > >> It's not clear from the study that this is a 8mbit down 1mbit up DSL > >> network (?), > >> > >> SA: In the study presented, It was 8M down and 1.6M up - slide 9 > > > > Thx. > > > > > >> > >> nor is it clear if RED is being applied in both directions or only one > direction onl? > >> > >> SA: AQMs (including RED) were only applied in downstream direction - > >> slide 9 > > > > Are you going to follow up with stuff that looks at the upstream > direction? > > > >> (and the results you get from an asymmetric network are quite > >> interesting, particularly in the face of any cross traffic at all) > >> > >> SA: I am not sure what you mean by cross-traffic, the DSL link only > goes to one residence (or business). The typical traffic to that was > modeled. > > > > I do need a consistent name for this that matches people's expectations= . > Does not cross traffic make sense in a DSL context? > > Competing? > > > > I mean someone doing *anything* that involves sending data upstream > other than tiny tcp acks. > > > >> And I do keep hoping that someone will do a study of how prevalent fq > is on dsl devices, I keep accumulating anecdotal data that it's fairly > common. > >> > >>> One of the major reasons why operators chose not to deploy (W)RED was > a number of studies and research which gave operators conflicting message= s > on the value of (W)RED and appropriate parameters to use. Some of these a= re > mentioned in the presentation above. > >>> > >>> In it we show that the previous studies which showed low value for RE= D > used web traffic which had very small file sizes (of the order of 5-10 > packets), which reduces the effectives of all AQMs which work by dropping > or ECN marking of flows to indicate congestion. Today's traffic is compos= ed > of mostly multi-media traffic like HAS or video progressive download whic= h > has much larger file sizes and can be controlled much better with AQMs an= d > in our research we show that RED can be quite effective with this traffic= , > with little tuning needed for typical residential access flows. > > > > I agree, incidentally, that RED is OK for fat non-interactive video > flows over tcp. And I approve of people coming up with ways to tune it > properly for all sorts of environments and fully documenting how to do it= . > > > >> > >> I tend to disagree with this, (well, not the trendline to big video > >> flows) but my own studies are focused on retaining high performance > gaming, voip, and videoconferencing traffic in the face of things like HA= S > video traffic. I would be much happier about your study had you also run > that sort of traffic while testing your video downloads and aqms... and w= hy > is it so hard to get folk to try sfq_codel, etc, while they try everythin= g > else? > >> > >> SA: We did not model smaller flows (in terms of throughput). Small > > > > LATENCY, damn it. > > > >>UDP flows, which I assume all/most of the above would fall in, would > benefit significantly with RED - slide 13 shows much lower average queue > length with RED. > > > > Average queue length is valueless, according to Kathy and Van - and a > few other people, including me. > > > >>Other studies have shown that small UDP flows with lots of TCP traffic > benefit significantly with RED achieving lower packet loss (M. Mays et al= , > =E2=80=9CReasons not to deploy RED=E2=80=9D). > > > > Hmm... you really, really, really need to spend some time playing with > real traffic over real, asymmetric networks that goes in both directions. > > > >>> > >>> Prefer John's proposal of updating 2309 rather than obsoleting, but i= f > we can have some text in Fred's draft acknowledging the large deployment = of > (W)RED and the need to still find good configurations - that may work. I > can volunteer to provide that text. > >>> > >>> -Shahid. > >> > >>> > >>> -----Original Message----- > >>> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Fred Baker > >>> (fred) > >>> Sent: Monday, July 14, 2014 2:06 AM > >>> To: John Leslie > >>> Cc: aqm@ietf.org > >>> Subject: Re: [aqm] Obsoleting RFC 2309 > >>> > >>> > >>> On Jul 3, 2014, at 10:22 AM, John Leslie wrote: > >>> > >>>> It would be possible for someone to argue that restating a > >>>> recommendation from another document weakens both statements; but I > >>>> disagree: We should clearly state what we mean in this document, and > >>>> I believe this wording does so. > >>> > >>> The argument for putting it in there started from the fact that we ar= e > obsoleting 2309, as stated in the charter. I would understand a document > that updates 2309 to be in a strange state if 2309 is itself made histori= c > or obsolete. So we carried the recommendation into this document so it > wouldn't get lost. > >>> > >>> _______________________________________________ > >>> aqm mailing list > >>> aqm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/aqm > >> > >> > >> > >> -- > >> Dave T=C3=A4ht > >> > >> NSFW: > >> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_i > >> ndecent.article > > > > > > > > -- > > Dave T=C3=A4ht > > > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_inde= cent.article > > > > -- > Dave T=C3=A4ht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_inde= cent.article > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a11354864abfabe04fea4e6aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Traffic volume has basically nothing to do with traffic va= lue. =C2=A0Consider the DNS... a tiny fraction of upstream traffic must wor= k in order for anything else to work.

Similarly, a VoIP = call is a tiny amount of traffic, but rather sensitive to loss.

Games can be quite chatty, but even so they are sensiti= ve to latency variability (latency compensation works much better if the la= tency is fairly consistent).

Whereas, if my HD vid= eo stream downgrades one codec notch, that will halve the bandwidth and I w= ill barely notice the difference.

On asymmetric DSL, the upstream value is usually much h= igher than downstream... if I send anything but ACKs I probably care a lot = about whatever that traffic is.


On 17 July 2014 09:30, Dave Taht <dave.= taht@gmail.com> wrote:
On Thu, Jul 17, 2014 at 8:51 AM, Akhtar, Shahid (Shahid)
<shahid.akhtar@alcat= el-lucent.com> wrote:
> Dave,
>
> Web traffic was part of the study - you should be able= to see page load times on slide 12
>
> Lower levels of traffic were also tested (slides 11,12), however the h= ighest impact of AQM was observed at high traffic levels
>
> We included the largest components of Internet traffic (HAS, Web Traff= ic, Video Progressive download) which constitute over 75% of all traffic (<= a href=3D"https://www.sandvine.com/downloads/general/global-internet-phenom= ena/2014/1h-2014-global-internet-phenomena-report.pdf" target=3D"_blank">ht= tps://www.sandvine.com/downloads/general/global-internet-phenomena/2014/1h-= 2014-global-internet-phenomena-report.pdf) at peak hour

I continually am mind-blown by statistical legerdemain.

Just look at the size of the ps3/ps4/xbox gamer market for example. I
don't care about the amount of traffic at all. I care that in a
all-night aming session or a hour long videconference that the
relatively sparse latency sensitive packets get through - in both
directions - regardless of what else is going on on the network.

> The study presented in Nov was our initial work and is not the only co= mponent in development of any configuration guidelines

Got any gamers helping write your specs?

>
> -Shahid.
>
> -----Original Message-----
> From: Dave Taht [mailto:dave.ta= ht@gmail.com]
> Sent: Tuesday, July 15, 2014 4:00 PM
> To: Akhtar, Shahid (Shahid)
> Cc: Fred Baker (fred); John Leslie; aq= m@ietf.org
> Subject: Sane analysis of "typical traffic"
>
> changing the title as this is not relevant to the aqm document...
>
> ... but to an attitude that is driving me absolutely crazy.
>
> On Tue, Jul 15, 2014 at 10:46 AM, Akhtar, Shahid (Shahid) <shahid.akhtar@alcatel-lucent.c= om> wrote:
>> Dave,
>>
>> The message of the results that we presented in November is that i= t is possible, with currently deployed access hardware, to configure RED so= that it consistently improves the end user experience of common network se= rvices over Tail-Drop (which is most often configured), and that this impro= vement can be achieved with a fixed set of RED configuration guidelines. >>
>> We did not run experiments with sfq_codel because it is not deploy= ed in access networks today. We ran experiments with plain CoDel to underst= and the difference between a well-configured RED and a more recent single-b= ucket AQM in our target scenarios, and as reported, didn't observe sign= ificant differences in application QoE.
>
> Your "application" was a bunch of video streams. Not web tra= ffic, not voip, not, gaming, not bittorrent, not a family of four doing a c= ombination of these things, nor a small business that isn't going to us= e HAS at all.
>
> Please don't over generalize your results. "RED proven suitab= le for family of couch potatoes surfing the internet and watching 4 movies = at once over the internet but not 5, at 8mbit/sec" might have been a b= etter title for this paper.
>
> In this fictional family, just one kid under the stair, trying to do s= omething useful, interactive and/or fun, can both wreck the couch potatoes&= #39; internet experience, and have his own, wrecked also.
>
>>
>> Additional inline clarifications below.
>>
>> -Shahid.
>>
>> -----Original Message-----
>> From: Dave Taht [mailto:dav= e.taht@gmail.com]
>> Sent: Monday, July 14, 2014 2:00 PM
>> To: Akhtar, Shahid (Shahid)
>> Cc: Fred Baker (fred); John Leslie; aqm@ietf.org
>> Subject: Re: [aqm] Obsoleting RFC 2309
>>
>> On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) <shahid.akhtar@alcatel-lucen= t.com> wrote:
>>> Hi Fred, All,
>>>
>>> Let me an additional thought to this issue.
>>>
>>> Given that (W)RED has been deployed extensively in operators&#= 39; networks, and most vendors are still shipping equipment with (W)RED, co= ncern is that obsoleting 2309 would discourage research on trying to find g= ood configurations to make (W)RED work.
>>>
>>> We had previously given a presentation at the ICCRG on why RED= can still provide value to operators (http://www.ietf.o= rg/proceedings/88/slides/slides-88-iccrg-0.pdf). We have a paper at Glo= becom 2014 that explains this study much better, but I cannot share a link = to it until the proceedings are available.
>>
>> My problem with the above preso and no doubt the resulting study i= s
>> that it doesn't appear cover the classic, most basic, bufferbl= oat
>> scenario, which is
>>
>> "1 stream up, 1 stream down, one ping (or some form of voip-l= ike traffic)" and usually on an edge network with asymmetric bandwidth= .
>
> Two additional analyses of use from the download perspective might be = Arris's analysis of the benefits of red and fq over cable head ends: >
> http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan= _Paper.pdf
>
> and the cable labs work which focused more on the effects of traffic g= oing upstream which has been discussed fairly extensively here.
>
>> SA: We tried to cover the typical expected traffic over the Intern= et.
>
> I don't know where you get your data, but my measured edge traffic= looks nothing like yours. Sure bandwidth wise, theres the netflix spike 3 = hours out of the day but the rest sure isn't HAS.
>
>
>>Most of the traffic is now HAS traffic (as per the sandvine report)= , so if only a single stream is present, it is likely to be HAS.
>
>>The closest approximation of a continuous TCP stream, as you mentio= n, would be a progressive download which can last long enough to look conti= nuous. These were modeled together with other types of traffic.
>
> You keep saying, download, download, download. I am saying merely plea= se ALWAYS try an upload at the same time you are testing downloads
> - be it videoconferencing (which can easily use up that 1.6mbit link),= a youtube upload, a rsync backup, a scp, anything...
>
> It needent be the crux of your paper! But adding several tests of that= sort does need to inform your total modeling experience.
>
> If you do that much, you we get a feel for how present day systems int= eract with things like ack clocking which will do very interesting things t= o your "downstream to the couch potato" performance metrics.
>
>>
>> It's not clear from the study that this is a 8mbit down 1mbit = up DSL
>> network (?),
>>
>> SA: In the study presented, It was 8M down and 1.6M up - slide 9 >
> Thx.
>
>
>>
>> nor is it clear if RED is being applied in both directions or only= one direction onl?
>>
>> SA: AQMs (including RED) were only applied in downstream direction= -
>> slide 9
>
> Are you going to follow up with stuff that looks at the upstream direc= tion?
>
>> (and the results you get from an asymmetric network are quite
>> interesting, particularly in the face of any cross traffic at all)=
>>
>> SA: I am not sure what you mean by cross-traffic, the DSL link onl= y goes to one residence (or business). The typical traffic to that was mode= led.
>
> I do need a consistent name for this that matches people's expecta= tions. Does not cross traffic make sense in a DSL context?
> Competing?
>
> I mean someone doing *anything* that involves sending data upstream ot= her than tiny tcp acks.
>
>> And I do keep hoping that someone will do a study of how prevalent= fq is on dsl devices, I keep accumulating anecdotal data that it's fai= rly common.
>>
>>> One of the major reasons why operators chose not to deploy (W)= RED was a number of studies and research which gave operators conflicting m= essages on the value of (W)RED and appropriate parameters to use. Some of t= hese are mentioned in the presentation above.
>>>
>>> In it we show that the previous studies which showed low value= for RED used web traffic which had very small file sizes (of the order of = 5-10 packets), which reduces the effectives of all AQMs which work by dropp= ing or ECN marking of flows to indicate congestion. Today's traffic is = composed of mostly multi-media traffic like HAS or video progressive downlo= ad which has much larger file sizes and can be controlled much better with = AQMs and in our research we show that RED can be quite effective with this = traffic, with little tuning needed for typical residential access flows. >
> I agree, incidentally, that RED is OK for fat non-interactive video fl= ows over tcp. And I approve of people coming up with ways to tune it proper= ly for all sorts of environments and fully documenting how to do it.
>
>>
>> I tend to disagree with this, (well, not the trendline to big vide= o
>> flows) but my own studies are focused on retaining high performanc= e gaming, voip, and videoconferencing traffic in the face of things like HA= S video traffic. I would be much happier about your study had you also run = that sort of traffic while testing your video downloads and aqms... and why= is it so hard to get folk to try sfq_codel, etc, while they try everything= else?
>>
>> SA: We did not model smaller flows (in terms of throughput). Small=
>
> LATENCY, damn it.
>
>>UDP flows, which I assume all/most of the above would fall in, woul= d benefit significantly with RED - slide 13 shows much lower average queue = length with RED.
>
> Average queue length is valueless, according to Kathy and Van - and a = few other people, including me.
>
>>Other studies have shown that small UDP flows with lots of TCP traf= fic benefit significantly with RED achieving lower packet loss (M. Mays et = al, =E2=80=9CReasons not to deploy RED=E2=80=9D).
>
> Hmm... you really, really, really need to spend some time playing with= real traffic over real, asymmetric networks that goes in both directions.<= br> >
>>>
>>> Prefer John's proposal of updating 2309 rather than obsole= ting, but if we can have some text in Fred's draft acknowledging the la= rge deployment of (W)RED and the need to still find good configurations - t= hat may work. I can volunteer to provide that text.
>>>
>>> -Shahid.
>>
>>>
>>> -----Original Message-----
>>> From: aqm [mailto:aqm-= bounces@ietf.org] On Behalf Of Fred Baker
>>> (fred)
>>> Sent: Monday, July 14, 2014 2:06 AM
>>> To: John Leslie
>>> Cc: aqm@ietf.org
>>> Subject: Re: [aqm] Obsoleting RFC 2309
>>>
>>>
>>> On Jul 3, 2014, at 10:22 AM, John Leslie <john@jlc.net> wrote:
>>>
>>>> It would be possible for someone to argue that restating a=
>>>> recommendation from another document weakens both statemen= ts; but I
>>>> disagree: We should clearly state what we mean in this doc= ument, and
>>>> I believe this wording does so.
>>>
>>> The argument for putting it in there started from the fact tha= t we are obsoleting 2309, as stated in the charter. I would understand a do= cument that updates 2309 to be in a strange state if 2309 is itself made hi= storic or obsolete. So we carried the recommendation into this document so = it wouldn't get lost.
>>>
>>> _______________________________________________
>>> aqm mailing list
>>> aqm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/aqm
>>
>>
>>
>> --
>> Dave T=C3=A4ht
>>
>> NSFW:
>> https://w2.eff.org/Censorship/Internet_c= ensorship_bills/russell_0296_i
>> ndecent.article
>
>
>
> --
> Dave T=C3=A4ht
>
> NSFW: https://w2.eff.org/Cens= orship/Internet_censorship_bills/russell_0296_indecent.article



--
Dave T=C3=A4ht

NSFW: https://w2.eff.org/Censorshi= p/Internet_censorship_bills/russell_0296_indecent.article

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



--
=
Andrew McGre= gor=C2=A0|=C2=A0SRE= =C2=A0|=C2=A0andrewmcgr@google.com= =C2=A0|=C2=A0+61 4 10= 71 2221
--001a11354864abfabe04fea4e6aa-- From nobody Mon Jul 21 05:34:03 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C7D1B2CE8 for ; Mon, 21 Jul 2014 05:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN9jzP-BN_m7 for ; Mon, 21 Jul 2014 05:33:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E701B2CA9 for ; Mon, 21 Jul 2014 05:33:56 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6LCXphK024403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 07:33:52 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s6LCXlh2024346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 08:33:50 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 21 Jul 2014 08:33:17 -0400 From: "Akhtar, Shahid (Shahid)" To: Andrew Mcgregor , Dave Taht Thread-Topic: [aqm] Sane analysis of "typical traffic" Thread-Index: AQHPpE/cC4YFjPQv4EGeBBcOFAboOJuqYVZw Date: Mon, 21 Jul 2014 12:33:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_C0611F522A6FA9498A044C36073E49659D804284US70UWXCHMBA01z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/k8TTUOe8MUjXKCQe2HHi0XQMQMM Cc: John Leslie , "aqm@ietf.org" , "Fred Baker \(fred\)" Subject: Re: [aqm] Sane analysis of "typical traffic" X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2014 12:34:01 -0000 --_000_C0611F522A6FA9498A044C36073E49659D804284US70UWXCHMBA01z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkIHRoYXQgYXBwbGljYXRpb25zIHdoaWNoIGNvbnN0aXR1dGUgYSBzbWFsbCBhbW91bnQg b2YgdHJhZmZpYyBtYXkgY2FycnkgYSBsYXJnZSB2YWx1ZSB0byB0aGUgZW5kIHVzZXIuIFRoZSBv YmplY3RpdmUgb2YgbW9kZWxpbmcgdGhlIGxhcmdlc3QgY29tcG9uZW50cyB3YXMgdG8gbW9kZWwg dGhlIG1ham9yaXR5IG9mIFRDUCB0cmFmZmljLiBUaGUgYW1vdW50IG9mIFZvSVAgdHJhZmZpYyBh bmQgZ2FtaW5nIHRyYWZmaWMsIGZvciBleGFtcGxlIGlzIG5vdCBsaXN0ZWQgaW5kaXZpZHVhbGx5 IGluIHRoZSByZWZlcmVuY2VkIFNhbmRyaW5lIHJlcG9ydCAocmVwb3J0IGxpc3RzIGNvbXBvbmVu dHMgbW9yZSB0aGFuIDElKSwgc28gdGhlc2UgYXJlIGV4cGVjdGVkIHRvIGJlIGEgc21hbGwgcG9y dGlvbiBvZiB0aGUgdG90YWwgZG93bmxvYWQgdHJhZmZpYy4gVGhlIGltcGFjdCBvZiB0aGlzIHRy YWZmaWMgaXMgZXhwZWN0ZWQgdG8gYmUgbGl0dGxlL25lZ2xpZ2libGUgb24gdGhlIGxhcmdlIFRD UCBjb21wb25lbnRzLg0KDQpUaGUgaW1wYWN0IG9mIHRoZSBsYXJnZSBUQ1AgdHJhZmZpYyBvbiB0 aGUgc21hbGwgVURQIGZsb3dzIChWb0lQLCBnYW1pbmcsIEROUyBhcmUgYWxsIGdvb2QgZXhhbXBs ZXMpIHdpdGgvd2l0aG91dCBBUU0gaXMgYW5vdGhlciBpc3N1ZS4gVGhpcyB3YXMgbm90IHN0dWRp ZWQgaW4gdGhlIHN0dWR5IHByZXNlbnRlZCBsYXN0IE5vdi4gSG93ZXZlciwgdGhpcyBpc3N1ZSBo YXMgYmVlbiBzdHVkaWVkIHRvIHNvbWUgZXh0ZW50IGVhcmxpZXIgKHNlZSBNLiBNYXlzIGV0IGFs LCDigJxSZWFzb25zIG5vdCB0byBkZXBsb3kgUkVE4oCdKSwgd2hlcmUgdGhlIGF1dGhvcnMgZm91 bmQgYSA0IHRpbWVzIHJlZHVjdGlvbiBpbiBVRFAgcGFja2V0IGxvc3Mgd2l0aCBsb3RzIG9mIFRD UCB0cmFmZmljLiBUaGlzIGlzIHNvbWV3aGF0IGludHVpdGl2ZSBhcyB0aGUgVURQIGZsb3dzIGFy ZSBsZXNzIGxpa2VseSB0byBmaW5kIHRoZSBxdWV1ZSB0byBiZSBmdWxsIHdpdGggQVFNLg0KDQpG cm9tOiBBbmRyZXcgTWNncmVnb3IgW21haWx0bzphbmRyZXdtY2dyQGdvb2dsZS5jb21dDQpTZW50 OiBTdW5kYXksIEp1bHkgMjAsIDIwMTQgMjoyMiBQTQ0KVG86IERhdmUgVGFodA0KQ2M6IEFraHRh ciwgU2hhaGlkIChTaGFoaWQpOyBhcW1AaWV0Zi5vcmc8bWFpbHRvOmFxbUBpZXRmLm9yZz47IEZy ZWQgQmFrZXIgKGZyZWQpOyBKb2huIExlc2xpZQ0KU3ViamVjdDogUmU6IFthcW1dIFNhbmUgYW5h bHlzaXMgb2YgInR5cGljYWwgdHJhZmZpYyINCg0KVHJhZmZpYyB2b2x1bWUgaGFzIGJhc2ljYWxs eSBub3RoaW5nIHRvIGRvIHdpdGggdHJhZmZpYyB2YWx1ZS4gIENvbnNpZGVyIHRoZSBETlMuLi4g YSB0aW55IGZyYWN0aW9uIG9mIHVwc3RyZWFtIHRyYWZmaWMgbXVzdCB3b3JrIGluIG9yZGVyIGZv ciBhbnl0aGluZyBlbHNlIHRvIHdvcmsuDQoNClNpbWlsYXJseSwgYSBWb0lQIGNhbGwgaXMgYSB0 aW55IGFtb3VudCBvZiB0cmFmZmljLCBidXQgcmF0aGVyIHNlbnNpdGl2ZSB0byBsb3NzLg0KDQpH YW1lcyBjYW4gYmUgcXVpdGUgY2hhdHR5LCBidXQgZXZlbiBzbyB0aGV5IGFyZSBzZW5zaXRpdmUg dG8gbGF0ZW5jeSB2YXJpYWJpbGl0eSAobGF0ZW5jeSBjb21wZW5zYXRpb24gd29ya3MgbXVjaCBi ZXR0ZXIgaWYgdGhlIGxhdGVuY3kgaXMgZmFpcmx5IGNvbnNpc3RlbnQpLg0KDQpXaGVyZWFzLCBp ZiBteSBIRCB2aWRlbyBzdHJlYW0gZG93bmdyYWRlcyBvbmUgY29kZWMgbm90Y2gsIHRoYXQgd2ls bCBoYWx2ZSB0aGUgYmFuZHdpZHRoIGFuZCBJIHdpbGwgYmFyZWx5IG5vdGljZSB0aGUgZGlmZmVy ZW5jZS4NCg0KT24gYXN5bW1ldHJpYyBEU0wsIHRoZSB1cHN0cmVhbSB2YWx1ZSBpcyB1c3VhbGx5 IG11Y2ggaGlnaGVyIHRoYW4gZG93bnN0cmVhbS4uLiBpZiBJIHNlbmQgYW55dGhpbmcgYnV0IEFD S3MgSSBwcm9iYWJseSBjYXJlIGEgbG90IGFib3V0IHdoYXRldmVyIHRoYXQgdHJhZmZpYyBpcy4N Cg0KT24gMTcgSnVseSAyMDE0IDA5OjMwLCBEYXZlIFRhaHQgPGRhdmUudGFodEBnbWFpbC5jb208 bWFpbHRvOmRhdmUudGFodEBnbWFpbC5jb20+PiB3cm90ZToNCk9uIFRodSwgSnVsIDE3LCAyMDE0 IGF0IDg6NTEgQU0sIEFraHRhciwgU2hhaGlkIChTaGFoaWQpDQo8c2hhaGlkLmFraHRhckBhbGNh dGVsLWx1Y2VudC5jb208bWFpbHRvOnNoYWhpZC5ha2h0YXJAYWxjYXRlbC1sdWNlbnQuY29tPj4g d3JvdGU6DQo+IERhdmUsDQo+DQo+IFdlYiB0cmFmZmljIHdhcyBwYXJ0IG9mIHRoZSBzdHVkeSAt IHlvdSBzaG91bGQgYmUgYWJsZSB0byBzZWUgcGFnZSBsb2FkIHRpbWVzIG9uIHNsaWRlIDEyDQo+ DQo+IExvd2VyIGxldmVscyBvZiB0cmFmZmljIHdlcmUgYWxzbyB0ZXN0ZWQgKHNsaWRlcyAxMSwx MiksIGhvd2V2ZXIgdGhlIGhpZ2hlc3QgaW1wYWN0IG9mIEFRTSB3YXMgb2JzZXJ2ZWQgYXQgaGln aCB0cmFmZmljIGxldmVscw0KPg0KPiBXZSBpbmNsdWRlZCB0aGUgbGFyZ2VzdCBjb21wb25lbnRz IG9mIEludGVybmV0IHRyYWZmaWMgKEhBUywgV2ViIFRyYWZmaWMsIFZpZGVvIFByb2dyZXNzaXZl IGRvd25sb2FkKSB3aGljaCBjb25zdGl0dXRlIG92ZXIgNzUlIG9mIGFsbCB0cmFmZmljIChodHRw czovL3d3dy5zYW5kdmluZS5jb20vZG93bmxvYWRzL2dlbmVyYWwvZ2xvYmFsLWludGVybmV0LXBo ZW5vbWVuYS8yMDE0LzFoLTIwMTQtZ2xvYmFsLWludGVybmV0LXBoZW5vbWVuYS1yZXBvcnQucGRm KSBhdCBwZWFrIGhvdXINCkkgY29udGludWFsbHkgYW0gbWluZC1ibG93biBieSBzdGF0aXN0aWNh bCBsZWdlcmRlbWFpbi4NCg0KSnVzdCBsb29rIGF0IHRoZSBzaXplIG9mIHRoZSBwczMvcHM0L3hi b3ggZ2FtZXIgbWFya2V0IGZvciBleGFtcGxlLiBJDQpkb24ndCBjYXJlIGFib3V0IHRoZSBhbW91 bnQgb2YgdHJhZmZpYyBhdCBhbGwuIEkgY2FyZSB0aGF0IGluIGENCmFsbC1uaWdodCBhbWluZyBz ZXNzaW9uIG9yIGEgaG91ciBsb25nIHZpZGVjb25mZXJlbmNlIHRoYXQgdGhlDQpyZWxhdGl2ZWx5 IHNwYXJzZSBsYXRlbmN5IHNlbnNpdGl2ZSBwYWNrZXRzIGdldCB0aHJvdWdoIC0gaW4gYm90aA0K ZGlyZWN0aW9ucyAtIHJlZ2FyZGxlc3Mgb2Ygd2hhdCBlbHNlIGlzIGdvaW5nIG9uIG9uIHRoZSBu ZXR3b3JrLg0KDQo+IFRoZSBzdHVkeSBwcmVzZW50ZWQgaW4gTm92IHdhcyBvdXIgaW5pdGlhbCB3 b3JrIGFuZCBpcyBub3QgdGhlIG9ubHkgY29tcG9uZW50IGluIGRldmVsb3BtZW50IG9mIGFueSBj b25maWd1cmF0aW9uIGd1aWRlbGluZXMNCkdvdCBhbnkgZ2FtZXJzIGhlbHBpbmcgd3JpdGUgeW91 ciBzcGVjcz8NCg0KPg0KPiAtU2hhaGlkLg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBEYXZlIFRhaHQgW21haWx0bzpkYXZlLnRhaHRAZ21haWwuY29tPG1haWx0bzpk YXZlLnRhaHRAZ21haWwuY29tPl0NCj4gU2VudDogVHVlc2RheSwgSnVseSAxNSwgMjAxNCA0OjAw IFBNDQo+IFRvOiBBa2h0YXIsIFNoYWhpZCAoU2hhaGlkKQ0KPiBDYzogRnJlZCBCYWtlciAoZnJl ZCk7IEpvaG4gTGVzbGllOyBhcW1AaWV0Zi5vcmc8bWFpbHRvOmFxbUBpZXRmLm9yZz4NCj4gU3Vi amVjdDogU2FuZSBhbmFseXNpcyBvZiAidHlwaWNhbCB0cmFmZmljIg0KPg0KPiBjaGFuZ2luZyB0 aGUgdGl0bGUgYXMgdGhpcyBpcyBub3QgcmVsZXZhbnQgdG8gdGhlIGFxbSBkb2N1bWVudC4uLg0K Pg0KPiAuLi4gYnV0IHRvIGFuIGF0dGl0dWRlIHRoYXQgaXMgZHJpdmluZyBtZSBhYnNvbHV0ZWx5 IGNyYXp5Lg0KPg0KPiBPbiBUdWUsIEp1bCAxNSwgMjAxNCBhdCAxMDo0NiBBTSwgQWtodGFyLCBT aGFoaWQgKFNoYWhpZCkgPHNoYWhpZC5ha2h0YXJAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpz aGFoaWQuYWtodGFyQGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdyb3RlOg0KPj4gRGF2ZSwNCj4+DQo+ PiBUaGUgbWVzc2FnZSBvZiB0aGUgcmVzdWx0cyB0aGF0IHdlIHByZXNlbnRlZCBpbiBOb3ZlbWJl ciBpcyB0aGF0IGl0IGlzIHBvc3NpYmxlLCB3aXRoIGN1cnJlbnRseSBkZXBsb3llZCBhY2Nlc3Mg aGFyZHdhcmUsIHRvIGNvbmZpZ3VyZSBSRUQgc28gdGhhdCBpdCBjb25zaXN0ZW50bHkgaW1wcm92 ZXMgdGhlIGVuZCB1c2VyIGV4cGVyaWVuY2Ugb2YgY29tbW9uIG5ldHdvcmsgc2VydmljZXMgb3Zl ciBUYWlsLURyb3AgKHdoaWNoIGlzIG1vc3Qgb2Z0ZW4gY29uZmlndXJlZCksIGFuZCB0aGF0IHRo aXMgaW1wcm92ZW1lbnQgY2FuIGJlIGFjaGlldmVkIHdpdGggYSBmaXhlZCBzZXQgb2YgUkVEIGNv bmZpZ3VyYXRpb24gZ3VpZGVsaW5lcy4NCj4+DQo+PiBXZSBkaWQgbm90IHJ1biBleHBlcmltZW50 cyB3aXRoIHNmcV9jb2RlbCBiZWNhdXNlIGl0IGlzIG5vdCBkZXBsb3llZCBpbiBhY2Nlc3MgbmV0 d29ya3MgdG9kYXkuIFdlIHJhbiBleHBlcmltZW50cyB3aXRoIHBsYWluIENvRGVsIHRvIHVuZGVy c3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHdlbGwtY29uZmlndXJlZCBSRUQgYW5kIGEg bW9yZSByZWNlbnQgc2luZ2xlLWJ1Y2tldCBBUU0gaW4gb3VyIHRhcmdldCBzY2VuYXJpb3MsIGFu ZCBhcyByZXBvcnRlZCwgZGlkbid0IG9ic2VydmUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgaW4g YXBwbGljYXRpb24gUW9FLg0KPg0KPiBZb3VyICJhcHBsaWNhdGlvbiIgd2FzIGEgYnVuY2ggb2Yg dmlkZW8gc3RyZWFtcy4gTm90IHdlYiB0cmFmZmljLCBub3Qgdm9pcCwgbm90LCBnYW1pbmcsIG5v dCBiaXR0b3JyZW50LCBub3QgYSBmYW1pbHkgb2YgZm91ciBkb2luZyBhIGNvbWJpbmF0aW9uIG9m IHRoZXNlIHRoaW5ncywgbm9yIGEgc21hbGwgYnVzaW5lc3MgdGhhdCBpc24ndCBnb2luZyB0byB1 c2UgSEFTIGF0IGFsbC4NCj4NCj4gUGxlYXNlIGRvbid0IG92ZXIgZ2VuZXJhbGl6ZSB5b3VyIHJl c3VsdHMuICJSRUQgcHJvdmVuIHN1aXRhYmxlIGZvciBmYW1pbHkgb2YgY291Y2ggcG90YXRvZXMg c3VyZmluZyB0aGUgaW50ZXJuZXQgYW5kIHdhdGNoaW5nIDQgbW92aWVzIGF0IG9uY2Ugb3ZlciB0 aGUgaW50ZXJuZXQgYnV0IG5vdCA1LCBhdCA4bWJpdC9zZWMiIG1pZ2h0IGhhdmUgYmVlbiBhIGJl dHRlciB0aXRsZSBmb3IgdGhpcyBwYXBlci4NCj4NCj4gSW4gdGhpcyBmaWN0aW9uYWwgZmFtaWx5 LCBqdXN0IG9uZSBraWQgdW5kZXIgdGhlIHN0YWlyLCB0cnlpbmcgdG8gZG8gc29tZXRoaW5nIHVz ZWZ1bCwgaW50ZXJhY3RpdmUgYW5kL29yIGZ1biwgY2FuIGJvdGggd3JlY2sgdGhlIGNvdWNoIHBv dGF0b2VzJyBpbnRlcm5ldCBleHBlcmllbmNlLCBhbmQgaGF2ZSBoaXMgb3duLCB3cmVja2VkIGFs c28uDQo+DQo+Pg0KPj4gQWRkaXRpb25hbCBpbmxpbmUgY2xhcmlmaWNhdGlvbnMgYmVsb3cuDQo+ Pg0KPj4gLVNoYWhpZC4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogRGF2ZSBUYWh0IFttYWlsdG86ZGF2ZS50YWh0QGdtYWlsLmNvbTxtYWlsdG86ZGF2ZS50YWh0 QGdtYWlsLmNvbT5dDQo+PiBTZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMjowMCBQTQ0KPj4g VG86IEFraHRhciwgU2hhaGlkIChTaGFoaWQpDQo+PiBDYzogRnJlZCBCYWtlciAoZnJlZCk7IEpv aG4gTGVzbGllOyBhcW1AaWV0Zi5vcmc8bWFpbHRvOmFxbUBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6 IFJlOiBbYXFtXSBPYnNvbGV0aW5nIFJGQyAyMzA5DQo+Pg0KPj4gT24gTW9uLCBKdWwgMTQsIDIw MTQgYXQgMTE6MDggQU0sIEFraHRhciwgU2hhaGlkIChTaGFoaWQpIDxzaGFoaWQuYWtodGFyQGFs Y2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86c2hhaGlkLmFraHRhckBhbGNhdGVsLWx1Y2VudC5jb20+ PiB3cm90ZToNCj4+PiBIaSBGcmVkLCBBbGwsDQo+Pj4NCj4+PiBMZXQgbWUgYW4gYWRkaXRpb25h bCB0aG91Z2h0IHRvIHRoaXMgaXNzdWUuDQo+Pj4NCj4+PiBHaXZlbiB0aGF0IChXKVJFRCBoYXMg YmVlbiBkZXBsb3llZCBleHRlbnNpdmVseSBpbiBvcGVyYXRvcnMnIG5ldHdvcmtzLCBhbmQgbW9z dCB2ZW5kb3JzIGFyZSBzdGlsbCBzaGlwcGluZyBlcXVpcG1lbnQgd2l0aCAoVylSRUQsIGNvbmNl cm4gaXMgdGhhdCBvYnNvbGV0aW5nIDIzMDkgd291bGQgZGlzY291cmFnZSByZXNlYXJjaCBvbiB0 cnlpbmcgdG8gZmluZCBnb29kIGNvbmZpZ3VyYXRpb25zIHRvIG1ha2UgKFcpUkVEIHdvcmsuDQo+ Pj4NCj4+PiBXZSBoYWQgcHJldmlvdXNseSBnaXZlbiBhIHByZXNlbnRhdGlvbiBhdCB0aGUgSUND Ukcgb24gd2h5IFJFRCBjYW4gc3RpbGwgcHJvdmlkZSB2YWx1ZSB0byBvcGVyYXRvcnMgKGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODgvc2xpZGVzL3NsaWRlcy04OC1pY2NyZy0wLnBk ZikuIFdlIGhhdmUgYSBwYXBlciBhdCBHbG9iZWNvbSAyMDE0IHRoYXQgZXhwbGFpbnMgdGhpcyBz dHVkeSBtdWNoIGJldHRlciwgYnV0IEkgY2Fubm90IHNoYXJlIGEgbGluayB0byBpdCB1bnRpbCB0 aGUgcHJvY2VlZGluZ3MgYXJlIGF2YWlsYWJsZS4NCj4+DQo+PiBNeSBwcm9ibGVtIHdpdGggdGhl IGFib3ZlIHByZXNvIGFuZCBubyBkb3VidCB0aGUgcmVzdWx0aW5nIHN0dWR5IGlzDQo+PiB0aGF0 IGl0IGRvZXNuJ3QgYXBwZWFyIGNvdmVyIHRoZSBjbGFzc2ljLCBtb3N0IGJhc2ljLCBidWZmZXJi bG9hdA0KPj4gc2NlbmFyaW8sIHdoaWNoIGlzDQo+Pg0KPj4gIjEgc3RyZWFtIHVwLCAxIHN0cmVh bSBkb3duLCBvbmUgcGluZyAob3Igc29tZSBmb3JtIG9mIHZvaXAtbGlrZSB0cmFmZmljKSIgYW5k IHVzdWFsbHkgb24gYW4gZWRnZSBuZXR3b3JrIHdpdGggYXN5bW1ldHJpYyBiYW5kd2lkdGguDQo+ DQo+IFR3byBhZGRpdGlvbmFsIGFuYWx5c2VzIG9mIHVzZSBmcm9tIHRoZSBkb3dubG9hZCBwZXJz cGVjdGl2ZSBtaWdodCBiZSBBcnJpcydzIGFuYWx5c2lzIG9mIHRoZSBiZW5lZml0cyBvZiByZWQg YW5kIGZxIG92ZXIgY2FibGUgaGVhZCBlbmRzOg0KPg0KPiBodHRwOi8vc25hcG9uLmxhYi5idWZm ZXJibG9hdC5uZXQvfmQvdHJpbWZhdC9DbG9vbmFuX1BhcGVyLnBkZg0KPg0KPiBhbmQgdGhlIGNh YmxlIGxhYnMgd29yayB3aGljaCBmb2N1c2VkIG1vcmUgb24gdGhlIGVmZmVjdHMgb2YgdHJhZmZp YyBnb2luZyB1cHN0cmVhbSB3aGljaCBoYXMgYmVlbiBkaXNjdXNzZWQgZmFpcmx5IGV4dGVuc2l2 ZWx5IGhlcmUuDQo+DQo+PiBTQTogV2UgdHJpZWQgdG8gY292ZXIgdGhlIHR5cGljYWwgZXhwZWN0 ZWQgdHJhZmZpYyBvdmVyIHRoZSBJbnRlcm5ldC4NCj4NCj4gSSBkb24ndCBrbm93IHdoZXJlIHlv dSBnZXQgeW91ciBkYXRhLCBidXQgbXkgbWVhc3VyZWQgZWRnZSB0cmFmZmljIGxvb2tzIG5vdGhp bmcgbGlrZSB5b3Vycy4gU3VyZSBiYW5kd2lkdGggd2lzZSwgdGhlcmVzIHRoZSBuZXRmbGl4IHNw aWtlIDMgaG91cnMgb3V0IG9mIHRoZSBkYXkgYnV0IHRoZSByZXN0IHN1cmUgaXNuJ3QgSEFTLg0K Pg0KPg0KPj5Nb3N0IG9mIHRoZSB0cmFmZmljIGlzIG5vdyBIQVMgdHJhZmZpYyAoYXMgcGVyIHRo ZSBzYW5kdmluZSByZXBvcnQpLCBzbyBpZiBvbmx5IGEgc2luZ2xlIHN0cmVhbSBpcyBwcmVzZW50 LCBpdCBpcyBsaWtlbHkgdG8gYmUgSEFTLg0KPg0KPj5UaGUgY2xvc2VzdCBhcHByb3hpbWF0aW9u IG9mIGEgY29udGludW91cyBUQ1Agc3RyZWFtLCBhcyB5b3UgbWVudGlvbiwgd291bGQgYmUgYSBw cm9ncmVzc2l2ZSBkb3dubG9hZCB3aGljaCBjYW4gbGFzdCBsb25nIGVub3VnaCB0byBsb29rIGNv bnRpbnVvdXMuIFRoZXNlIHdlcmUgbW9kZWxlZCB0b2dldGhlciB3aXRoIG90aGVyIHR5cGVzIG9m IHRyYWZmaWMuDQo+DQo+IFlvdSBrZWVwIHNheWluZywgZG93bmxvYWQsIGRvd25sb2FkLCBkb3du bG9hZC4gSSBhbSBzYXlpbmcgbWVyZWx5IHBsZWFzZSBBTFdBWVMgdHJ5IGFuIHVwbG9hZCBhdCB0 aGUgc2FtZSB0aW1lIHlvdSBhcmUgdGVzdGluZyBkb3dubG9hZHMNCj4gLSBiZSBpdCB2aWRlb2Nv bmZlcmVuY2luZyAod2hpY2ggY2FuIGVhc2lseSB1c2UgdXAgdGhhdCAxLjZtYml0IGxpbmspLCBh IHlvdXR1YmUgdXBsb2FkLCBhIHJzeW5jIGJhY2t1cCwgYSBzY3AsIGFueXRoaW5nLi4uDQo+DQo+ IEl0IG5lZWRlbnQgYmUgdGhlIGNydXggb2YgeW91ciBwYXBlciEgQnV0IGFkZGluZyBzZXZlcmFs IHRlc3RzIG9mIHRoYXQgc29ydCBkb2VzIG5lZWQgdG8gaW5mb3JtIHlvdXIgdG90YWwgbW9kZWxp bmcgZXhwZXJpZW5jZS4NCj4NCj4gSWYgeW91IGRvIHRoYXQgbXVjaCwgeW91IHdlIGdldCBhIGZl ZWwgZm9yIGhvdyBwcmVzZW50IGRheSBzeXN0ZW1zIGludGVyYWN0IHdpdGggdGhpbmdzIGxpa2Ug YWNrIGNsb2NraW5nIHdoaWNoIHdpbGwgZG8gdmVyeSBpbnRlcmVzdGluZyB0aGluZ3MgdG8geW91 ciAiZG93bnN0cmVhbSB0byB0aGUgY291Y2ggcG90YXRvIiBwZXJmb3JtYW5jZSBtZXRyaWNzLg0K Pg0KPj4NCj4+IEl0J3Mgbm90IGNsZWFyIGZyb20gdGhlIHN0dWR5IHRoYXQgdGhpcyBpcyBhIDht Yml0IGRvd24gMW1iaXQgdXAgRFNMDQo+PiBuZXR3b3JrICg/KSwNCj4+DQo+PiBTQTogSW4gdGhl IHN0dWR5IHByZXNlbnRlZCwgSXQgd2FzIDhNIGRvd24gYW5kIDEuNk0gdXAgLSBzbGlkZSA5DQo+ DQo+IFRoeC4NCj4NCj4NCj4+DQo+PiBub3IgaXMgaXQgY2xlYXIgaWYgUkVEIGlzIGJlaW5nIGFw cGxpZWQgaW4gYm90aCBkaXJlY3Rpb25zIG9yIG9ubHkgb25lIGRpcmVjdGlvbiBvbmw/DQo+Pg0K Pj4gU0E6IEFRTXMgKGluY2x1ZGluZyBSRUQpIHdlcmUgb25seSBhcHBsaWVkIGluIGRvd25zdHJl YW0gZGlyZWN0aW9uIC0NCj4+IHNsaWRlIDkNCj4NCj4gQXJlIHlvdSBnb2luZyB0byBmb2xsb3cg dXAgd2l0aCBzdHVmZiB0aGF0IGxvb2tzIGF0IHRoZSB1cHN0cmVhbSBkaXJlY3Rpb24/DQo+DQo+ PiAoYW5kIHRoZSByZXN1bHRzIHlvdSBnZXQgZnJvbSBhbiBhc3ltbWV0cmljIG5ldHdvcmsgYXJl IHF1aXRlDQo+PiBpbnRlcmVzdGluZywgcGFydGljdWxhcmx5IGluIHRoZSBmYWNlIG9mIGFueSBj cm9zcyB0cmFmZmljIGF0IGFsbCkNCj4+DQo+PiBTQTogSSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBt ZWFuIGJ5IGNyb3NzLXRyYWZmaWMsIHRoZSBEU0wgbGluayBvbmx5IGdvZXMgdG8gb25lIHJlc2lk ZW5jZSAob3IgYnVzaW5lc3MpLiBUaGUgdHlwaWNhbCB0cmFmZmljIHRvIHRoYXQgd2FzIG1vZGVs ZWQuDQo+DQo+IEkgZG8gbmVlZCBhIGNvbnNpc3RlbnQgbmFtZSBmb3IgdGhpcyB0aGF0IG1hdGNo ZXMgcGVvcGxlJ3MgZXhwZWN0YXRpb25zLiBEb2VzIG5vdCBjcm9zcyB0cmFmZmljIG1ha2Ugc2Vu c2UgaW4gYSBEU0wgY29udGV4dD8NCj4gQ29tcGV0aW5nPw0KPg0KPiBJIG1lYW4gc29tZW9uZSBk b2luZyAqYW55dGhpbmcqIHRoYXQgaW52b2x2ZXMgc2VuZGluZyBkYXRhIHVwc3RyZWFtIG90aGVy IHRoYW4gdGlueSB0Y3AgYWNrcy4NCj4NCj4+IEFuZCBJIGRvIGtlZXAgaG9waW5nIHRoYXQgc29t ZW9uZSB3aWxsIGRvIGEgc3R1ZHkgb2YgaG93IHByZXZhbGVudCBmcSBpcyBvbiBkc2wgZGV2aWNl cywgSSBrZWVwIGFjY3VtdWxhdGluZyBhbmVjZG90YWwgZGF0YSB0aGF0IGl0J3MgZmFpcmx5IGNv bW1vbi4NCj4+DQo+Pj4gT25lIG9mIHRoZSBtYWpvciByZWFzb25zIHdoeSBvcGVyYXRvcnMgY2hv c2Ugbm90IHRvIGRlcGxveSAoVylSRUQgd2FzIGEgbnVtYmVyIG9mIHN0dWRpZXMgYW5kIHJlc2Vh cmNoIHdoaWNoIGdhdmUgb3BlcmF0b3JzIGNvbmZsaWN0aW5nIG1lc3NhZ2VzIG9uIHRoZSB2YWx1 ZSBvZiAoVylSRUQgYW5kIGFwcHJvcHJpYXRlIHBhcmFtZXRlcnMgdG8gdXNlLiBTb21lIG9mIHRo ZXNlIGFyZSBtZW50aW9uZWQgaW4gdGhlIHByZXNlbnRhdGlvbiBhYm92ZS4NCj4+Pg0KPj4+IElu IGl0IHdlIHNob3cgdGhhdCB0aGUgcHJldmlvdXMgc3R1ZGllcyB3aGljaCBzaG93ZWQgbG93IHZh bHVlIGZvciBSRUQgdXNlZCB3ZWIgdHJhZmZpYyB3aGljaCBoYWQgdmVyeSBzbWFsbCBmaWxlIHNp emVzIChvZiB0aGUgb3JkZXIgb2YgNS0xMCBwYWNrZXRzKSwgd2hpY2ggcmVkdWNlcyB0aGUgZWZm ZWN0aXZlcyBvZiBhbGwgQVFNcyB3aGljaCB3b3JrIGJ5IGRyb3BwaW5nIG9yIEVDTiBtYXJraW5n IG9mIGZsb3dzIHRvIGluZGljYXRlIGNvbmdlc3Rpb24uIFRvZGF5J3MgdHJhZmZpYyBpcyBjb21w b3NlZCBvZiBtb3N0bHkgbXVsdGktbWVkaWEgdHJhZmZpYyBsaWtlIEhBUyBvciB2aWRlbyBwcm9n cmVzc2l2ZSBkb3dubG9hZCB3aGljaCBoYXMgbXVjaCBsYXJnZXIgZmlsZSBzaXplcyBhbmQgY2Fu IGJlIGNvbnRyb2xsZWQgbXVjaCBiZXR0ZXIgd2l0aCBBUU1zIGFuZCBpbiBvdXIgcmVzZWFyY2gg d2Ugc2hvdyB0aGF0IFJFRCBjYW4gYmUgcXVpdGUgZWZmZWN0aXZlIHdpdGggdGhpcyB0cmFmZmlj LCB3aXRoIGxpdHRsZSB0dW5pbmcgbmVlZGVkIGZvciB0eXBpY2FsIHJlc2lkZW50aWFsIGFjY2Vz cyBmbG93cy4NCj4NCj4gSSBhZ3JlZSwgaW5jaWRlbnRhbGx5LCB0aGF0IFJFRCBpcyBPSyBmb3Ig ZmF0IG5vbi1pbnRlcmFjdGl2ZSB2aWRlbyBmbG93cyBvdmVyIHRjcC4gQW5kIEkgYXBwcm92ZSBv ZiBwZW9wbGUgY29taW5nIHVwIHdpdGggd2F5cyB0byB0dW5lIGl0IHByb3Blcmx5IGZvciBhbGwg c29ydHMgb2YgZW52aXJvbm1lbnRzIGFuZCBmdWxseSBkb2N1bWVudGluZyBob3cgdG8gZG8gaXQu DQo+DQo+Pg0KPj4gSSB0ZW5kIHRvIGRpc2FncmVlIHdpdGggdGhpcywgKHdlbGwsIG5vdCB0aGUg dHJlbmRsaW5lIHRvIGJpZyB2aWRlbw0KPj4gZmxvd3MpIGJ1dCBteSBvd24gc3R1ZGllcyBhcmUg Zm9jdXNlZCBvbiByZXRhaW5pbmcgaGlnaCBwZXJmb3JtYW5jZSBnYW1pbmcsIHZvaXAsIGFuZCB2 aWRlb2NvbmZlcmVuY2luZyB0cmFmZmljIGluIHRoZSBmYWNlIG9mIHRoaW5ncyBsaWtlIEhBUyB2 aWRlbyB0cmFmZmljLiBJIHdvdWxkIGJlIG11Y2ggaGFwcGllciBhYm91dCB5b3VyIHN0dWR5IGhh ZCB5b3UgYWxzbyBydW4gdGhhdCBzb3J0IG9mIHRyYWZmaWMgd2hpbGUgdGVzdGluZyB5b3VyIHZp ZGVvIGRvd25sb2FkcyBhbmQgYXFtcy4uLiBhbmQgd2h5IGlzIGl0IHNvIGhhcmQgdG8gZ2V0IGZv bGsgdG8gdHJ5IHNmcV9jb2RlbCwgZXRjLCB3aGlsZSB0aGV5IHRyeSBldmVyeXRoaW5nIGVsc2U/ DQo+Pg0KPj4gU0E6IFdlIGRpZCBub3QgbW9kZWwgc21hbGxlciBmbG93cyAoaW4gdGVybXMgb2Yg dGhyb3VnaHB1dCkuIFNtYWxsDQo+DQo+IExBVEVOQ1ksIGRhbW4gaXQuDQo+DQo+PlVEUCBmbG93 cywgd2hpY2ggSSBhc3N1bWUgYWxsL21vc3Qgb2YgdGhlIGFib3ZlIHdvdWxkIGZhbGwgaW4sIHdv dWxkIGJlbmVmaXQgc2lnbmlmaWNhbnRseSB3aXRoIFJFRCAtIHNsaWRlIDEzIHNob3dzIG11Y2gg bG93ZXIgYXZlcmFnZSBxdWV1ZSBsZW5ndGggd2l0aCBSRUQuDQo+DQo+IEF2ZXJhZ2UgcXVldWUg bGVuZ3RoIGlzIHZhbHVlbGVzcywgYWNjb3JkaW5nIHRvIEthdGh5IGFuZCBWYW4gLSBhbmQgYSBm ZXcgb3RoZXIgcGVvcGxlLCBpbmNsdWRpbmcgbWUuDQo+DQo+Pk90aGVyIHN0dWRpZXMgaGF2ZSBz aG93biB0aGF0IHNtYWxsIFVEUCBmbG93cyB3aXRoIGxvdHMgb2YgVENQIHRyYWZmaWMgYmVuZWZp dCBzaWduaWZpY2FudGx5IHdpdGggUkVEIGFjaGlldmluZyBsb3dlciBwYWNrZXQgbG9zcyAoTS4g TWF5cyBldCBhbCwg4oCcUmVhc29ucyBub3QgdG8gZGVwbG95IFJFROKAnSkuDQo+DQo+IEhtbS4u LiB5b3UgcmVhbGx5LCByZWFsbHksIHJlYWxseSBuZWVkIHRvIHNwZW5kIHNvbWUgdGltZSBwbGF5 aW5nIHdpdGggcmVhbCB0cmFmZmljIG92ZXIgcmVhbCwgYXN5bW1ldHJpYyBuZXR3b3JrcyB0aGF0 IGdvZXMgaW4gYm90aCBkaXJlY3Rpb25zLg0KPg0KPj4+DQo+Pj4gUHJlZmVyIEpvaG4ncyBwcm9w b3NhbCBvZiB1cGRhdGluZyAyMzA5IHJhdGhlciB0aGFuIG9ic29sZXRpbmcsIGJ1dCBpZiB3ZSBj YW4gaGF2ZSBzb21lIHRleHQgaW4gRnJlZCdzIGRyYWZ0IGFja25vd2xlZGdpbmcgdGhlIGxhcmdl IGRlcGxveW1lbnQgb2YgKFcpUkVEIGFuZCB0aGUgbmVlZCB0byBzdGlsbCBmaW5kIGdvb2QgY29u ZmlndXJhdGlvbnMgLSB0aGF0IG1heSB3b3JrLiBJIGNhbiB2b2x1bnRlZXIgdG8gcHJvdmlkZSB0 aGF0IHRleHQuDQo+Pj4NCj4+PiAtU2hhaGlkLg0KPj4NCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogYXFtIFttYWlsdG86YXFtLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmFxbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEZyZWQgQmFrZXINCj4+ PiAoZnJlZCkNCj4+PiBTZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMjowNiBBTQ0KPj4+IFRv OiBKb2huIExlc2xpZQ0KPj4+IENjOiBhcW1AaWV0Zi5vcmc8bWFpbHRvOmFxbUBpZXRmLm9yZz4N Cj4+PiBTdWJqZWN0OiBSZTogW2FxbV0gT2Jzb2xldGluZyBSRkMgMjMwOQ0KPj4+DQo+Pj4NCj4+ PiBPbiBKdWwgMywgMjAxNCwgYXQgMTA6MjIgQU0sIEpvaG4gTGVzbGllIDxqb2huQGpsYy5uZXQ8 bWFpbHRvOmpvaG5AamxjLm5ldD4+IHdyb3RlOg0KPj4+DQo+Pj4+IEl0IHdvdWxkIGJlIHBvc3Np YmxlIGZvciBzb21lb25lIHRvIGFyZ3VlIHRoYXQgcmVzdGF0aW5nIGENCj4+Pj4gcmVjb21tZW5k YXRpb24gZnJvbSBhbm90aGVyIGRvY3VtZW50IHdlYWtlbnMgYm90aCBzdGF0ZW1lbnRzOyBidXQg SQ0KPj4+PiBkaXNhZ3JlZTogV2Ugc2hvdWxkIGNsZWFybHkgc3RhdGUgd2hhdCB3ZSBtZWFuIGlu IHRoaXMgZG9jdW1lbnQsIGFuZA0KPj4+PiBJIGJlbGlldmUgdGhpcyB3b3JkaW5nIGRvZXMgc28u DQo+Pj4NCj4+PiBUaGUgYXJndW1lbnQgZm9yIHB1dHRpbmcgaXQgaW4gdGhlcmUgc3RhcnRlZCBm cm9tIHRoZSBmYWN0IHRoYXQgd2UgYXJlIG9ic29sZXRpbmcgMjMwOSwgYXMgc3RhdGVkIGluIHRo ZSBjaGFydGVyLiBJIHdvdWxkIHVuZGVyc3RhbmQgYSBkb2N1bWVudCB0aGF0IHVwZGF0ZXMgMjMw OSB0byBiZSBpbiBhIHN0cmFuZ2Ugc3RhdGUgaWYgMjMwOSBpcyBpdHNlbGYgbWFkZSBoaXN0b3Jp YyBvciBvYnNvbGV0ZS4gU28gd2UgY2FycmllZCB0aGUgcmVjb21tZW5kYXRpb24gaW50byB0aGlz IGRvY3VtZW50IHNvIGl0IHdvdWxkbid0IGdldCBsb3N0Lg0KPj4+DQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBhcW0gbWFpbGluZyBsaXN0 DQo+Pj4gYXFtQGlldGYub3JnPG1haWx0bzphcW1AaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcW0NCj4+DQo+Pg0KPj4NCj4+IC0tDQo+PiBEYXZl IFTDpGh0DQo+Pg0KPj4gTlNGVzoNCj4+IGh0dHBzOi8vdzIuZWZmLm9yZy9DZW5zb3JzaGlwL0lu dGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2X2kNCj4+IG5kZWNlbnQuYXJ0aWNs ZQ0KPg0KPg0KPg0KPiAtLQ0KPiBEYXZlIFTDpGh0DQo+DQo+IE5TRlc6IGh0dHBzOi8vdzIuZWZm Lm9yZy9DZW5zb3JzaGlwL0ludGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2X2lu ZGVjZW50LmFydGljbGUNCg0KDQoNCi0tDQpEYXZlIFTDpGh0DQoNCk5TRlc6IGh0dHBzOi8vdzIu ZWZmLm9yZy9DZW5zb3JzaGlwL0ludGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2 X2luZGVjZW50LmFydGljbGUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmFxbSBtYWlsaW5nIGxpc3QNCmFxbUBpZXRmLm9yZzxtYWlsdG86YXFtQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcW0NCg0KDQoN Ci0tDQpBbmRyZXcgTWNHcmVnb3IgfCBTUkUgfCBhbmRyZXdtY2dyQGdvb2dsZS5jb208bWFpbHRv OmFuZHJld21jZ3JAZ29vZ2xlLmNvbT4gfCArNjEgNCAxMDcxIDIyMjENCg== --_000_C0611F522A6FA9498A044C36073E49659D804284US70UWXCHMBA01z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymx1 ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNv cmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5BZ3JlZWQgdGhhdCBhcHBsaWNhdGlvbnMgd2hpY2ggY29uc3RpdHV0ZSBhIHNt YWxsIGFtb3VudCBvZiB0cmFmZmljIG1heSBjYXJyeSBhIGxhcmdlIHZhbHVlIHRvIHRoZSBlbmQg dXNlci4gVGhlIG9iamVjdGl2ZSBvZiBtb2RlbGluZyB0aGUgbGFyZ2VzdCBjb21wb25lbnRzIHdh cw0KIHRvIG1vZGVsIHRoZSBtYWpvcml0eSBvZiBUQ1AgdHJhZmZpYy4gVGhlIGFtb3VudCBvZiBW b0lQIHRyYWZmaWMgYW5kIGdhbWluZyB0cmFmZmljLCBmb3IgZXhhbXBsZSBpcyBub3QgbGlzdGVk IGluZGl2aWR1YWxseSBpbiB0aGUgcmVmZXJlbmNlZCBTYW5kcmluZSByZXBvcnQgKHJlcG9ydCBs aXN0cyBjb21wb25lbnRzIG1vcmUgdGhhbiAxJSksIHNvIHRoZXNlIGFyZSBleHBlY3RlZCB0byBi ZSBhIHNtYWxsIHBvcnRpb24gb2YgdGhlIHRvdGFsIGRvd25sb2FkDQogdHJhZmZpYy4gVGhlIGlt cGFjdCBvZiB0aGlzIHRyYWZmaWMgaXMgZXhwZWN0ZWQgdG8gYmUgbGl0dGxlL25lZ2xpZ2libGUg b24gdGhlIGxhcmdlIFRDUCBjb21wb25lbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoZSBpbXBhY3Qgb2YgdGhlIGxhcmdlIFRD UCB0cmFmZmljIG9uIHRoZSBzbWFsbCBVRFAgZmxvd3MgKFZvSVAsIGdhbWluZywgRE5TIGFyZSBh bGwgZ29vZCBleGFtcGxlcykgd2l0aC93aXRob3V0IEFRTSBpcyBhbm90aGVyIGlzc3VlLiBUaGlz IHdhcyBub3Qgc3R1ZGllZCBpbiB0aGUNCiBzdHVkeSBwcmVzZW50ZWQgbGFzdCBOb3YuIEhvd2V2 ZXIsIHRoaXMgaXNzdWUgaGFzIGJlZW4gc3R1ZGllZCB0byBzb21lIGV4dGVudCBlYXJsaWVyIChz ZWUgTS4gTWF5cyBldCBhbCwg4oCcUmVhc29ucyBub3QgdG8gZGVwbG95IFJFROKAnSksIHdoZXJl IHRoZSBhdXRob3JzIGZvdW5kIGEgNCB0aW1lcyByZWR1Y3Rpb24gaW4gVURQIHBhY2tldCBsb3Nz IHdpdGggbG90cyBvZiBUQ1AgdHJhZmZpYy4gVGhpcyBpcyBzb21ld2hhdCBpbnR1aXRpdmUgYXMg dGhlDQogVURQIGZsb3dzIGFyZSBsZXNzIGxpa2VseSB0byBmaW5kIHRoZSBxdWV1ZSB0byBiZSBm dWxsIHdpdGggQVFNLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHJldyBNY2dyZWdvciBbPGEgaHJlZj0ibWFpbHRvOmFu ZHJld21jZ3JAZ29vZ2xlLmNvbSI+bWFpbHRvOmFuZHJld21jZ3JAZ29vZ2xlLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKdWx5IDIwLCAyMDE0IDI6MjIgUE08YnI+DQo8Yj5U bzo8L2I+IERhdmUgVGFodDxicj4NCjxiPkNjOjwvYj4gQWtodGFyLCBTaGFoaWQgKFNoYWhpZCk7 IDxhIGhyZWY9Im1haWx0bzphcW1AaWV0Zi5vcmciPmFxbUBpZXRmLm9yZzwvYT47IEZyZWQgQmFr ZXIgKGZyZWQpOyBKb2huIExlc2xpZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2FxbV0gU2Fu ZSBhbmFseXNpcyBvZiAmcXVvdDt0eXBpY2FsIHRyYWZmaWMmcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRyYWZmaWMgdm9sdW1lIGhhcyBiYXNpY2Fs bHkgbm90aGluZyB0byBkbyB3aXRoIHRyYWZmaWMgdmFsdWUuICZuYnNwO0NvbnNpZGVyIHRoZSBE TlMuLi4gYSB0aW55IGZyYWN0aW9uIG9mIHVwc3RyZWFtIHRyYWZmaWMgbXVzdCB3b3JrIGluIG9y ZGVyIGZvciBhbnl0aGluZyBlbHNlIHRvIHdvcmsuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW1pbGFybHksIGEgVm9JUCBjYWxsIGlzIGEgdGlueSBhbW91 bnQgb2YgdHJhZmZpYywgYnV0IHJhdGhlciBzZW5zaXRpdmUgdG8gbG9zcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2FtZXMgY2FuIGJlIHF1 aXRlIGNoYXR0eSwgYnV0IGV2ZW4gc28gdGhleSBhcmUgc2Vuc2l0aXZlIHRvIGxhdGVuY3kgdmFy aWFiaWxpdHkgKGxhdGVuY3kgY29tcGVuc2F0aW9uIHdvcmtzIG11Y2ggYmV0dGVyIGlmIHRoZSBs YXRlbmN5IGlzIGZhaXJseSBjb25zaXN0ZW50KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlcmVhcywgaWYgbXkgSEQgdmlkZW8gc3RyZWFt IGRvd25ncmFkZXMgb25lIGNvZGVjIG5vdGNoLCB0aGF0IHdpbGwgaGFsdmUgdGhlIGJhbmR3aWR0 aCBhbmQgSSB3aWxsIGJhcmVseSBub3RpY2UgdGhlIGRpZmZlcmVuY2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIGFzeW1tZXRyaWMgRFNM LCB0aGUgdXBzdHJlYW0gdmFsdWUgaXMgdXN1YWxseSBtdWNoIGhpZ2hlciB0aGFuIGRvd25zdHJl YW0uLi4gaWYgSSBzZW5kIGFueXRoaW5nIGJ1dCBBQ0tzIEkgcHJvYmFibHkgY2FyZSBhIGxvdCBh Ym91dCB3aGF0ZXZlciB0aGF0IHRyYWZmaWMgaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gMTcgSnVseSAyMDE0IDA5OjMwLCBEYXZlIFRhaHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZl LnRhaHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2ZS50YWh0QGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBK dWwgMTcsIDIwMTQgYXQgODo1MSBBTSwgQWtodGFyLCBTaGFoaWQgKFNoYWhpZCk8YnI+DQombHQ7 PGEgaHJlZj0ibWFpbHRvOnNoYWhpZC5ha2h0YXJAYWxjYXRlbC1sdWNlbnQuY29tIj5zaGFoaWQu YWtodGFyQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgRGF2ZSw8 YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IFdlYiB0cmFmZmljIHdhcyBwYXJ0IG9mIHRo ZSBzdHVkeSAtIHlvdSBzaG91bGQgYmUgYWJsZSB0byBzZWUgcGFnZSBsb2FkIHRpbWVzIG9uIHNs aWRlIDEyPGJyPg0KJmd0Ozxicj4NCiZndDsgTG93ZXIgbGV2ZWxzIG9mIHRyYWZmaWMgd2VyZSBh bHNvIHRlc3RlZCAoc2xpZGVzIDExLDEyKSwgaG93ZXZlciB0aGUgaGlnaGVzdCBpbXBhY3Qgb2Yg QVFNIHdhcyBvYnNlcnZlZCBhdCBoaWdoIHRyYWZmaWMgbGV2ZWxzPGJyPg0KJmd0Ozxicj4NCiZn dDsgV2UgaW5jbHVkZWQgdGhlIGxhcmdlc3QgY29tcG9uZW50cyBvZiBJbnRlcm5ldCB0cmFmZmlj IChIQVMsIFdlYiBUcmFmZmljLCBWaWRlbyBQcm9ncmVzc2l2ZSBkb3dubG9hZCkgd2hpY2ggY29u c3RpdHV0ZSBvdmVyIDc1JSBvZiBhbGwgdHJhZmZpYyAoPGEgaHJlZj0iaHR0cHM6Ly93d3cuc2Fu ZHZpbmUuY29tL2Rvd25sb2Fkcy9nZW5lcmFsL2dsb2JhbC1pbnRlcm5ldC1waGVub21lbmEvMjAx NC8xaC0yMDE0LWdsb2JhbC1pbnRlcm5ldC1waGVub21lbmEtcmVwb3J0LnBkZiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LnNhbmR2aW5lLmNvbS9kb3dubG9hZHMvZ2VuZXJhbC9nbG9iYWwt aW50ZXJuZXQtcGhlbm9tZW5hLzIwMTQvMWgtMjAxNC1nbG9iYWwtaW50ZXJuZXQtcGhlbm9tZW5h LXJlcG9ydC5wZGY8L2E+KQ0KIGF0IHBlYWsgaG91cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNvbnRpbnVhbGx5IGFtIG1pbmQtYmxvd24gYnkgc3RhdGlz dGljYWwgbGVnZXJkZW1haW4uPGJyPg0KPGJyPg0KSnVzdCBsb29rIGF0IHRoZSBzaXplIG9mIHRo ZSBwczMvcHM0L3hib3ggZ2FtZXIgbWFya2V0IGZvciBleGFtcGxlLiBJPGJyPg0KZG9uJ3QgY2Fy ZSBhYm91dCB0aGUgYW1vdW50IG9mIHRyYWZmaWMgYXQgYWxsLiBJIGNhcmUgdGhhdCBpbiBhPGJy Pg0KYWxsLW5pZ2h0IGFtaW5nIHNlc3Npb24gb3IgYSBob3VyIGxvbmcgdmlkZWNvbmZlcmVuY2Ug dGhhdCB0aGU8YnI+DQpyZWxhdGl2ZWx5IHNwYXJzZSBsYXRlbmN5IHNlbnNpdGl2ZSBwYWNrZXRz IGdldCB0aHJvdWdoIC0gaW4gYm90aDxicj4NCmRpcmVjdGlvbnMgLSByZWdhcmRsZXNzIG9mIHdo YXQgZWxzZSBpcyBnb2luZyBvbiBvbiB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CiZndDsgVGhlIHN0dWR5IHByZXNlbnRlZCBpbiBOb3Ygd2FzIG91ciBpbml0aWFsIHdvcmsgYW5k IGlzIG5vdCB0aGUgb25seSBjb21wb25lbnQgaW4gZGV2ZWxvcG1lbnQgb2YgYW55IGNvbmZpZ3Vy YXRpb24gZ3VpZGVsaW5lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Hb3QgYW55IGdhbWVycyBoZWxwaW5nIHdyaXRlIHlvdXIgc3BlY3M/PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDs8YnI+DQom Z3Q7IC1TaGFoaWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQomZ3Q7IEZyb206IERhdmUgVGFodCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkYXZl LnRhaHRAZ21haWwuY29tIj5kYXZlLnRhaHRAZ21haWwuY29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6 IFR1ZXNkYXksIEp1bHkgMTUsIDIwMTQgNDowMCBQTTxicj4NCiZndDsgVG86IEFraHRhciwgU2hh aGlkIChTaGFoaWQpPGJyPg0KJmd0OyBDYzogRnJlZCBCYWtlciAoZnJlZCk7IEpvaG4gTGVzbGll OyA8YSBocmVmPSJtYWlsdG86YXFtQGlldGYub3JnIj5hcW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyBTdWJqZWN0OiBTYW5lIGFuYWx5c2lzIG9mICZxdW90O3R5cGljYWwgdHJhZmZpYyZxdW90Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IGNoYW5naW5nIHRoZSB0aXRsZSBhcyB0aGlzIGlzIG5vdCByZWxl dmFudCB0byB0aGUgYXFtIGRvY3VtZW50Li4uPGJyPg0KJmd0Ozxicj4NCiZndDsgLi4uIGJ1dCB0 byBhbiBhdHRpdHVkZSB0aGF0IGlzIGRyaXZpbmcgbWUgYWJzb2x1dGVseSBjcmF6eS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBPbiBUdWUsIEp1bCAxNSwgMjAxNCBhdCAxMDo0NiBBTSwgQWtodGFyLCBT aGFoaWQgKFNoYWhpZCkgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFoaWQuYWtodGFyQGFsY2F0ZWwt bHVjZW50LmNvbSI+c2hhaGlkLmFraHRhckBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyBEYXZlLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIG1l c3NhZ2Ugb2YgdGhlIHJlc3VsdHMgdGhhdCB3ZSBwcmVzZW50ZWQgaW4gTm92ZW1iZXIgaXMgdGhh dCBpdCBpcyBwb3NzaWJsZSwgd2l0aCBjdXJyZW50bHkgZGVwbG95ZWQgYWNjZXNzIGhhcmR3YXJl LCB0byBjb25maWd1cmUgUkVEIHNvIHRoYXQgaXQgY29uc2lzdGVudGx5IGltcHJvdmVzIHRoZSBl bmQgdXNlciBleHBlcmllbmNlIG9mIGNvbW1vbiBuZXR3b3JrIHNlcnZpY2VzIG92ZXIgVGFpbC1E cm9wICh3aGljaCBpcyBtb3N0IG9mdGVuDQogY29uZmlndXJlZCksIGFuZCB0aGF0IHRoaXMgaW1w cm92ZW1lbnQgY2FuIGJlIGFjaGlldmVkIHdpdGggYSBmaXhlZCBzZXQgb2YgUkVEIGNvbmZpZ3Vy YXRpb24gZ3VpZGVsaW5lcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIGRpZCBub3Qg cnVuIGV4cGVyaW1lbnRzIHdpdGggc2ZxX2NvZGVsIGJlY2F1c2UgaXQgaXMgbm90IGRlcGxveWVk IGluIGFjY2VzcyBuZXR3b3JrcyB0b2RheS4gV2UgcmFuIGV4cGVyaW1lbnRzIHdpdGggcGxhaW4g Q29EZWwgdG8gdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgd2VsbC1jb25maWd1 cmVkIFJFRCBhbmQgYSBtb3JlIHJlY2VudCBzaW5nbGUtYnVja2V0IEFRTSBpbiBvdXIgdGFyZ2V0 IHNjZW5hcmlvcywgYW5kDQogYXMgcmVwb3J0ZWQsIGRpZG4ndCBvYnNlcnZlIHNpZ25pZmljYW50 IGRpZmZlcmVuY2VzIGluIGFwcGxpY2F0aW9uIFFvRS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBZb3Vy ICZxdW90O2FwcGxpY2F0aW9uJnF1b3Q7IHdhcyBhIGJ1bmNoIG9mIHZpZGVvIHN0cmVhbXMuIE5v dCB3ZWIgdHJhZmZpYywgbm90IHZvaXAsIG5vdCwgZ2FtaW5nLCBub3QgYml0dG9ycmVudCwgbm90 IGEgZmFtaWx5IG9mIGZvdXIgZG9pbmcgYSBjb21iaW5hdGlvbiBvZiB0aGVzZSB0aGluZ3MsIG5v ciBhIHNtYWxsIGJ1c2luZXNzIHRoYXQgaXNuJ3QgZ29pbmcgdG8gdXNlIEhBUyBhdCBhbGwuPGJy Pg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIGRvbid0IG92ZXIgZ2VuZXJhbGl6ZSB5b3VyIHJlc3Vs dHMuICZxdW90O1JFRCBwcm92ZW4gc3VpdGFibGUgZm9yIGZhbWlseSBvZiBjb3VjaCBwb3RhdG9l cyBzdXJmaW5nIHRoZSBpbnRlcm5ldCBhbmQgd2F0Y2hpbmcgNCBtb3ZpZXMgYXQgb25jZSBvdmVy IHRoZSBpbnRlcm5ldCBidXQgbm90IDUsIGF0IDhtYml0L3NlYyZxdW90OyBtaWdodCBoYXZlIGJl ZW4gYSBiZXR0ZXIgdGl0bGUgZm9yIHRoaXMgcGFwZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4g dGhpcyBmaWN0aW9uYWwgZmFtaWx5LCBqdXN0IG9uZSBraWQgdW5kZXIgdGhlIHN0YWlyLCB0cnlp bmcgdG8gZG8gc29tZXRoaW5nIHVzZWZ1bCwgaW50ZXJhY3RpdmUgYW5kL29yIGZ1biwgY2FuIGJv dGggd3JlY2sgdGhlIGNvdWNoIHBvdGF0b2VzJyBpbnRlcm5ldCBleHBlcmllbmNlLCBhbmQgaGF2 ZSBoaXMgb3duLCB3cmVja2VkIGFsc28uPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgQWRkaXRpb25hbCBpbmxpbmUgY2xhcmlmaWNhdGlvbnMgYmVsb3cuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAtU2hhaGlkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBEYXZlIFRhaHQgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86ZGF2ZS50YWh0QGdtYWlsLmNvbSI+ZGF2ZS50YWh0QGdtYWls LmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgU2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDI6MDAg UE08YnI+DQomZ3Q7Jmd0OyBUbzogQWtodGFyLCBTaGFoaWQgKFNoYWhpZCk8YnI+DQomZ3Q7Jmd0 OyBDYzogRnJlZCBCYWtlciAoZnJlZCk7IEpvaG4gTGVzbGllOyA8YSBocmVmPSJtYWlsdG86YXFt QGlldGYub3JnIj5hcW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgU3ViamVjdDogUmU6IFth cW1dIE9ic29sZXRpbmcgUkZDIDIzMDk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIE1v biwgSnVsIDE0LCAyMDE0IGF0IDExOjA4IEFNLCBBa2h0YXIsIFNoYWhpZCAoU2hhaGlkKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNoYWhpZC5ha2h0YXJAYWxjYXRlbC1sdWNlbnQuY29tIj5zaGFoaWQu YWtodGFyQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0 OyBIaSBGcmVkLCBBbGwsPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IExldCBt ZSBhbiBhZGRpdGlvbmFsIHRob3VnaHQgdG8gdGhpcyBpc3N1ZS48YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgR2l2ZW4gdGhhdCAoVylSRUQgaGFzIGJlZW4gZGVwbG95ZWQgZXh0 ZW5zaXZlbHkgaW4gb3BlcmF0b3JzJyBuZXR3b3JrcywgYW5kIG1vc3QgdmVuZG9ycyBhcmUgc3Rp bGwgc2hpcHBpbmcgZXF1aXBtZW50IHdpdGggKFcpUkVELCBjb25jZXJuIGlzIHRoYXQgb2Jzb2xl dGluZyAyMzA5IHdvdWxkIGRpc2NvdXJhZ2UgcmVzZWFyY2ggb24gdHJ5aW5nIHRvIGZpbmQgZ29v ZCBjb25maWd1cmF0aW9ucyB0byBtYWtlIChXKVJFRCB3b3JrLjxicj4NCiZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyBXZSBoYWQgcHJldmlvdXNseSBnaXZlbiBhIHByZXNlbnRhdGlvbiBh dCB0aGUgSUNDUkcgb24gd2h5IFJFRCBjYW4gc3RpbGwgcHJvdmlkZSB2YWx1ZSB0byBvcGVyYXRv cnMgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODgvc2xpZGVzL3Ns aWRlcy04OC1pY2NyZy0wLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvODgvc2xpZGVzL3NsaWRlcy04OC1pY2NyZy0wLnBkZjwvYT4pLg0KIFdlIGhh dmUgYSBwYXBlciBhdCBHbG9iZWNvbSAyMDE0IHRoYXQgZXhwbGFpbnMgdGhpcyBzdHVkeSBtdWNo IGJldHRlciwgYnV0IEkgY2Fubm90IHNoYXJlIGEgbGluayB0byBpdCB1bnRpbCB0aGUgcHJvY2Vl ZGluZ3MgYXJlIGF2YWlsYWJsZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE15IHByb2Js ZW0gd2l0aCB0aGUgYWJvdmUgcHJlc28gYW5kIG5vIGRvdWJ0IHRoZSByZXN1bHRpbmcgc3R1ZHkg aXM8YnI+DQomZ3Q7Jmd0OyB0aGF0IGl0IGRvZXNuJ3QgYXBwZWFyIGNvdmVyIHRoZSBjbGFzc2lj LCBtb3N0IGJhc2ljLCBidWZmZXJibG9hdDxicj4NCiZndDsmZ3Q7IHNjZW5hcmlvLCB3aGljaCBp czxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJnF1b3Q7MSBzdHJlYW0gdXAsIDEgc3RyZWFt IGRvd24sIG9uZSBwaW5nIChvciBzb21lIGZvcm0gb2Ygdm9pcC1saWtlIHRyYWZmaWMpJnF1b3Q7 IGFuZCB1c3VhbGx5IG9uIGFuIGVkZ2UgbmV0d29yayB3aXRoIGFzeW1tZXRyaWMgYmFuZHdpZHRo Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFR3byBhZGRpdGlvbmFsIGFuYWx5c2VzIG9mIHVzZSBmcm9t IHRoZSBkb3dubG9hZCBwZXJzcGVjdGl2ZSBtaWdodCBiZSBBcnJpcydzIGFuYWx5c2lzIG9mIHRo ZSBiZW5lZml0cyBvZiByZWQgYW5kIGZxIG92ZXIgY2FibGUgaGVhZCBlbmRzOjxicj4NCiZndDs8 YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9zbmFwb24ubGFiLmJ1ZmZlcmJsb2F0Lm5ldC9+ZC90 cmltZmF0L0Nsb29uYW5fUGFwZXIucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vc25hcG9u LmxhYi5idWZmZXJibG9hdC5uZXQvfmQvdHJpbWZhdC9DbG9vbmFuX1BhcGVyLnBkZjwvYT48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBhbmQgdGhlIGNhYmxlIGxhYnMgd29yayB3aGljaCBmb2N1c2VkIG1v cmUgb24gdGhlIGVmZmVjdHMgb2YgdHJhZmZpYyBnb2luZyB1cHN0cmVhbSB3aGljaCBoYXMgYmVl biBkaXNjdXNzZWQgZmFpcmx5IGV4dGVuc2l2ZWx5IGhlcmUuPGJyPg0KJmd0Ozxicj4NCiZndDsm Z3Q7IFNBOiBXZSB0cmllZCB0byBjb3ZlciB0aGUgdHlwaWNhbCBleHBlY3RlZCB0cmFmZmljIG92 ZXIgdGhlIEludGVybmV0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZG9uJ3Qga25vdyB3aGVyZSB5 b3UgZ2V0IHlvdXIgZGF0YSwgYnV0IG15IG1lYXN1cmVkIGVkZ2UgdHJhZmZpYyBsb29rcyBub3Ro aW5nIGxpa2UgeW91cnMuIFN1cmUgYmFuZHdpZHRoIHdpc2UsIHRoZXJlcyB0aGUgbmV0ZmxpeCBz cGlrZSAzIGhvdXJzIG91dCBvZiB0aGUgZGF5IGJ1dCB0aGUgcmVzdCBzdXJlIGlzbid0IEhBUy48 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7TW9zdCBvZiB0aGUgdHJhZmZpYyBpcyBu b3cgSEFTIHRyYWZmaWMgKGFzIHBlciB0aGUgc2FuZHZpbmUgcmVwb3J0KSwgc28gaWYgb25seSBh IHNpbmdsZSBzdHJlYW0gaXMgcHJlc2VudCwgaXQgaXMgbGlrZWx5IHRvIGJlIEhBUy48YnI+DQom Z3Q7PGJyPg0KJmd0OyZndDtUaGUgY2xvc2VzdCBhcHByb3hpbWF0aW9uIG9mIGEgY29udGludW91 cyBUQ1Agc3RyZWFtLCBhcyB5b3UgbWVudGlvbiwgd291bGQgYmUgYSBwcm9ncmVzc2l2ZSBkb3du bG9hZCB3aGljaCBjYW4gbGFzdCBsb25nIGVub3VnaCB0byBsb29rIGNvbnRpbnVvdXMuIFRoZXNl IHdlcmUgbW9kZWxlZCB0b2dldGhlciB3aXRoIG90aGVyIHR5cGVzIG9mIHRyYWZmaWMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgWW91IGtlZXAgc2F5aW5nLCBkb3dubG9hZCwgZG93bmxvYWQsIGRvd25s b2FkLiBJIGFtIHNheWluZyBtZXJlbHkgcGxlYXNlIEFMV0FZUyB0cnkgYW4gdXBsb2FkIGF0IHRo ZSBzYW1lIHRpbWUgeW91IGFyZSB0ZXN0aW5nIGRvd25sb2Fkczxicj4NCiZndDsgLSBiZSBpdCB2 aWRlb2NvbmZlcmVuY2luZyAod2hpY2ggY2FuIGVhc2lseSB1c2UgdXAgdGhhdCAxLjZtYml0IGxp bmspLCBhIHlvdXR1YmUgdXBsb2FkLCBhIHJzeW5jIGJhY2t1cCwgYSBzY3AsIGFueXRoaW5nLi4u PGJyPg0KJmd0Ozxicj4NCiZndDsgSXQgbmVlZGVudCBiZSB0aGUgY3J1eCBvZiB5b3VyIHBhcGVy ISBCdXQgYWRkaW5nIHNldmVyYWwgdGVzdHMgb2YgdGhhdCBzb3J0IGRvZXMgbmVlZCB0byBpbmZv cm0geW91ciB0b3RhbCBtb2RlbGluZyBleHBlcmllbmNlLjxicj4NCiZndDs8YnI+DQomZ3Q7IElm IHlvdSBkbyB0aGF0IG11Y2gsIHlvdSB3ZSBnZXQgYSBmZWVsIGZvciBob3cgcHJlc2VudCBkYXkg c3lzdGVtcyBpbnRlcmFjdCB3aXRoIHRoaW5ncyBsaWtlIGFjayBjbG9ja2luZyB3aGljaCB3aWxs IGRvIHZlcnkgaW50ZXJlc3RpbmcgdGhpbmdzIHRvIHlvdXIgJnF1b3Q7ZG93bnN0cmVhbSB0byB0 aGUgY291Y2ggcG90YXRvJnF1b3Q7IHBlcmZvcm1hbmNlIG1ldHJpY3MuPGJyPg0KJmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSXQncyBub3QgY2xlYXIgZnJvbSB0aGUgc3R1ZHkgdGhh dCB0aGlzIGlzIGEgOG1iaXQgZG93biAxbWJpdCB1cCBEU0w8YnI+DQomZ3Q7Jmd0OyBuZXR3b3Jr ICg/KSw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNBOiBJbiB0aGUgc3R1ZHkgcHJlc2Vu dGVkLCBJdCB3YXMgOE0gZG93biBhbmQgMS42TSB1cCAtIHNsaWRlIDk8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaHguPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IG5vciBpcyBpdCBjbGVhciBpZiBSRUQgaXMgYmVpbmcgYXBwbGllZCBpbiBib3RoIGRpcmVjdGlv bnMgb3Igb25seSBvbmUgZGlyZWN0aW9uIG9ubD88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IFNBOiBBUU1zIChpbmNsdWRpbmcgUkVEKSB3ZXJlIG9ubHkgYXBwbGllZCBpbiBkb3duc3RyZWFt IGRpcmVjdGlvbiAtPGJyPg0KJmd0OyZndDsgc2xpZGUgOTxicj4NCiZndDs8YnI+DQomZ3Q7IEFy ZSB5b3UgZ29pbmcgdG8gZm9sbG93IHVwIHdpdGggc3R1ZmYgdGhhdCBsb29rcyBhdCB0aGUgdXBz dHJlYW0gZGlyZWN0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyAoYW5kIHRoZSByZXN1bHRz IHlvdSBnZXQgZnJvbSBhbiBhc3ltbWV0cmljIG5ldHdvcmsgYXJlIHF1aXRlPGJyPg0KJmd0OyZn dDsgaW50ZXJlc3RpbmcsIHBhcnRpY3VsYXJseSBpbiB0aGUgZmFjZSBvZiBhbnkgY3Jvc3MgdHJh ZmZpYyBhdCBhbGwpPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTQTogSSBhbSBub3Qgc3Vy ZSB3aGF0IHlvdSBtZWFuIGJ5IGNyb3NzLXRyYWZmaWMsIHRoZSBEU0wgbGluayBvbmx5IGdvZXMg dG8gb25lIHJlc2lkZW5jZSAob3IgYnVzaW5lc3MpLiBUaGUgdHlwaWNhbCB0cmFmZmljIHRvIHRo YXQgd2FzIG1vZGVsZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBkbyBuZWVkIGEgY29uc2lzdGVu dCBuYW1lIGZvciB0aGlzIHRoYXQgbWF0Y2hlcyBwZW9wbGUncyBleHBlY3RhdGlvbnMuIERvZXMg bm90IGNyb3NzIHRyYWZmaWMgbWFrZSBzZW5zZSBpbiBhIERTTCBjb250ZXh0Pzxicj4NCiZndDsg Q29tcGV0aW5nPzxicj4NCiZndDs8YnI+DQomZ3Q7IEkgbWVhbiBzb21lb25lIGRvaW5nICphbnl0 aGluZyogdGhhdCBpbnZvbHZlcyBzZW5kaW5nIGRhdGEgdXBzdHJlYW0gb3RoZXIgdGhhbiB0aW55 IHRjcCBhY2tzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBBbmQgSSBkbyBrZWVwIGhvcGluZyB0 aGF0IHNvbWVvbmUgd2lsbCBkbyBhIHN0dWR5IG9mIGhvdyBwcmV2YWxlbnQgZnEgaXMgb24gZHNs IGRldmljZXMsIEkga2VlcCBhY2N1bXVsYXRpbmcgYW5lY2RvdGFsIGRhdGEgdGhhdCBpdCdzIGZh aXJseSBjb21tb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT25lIG9mIHRoZSBt YWpvciByZWFzb25zIHdoeSBvcGVyYXRvcnMgY2hvc2Ugbm90IHRvIGRlcGxveSAoVylSRUQgd2Fz IGEgbnVtYmVyIG9mIHN0dWRpZXMgYW5kIHJlc2VhcmNoIHdoaWNoIGdhdmUgb3BlcmF0b3JzIGNv bmZsaWN0aW5nIG1lc3NhZ2VzIG9uIHRoZSB2YWx1ZSBvZiAoVylSRUQgYW5kIGFwcHJvcHJpYXRl IHBhcmFtZXRlcnMgdG8gdXNlLiBTb21lIG9mIHRoZXNlIGFyZSBtZW50aW9uZWQgaW4gdGhlIHBy ZXNlbnRhdGlvbiBhYm92ZS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSW4g aXQgd2Ugc2hvdyB0aGF0IHRoZSBwcmV2aW91cyBzdHVkaWVzIHdoaWNoIHNob3dlZCBsb3cgdmFs dWUgZm9yIFJFRCB1c2VkIHdlYiB0cmFmZmljIHdoaWNoIGhhZCB2ZXJ5IHNtYWxsIGZpbGUgc2l6 ZXMgKG9mIHRoZSBvcmRlciBvZiA1LTEwIHBhY2tldHMpLCB3aGljaCByZWR1Y2VzIHRoZSBlZmZl Y3RpdmVzIG9mIGFsbCBBUU1zIHdoaWNoIHdvcmsgYnkgZHJvcHBpbmcgb3IgRUNOIG1hcmtpbmcg b2YgZmxvd3MgdG8gaW5kaWNhdGUgY29uZ2VzdGlvbi4NCiBUb2RheSdzIHRyYWZmaWMgaXMgY29t cG9zZWQgb2YgbW9zdGx5IG11bHRpLW1lZGlhIHRyYWZmaWMgbGlrZSBIQVMgb3IgdmlkZW8gcHJv Z3Jlc3NpdmUgZG93bmxvYWQgd2hpY2ggaGFzIG11Y2ggbGFyZ2VyIGZpbGUgc2l6ZXMgYW5kIGNh biBiZSBjb250cm9sbGVkIG11Y2ggYmV0dGVyIHdpdGggQVFNcyBhbmQgaW4gb3VyIHJlc2VhcmNo IHdlIHNob3cgdGhhdCBSRUQgY2FuIGJlIHF1aXRlIGVmZmVjdGl2ZSB3aXRoIHRoaXMgdHJhZmZp Yywgd2l0aA0KIGxpdHRsZSB0dW5pbmcgbmVlZGVkIGZvciB0eXBpY2FsIHJlc2lkZW50aWFsIGFj Y2VzcyBmbG93cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFncmVlLCBpbmNpZGVudGFsbHksIHRo YXQgUkVEIGlzIE9LIGZvciBmYXQgbm9uLWludGVyYWN0aXZlIHZpZGVvIGZsb3dzIG92ZXIgdGNw LiBBbmQgSSBhcHByb3ZlIG9mIHBlb3BsZSBjb21pbmcgdXAgd2l0aCB3YXlzIHRvIHR1bmUgaXQg cHJvcGVybHkgZm9yIGFsbCBzb3J0cyBvZiBlbnZpcm9ubWVudHMgYW5kIGZ1bGx5IGRvY3VtZW50 aW5nIGhvdyB0byBkbyBpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJ IHRlbmQgdG8gZGlzYWdyZWUgd2l0aCB0aGlzLCAod2VsbCwgbm90IHRoZSB0cmVuZGxpbmUgdG8g YmlnIHZpZGVvPGJyPg0KJmd0OyZndDsgZmxvd3MpIGJ1dCBteSBvd24gc3R1ZGllcyBhcmUgZm9j dXNlZCBvbiByZXRhaW5pbmcgaGlnaCBwZXJmb3JtYW5jZSBnYW1pbmcsIHZvaXAsIGFuZCB2aWRl b2NvbmZlcmVuY2luZyB0cmFmZmljIGluIHRoZSBmYWNlIG9mIHRoaW5ncyBsaWtlIEhBUyB2aWRl byB0cmFmZmljLiBJIHdvdWxkIGJlIG11Y2ggaGFwcGllciBhYm91dCB5b3VyIHN0dWR5IGhhZCB5 b3UgYWxzbyBydW4gdGhhdCBzb3J0IG9mIHRyYWZmaWMgd2hpbGUgdGVzdGluZyB5b3VyDQogdmlk ZW8gZG93bmxvYWRzIGFuZCBhcW1zLi4uIGFuZCB3aHkgaXMgaXQgc28gaGFyZCB0byBnZXQgZm9s ayB0byB0cnkgc2ZxX2NvZGVsLCBldGMsIHdoaWxlIHRoZXkgdHJ5IGV2ZXJ5dGhpbmcgZWxzZT88 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNBOiBXZSBkaWQgbm90IG1vZGVsIHNtYWxsZXIg Zmxvd3MgKGluIHRlcm1zIG9mIHRocm91Z2hwdXQpLiBTbWFsbDxicj4NCiZndDs8YnI+DQomZ3Q7 IExBVEVOQ1ksIGRhbW4gaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7VURQIGZsb3dzLCB3aGlj aCBJIGFzc3VtZSBhbGwvbW9zdCBvZiB0aGUgYWJvdmUgd291bGQgZmFsbCBpbiwgd291bGQgYmVu ZWZpdCBzaWduaWZpY2FudGx5IHdpdGggUkVEIC0gc2xpZGUgMTMgc2hvd3MgbXVjaCBsb3dlciBh dmVyYWdlIHF1ZXVlIGxlbmd0aCB3aXRoIFJFRC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBdmVyYWdl IHF1ZXVlIGxlbmd0aCBpcyB2YWx1ZWxlc3MsIGFjY29yZGluZyB0byBLYXRoeSBhbmQgVmFuIC0g YW5kIGEgZmV3IG90aGVyIHBlb3BsZSwgaW5jbHVkaW5nIG1lLjxicj4NCiZndDs8YnI+DQomZ3Q7 Jmd0O090aGVyIHN0dWRpZXMgaGF2ZSBzaG93biB0aGF0IHNtYWxsIFVEUCBmbG93cyB3aXRoIGxv dHMgb2YgVENQIHRyYWZmaWMgYmVuZWZpdCBzaWduaWZpY2FudGx5IHdpdGggUkVEIGFjaGlldmlu ZyBsb3dlciBwYWNrZXQgbG9zcyAoTS4gTWF5cyBldCBhbCwg4oCcUmVhc29ucyBub3QgdG8gZGVw bG95IFJFROKAnSkuPGJyPg0KJmd0Ozxicj4NCiZndDsgSG1tLi4uIHlvdSByZWFsbHksIHJlYWxs eSwgcmVhbGx5IG5lZWQgdG8gc3BlbmQgc29tZSB0aW1lIHBsYXlpbmcgd2l0aCByZWFsIHRyYWZm aWMgb3ZlciByZWFsLCBhc3ltbWV0cmljIG5ldHdvcmtzIHRoYXQgZ29lcyBpbiBib3RoIGRpcmVj dGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBQcmVm ZXIgSm9obidzIHByb3Bvc2FsIG9mIHVwZGF0aW5nIDIzMDkgcmF0aGVyIHRoYW4gb2Jzb2xldGlu ZywgYnV0IGlmIHdlIGNhbiBoYXZlIHNvbWUgdGV4dCBpbiBGcmVkJ3MgZHJhZnQgYWNrbm93bGVk Z2luZyB0aGUgbGFyZ2UgZGVwbG95bWVudCBvZiAoVylSRUQgYW5kIHRoZSBuZWVkIHRvIHN0aWxs IGZpbmQgZ29vZCBjb25maWd1cmF0aW9ucyAtIHRoYXQgbWF5IHdvcmsuIEkgY2FuIHZvbHVudGVl ciB0byBwcm92aWRlIHRoYXQgdGV4dC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgLVNoYWhpZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyBGcm9tOiBh cW0gW21haWx0bzo8YSBocmVmPSJtYWlsdG86YXFtLWJvdW5jZXNAaWV0Zi5vcmciPmFxbS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEZyZWQgQmFrZXI8YnI+DQomZ3Q7Jmd0OyZn dDsgKGZyZWQpPGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCAy OjA2IEFNPGJyPg0KJmd0OyZndDsmZ3Q7IFRvOiBKb2huIExlc2xpZTxicj4NCiZndDsmZ3Q7Jmd0 OyBDYzogPGEgaHJlZj0ibWFpbHRvOmFxbUBpZXRmLm9yZyI+YXFtQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW2FxbV0gT2Jzb2xldGluZyBSRkMgMjMwOTxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBKdWwg MywgMjAxNCwgYXQgMTA6MjIgQU0sIEpvaG4gTGVzbGllICZsdDs8YSBocmVmPSJtYWlsdG86am9o bkBqbGMubmV0Ij5qb2huQGpsYy5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEl0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBzb21lb25lIHRv IGFyZ3VlIHRoYXQgcmVzdGF0aW5nIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJlY29tbWVuZGF0 aW9uIGZyb20gYW5vdGhlciBkb2N1bWVudCB3ZWFrZW5zIGJvdGggc3RhdGVtZW50czsgYnV0IEk8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRpc2FncmVlOiBXZSBzaG91bGQgY2xlYXJseSBzdGF0ZSB3 aGF0IHdlIG1lYW4gaW4gdGhpcyBkb2N1bWVudCwgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJ IGJlbGlldmUgdGhpcyB3b3JkaW5nIGRvZXMgc28uPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IFRoZSBhcmd1bWVudCBmb3IgcHV0dGluZyBpdCBpbiB0aGVyZSBzdGFydGVkIGZy b20gdGhlIGZhY3QgdGhhdCB3ZSBhcmUgb2Jzb2xldGluZyAyMzA5LCBhcyBzdGF0ZWQgaW4gdGhl IGNoYXJ0ZXIuIEkgd291bGQgdW5kZXJzdGFuZCBhIGRvY3VtZW50IHRoYXQgdXBkYXRlcyAyMzA5 IHRvIGJlIGluIGEgc3RyYW5nZSBzdGF0ZSBpZiAyMzA5IGlzIGl0c2VsZiBtYWRlIGhpc3Rvcmlj IG9yIG9ic29sZXRlLiBTbyB3ZSBjYXJyaWVkIHRoZSByZWNvbW1lbmRhdGlvbg0KIGludG8gdGhp cyBkb2N1bWVudCBzbyBpdCB3b3VsZG4ndCBnZXQgbG9zdC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyZndDsgYXFtIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJtYWlsdG86YXFtQGlldGYub3JnIj5hcW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YXFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hcW08L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyBEYXZlIFTDpGh0PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBOU0ZXOjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdzIuZWZmLm9yZy9D ZW5zb3JzaGlwL0ludGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2X2kiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vdzIuZWZmLm9yZy9DZW5zb3JzaGlwL0ludGVybmV0X2NlbnNv cnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2X2k8L2E+PGJyPg0KJmd0OyZndDsgbmRlY2VudC5hcnRp Y2xlPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsg RGF2ZSBUw6RodDxicj4NCiZndDs8YnI+DQomZ3Q7IE5TRlc6IDxhIGhyZWY9Imh0dHBzOi8vdzIu ZWZmLm9yZy9DZW5zb3JzaGlwL0ludGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2 X2luZGVjZW50LmFydGljbGUiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdzIuZWZmLm9yZy9D ZW5zb3JzaGlwL0ludGVybmV0X2NlbnNvcnNoaXBfYmlsbHMvcnVzc2VsbF8wMjk2X2luZGVjZW50 LmFydGljbGU8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+DQpEYXZlIFTDpGh0PGJy Pg0KPGJyPg0KTlNGVzogPGEgaHJlZj0iaHR0cHM6Ly93Mi5lZmYub3JnL0NlbnNvcnNoaXAvSW50 ZXJuZXRfY2Vuc29yc2hpcF9iaWxscy9ydXNzZWxsXzAyOTZfaW5kZWNlbnQuYXJ0aWNsZSIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93Mi5lZmYub3JnL0NlbnNvcnNoaXAvSW50ZXJuZXRfY2Vu c29yc2hpcF9iaWxscy9ydXNzZWxsXzAyOTZfaW5kZWNlbnQuYXJ0aWNsZTwvYT48YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFx bSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86YXFtQGlldGYub3JnIj5hcW1AaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FxbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjRDUw RjI1IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPkFuZHJldyBNY0dyZWdvciZuYnNwO3w8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzMzNjlFOCAxLjVwdDtwYWRkaW5nOjIu MHB0Ij4mbmJzcDtTUkUmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTU7Ym9yZGVy OnNvbGlkICMwMDk5MzkgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRv OmFuZHJld21jZ3JAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHJld21jZ3JAZ29vZ2xl LmNvbTwvYT4mbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlk ICNFRUIyMTEgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7JiM0Mzs2MQ0KIDQgMTA3MSAyMjIx PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_C0611F522A6FA9498A044C36073E49659D804284US70UWXCHMBA01z_-- From nobody Tue Jul 22 06:45:24 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48EE1B2809 for ; Tue, 22 Jul 2014 06:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGd1Ayltf6Y6 for ; Tue, 22 Jul 2014 06:45:19 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A241B2812 for ; Tue, 22 Jul 2014 06:45:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400050800"; d="scan'208,217";a="177482786" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 22 Jul 2014 06:45:18 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 22 Jul 2014 06:45:18 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 22 Jul 2014 06:45:17 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::b0c8:2b85:3071:3540%21]) with mapi id 15.00.0847.030; Tue, 22 Jul 2014 06:45:17 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: Note takers and Jabber scribe Thread-Index: Ac+lswYQz125PUbbTIipABEO1+sPsw== Date: Tue, 22 Jul 2014 13:45:16 +0000 Message-ID: <4879c28657cd470397689c9d5fa04d34@hioexcmbx05-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.120.60.34] Content-Type: multipart/alternative; boundary="_000_4879c28657cd470397689c9d5fa04d34hioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/lGqQJrrSNdJhwtdjLGdUvqS_TeY Subject: [aqm] Note takers and Jabber scribe X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 13:45:22 -0000 --_000_4879c28657cd470397689c9d5fa04d34hioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Are there any volunteers to take up the role as note taker or jabber scribe= ? Best regards, Richard Scheffenegger --_000_4879c28657cd470397689c9d5fa04d34hioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Are there any volunteers to take up the role as note taker or jabber s= cribe?
 
Best regards,
 
Richard Scheffenegger
 
 
 --_000_4879c28657cd470397689c9d5fa04d34hioexcmbx05prdhqnetappc_-- From nobody Tue Jul 22 07:03:03 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661C11B2873 for ; Tue, 22 Jul 2014 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AKnZb-wf25l for ; Tue, 22 Jul 2014 07:02:43 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 71B111B286F for ; Tue, 22 Jul 2014 07:02:35 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6ME2XQu005790 for ; Tue, 22 Jul 2014 10:02:33 -0400 Received: (qmail 23763 invoked by uid 0); 22 Jul 2014 14:02:33 -0000 X-TCPREMOTEIP: 31.133.164.243 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?31.133.164.243?) (wes@mti-systems.com@31.133.164.243) by 0 with ESMTPA; 22 Jul 2014 14:02:33 -0000 Message-ID: <53CE6EF7.8060307@mti-systems.com> Date: Tue, 22 Jul 2014 10:02:31 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/_MYXvRhcWfXtBxYC7oA9pCE5kig Subject: [aqm] proposed process for algorithm RFCs X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 14:02:50 -0000 One of the things we will talk about in the meeting today, and should also discuss on the mailing list, is starting to adopt algorithms specs as WG drafts towards getting them into RFCs. We drafted a diagram to show the process we're thinking of as chairs. It's on the final slide of: http://www.ietf.org/proceedings/90/slides/slides-90-aqm-0.pptx Please share any thoughts, comments, criticisms, etc. -- Wes Eddy MTI Systems From nobody Tue Jul 22 07:20:05 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ECF1B28C4 for ; Tue, 22 Jul 2014 07:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DA8yxzN676x for ; Tue, 22 Jul 2014 07:20:00 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDC41B28CC for ; Tue, 22 Jul 2014 07:19:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400050800"; d="scan'208,217";a="177489943" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 22 Jul 2014 07:19:51 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 22 Jul 2014 07:19:50 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 22 Jul 2014 07:19:49 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::b0c8:2b85:3071:3540%21]) with mapi id 15.00.0847.030; Tue, 22 Jul 2014 07:19:49 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: Note takers and Jabber scribe Thread-Index: Ac+lswYQz125PUbbTIipABEO1+sPswABNhcg Date: Tue, 22 Jul 2014 14:19:48 +0000 Message-ID: References: <4879c28657cd470397689c9d5fa04d34@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <4879c28657cd470397689c9d5fa04d34@hioexcmbx05-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.120.60.34] Content-Type: multipart/alternative; boundary="_000_d8f135487b084177bf71e88ed870a3e4hioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/zKKtlM4ymL850cn8n299a3ENHZk Subject: Re: [aqm] Note takers and Jabber scribe X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 14:20:03 -0000 --_000_d8f135487b084177bf71e88ed870a3e4hioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick hint as potential note takers: You can collectively use etherp= ad to capture major discussion points: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-aqm?useMonospaceFont=3D= true Richard Scheffenegger From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Scheffenegger, Richard Sent: Dienstag, 22. Juli 2014 09:45 To: aqm@ietf.org Subject: [aqm] Note takers and Jabber scribe Hi, Are there any volunteers to take up the role as note taker or jabber scribe= ? Best regards, Richard Scheffenegger --_000_d8f135487b084177bf71e88ed870a3e4hioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

Just a qui= ck hint as potential note takers: You can collectively use etherpad to capt= ure major discussion points:

 = ;

http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-aqm?useMonospa= ceFont=3Dtrue

 = ;

 = ;

Richard Scheffenegger

 <= /p>

From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Scheffenegger, Richard
Sent: Dienstag, 22. Juli 2014 09:45
To: aqm@ietf.org
Subject: [aqm] Note takers and Jabber scribe

 

Hi,

 

Are there any volunteers to take up the= role as note taker or jabber scribe?

 

Best regards,

 

Richard Scheffenegger=

 

 

--_000_d8f135487b084177bf71e88ed870a3e4hioexcmbx05prdhqnetappc_-- From nobody Tue Jul 22 19:41:18 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD93A1B288F for ; Tue, 22 Jul 2014 19:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kygTLBnm8sGr for ; Tue, 22 Jul 2014 19:41:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BB31B287E for ; Tue, 22 Jul 2014 19:41:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-7d-53cf20c81668 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.0B.04090.8C02FC35; Wed, 23 Jul 2014 04:41:12 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.228]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 04:41:11 +0200 From: Szilveszter Nadas To: "aqm@ietf.org" Thread-Topic: draft-kuhn-aqm-eval-guidelines-01 Thread-Index: Ac+l9Khny10tDbswRc+5GMCLySsSew== Date: Wed, 23 Jul 2014 02:41:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23B46742ESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje4JhfPBBv27BCzW7JN0YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGkSWvmAsmyFb8nTmTqYFxkWQXIyeHhICJRPOSJiYIW0ziwr31 bF2MXBxCAkcZJdrmL2KEcJYwStx60MoCUsUmYCHRsHIzG4gtIqAoseXXfeYuRg4OYQEtiV0n IiDC+hKLu24yQdh6ElvePwArZxFQlXi5egYjiM0r4Ctx7OcHsDgj0OLvp9aA1TMLiEvcejIf 6iABiSV7zjND2KISLx//Y4WwlSQW3f4MVZ8vMeHTSyaImYISJ2c+YZnAKDQLyahZSMpmISmD iOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC I+Lglt9WOxgPPnc8xCjAwajEw7tg2blgIdbEsuLK3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAyJ7Oc8M+zP6TyJq0JAfT5Ka1qYXmr7hjRQ6zlJzbM6VN54HIEm3F Q9bdfy488k1tvvqyPea8AIdI7u7qkxOVnv/KXt3xwflVmdcPz66Jvr1L0sq/ya1SuHRu8nmB 9g0Pvr3TCXvAw1Oh3fLTb/rZJWbbZn3obPy/7Xhbj8//j/E776vy/rpiqMRSnJFoqMVcVJwI ALCyVStpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/79baUkhFdftkhjlatM-oWGKTtrk Subject: [aqm] draft-kuhn-aqm-eval-guidelines-01 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 02:41:16 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23B46742ESESSMB303erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, On ECN and its support this came to my mind during the presentation today: = I assume that most of the results of characterization would be different wi= th ECN present and supported (as you also mention in section 2.4). I am not= quite sure what would be a "solution" when it comes to the document, still= it seems to me that characterization of the AQM algorithm when ECN is pres= ent and supported should be also required. Maybe it is even more important = in the long term than without ECN. Cheers, Szilveszter --_000_EA4C43BE752A194597B002779DF69BAE23B46742ESESSMB303erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

On ECN and its support this came to my mind during t= he presentation today: I assume that most of the results of characterizatio= n would be different with ECN present and supported (as you also mention in= section 2.4). I am not quite sure what would be a “solution” when it comes to the document, stil= l it seems to me that characterization of the AQM algorithm when ECN is pre= sent and supported should be also required. Maybe it is even more important= in the long term than without ECN.

 

Cheers,

Szilveszter

--_000_EA4C43BE752A194597B002779DF69BAE23B46742ESESSMB303erics_-- From nobody Thu Jul 24 06:41:15 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282021A032F for ; Thu, 24 Jul 2014 06:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2pqlFGr9My8 for ; Thu, 24 Jul 2014 06:41:12 -0700 (PDT) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4991A0348 for ; Thu, 24 Jul 2014 06:41:12 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6ODf9lL028532 for ; Thu, 24 Jul 2014 09:41:09 -0400 Received: (qmail 9577 invoked by uid 0); 24 Jul 2014 13:41:09 -0000 X-TCPREMOTEIP: 31.133.164.243 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?31.133.164.243?) (wes@mti-systems.com@31.133.164.243) by 0 with ESMTPA; 24 Jul 2014 13:41:09 -0000 Message-ID: <53D10CF1.9030305@mti-systems.com> Date: Thu, 24 Jul 2014 09:41:05 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "aqm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/y_20WL_EXqg6hlHbRp5JxDsUnTk Subject: [aqm] IETF 90 minutes posted X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 13:41:14 -0000 Please see the IETF 90 AQM meeting minutes posted at: http://www.ietf.org/proceedings/90/minutes/minutes-90-aqm Many thanks to Andrew McGregor for taking these down. There are a couple of names that may need correcting; please relay these and any other changes to either this list or to aqm-chairs@tools.ietf.org. -- Wes Eddy MTI Systems From nobody Thu Jul 24 07:53:14 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930841A0377 for ; Thu, 24 Jul 2014 07:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOh8azbgK1xw for ; Thu, 24 Jul 2014 07:53:09 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69421A030C for ; Thu, 24 Jul 2014 07:53:09 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n16so3827376oag.27 for ; Thu, 24 Jul 2014 07:53:09 -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 :content-transfer-encoding; bh=ZcmXYJsNvlaweBLk+yVuYa1siaaJAM8QPyb2lYXi9I0=; b=cvJWXA0bWANMIf0EcSDQp0XU5/Tm3ScLV6dbKXd7HQcezS7YjGWB1xt3Ob08auIi1A yBWy8zrvrtJzLqIKWasupPvxJscG54TYOPMa/oxhTemDmhhlgKbD3CgXHC2zLkNi4s9f jJ6a+UAhTHHAUh50YkBBXZ2HiRAaegda9M1V4qLRanf5cqYotzr5yrNTK8tgDbLRV6hC GzKK7Fzyez33beTAPXq4kTsigocb2bAuYfn1FsRDn06o1r1UuhgXyf7MliWDQMUhCq+4 5/HshHq4d3MsGBBYTePARRng+iFmt62OL6XjSM95LD1wW9+nhnlL8lZj0fvGArAcEn1b GFPw== MIME-Version: 1.0 X-Received: by 10.182.118.193 with SMTP id ko1mr13729966obb.45.1406213589129; Thu, 24 Jul 2014 07:53:09 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Thu, 24 Jul 2014 07:53:09 -0700 (PDT) Date: Thu, 24 Jul 2014 07:53:09 -0700 Message-ID: From: Dave Taht To: "aqm@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/-iS7FvJ1B_ulEEVMDnLS1oRSJVY Subject: [aqm] draft-constantine-bmwg-traffic-management-04.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 14:53:11 -0000 https://datatracker.ietf.org/doc/draft-constantine-bmwg-traffic-management/ This draft looks really good, but aqm/ps is currently out of its scope. (I managed to miss this meeting, darn it) --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Thu Jul 24 08:29:58 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200E91A024E for ; Thu, 24 Jul 2014 08:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hSUoDON29x8 for ; Thu, 24 Jul 2014 08:29:48 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9571A02C1 for ; Thu, 24 Jul 2014 08:29:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,724,1400050800"; d="scan'208";a="136270136" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 24 Jul 2014 08:29:37 -0700 Received: from HIOEXCMBX04-PRD.hq.netapp.com (10.122.105.37) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 24 Jul 2014 08:29:35 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 24 Jul 2014 08:29:17 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::b0c8:2b85:3071:3540%21]) with mapi id 15.00.0847.030; Thu, 24 Jul 2014 08:29:16 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" Thread-Topic: Summary of WG discussion around draft-ietf-aqm-recommendations Thread-Index: Ac+nU7Oi9e/VODmsQMe+za28z42pkA== Date: Thu, 24 Jul 2014 15:29:15 +0000 Message-ID: <882f61cca0af4288b7e88b23ef45d37c@hioexcmbx05-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.120.60.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/TOgKDHTRR5pRifXmWlOXY_DbZ0c Subject: [aqm] Summary of WG discussion around draft-ietf-aqm-recommendations X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 15:29:49 -0000 Group, =20 This is to quickly summarize the WG chairs understanding of the status=20 of the above mentioned draft and next steps: =20 After the extensive discussion regarding the intended status and=20 relation to RFC2309, a significant consensus has been reached to=20 proceed by obsoleting RFC2309 with this new draft. The objections=20 raised both on procedural grounds (RFC2309 was the output of the E2E=20 group, best compared to an IRTF document today), and content status=20 ("invalidating" RED) have been thoroughly looked at. The conclusion=20 Reached is that the document should proceed becoming a BCP that=20 obsoletes the older recommendations, instead of updating them and=20 potentially creating confusion. =20 The Chairs believe that after this extensive discussions, the path=20 forward is clear and there exists consensus on that. =20 The authors will do a final update reflecting this intended status and=20 relation to the older document, and once that is done, we will proceed=20 with submitting it for IESG review, as the WGLC has been concluded with the above result. =20 Richard Scheffenegger From nobody Thu Jul 24 10:09:05 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190FA1A04A2 for ; Thu, 24 Jul 2014 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXLhimbgBE_2 for ; Thu, 24 Jul 2014 10:09:00 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 90E281A0444 for ; Thu, 24 Jul 2014 10:09:00 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0705DC94BF; Thu, 24 Jul 2014 13:08:58 -0400 (EDT) Date: Thu, 24 Jul 2014 13:08:57 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20140724170857.GC75235@verdi> References: <882f61cca0af4288b7e88b23ef45d37c@hioexcmbx05-prd.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <882f61cca0af4288b7e88b23ef45d37c@hioexcmbx05-prd.hq.netapp.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/bePchdHv2GXXX9gTvhB4PnZEJuE Cc: "aqm@ietf.org" Subject: Re: [aqm] Summary of WG discussion around draft-ietf-aqm-recommendations X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 17:09:03 -0000 Scheffenegger, Richard wrote: > > This is to quickly summarize the WG chairs understanding of the status > of the above mentioned draft and next steps: > > After the extensive discussion regarding the intended status and > relation to RFC2309, a significant consensus has been reached to > proceed by obsoleting RFC2309 with this new draft. (I did not, and do not, join that consensus.) > The objections raised both on procedural grounds (RFC2309 was the > output of the E2E group, best compared to an IRTF document today), I am genuinely interested in who raise that objection (I didn't). > and content status ("invalidating" RED) have been thoroughly looked > at. I'll try to restate my impression of that part: - several folks did not want to "invalidate RED" at this stage of our work, but understood we might recommend against it in the future; - the authors stated an intent to supersede the recommendation to use RED as quickly as possible; - someone else said that there is no such recommendation in 2309. > The conclusion Reached is that the document should proceed becoming > a BCP that obsoletes the older recommendations, instead of updating > them and potentially creating confusion. IMHO, the document as it stands remains confusing -- because the reader has to guess the intent of seemingly-small wording changes, instead of having a clear statement of what we intend to supersede. > The Chairs believe that after this extensive discussions, the path > forward is clear and there exists consensus on that. This "extensive discussion" seems to have entirely avoided the point I _did_ raise: that the document would be a lot easier to read if we didn't have to carry over text from 2309. Perhaps I _am_ in the rough, but it seems to me I'm not the only person who has been ignored here. > The authors will do a final update reflecting this intended status and > relation to the older document, and once that is done, we will proceed > with submitting it for IESG review, as the WGLC has been concluded with > the above result. I don't intend to formally appeal this statement of consensus (though I would appreciate the Document Shepherd noting the consensus is "rough"); but I will have to raise a few of my points during IETF Last-Call. :^( -- John Leslie From nobody Thu Jul 24 10:37:05 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3AF1A0275 for ; Thu, 24 Jul 2014 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rsj4owMr3zxM for ; Thu, 24 Jul 2014 10:37:02 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123F91A0B02 for ; Thu, 24 Jul 2014 10:37:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,725,1400050800"; d="scan'208";a="177978684" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 24 Jul 2014 10:36:59 -0700 Received: from HIOEXCMBX04-PRD.hq.netapp.com (10.122.105.37) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 24 Jul 2014 10:36:59 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 24 Jul 2014 10:36:58 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::b0c8:2b85:3071:3540%21]) with mapi id 15.00.0847.030; Thu, 24 Jul 2014 10:36:58 -0700 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [aqm] Summary of WG discussion around draft-ietf-aqm-recommendations Thread-Index: Ac+nU7Oi9e/VODmsQMe+za28z42pkAASO0SAAA5bPEA= Date: Thu, 24 Jul 2014 17:36:58 +0000 Message-ID: <1883c969d4df452d8880e824a5b50ecf@hioexcmbx05-prd.hq.netapp.com> References: <882f61cca0af4288b7e88b23ef45d37c@hioexcmbx05-prd.hq.netapp.com> <20140724170857.GC75235@verdi> In-Reply-To: <20140724170857.GC75235@verdi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/qZ8Qn7bwqOnejSJK_GKTtKKwxeY Cc: "aqm@ietf.org" Subject: Re: [aqm] Summary of WG discussion around draft-ietf-aqm-recommendations X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 17:37:04 -0000 Hi John, > > After the extensive discussion regarding the intended status and > > relation to RFC2309, a significant consensus has been reached to > > proceed by obsoleting RFC2309 with this new draft. >=20 > (I did not, and do not, join that consensus.) > > I don't intend to formally appeal this statement of consensus (though = I > would appreciate the Document Shepherd noting the consensus is "rough"); > but I will have to raise a few of my points during IETF Last-Call. :^( Noted, your objection will be included in the shepherd write-up for the IES= G. >> The objections raised both on procedural grounds (RFC2309 was the >> output of the E2E group, best compared to an IRTF document today), >=20 > I am genuinely interested in who raise that objection (I didn't). Let me rephrase this - it was not so much as an objection by one specific p= erson, but an open question which was considered between the Authors, WG ch= airs, ADs and the IRTF chair. Also, the authors are still busy working on an update which includes your e= arlier points, in particular the relationship between this document and RFC= 2309, and your other suggestions. I will follow up with you to see, if at least some of the concerns you have= with -06 will have been addressed in the upcoming -07 revision. Best regards, Richard Scheffenegger From nobody Thu Jul 24 13:00:18 2014 Return-Path: X-Original-To: aqm@ietfa.amsl.com Delivered-To: aqm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F211A02D6 for ; Thu, 24 Jul 2014 13:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC-dEE8b49x4 for ; Thu, 24 Jul 2014 13:00:14 -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 7D3321A0643 for ; Thu, 24 Jul 2014 13:00:14 -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 A59802B44CE; Thu, 24 Jul 2014 21:00:13 +0100 (BST) Received: from 31.133.156.169 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 24 Jul 2014 21:00:13 +0100 Message-ID: <8597c1bc093991047a819909f273c465.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <201407231414.s6NEEJhC012146@bagheera.jungle.bt.co.uk> References: <20140701091519.13796.89481.idtracker@ietfa.amsl.com> <53B3D7B6.90607@erg.abdn.ac.uk> <201407222232.s6MMWGCc007545@bagheera.jungle.bt.co.uk> <84ce732783175388a894a282614d04ac.squirrel@www.erg.abdn.ac.uk> <201407231414.s6NEEJhC012146@bagheera.jungle.bt.co.uk> Date: Thu, 24 Jul 2014 21:00:13 +0100 From: gorry@erg.abdn.ac.uk To: aqm@ietf.org 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 Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/H8n_Dwcdppw10FTNj7a1u5Fc2q4 Subject: [aqm] On list: Great improvement (& nits): draft-ietf-aqm-recommendation-06.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 20:00:17 -0000 I'm forwarding this with Bob's permission, as a response to the edits he requested in WGLC. I shall incorporate changes in the revision we are now preparing (-07). Gorry > > At 14:37 23/07/2014, gorry@erg.abdn.ac.uk wrote: >>Thanks for the careful read. These are all OK. I'll add them to rev -07 >>within a week or so. >> >>I'd like to take these as proposed resolutions to the WGLC comments. With >>this in mind, can I copy this email to the list Bob? >> >>Gorry >> >> > Gorry, Fred, >> > >> > Thank you v much for the new intro. You've done a great job. >> > Now that it's not tied to the structure of 2309, it is much much >> > easier to understand. >> > >> > Below are nitty things I've noticed in the new introductory sections >> > (up to section 3). Nothing controversial. I haven't cc'd to list, so >> > you can choose to ignore these (given WG last call has passed), but >> > you'll probably want to fix them - I've suggested text in each case. >> > >> > 1. Intro >> > s/for a variety traffic of traffic/ >> > /for a variety of traffic/ >> > >> > s/ In the current Internet and low latency/ >> > / In the current Internet low latency/ >> > >> > Section 1.1 >> > "congestion signals (i.e., marked or dropped packets) " >> > The concept of ECN marking has not been introduced yet. How about: >> > "congestion signals (i.e., packets that are dropped or >> > marked with explicit congestion notification [RFC3168]) >> > >> > Section 2. >> > s/ The solution to the full-queues problem is for network >> > devices to drop packets before a queue becomes full,/ >> > /The solution to the full-queues problem is for network >> > devices to drop or ECN-mark packets before a queue becomes full,/ >> > >> > s/By dropping packets before buffers overflow, >> > AQM allows network devices to control when and how many packets to >> > drop./ >> > /By dropping or ECN-marking packets before buffers overflow, >> > AQM allows network devices to control when and how many packets to >> > drop./ >> > >> > Section 2.1 >> > " AQM >> > mechanisms need to control the overall queue sizes, to ensure that >> > arriving bursts can be accommodated without dropping packets. AQM >> > should also be used to control the queue size for each individual >> > flow or class, >> > " >> > s/AQM mechanisms need to control the overall/ >> > /AQM mechanisms might need to control the overall/ >> > >> > Rationale: >> > This implies AQM is needed for the overall queue, and for each >> > individual class. Is the former actually known to be true? If not, I >> > don't believe this should be stated with such certainty. >> > >>Fred are you OK with this? >> >> > Section 3. >> > " It is convenient to divide flows into three classes: (1) TCP >> Friendly >> > flows, (2) unresponsive flows, i.e., flows that do not slow down >> when >> > congestion occurs, and (3) flows that are responsive but are not >> TCP- >> > friendly. >> > " >> > The names of the 3 categories and their later definitions could be >> > understood by the reader as points on the spectrum, not the regions >> > between the points. >> > The subsequent section headings need to be disambiguated too. >> > >> > "congestive collapse [RFC2309]." >> > You're referring to an RFC that you are obsoleting! >> > >> > s/congestion control in the application [RFC5405]./ >> > /congestion control in the application [RFC5405], [RFC6679]. >> > >> > s/granugranularity/ >> > /granularity/ >> > >> > I'd like to suggest an item 5) for the list of granularities: >> > 5) a class per site (enterprise or residential). >> > We never use a granularity lower than this as a carrier, other than >> > in the home gateway. >> > >>I'd also be Ok with this. >> >> > But this last one is probably beyond a nit, so you can ignore it at >> this >> > stage. >> > >> > >> > That's it. HTH >> > >> > >> > >> > Bob >> > >>Gorry >> >> > At 10:58 02/07/2014, Gorry Fairhurst wrote: >> >>To keep things clear, we published a new revision of the AQM >> >>recommendations (-06) after the conference call for which Richard sent >> >> notes. >> >> >> >>Our hope is that this provides a firm basis for any further >> >>discussion. The editors are asking the group to read this and note any >> >> errors. >> >> >> >>There remains some on-going discussion about whether this now should >> >>move RFC2309 to Historic, or not. This issue needs to be resolved >> >>before we finalize the introduction. Let's hope we can conclude this >> >> soon. >> >> >> >>Best wishes, >> >> >> >>Gorry >> >> >> >> >> >> >> >>On 01/07/2014 10:15, internet-drafts@ietf.org wrote: >> >>> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts >> >>>directories. >> >>> This draft is a work item of the Active Queue Management and >> >>> Packet Scheduling Working Group of the IETF. >> >>> >> >>> Title : IETF Recommendations Regarding Active >> >>> Queue Management >> >>> Authors : Fred Baker >> >>> Godred Fairhurst >> >>> Filename : draft-ietf-aqm-recommendation-06.txt >> >>> Pages : 27 >> >>> Date : 2014-07-01 >> >>> >> >>>Abstract: >> >>> This memo presents recommendations to the Internet community >> >>> concerning measures to improve and preserve Internet >> performance. >> >>> It >> >>> presents a strong recommendation for testing, standardization, >> and >> >>> widespread deployment of active queue management (AQM) in >> network >> >>> devices, to improve the performance of today's Internet. It >> also >> >>> urges a concerted effort of research, measurement, and ultimate >> >>> deployment of AQM mechanisms to protect the Internet from flows >> >>> that >> >>> are not sufficiently responsive to congestion notification. >> >>> >> >>> The note largely repeats the recommendations of RFC 2309, >> updated >> >>> after fifteen years of experience and new research. >> >>> >> >>> >> >>>The IETF datatracker status page for this draft is: >> >>>https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ >> >>> >> >>>There's also a htmlized version available at: >> >>>http://tools.ietf.org/html/draft-ietf-aqm-recommendation-06 >> >>> >> >>>A diff from the previous version is available at: >> >>>http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-06 >> >>> >> >>> >> >>>Please note that it may take a couple of minutes from the time of >> >>> submission >> >>>until the htmlized version and diff are available at tools.ietf.org. >> >>> >> >>>Internet-Drafts are also available by anonymous FTP at: >> >>>ftp://ftp.ietf.org/internet-drafts/ >> >>> >> >>>_______________________________________________ >> >>>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 >> > > > ________________________________________________________________ > Bob Briscoe, BT >