On Apr 24, 2013, at 12:38 PM, Dave Taht <dave.taht@gmail.com>
 wrote:

> On Wed, Apr 24, 2013 at 7:00 AM, Fred Baker (fred) <fred@cisco.com> wrote:
>> Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.1?
> 
> Sure. If we have to struggle for consensus on that, we're in for an
> uphill battle. :)

Yes. But it still pays to check one's assumptions.

> I don't make the solid distinction between packet scheduling
> algorithms and queue length management algorithms as you do.  the
> phrase "active queue management" is a bit overloaded and I tend to
> blend together packet scheduling with a queue length management drop
> strategy when thinking about it.

Well, yes. You do tend to blend the conversations. That makes it hard when one is trying to have a specific conversation. For example, if I am looking specifically at the effects of CoDel, PIE, AVQ, or pick-your-approach, and the response I get blends in queuing effects, I don't know whether the result seen is due to mark vs drop, randomness vs determinism, or the queuing methodology. It's kind of like if we try to have a conversation about oranges and how the taste affects people's preferences, and someone yammers about the color and bug-resistance.

The reason I approach it this way - and I'm open to other viewpoints, but I'm expressing my own here - is that (a) queuing is rather a different mechanism, and (b) for each queue in a WRR system or class in a calendar based WFQ system, I'm still going to need some mechanism to signal to TCP/SCTP in the form of dropping or marking. In a WRR system, I might apply AQM in each queue, and I might even apply a *different* AQM algorithm or set of parameters to each queue. So I would prefer to have the dropping/marking methodology separately described from the queuing methodology.

Let me comment for a moment on what queuing does. The logic behind packet-pair and packet-burst is that as data segments go in the forward direction, they will be spaced out at the rate of the slowest link en route, which is the actual bit rate of the link (at least ideally) reduced by the mean rate of competing traffic at that instant. As a result, the ratio of the number of bytes or segments acknowledged to the interval between first ack received and last ack received gives you a transmission rate, and the resulting ack pacing has the sender sending (after slow-start and in the normal case) at precisely the rate of the bottleneck as so measured. If I use FIFO queuing, it is possible that my segments arrive in a burst, and so measure the rate of the link rather than the rate of the link less the traffic I'm competing with; it won't be until the third or fourth RTT that I can clear that out of the measurement. If I use a fair queuing technology (WRR or WFQ), I'm explicitly allowing competing traffic to take transmission slots between the segments in the segment burst, so that I am more likely to measure something akin to the rate of the link less the traffic I'm competing with. So any form of fair queuing will have a superior effect on the sender to FIFO. War stories on request. It's a very effective technology.

BUT - in any queuing system, whether WRR or WFQ and whether per-microflow or by some other classifications schema, you want to apply the drop/mark technology to an individual queue or class, not to the entire system. Imagine, if you will, a WRR system with N queues, one of which has a stampeding elephant in it. Let's further imagine that you are dropping or marking packets after the total system has more than some number of packets in queue. If you apply that logic to the queue (or a packet dequeued from the queue) that has the stampeding elephant, you have some probability (perhaps 1) of signaling to the elephant. If you drop/mark from any other queue, you have a probability of 0 of hitting the session that is currently making life difficult. So restrict the drop/mark algorithm, whatever it is, to to the deepest queue in the system. Implementers of other approaches can transfer the logic to their paradigms.

Coming specifically to flow queuing, as you call it, what you have is a WRR system in which zero or more micro flows go to individual queues that are expected to fill and remain full while everything else goes to a distinguished queue that is normally empty or not very deep. The distinguished queue might be given priority (if it has traffic, that traffic always goes "next", but the expectation is that it is empty a significant percentage of the time) or might simply take its turn with the other WRR queues. The WRR queues operate in rotation, either each getting a packet to send or sending up to some number of octets in DWRR manner in rotation. Flows with allocated queues leave their queues when their queues go empty, and flows in the distinguished queue get moved to other queues when the distinguished queue is deeper than some threshold and one of the other queues is available. In a CoDel world, I would expect a packet to be dropped/marked if it waits for more than some interval, which is most likely to apply to the per-flow queues. In a PIE world, I would expect only those queues to become deeper than the threshold of interest, with the same effect. But I would expect neither to apply to the distinguished queue, at least in the normal case, because that queue rarely attains anything resembling a deep queue depth or implied latency.

I'm glad you like flow queuing, and I'm all for implementations like yours. That doesn't make the methodology for the entire queuing system or a sub-class of it pertinent to the drop/mark policy of a single queue within it. In my view.



> IMHO:
> 
> "flow queue-ing" + "a drop strategy" is better than either alone and
> allows for better techniques to be applied (notably drop head of a
> given flow and the "fast/slow" queue concept in fq_codel and fq_pie.
> So far.)
> 
> Many of the problems mentioned in section 3 in particular are
> mitigated by better scheduling.
> 
> So I can live with "active queue management" but feel obligated to
> bring up the visibility of scheduling in the draft, if you can live
> with that?
> 
> Related to that, the definition of "active queue management" is rather
> late in the draft:
> 
> "The solution to the full-queues problem is for routers to
>   drop packets before a queue becomes full, so that end nodes can
>   respond to congestion before buffers overflow.  We call such a
>   proactive approach "active queue management".  By dropping packets
>   before buffers overflow, active queue management allows routers to
>   control when and how many packets to drop."
> 
> I have a few days free to take a stab at this draft coming up.
> 
>> 
>> 
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
> 
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm