AQM IETF-89 Minutes IETF 89 in London, United Kingdom Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) Minutes Takers: Alex Zimmermann, Spencer Dawkins, (Lars Eggert) WG status agenda not bashed ------------------------------------ draft-ietf-aqm-recommendation Fred Baker / Gorry Fairhurst short WGLC will be started after IETF89, no objections ------------------------------------ draft-welzl-ecn-benefits Gorry Fairhurst/Michael Welzl Next Steps - Is a document like this helpful? Fred Baker: yes the doc is helpful, especially to make sure we don't trip on other mechanisms that are also trying to help. Lingli Deng from China Mobile: Have you done any experimentation about how pervasive ECN is on the Internet? Google has explored this, their conclusion is that the percentage of well-functioning ECN is below 20%. ECN has a long history, however is still not widley deployed Michael Welzl: General feeling is that is much more possible than those numbers. Please send link to the list? Stuart Cheshire: Thanks for the work. Good to get the message out. Was independently looking at Apple perf issues, did measurements, found surprisingly good results from ECN, wondered why not used more widespread. Will show graphs at TSVAREA. Michael Welzl (Anwser previously Q): Linux has ECN available (it responds with ECN if it get a ECN market SYN), MacOS has turned off by default. Bottleneck router needs to do ECN marking. Point of my presentation is get router vendors to do it. Mirja: We have some results showing a population around 30% of servers support ECN. Stuart: Consider 30% a large number for adoption of a technology that doesn't actually do anything yet Mirja: Not so large after 30 years. Dave Taht: Came up with six negatives of ECN before started drinking. Agree that expressing ECN benefits is very good. Would put out anti-ECN manifesto, or roll into one document? Michael Welzl: Can have a long conversation about this. Al Morton: Friend (former AD) said "ECN should be made historic". Will try to get him to comment. But is good work, please do. Mirja: Is helpful, need to be more careful on how to describe. If you use it wrong, it can cause issues. Can't tell you exactly now what should be in the doc. Document would be useful IF we write it right. Need to more exactly describe scenarios where you see benefits. Matt Mathis: There are documents that never make it out of being Internet Drafts (never published). Mirja: How ECN is being specified is currently changing (immediate ECN) Gorry: Is this type of document useful? Mirja: ECN could be much more useful than it is right now. Michael Welzl: Yeah Matt: Like to have a documents that presents a balanced point of view. RED manifesto made requirements that they thought would apply for all times, but... If you turn on ECN on industrial strength server, expect to see a small number of routers with issues. Andrew McGregor: If you're trying to enable ECN in a large content provider, you can find the routers that cause you problems and disable ECN toward the subnets behind them. It can be a more serious issue to deal with mark-equals-drop ECN on the outside and early-onset ECN on the inside, since traffic often crosses the same switches in both cases. Dave Robinson: Interested when you have some flows that are ECN protected and some flows not. Last hop device may have different flows coming from different sources. Dirk Kutscher: Use cases, what you can achieve. If audience is outside the working group, that's the right approach. The focus for this document should be an audience outside of this WG. Stuart Cheshire: Answer point that Dave made. Easy to only care about bandwidth in this community. Fairness. OK, if I use ECN i may not get a fair share. I don't care. Care about bufferbloat, latency. Don't care about Bandwidth. As BW goes up, fair share doesn't matter anymore. Someone asked "does ECN work on OSX, how can I do it. Use sudo sysctl -w net.inet.tcp.ecn_initiate_out=1 sudo sysctl -w net.inet.tcp.ecn_negotiate_in=1 (MAC OS X). There is a benefit to playing with it for real rather than just reading about it in the drafts. Bob Briscoe: recommenend that this draft adds a section on use cases, explaining what applications benefit and why. Also interesting to have a draft on deployment challenges, but it should be a separate draft. Jana Iyengar: Haven't read the draft. ECN is just a signal. If explaining it, want to be clear how the signal can be generated, and how it can get used. ID not the best way to teach a religion. Michael Welzl: Different spec on how it is generated (RFC 3168) Andrew McG: Type of the document maybe "perpetual draft". Or maybe it's not this doc but a different one Jon Crowcroft: if you encourage people to get rid of bufferbloat, Cisco will buy less memory, so people save money. Win win. Richard: Should we adopt this in AQM? Gorry: As TSVWG chair, I don't think we need to adopt now, and AQM may not be the right place. Should talk about whether this doc is the right doc. Wanted feedback, and got feedback. ------------------------------------ draft-kuhn-aqm-eval-guidelines Nicolas Kuhn et. al. Lars: Why it is useful to have metric on the queue? Nicolas: We believe having metrics on the queue length would help us react, the benefit of having these metrics may be specific to a particular algorithm. Matt Matthis: The queue will add additional delay Scott Bradner: several years ago I tried to collect queue length statistics from routers and got NO useful data. Statistics varied by 17 percent with exactly the same traffic inputs. This might work for you, but it didn't work for me. Question from "john" from Jabber room: What about multiple queueus (sfq, etc)? ??? there could be buffers along the path. Can you tell AQM is doing its job? Rong Pan: if we come up with a new method of curing cancer, the person has been cured, but if we want to prevent cancer, curing cancer after you get it doesn't help. It's the same with queue length. Matt: ??? Michael Scharf: On link utiliziation, want to see how you measure this on a real box with multiple queues, diffserv, etc. Is really difficult. Add an example on how you want to measure this metric Fred Baker: Place I'd really like to know queueing delay is input queue switch, with multiple racks, etc. I don't know how to tell you in an input q switch, how to calculate q delay. Might be able to tell you "on this card", but measure through the box really hard. Dave Robinson: For adaptive streaming, all we could do is algorithmic way to compare 2-3 simulations. Dave Taht: I care a lot about interflow latency, jitter, and packet loss. Only bursty packet loss is really bad. I'd like to have a metric on interflow latency, jitter, and packet loss. Al Morton: This is a lot like benchmarking. If you want to do this sort of evaluation, we have folks that have experience. 2nd comment: QoE requires content. Lars: Could we level-up this discussion? We should ask 1) what is good for a queuing algo, and 2) what is bad - when we get results, can we tell from the results whether what we saw was good or bad? Ruediger Geib: Good depends on the application. Andrew McGregor: We can agree on algorithms that are disasterously bad (laughter). I've had good results scatter-graphing *input bandwidth* vs *packet loss*, which were very illuminating. We can also describe what the requirements for algorithms to be composable, to avoid their control systems fighting each other. It's not clear we know exactly how to do that, but it is critical that we do this. Chris ???: How you deal with cases where deal with power consumption? Lee Howard: We do not know what the end is and we don't know what the link is Lars: we should narrow down the common set of metrics Dave Taht: we should also take care about packet scheduling Naeem Khademi: It's up to the AQM designers to justify the cost of their proposed AQM given a set of scenarios/environments where their AQM is aimed to operate at. Is it mandatory for them to design an AQM that is justified in cost for every possible network scenario (e.g. w/ packet scheduling, etc.)? Answer: no! Naeem Khademi: Do we require them (or is it mandatory) to justify the cost of AQM implementation in where they define their AQM to operate at? Answer: yes! Lars: before defining metrices, we should define first the goals we want achieve. Then we can talk about metrices to achieve this goals Gorry: I like this work, but we need a shorter list on metrices ------------------------------------ draft-lauten-aqm-gsp Wolfram Lautenschlaeger (presented in ICCRG) draft-white-aqm-docsis-pie Greg White (presented in ICCRG)