Active Queue Management (AQM) BoF

Background (chairs)

Introduction to the BoF and brief summary of AQM discussion in TSVAREA at last IETF.

Recommendations (Fred Baker)
draft-baker-aqm-recommendation

Lars Eggert: Generally, I agree with all of this. This is written as if there are multiple algorithms - can there be one?
Fred Baker: One of the problems in RFC 2309 only specified one algorithm. I think there is room to have more than one algorithm. Instead of saying, let's substitute a different algorithm, we need to update the recommendation. The important part is what the characteristics of the algorithm(s) are. There are environments where an algorithm that works on enqueue is required, and others where one that works on dequeue is fine.
Lars Eggert: I want to avoid a stream of proposals for new algorithm proposals.
Jim Gettys: I agree with what Fred said. I think Number 5 (see slide deck) is where it becomes interesting when there are multimedia flows, e.g. drop a bunch of related packets because I won't need them anyway. Some hints might be interesting.
Fred Baker: The target in TSVWG is please do not look for a SYN in a stream and treat it differently.
David Black: Right. What about different markings in an AF class, so that you preferentially drop based on DSCP headers.
Jim Gettys: That is another piece, related packets in a stream, i.e. a frame of video. If you drop one of them, you might as well drop all of them.
David Black: What I'm suggesting here is, if you use DiffServ, you don't go fuzzing around L4 or above.

--: I have a question about 4. I saw a gigabyte file transfer that messed things up.
Fred Baker: This is not about file transfer. You had a large TCP flow that moved an awful lot of data and was filling up the queue. You can also use diffserv to prioritize.

Stewart Brynat: I think this also must be hardware-friendly.
Fred Baker: Define hardware. 
Stewart Brynat: Something that looks in the queue and modifies RED parameters would be much quicker to deploy.
Fred Baker: We can choose to build new hardware, we can do firmware.

Jim Gettys: It is clear that CoDel is difficult to retrofit on old platforms.
Ian Smith: A comment about application awareness. It's more useful to let the app do the queuing, than within the network.
Fred: What we are doing is we are communicating from somewhere in the network that perceives a problem and is at the right place to know about that problem, back to the transport, functionally the application, which is sending the data, to reduce the amount of traffic that it is keeping in the network. This is Congestion Control. AQM is about dealing with the information, where you have the information.
Ian Smith: I think that networks should not second-guess what applications need, or figure out what segments belong together. That is far too hard.

Lars Eggert: I agree. Maybe this should say, the algorithm must be application agnostic. Apps will evolve - it will soon be wrong.

--: Do you want to define a concept of fairness between flows? Is that a requirement to have fairness?
Fred Baker: I do not know about how to measure fairness. I do think we want to make sure this is not unfair.
--: Shouldn't that become part of the recommendation?
Mirja Kühlewind: I think that fairness is a matter for the transport not the queues, so we should be clear about this. It may become a requirement to not introduce some kind of specific fairness here.
Fred Baker: In any type of WFQ environment with stochastic properties, there's an advantage of a drop to the packet that is going to wait the longest.

Example Algorithms for Consideration
PIE (Rong Pan)
draft-pan-tsvwg-pie

Hannes Tschofenig: I am curious on the argument that CoDel cannot be implemented on specific hardware.
Jim Gettys: This is why we need more than one algorithm. There won't be one universal algorithm.
Hannes Tschofenig: Can we have more than one algorithm?
Ken Gray: What is the implication of deploying ECN.
Rong Pan: For PIE this works with ECN or drop in the same manner.
Fred Baker: The algorithm decides the packet, you can then apply ECN.
Anurag Bhargava: We heard that RED can be complicated. Multiple algorithms may be confusing in the perception of customer. Are we recommending having AQM enabled by default on a queue?
Fred Baker: We specify multiple TCP stacks - customers see this controls congestion, and this is OK. This is true in this case as well.
Anurag Bhargava: When there are multiple classes sharing one queue, for class-based PIE, you would have multiple parameters?
Rong Pan: ANB parameters will be same, but the drop probability would be different for each class.
Mitch(?): If you measure the delay, wouldn't it be easier to measure the queue occupancy? That would translate from the delay control problem to a buffer occupancy problem, which might be easier?
Wes Eddy: We defer to answer this once we have formed a working group, where we can beat the algorithms to death.
Andrew McGregor: There is one easy answer to that: It may not even theoretically possible to know the drain rate of a buffer in advance. And this is even true on ethernet.


FQ_CODEL and/or variants (Andrew McGregor) draft-nichols-tsvwg-codel

Fred Baker: I remember the argument that the fairness resolves all the issues, when WFQ and AQM would be out there. This ends up not being true, because of operational requirements and because new products such as VoIP being introduced we needed classes in addition to fair queuing.
Jim Gettys: This doesn't mean that you do not need other classes of traffic.
Hannes Tschofenig: What does classification mean - do you refer to Deep Packet Inspection versus DSCP?
Andrew McGregor: The working group needs to talk about DSCPs and how to handle these.

Toerless Eckert: Performance question - people have been doing TCP friendly rate control for some time, some flows typically get more than others. How does this change with FQ-CoDEL?
Andrew McGregor: It makes the network stiffer, but I can't say exactly.


Ted Hardie: Can we recommend application behaviours? - Are you referring to what transport to select?
Andrew McGregor: Yes, and what applications do with DSCPs.
Ted Hardie: It's hard to know what AQM you will encounter on a path.
Andrew McGregor: This is a question for the group, I can't claim to know the answer.
Jim Gettys: Video players that run flat-out will fill the buffers along the path. This would be less of a problem, if the players wouldn't try to go as fast as possible when they can.
Dave That (via jabber): This is made worse by locating services close to users - resulting in small RTTs.
Ted Hardie: Pacing could also result in problems. It's hard to detect what is going on in the network.
Jim Gettys: I did not say this was easy
Stuart Cheshire: I think we need to think about the incentives to getting this deployed - there are many players along the path and we need to make this a priority, so this gets deployed. 
Jim Gettys: There are many people who need to understand the problem, service calls cost the industry, potentially as much as replacing the problematic equipment.
Andrew McGregor: FQ-Codel can make a big difference, in other cases you need different algorithms. FQ-Codel is not for all environments.

###
How many people have read the charter (hum 2/3), not (1/3).

###
How think this is well-scoped work? hum agreement, none against.

David Black: Can I make the use of diffserv codepoints out of scope.
Andrew McGregor: DCSPs have a role here, there is a question about whether to use DSCPs for flow separation. This is a question for this group.
David Black: Fine, but get advice about DiffServ when it comes to that.

###
Should we take Fred's document as an initial working group item? (hum), none against.


Fred Baker: I suggest we focus on AQM first, add some FQ scheduling in a recharter later.
Jim Gettys: I have to slightly disagree with Fred. Certain AQM algorithms really don't work well when mixed with flow queuing, and can make things worse. Scheduling should be in-scope.
--: There has been a lot of research on packet scheduling, so i don't know what the scope we are asking from this charter is.
Gorry Fairhurst: I think we should cast the net slightly wider than just PIE and FQ-CoDEL. If we limit the scope because of these two well-developed algorithms, we may begin to worry.
Stewart Brynat: Makes sense. But I'm asking, am I required to keep per flow state on a core router?
Andrew McGregor: Not required, but if you can, we should be able to say how you can win from that. Multiple algorithms are a good here. Neither FQ-Codel nor Pie is perfect. If I have routers with many flows, there is a point at which this becomes unsustainable.
Fred Baker: Question is, if Packet scheduling should be part of the charter, of what the IETF should recommend.



###
Should packet scheduling be a part of the discussion? (i.e. without flow isolation mechanisms or as a recharter)

Should we exclude flow isolation (hum: ) Should we permit flow isolation? ( ) Don't know ( )

Mirja Kühlewind: is this really only flow isolation, different service classes excluded.
Ruedriger Geib: I'm interested in using WRED etc with MPLS and I don't know what a flow means in this context. I would be nice to recommendations? Also, I would like to have this not only on the edge. SHOULD, not MUST
Andrew McGregor: Should packet scheduling be a required part of algorithms or not?

Tim Shepherd: I would like to encourage things like FQ-Codel. We don't want to step off into research in the charter. I don't know if we want to have people show their research in the working group and picked up by it.
Hannes Tschofenig: It would be stupid to not pick up FQ-Codel, as it is a good algorithm.
Jim Gettys: Importance is to give purchasing info to promote deployment of certain algorithms.
Hannes Tschofenig: Output of the WG in addition to Freds document, should be informational documents that describe these algorithms.
Michael Welzl: The idea of excluding scheduling is weird - at the same time as requiring this is equally not useful.
Michael Abrahamson: I do not understand why we would exclude packet scheduling as an option.
Lars Eggert: If an algorithm comes with a good evaluation this makes sense.
--: I would like to emphasize that. Given that FQ-Codel has the broad support of the open software community, if we are excluding it, we risk to marginalizing ourselves to some extent.

###
Should the initial charter exclude flow isolation? (none),  be within charter (strong hum).

--: Are you saying packet scheduling is within the charter?
Wes Eddy: Packet scheduling may be allowed as a part of an AQM algorithm. 
--: This is where my question is coming from. If we allow them to go together, there will be lots of algorithms coming in that are driven by the packet scheduling. These are two separate entities.
Wes Eddy: This is why we need to define requirements and good evaluation criteria as Lars said.
Andrew McGregor: And yet we have an example that they run synergistically.
Randall Stewart: Is there IPR in any of this?
Jim Gettys: CoDEL has no IPR, and is dual-licensed. FQ-CoDEL is GPL for the prior work on FQ.
Fred Baker: IPR exists for PIE it's filed with the IETF.

###
Should a group be formed (very strong hum) No? (single hum)

Adjourn BoF at or before 1830