Minutes for AQM at IETF-92
minutes-92-aqm-1

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