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

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

<support for going forward>

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

<people in room attending other groups that are relevant>

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.

<discussion about definitions and kinds of policing>

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