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

 ******************************************************
 AQM Agenda
 IETF 91 in Honolulu, HI, USA
 Monday, November 10, 2014, 13:00-15:00 HAST
 ******************************************************

 WG status
 ---------

 13:00
 Agenda bashing
 AQM status
 Process for adopting algorithms
 Chairs
 10 min
Recommendations draft near done.
Five items recently adopted (see slides)

WG items
 --------

 13:10
 draft-ietf-aqm-ecn-benefits
 Michael Welzl
 10 min
Pitfalls listed in latest version.

Aim for WGLC at Dallas, add

Mirja Kühlewind: should there be a recommendation to use ECN? As it stands the
conclusion seems a bit weak. Michael Welzl: Opposed this, such a recommendation
would have to be specific on how exactly ECN should be used, we can't say how
to implement; document avoids that ? from Google: but you have a statement ,
Andrew McGregor Steve Padgett: Remove the statement about routers marking
packets in congestion. Andrew McGregor: remove the statement - cover this in
another document.

 13:20
 draft-ietf-aqm-eval-guidelines
 Naeem Khademi et. al.
 40 min
(slide 3)
Fred Baker: Do you have specific AQM algorithms in mind that cannot
   support ECN? We want the
AQM to be compatible with TCP.
Naeem Khademi: We wanted to make it possible to document an AQM without
   necessarily having to document all the ECN parts.
Fred: I wonder if we’re designing incompatible ways to set ECN depending
   on which algorithm you choose. (..)
David Black: Allowing non-ECN support is not a good way ECN; what is the
   concern?
Naeem: RFC says should mark where you drop. Else you must specify how.
Mirja: the requirement for ECN should be SHOULD, so that if you don't do it
   you have to reason it.
Naeem: Probably we need to change that to at least a SHOULD.
Andrew: in an AQM algorithm an ECN-mark is not drop-equivalent. Question
   to be answered in designing the algorithm.  How does it work with that
   between different algorithms is also a question.
David: One the one hand we need some queue managers that do the right thing.
   Flip side is that there are proposals to do clever things with ECN.
   Those ought to be out of scope.

<???>: We need a definition of congestion levels - suggestion of using
   packet loss rate is appropriate.
Rong Pan: question about congestion levels. Depends on link speed. What
   is the proposed test scenario?
Naeem: we need to come up with a better definition of congestion levels.
   Instead of having static number of flows and mapping to congestion
   levels depending on link speed. Equation that would tell you how many
   flows means what.
Rong Pan: Drop percentage is a better indication.
Andrew: I can give you public paper that is about comparing drop rate on
   AQM to what you would expect given the arrival process into a droptail
   queue. (..) but there is a way of disentanglement. ###
Richard Scheffenegger: Please send this reference to the list.
Andrew: Will send.

Bob Briscoe: UDP CBR (slide 4) - as another example, unresponsive UDP VBR
   should be there too.
Fred: Another important part is how bursty a video comes out. A burst of
   packets for an entire video frame can do really bad things to competing
   traffic.
Bob: If video is competing with elastic traffic you want to keep the video
   going and the elastic traffic to be elastic.
Bill Versteeg: It is important to talk about effect of bursts .. .queues
    .. within a queue .. talk to you later offline.

 14:00
 draft-ietf-aqm-pie
 Rong Pan
 20 min

Bob: code on de-randomization is wasted. There is a PhD thesis that proves
   you cannot de-randomize with 2 or more flows. Each flow has a random
   chance of a drop, so the drops will get the outliers back again.. Even
   when you look at the aggregate and you had removed them.  It’s fine
   for one flow.
Rong Pan: Understand your point, this was for low multiplexing scenarios
Yuchung Cheng: Why do you need to do de-randomization?
Rong: sometimes in low multiplexing scenarios your TCP flow got hit twice.
   You can lose throughput on that flow.
Yuchung: I think it’s the opposite. Normal standard TCP reacts once every
   RTT. If you drop it too close you only get to reduce the rate once. If
   you drop it an RTT apart then you get to reduce the rate twice.
Rong: Also notice slow start when you drop too much, it may stop early.
Yuchung: Yes, that’s another issue. In this case you actually try to drop
   it a little bit further apart.
Bill Versteeg: We’re talking about different time scales here. This trying
   to spread it out 3, 4 or 5 RTTs or even further.
Rong: we got first results, very encouraging.

Michael ??: this is working in silicon?  How can you know the milliseconds
   of the buffer delay?  This says it's measured in bytes.
Rong: we’re measuring at an interval above 10-20 ms, we can’t go to the
   granularity of a couple of ms because the up and down of the link is
   too much
Pat Thaler: You know the queue service rate.
Michael ??: ?: I’ve done it - if you have multiple queues that are being
   drained at different speeds. You never know how deep the queue is unless
   you measure ms.
Andrew: What Rong is explaining is how to do that. You estimate the departure
   rate by observing bytes sent over an interval.  You get an estimate of
   how deep the queue is. Doesn’t have to be exact.
David Dolson: PIE is a proportional controller. Why haven’t you formulated
   the math the way I learned it in school.
Rong: I have
David: So actual algorithm is derived from that but you just didn’t present it?
Rong: Yes. Detailed maths can be found in reference paper.
David: You could characterize the algorithm in a step fashion, going from
   1 to 2 MBit/s, it would be interesting to know how it reacts.
Rong: Yes. But different from books we learn in school, this is not mechanical,
   everything is software based. So we can make things faster if we want.
   That’s why auto-tuning helps also. We can choose different control
   parameter, different configuration, different time.
Jana Iyengar: Willing to send paper to list. ###
Rong: Sure. But after published draft if I receive comments about inaccuracy
   and improvements I’d really appreciate that.
Richard: who would be willing to review this?
Jana and Fred. ###

 14:20
 draft-ietf-aqm-codel
 Andrew McGregor
 20 min

Asking for editorial checking - this is the revised version of the original
Kathy Nicoles draft.  Also need to get Van's technical updates and tweaks
to the algorithm, but no date for that. Probably before the next IETF in Dallas.
Document should serve as a reference document for derived mechanisms.

Bob: I sent an email some time ago to Van and Cathy about a couple of questions
and never got a reply.
Jana: I will follow up and talk to Van, and post the reply to the list also.

 Algorithm Proposals
 -------------------

 14:40
 draft-hoeiland-joergensen-aqm-fq-codel
 Toke Hoeiland-Joergensen
 20 min

Rong Pan:  When a queue becomes empty, that queue is removed: what is the
   dequeue mechanism here? Do you hold it for a reasonable amount of time?
   When you have a new flow, how long till you de-queue?
Toke: You’re talking about potential for lock-out. If you manage to hit a
   queue with packets so that it goes away and you could have it perpetually
   de-prioritized. That can not happen because the empty queue goes into the
   old flows, before being deleted. There they keep an empty queue for
   a cycle so it keeps then in the round-robin.
Rong: Does this depend on how many competing flows are there
Toke: The hash is random so it’s very hard to predict which queue you are
   going to end up in, though you’d have to burst a lot of packets. The
   effect is even worse on a FIFO or normal AQM queue.
Rong: I’ll ask offline
Bob: You say would be better to have more queues than SFQ so there is less
   chance of collisions. The more empty queues you have the more likely
   you are to start taking bandwidth away of others.
Toke: only if they are active
Bob: you can have 1000 first packets then it will be long time for the old
  flows to get serviced again. Seems to be a rather arbitrary distinction
Toke: you can’t get worse behavior than with a FIFO queue
Bob: you could, you could get lock-out
Andrew: two little subtleties here. You can’t completely lock them out. When
   a queue flow is removed from the old flows list, CoDel state is not deleted,
   CoDel state still remains valid, for another packet arrives to the queue.
   It doesn’t reset the CoDel state until it knows that there hasn’t been a
   packet in the queue for a (very) long time (seconds).
Richard: Who has read this latest version of the draft? Show of hands?
About 4-6 people
Richard: What is the WG opinion? Decouple scheduling from AQM in this draft
   as was suggested or keep it together?
Andrew: I’d like to adopt it, and keep it in its present form. While the
   idea of decoupling scheduling from AQM is a good idea, from the point of
   view of documenting what’s out there it would be good to have the document
   as it stands.
Fred: I agree with that. Decoupling could be helpful for long delay paths.
   Almost any AQM algorithm hits its limits; being able to turn off that
   thing in favor of e.g. tail drop would perhaps be useful.
Bill Versteeg: We should document existing code. In moving towards FQ scheme
   the good news is we use the same structure and good basis for generic
   queuing algorithm.
Jana: The draft quite nicely documents interfaces between AQM and de-queue
   mechanism.
Toke: would be quite doable to separate it out in the document.
Rong: But the implementation of FQ and Codel is quite intervened.
Andrew: implementation is deeply entangled but that’s because of the way
   it’s written. Conceptually it could be decoupled.
Rong: Do I understand this correctly that CoDel and FQ_CoDel are together?
Andrew: in Linux; that’s an implementation artifact, they’re not conceptually
   entangled. In principle you could write an implementation where any AQM
   mechanism could be plugged in.
Toke: Linux has an implementation of CoDel by itself and the heavily entangled
   FQ_CoDel implementation
Jana: the implementation entanglement is a feature, not a bug. But in terms
   of features and documentation we want to clearly disambiguate where
   interfaces are.
Andrew: It would be much slower if it were coded without the entanglement,
   but that’s just an implementation consideration.

Richard: Should this be adopted for a WG item - strong hum in favor, no hum
against.

Jana: quick comment. If CoDel was accepted as well then descriptions could
   be eliminated from this draft and replaced by references to CoDel in the
   FQ-Codel draft.

Richard: need additional WG feedback on draft-ietf-aqm-fq-implementation

Fred: yes