#################### # AQM WG Meeting # #################### Meeting: IETF88, Tuesday 5. Nov. 2013, 13:00-14:00 PST Location: Vancouver, Canada (Georgia B) Chairs: Wes Eddy Richard Scheffenegger AD: Martin Stiemerling URL: http://tools.ietf.org/wg/aqm/ Note Taker: Pasi Sarolahti WG status ########### Agenda was bashed; The presentation around the AQM recommendations draft was pushed back after the AQM mechanisms status update presentations. The Chair slides for Friday reflect that change. A proposed move of the Friday slot to thursday found no consensus, as due to overlap with CORE and SFC BoF. -- Slide: CableLabs requiring AQM PIE in DOCSIS 3.1 modems Lars Eggert: I wish that we had heard earlier about their decision. Should Talk with DOCSIS liason person. Algorithm Proposals ##################### draft-pan-aqm-pie Rong Pan -- Slide: PIE work update Lars: PIE variant by DOCSIS, do you have the final spec? Rong Pan: Pseudocode is in the Specifications. Stuart Cheshire: Estimating queue occupancy, you know packet arrival and departure, so you should know the latency. Rong: You can timestamp on a per packet basis, but for hardware this is extra overhead Thomas Narten: Is this on slicon, or can you roll out this on firmware pretty quickly? Rong: It will be implemented on silicon, but can be implemented on firmware or software as well. Thomas: It will be a long term kind of thing Rong: possibly doing this on 3.0, but now doing this for 3.1 Thomas: What is the timeframe? Rong: three years from now Greg White (via Jabber): early 2015 for initial products Thomas: is it frozen now? Rong: pretty much is, some modifications possible Thomas: is it too late for this group to have influence? Dave Taht: There are vendor specific solutions that can be applied... Lars: Is there an open specification for PIE variant DOCSIS has chosen, for us to look at? Dave Taht (via Jabber): http://www.cablelabs.com/specifications/CM-SP-MULPIv3.1-101-131029.pdf Jim: How is it different from Linux implementation? Rong: Some parameters were optimized for the PHY/MAC layer of DOCSIS. -- Slide: variant of pie in docsis Bob Briscoe: does the docsis spec say which parameters are configurable Rong: A and B are self tuned, there will only be the reference and burst tolerance. all self tuning. Things like max burst? right now max burst cab be tuned. we don't want to hard code to silicon. Stuart: we could debate merits, but having smarter queueing is good thing. Does the docsis 3.1 spec include support for ECN? Rong: we discussed it. Right now there is no accepted status quo on ECN, remains pretty vague. (groans in the room) Stuart: issues at Apple, have run into situations in apple tv, got to do networking, etc. and keep the video going smoothly. having network data smoothly is desirable. When you have loss, with TCP you have bursts. Bursts cause difficult problems for us, would like it to be smoother, so would like to see ECN instead of drop. Fred: Who is preventing it? Rong: we don't exactly know if it works Stuart: if clients signal ECN support, doesn't seem controversial Rong: yeah, but... Stuart: we have a liason problem with docsis Lars: how we are going to work to get it better with docsis. There is probanly a spec in docsis, is that available to us? is there copyright? By doing something in cablelabs you may prevent doing something in the ietf Thomas: guide on defaults not very clear? is this clear enough for IETF to act on? outside bodies are reading specs, reading IETF docs, will be confused Gorry Fairhurst: ECN thing needs to be sorted out quickly, to get things right? could someone take action item to follow up? Wes: Yes. Continue on the mailing list ####### CoDel Algorithm status update Jim Gettys -- Slide: PIE response under load Stuart: can you explain the blue and red line in the bottom? Jim: These are for different RTTs Stuart: 20 ms is across the network? Jim: right -- Slide: division of attitudes in this group Jim: Who many cares about wireless? very many hands Jim: how many are paid for that? many hands Gorry: put this list into internet draft Jim: I'm willing to shepherd fq_codel draft. Trying to start that document, and would like to have help for fq_codel document. Need to get things written down. We need to document the deployed version of fq_codel Bob: Don't want people to get the message that AQM is forgot in the core. --- Was there meant to be some linkage between dynamics and rest of your presentation Jim: fq_codel is adapting in very short time interval. PIE is lot slower than fqcodel in adapting Bob: worried about the interval when you do nothing Jim: flow isolation helps a lot Tim Shepard: fq_codel is not on by default in openwrt, i tested it. Jim: in barrierbreaker it is on by default Jana Iyengar: i would love to see separation between codel and with and without flow isolation Jim: it is synergistic, it turns out, better than either by themselves. Rong: no reason that PIE cannot be used on top of that Rong: the reason we choose 20 ms was tradeoff between latency and throughput. In docsis we are able to make latency targets smaller. we have to discuss what is the right tradeoff between latency and throughput. Matt: there is an apples to oranges comparison... Dave Taht: The ultimate goal is 100% utilization and zero latency Jim: we want to keep hardware busy Lars Eggert: quick question: are there IPR declarations? Wes: none known Jim: no patents on codel, as far as the authors know -- End of Tuesday session -- Meeting: IETF88, Friday 8. Nov. 2013, 12:30-13:30 PST Location: Vancouver, Canada (Regency B) Note Taker: Kevin Lahey WG items ########## draft-ietf-aqm-recommendation Fred Baker -- Slide: changes since -02 Andrew McGregor: AQM parameters should be configurable seperately for ECN vs. Non-ECN. Bob Briscoe: Refers to TSVWG presentation on ECN -- Slide: conclusions/recommendations Open discussion, summary: Point 2. SHOULD support ECN Wes George: I've seen some issues with middleboxes Gorry Fairhurst: We're trying to get some data in this area, with Brian Trammell. Bob Briscoe: A middlebox can be an issue for some endpoints, but other endpoints could still get some advantage. Fred Baker: ECN can be more aggressive than drops. Bob, does making ECN more aggressive affect delay-based congestion control? BB: We found a way to tune both kinds of flows so that no one starves. Andrew McGregor: There's substantial operational experience with this. We don't see full performance with drop, but it doesn't totally get nuked. Anoop Ghanwani also asked about what type of devices the AQM work here was intended for, whether this included devices with only small buffers. Fred pointed out a case where different cards can interact with one another inside a switch to create short term bufferbloat type of events when there is contention for switch fabric. Fred also mentioned a Sprint measurement paper where there are spikes in delay on the Sprint backbone, as another example that this can happen everywhere. Anoop mentioned cases where RED can be harmful if not tuned properly, and Fred pointed out that this is why we're not recommending it. Matt Mathis: I'd like to increase the strength of the wish that ECN worked, and explain that Floyd's ECN and Data Center ECN are different, and there are more open questions than we thought there were. Jana Iyengar: Queues may exist in devices, and hosts as well, and we should use ECN wherever we see queues. Jabber, Greg White: How does ECN work with Codel? Dave Taht: We've had ECN in FQ-CoDel from the start. (Jabber, GW: question was regarding using different criteria for drop vs mark in Codel) Point 4. AQM algorithms SHOULD respond to measured congestion, not application profiles MM: What's the definition of congestion? FB: Should respond to traffic measurements, maybe? FB: Are we missing anything from Bob's update to RFC2309? Define "congestion" early on in the Draft, and adapt the wording FB & GF: Assumptions about higher layer protocols? DT: Make sure that this is about queue management, not packet scheduling. Point 5. Change the reference from "Transport" to "Application" Point 6. Transport congestion control algorithms SHOULD maximize their use of available capacity without incurring undue loss or round-trip delay. BB: Not too sure about this, what about RTP? GF: You should read the section, the summary statement is big and woolly. MM: Maybe the point of six is that AQM needs to be cognizant of the fact that transports are trying to optimize things against AQM. FB, DT, and others: Quality of experience? AMcG: Perhaps imposing on other flows? Jim Roskind: What about goodput? Something higher than the transport should suggest what we should be optimizing for? FB: So this is controversial? GF: People should read section 4.6 and see whether they agree or not. The summary is not getting consensus, and folks might agree on the text. FB: Looking for mailing list discussion, GF will initiate. Charter items ############### AQMs' evaluation process and criteria Naeem Khademi -- slide: Advantages of RED BB: RED goal was also to avoid lockout of large packets. MM: Yes, lockout was mentioned in RFC2309. -- slide: Implementation: SFQ_CoDel, SFQ_RED, SFQ_ARED, SFQ_PIE(?) FB: Implementing fair queuing still requires drop algorithms, when you run out of buffer, etc. Scheduling and dropping are different topics. AMcG: Scheduling and dropping interact. Jabber, GW: We have an SFQ_PIE implementation in NS/2 -- slide: Ongoing work, ns-2 and real life test FB: We would really like to see UDP- and RTP-based flows in measurements. MM: Note that many of these measurements depend on AQM and scheduling and flow classification. You could be doing not AQM testing but traffic management testing, which may be out of scope for this group. There are tradeoffs that you can't fix with AQM alone. BB: We must be careful about confusing autotuning and sensitivity to parameters; autotuning means that it can figure out what parameters it needs, whether it's in a broadband network or datacenter. Insensitivity means that once it's figured it out, it's okay. David Ross: We plan to separate it. BB: You're confusing the parameters between PIE and CoDel; they aren't even similar. DT: CoDel doesn't have a fixed update interval. It'll autotune it. Will comment in e-mail. Going back to RFC2309, and a reference to self-similarity paper, we need to revisit this. Speed has changed and core applications have, too. FB: Many papers came out to update that original paper. DT: Testbeds are important, we should make sure that this is repeatable. I'd be delighted to help specify the testbed, it doesn't have to be expensive. Anoop Ghanwani: Topology is very important; short RTT vs. long RTT, and mixed speeds, and varying numbers of hops. (note: This was specifically in the context of evaluating fairness of the algorithms, and was about the fairness across sessions which are experiencing different RTT, different speeds, different number of hops, etc.) AMcG: It's important to have large numbers of flows and very short RTTs, to represent data centers. ARP, ND, DNS may be sensitive to the AQM in use; any change could be very noticeable. Rong Pan via SMS: Design cost needs to be investigated as well, otherwise we have a fancy algorithm than nobody can implement. GF: We need a lot more text for this I-D. Do we want various test scenarios? Can we have 1 second and 1 microsecond RTTs together? AMcG: We will see this kind of thing, and we need to know what AQMs will do. DR: We will get a draft in a few days, not a few weeks DT: My favorite scenario has dad doing a $1M deal over the phone, his wife doing a big Facebook upload, and kids playing video game, plus the NSA devices sprinkled around uploading their bits, and quality of experience is important. We should really model the 2.4 billion people out there. BB: All of those applications have a datacenter at the other end. Note: At one point Dave Taht made the joke: "A decent aqm/packet scheduling testbed is nowhere near as expensive as the large hadron collider." This was funny enough that it should be mentioned in the minutes.