IETF-90 aqm agendaSlidesThese are also available from the materials page:WG Status AQM recommendation (2309bis) Evaluation guidelines SFQ Implementation ECN Benefits The Case for Comprehensive Queue Management Session 2014-07-22 1640-1840: Ontario - Audio stream - aqm chatroom Agenda ****************************************************** AQM Agenda IETF 90 in Toronto, Canada Tuesday, July 22, 2014, 16:40-18:40 EDT (Ontario) ****************************************************** WG status --------- 16:40 Agenda bashing AQM status Process for adopting algorithms Chairs 20 min Fred Baker: Process looks reasonable. Noted that two, maybe three, algorithms are already past Gate 1, while some more than that need further discussion. WG items -------- 17:00 draft-ietf-aqm-recommendation Fred Baker / Gorry Fairhurst 15 min Martin: Concern over obsoleting 2309 and making historic Fred: RED never actually became the default AQM, because there was no sensible default parameter set. Martin: Obsoleting and making historic are two separate events. No problem with obsoleting, since IRTF is OK with that (2309 predates IRTF stream). David Clark: Why do we need to obsolete 2309? Why not just update it? Changing an recommendation can be done in an update. Gorry: This document replaces ALL the recommendations. David: Understood. Fred: Only two recommendations from 2309. One is "we need more research". David: So, obsoletes is correct. Gorry: OK, we take the recommendation from here that we obsolete 2309, update boilerplate from there, and document is ready for publication. Charter items ------------- 17:15 draft-kuhn-aqm-eval-guidelines Nicolas Kuhn et. al. 45 min Andrew McGregor: Not having read the first version, looks adoptable in this form. Dave Täht: It is better. We need more review to make the adoption call. Wes: There's no other proposal however. Andrew: We can add text to this one. Dave: Wifi looks like a "parking lot" network rather than a "dumbbell" network. Nicolas: This is not a MUST, simply the canonical example. Andrew: NS-3 has quite a decent wifi model, which is suitable for testing variable bandwidth situations. Andrew: ECN behaviour should be evaluated, but this is slightly problematic given that there are moves afoot to redefine the recommendations for ECN Bill V.: This raises whether AQM includes scheduling or not... they should be separate Andrew: Whether or not we consider them part of the same algorithm, we should evaluate them together. Bob: The draft implies AQM per sub-queue and overall queue... Andrew: I don't think we can avoid talking about scheduling here, whatever we end up recommending. Some suspect scheduling plus AQM will prove necessary for slower links, but that may not end up being the group recommendation... however, it has to be part of the test matrix so we can determine that result. Bill: Let's clarify that published results should describe what was going on with scheduling in the test. Andrew: re "don't prefer small packets", phrased as a recommendation on the slide, but as an evaluation metric you should describe a test for that property Fred: "Evaluation" means to determine value, i.e. what should I choose. I don't think the draft tells us how to choose this. What it does is give us some clues as to how to characterise algorithms. Might be better to change the title s/evaluation/characterisation/ Dave: Agreed. Jim Roskind: Policers can have strange effect on congestion control, aggregating layers e.g. WiFi. There is quite a bit of weird stuff out there. Preethi: This was intended to be very general. If there are other cases that need considered, fair enough, but I don't think policers particularly belong in this. Bill: The document does include a number of cases Jim R.: the hard part is to replicate reality, which is rather surprising at times. Loss is often modelled as IID losses, but reality isn't like that and TCP relies on the correlations for performance. That's an example, but there could be more. Jim G.: It is one thing to have simulations, and a very different thing to have running code in real systems. There can be a great deal of divergence between simulation and reality. Somehow we should capture the sources of divergence. Andrew: Just highlighting the aggregating MAC point... they are schedulers, and can interact in the same ways as explicit scheduling. Wes: I'm hearing refinements from the room, rather than major course corrections. Really we need more people to read the draft. Maybe we schedule an interim meeting. Preethi: maybe we can expect a list of expected refinements? Algorithm Proposals ------------------- 18:00 draft-baker-aqm-sfq-implementation Fred Baker 20 min Stuart: Is ECN off vs ECN on simply replacing drop with mark? Jim G: Just saying it is Linux is insufficient information, versions matter, hardware drivers matter. Fred: 3.14, don't know about the drivers... but rathole. Dave: Under some workloads, fq_codel behaves as fq, other times it's something else. Stuart: Measuring throughput with iperf is one metric, there are other situations where smoothness matters and iperf doesn't capture that. Andrew: Like the draft very much. Scheduling and QM are separate, but understanding the regimes where the interactions degrade things or help is important. Dave: Have no problem with sending it toward publication. S in SFQ is an issue. Fred: named after McKenny's draft... Gorry: +1, including the S Fred: Repost? Wes: Will talk to area directors about process. Fred: Would like comments now. Bill: Like the idea of exploring transition regimes. If time permits: 18:20 The Case for Comprehensive Queue Management Dave Täht 15 min John Messenger: Some of those underlying L2 networks do inconvenient things because they really have to. Andrew: I believe TSO burst size adaptation interacts with downstream aggregating MACs... I don't know how, but I'm sure it does. Stuart: We need an integrated approach, not that aggregation is bad. Wes: When we form working groups, mail goes to liasons, so they may have understood that we were doing AQM work, but may not have understood the relevance. Better if some people attend both groups. Fred: AQM and ECN start out with the assumption that the primary application is something like TCP that will respond to drops by reducing windows. Down in the link layers, life may be radically different. E.g. in 802.11b, when a radio speaks, everyone hears. 802.11ac has to emulate all the previous versions, and may end up speaking independantly to all stations. This can lose 90% of the available bandwidth, and aggregation is the fix for this. Each has their own characteristics, and they don't assume upper layer is TCP. Jim G: We appear to have good contact with the Linux kernel world, and hopefully Apple, but we're much less confident about Microsoft. Lars: What does the BQL plot look like on 10G or 40G? Andrew: It's a bigger win... the absolute latencies are smaller, but not nearly in proportion to the higher performance. Fred: RMCAT, DART and TSVWG are internet drafts. So far as implementations I wouldn't assume anything much... but they're all based on the DIFFSERV universe, which has been implemented for a long time. Lars: Looks like L2 technologies are good to look at, but also a lot of work. Jana: Link technologies seem out of scope, but it is probably possible for evaluations to be done. x: Network is inside out, we are running wide area network over LAN technology. What is AQM to do with a link layer on top of a transport layer? John Messenger: From the 802 perspective, there's almost no such thing as plain ethernet any more, they're designing more and more complex queueing. Andrew: Maybe changing L2s is not in scope, but adapting to those as they exist is? 18:35 draft-welzl-ecn-benefits Michael Welzl 5 min