Active Queue Management and Packet Scheduling Working Group (AQM) IETF 92 - Dallas, TX - March 2015 2015/03/25 17:30 - 18:30 Room: Parisian Chairs: Wesley Eddy and Richard Scheffenegger -------- WG status --------- 17:30 - 17:40 Agenda Bashing & AQM Status (Chairs) AQM Recommendations Draft Wes: Many drafts will be going to last call soon, we need reviewers. Martin Stiemerling: There may still be some things that needs to be addressed, ==> Martin will check on this WGLC upcoming for multiple drafts (see slide 5) Wes: Will not issue WGLC for all documents at the same time, but perhaps with some overlap between 1-2 documents Fred Baker: Sequence of WGLC with two weeks per call has worked well before Wes: Asked for reviewers for the documents draft-ietf-aqm-eval-guidelines: Jim Gettys, Al Morton draft-ietf-aqm-ecn-benefits: Fred, Mirja Kühlewind draft-ietf-aqm-pie: Bob Briscoe draft-ietf-aqm-codel: Stuart Cheshire, Fred draft-ietf-aqm-fq-implementation: Andrew McGregor Wes: documents are good, readable, easy to review. Possible adoption of draft-white-aqm-docsis-pie Wes asked for a hum to see if anyone was against adoption: silence ==> adoption call on list in next few days -------- WG items -------- 17:40 - 17:55 AQM Characterization Guidelines Update draft-ietf-aqm-eval-guidelines Presented by Naeem Khademi (see slides) Discussion: Andrew: packet loss levels now reduced to more realistic numbers, but suggest you use also higher packet loss level, and a slightly wider spread Naeem: we had to pick some numbers; these levels were seen on mildly and seriously congested links. Andrew: ok, that’s reasonable. Wes: we should be careful that it is guidelines for evaluating algorithms, not for designing algorithms. The text on ECN may not be appropriate Gorry Fairhurst: Should we change the wording to separate these? I volunteer to help separate criteria for design and for evaluation Dave Dolson: are we targeting a specific domain? Are 100 000 flows in core router in scope? Or is this specific to small gateways? Naeem: guidelines should be general, numbers given in the talk were examples for the congestion levels (mild, medium, heavy) Dave: does the tester chose number of flows and apply guidelines Naeem: Yes Mirja: I also found the text on congestion levels confusing. Suggest we simplify this text to something more general (large number, medium number, and small number of flows) Naeem: We want to test over a range of flows. Mirja: yes, that is what you should test, just come up with some suitable numbers Mikael Abrahamsson: The specification talks about home router, need at least 100s of flows. There is an upper bound for home gateways but you should have way more flows. Naeem: This is active flows in queue Mikael: yes, fire up bittorrent and you will get 100 flows, should be evaluated for that Matt Mathis: most bittorrent connections are idle. There is an ippm draft that touches on these metrics, can we present AQM characterization guidelines in ippm, there is a lot of overlap with this ippm document Naeem Khademi: This is more of a recommendation rather than a specification like IPPM. Brian Trammell: IPPM chair hat on. need not define all metrics in ippm, waste of effort for these evaluation guidelines. it does not define new metrics that are operational, but for evaluation. We do need wider review from outside AQM. Naeem: some metrics come from ippm Brian: will read draft and come back Szilveszter Nádas: prefer this definition of congestion level as it is independent of the aqm used, just giving number of flows will not be general for any network configuration. I prefer this congestion level defined in this draft. These levels are independent of buffer sizes. Al Morton: benchmarking methodology co-chair hat on: much overlap with ippm and also with bmwg. will try to get bmwg to review. For the traffic mix test scenario, repeatability for different mixes need to be considered, tests with more than one packet size makes repeatability hard. For UDP Stateless we have an RFC that can help with repeatability with varying packet sizes. Mirja: the document is clear and very useful, it should be in line with ippm but not make it more complicated. That's why I suggested using simpler congestion levels. It is confusing to calculate the number of flows to use based on a drop-tail queue and then run it in a different scenario where it results in another congestion level (drop rate) Naeem: tester A and tester B should use the same number of flows if they evaluate the same scenario Mirja: you calculate the number of flows based on the parameters, when you change the bandwidth you get a different number. It is important to compare algorithm behavior in different scenarios. why is it important to have the same congestion level? Naeem: some number of flows will result in mild congestion on one link, not on another Mirja: we just want to cover use cases, don't care about congestion level. Naeem: we could skip the congestion level term Mirja: yes it is too complicated Andrew: want something that takes parameters out of problem. want to have different scenarios somewhat comparable. can be done with the congestion level metric. using a fixed number of flows does not make sense for this. Matt: the problem is a large dimensionality of space, you need to simplify this somehow, I suggest you pick normalized fair share rate as the parameter to hold constant as you scale system Mirja: agree on this Naeem Khademi: These are minor changes, we can make these changes and then move ahead to last call? Wesley Eddy agrees. Gorry: some of the terminology used is different from aqm recommendations document. should we align terminology? Wes: Yes Gorry: offers to review -------- 18:00 - 18:10 The Benefits and Pitfalls of using ECN draft-ietf-aqm-ecn-benefits-01 ECN Presented by Gorry Fairhurst (see slides) Discussion: Gorry mentions that the use of the word “pitfalls” has been removed Matt: suggests “challenges that should be addressed” Brian Trammel: Regarding the scope of the "challenges", how crazy do you want the challenges to be? Gorry: draft is a statement that we should use ECN Brian Trammel: Here's an example of a challenge: "this can break TCP anycast when hashing on the TOS byte" and I wonder where the line is Fred Baker: TCP anycast is already broken Brian Trammel: People might say this is broken because of bad ideas like this, should we put this in this draft? Gorry: broken things are already broken, needs to be fixed, but are out of scope for this document Andrew: consensus call on if ECN marking equivalent to drop is the right thing to do, is a challenge for this doc Gorry: getting ECN correct is a challenge. If people turn it on we will find more issues and fix them. We could say this instead of saying turn it on. Andrew: that precise question is why codel draft does not say anything about ECN. There is no way for code to decide what to do regarding ECN. Wes: document is not a spec for ECN, it is about explaining why ECN should be used Andrew: should be mentioned in challenges section Wes: agree Gorry: document is about what you get if you get ECN to work right Mirja: benefits when you mark ECN earlier – I did not understand this section, do not understand benefits, you will just reduce congestion window earlier and this will make your flow lose Michael Welzl: we should remove this section? Gorry: there are benefits, can be enumerated Michael: yes, may be good Bob: what Koen De Schepper presented in iccrg was one approach to get benefit Koen: this was not earlier marking, but different marking Andrew: fq codel will sort this out, fq codel is going to decide on the marking rate to take you to right level to balance DCTCP and TCP Reno with ECN. Mirja: To get benefits, you need two different queues, or a completely different congestion control algorithm. This would need agreement between AQM and TCP, we should think about it but not in this draft. Michael: yes it is not a specification, current recommendation says mark same as loss, remove any text saying mark earlier. Gorry: need to explain that marking the same implies use of AQM Mirja Kühlewind: If you change your ECN marking behavior you could make it better, that should be noted somewhere. Gorry: new benefit or greater benefit only? Is it same way of benefitting from a higher level perspective? Mirja: new benefit in that you get low latency and high utilization Gorry: ok, low delay better realized Michael: we will remove this part Gorry Fairhurst: We need rev3 and should go to WG last call. Wesley Eddy agrees. Mirja: will review document and see if remark can fit somewhere -------- 18:15 - 18:30 Update on codel draft draft-ietf-aqm-codel Presented by Andrew McGregor, no slides Andrew: Draft has known editorial remarks outstanding, particularly with respect to references, then ready for WGLC. People can review now but in a handful of weeks we will have these editorial issues resolved and ready for serious review. Jana Iyengar: will try to add experiences section if we can find something relevant for this Michael: has some reservation about what happens when algorithm enters square root rule, need justification about the repeated dropping part Andrew: idea is to document codel as it is used in the wild today Michael Welzl: I don't want to get in the way of documentation of current state. Wes: this can be mentioned in list of future research Bob: sent a question on the algorithm to the list long time ago. still waiting for a reply on my mail Andrew: ok, will look into this