Subject: [aqm] Question re draft-baker-aqm-recommendations recomendation #1

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 24 Apr 2013 14:00:48 +0000

Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.1?

---

From: Dave Taht <[email-masked]>
Date: Wed, 24 Apr 2013 12:38:54 -0700

> 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. :)

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.

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Jim Gettys <[email-masked]>
Date: Wed, 24 Apr 2013 15:58:08 -0400

I agree with Dave here: there are two issues that are often conflated:

1) a drop strategy to signal TCP to "slow down"; this is necessary to keep
TCP sane (by controlling it's RTT's and avoiding its misbehavior when RTT's
go up) and to try to keep buffers at a sane length.

2) packet scheduling, often between flows (of various sorts); this becomes
more and more necessary as you approach the edge of the network, since head
of line blocking becomes more and more significant.

This kind of scheduling may be unnecessary in the core of the network
(though breaking up large packet trains is always desirable, if we can do
it.)

For example, at 1Mbps (e.g. a shared 802.11 network) I care about the order
in which each and every packet is transmitted.  And with current web
behavior, this kind of "smarts" has become not only desirable, but
necessary for any sort of reliable real time performance.  Sigh...  These
packet bursts are killers.  We can't presume clients are cooperative; they
aren't, and every single application benchmark push clients in the wrong
direction: the network has to protect itself....

Packet scheduling (e.g. fq_codel), also helps handle unresponsive flows,
since such a flow can be identified and scheduled so that it does not
destroy the behavior of other flows.

Whether we use one term or two, these are two sides to the coin of "active
queue management"; it's avoiding drop tail fifo queues that is the win;
signalling TCP in a timely fashion by itself is insufficient.

I'll try to get the text I've written on this topic done this week finally;
I'm recovering from the worst case of flu I've had in over 20 years.
                               - Jim

On Wed, Apr 24, 2013 at 3:38 PM, Dave Taht <[email-masked]> wrote:

> > Do we generally agree with the recommendation of
> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.1?
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 24 Apr 2013 20:10:08 +0000

> Sure. If we have to struggle for consensus on that, we're in for an

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

> 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.