Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt

[Dave Taht <[e-mail]>]

On Tue, Jun 24, 2014 at 1:01 PM, Fred Baker (fred) <[e-mail]> wrote:
>
> On Jun 24, 2014, at 12:45 PM, Daniel Havey <[e-mail]> wrote:
>
>> So IMHO it really doesn't matter except in the weird corner case where a a running flow has already bloated the queue and then we switch on the AQM.

Hmm? In practice, changing the qdisc in Linux, at least, does
completely blow up the existing queue: all packets are discarded, the
various data structures removed, the new data structures created, then
switched.

Don't do that. Do it once, at init time, or before address
acquisition. Simple schemes can be handled now (linux 3.13 and later)
by a single sysctl variable, set either in /etc/sysctl.conf or via

sysctl -w net.core.default_qdisc=fq_codel # or pie, or sfq, or fq

Arguably this needs to allow for arguments, be more flexible and
interface specific. Same goes for enabling ecn or not.
(net.ipv4.tcp_ecn=0)

More complex implementations, like htb, have a "default" direction
things go until things are fully setup. Other linux implementations,
like drr and qfq, do not, and result in packet loss until entirely
setup.

Recently support for a "plug scheduler" was developed in order to
assist vm migration, which might make it more possible to switch out
qdiscs without interrupting service.


> That actually has me a little worried with the 100 ms delay built into codel.

"Initial delay" until it finds a sane delay to drop at.

>Imagine, if you will, that you have a deep buffer at the bottleneck and a relatively short RTT, and are moving a large file. I could imagine codel’s delay allowing a session to build a large backlog and then “suddenly turning on AQM”. on a 10 MS link with O(200) packets queue depth, for example, you could build 100 ms plus of data in the queue, spend the delay mostly emptying it, and then drop the last queued packet because 100 ms had gone by, there was still data in the queue, and the next packet had sat there longer than 5 ms.

Given that pie depends on an estimation window being filled this is
not a problem pie has. However needing that window filled is a big
problem at low bandwidths for pie.

As for codel....

Well there is a specific inhibit in present forms of codel to not drop
the last packet in the queue even if it has sat there too long. Codel
stops dropping at minbytes (called maxpacket in the code), which is a
variable determined from the flow characteristics, and is usually 1MTU
in size, but can be larger if TSO or GRO are in operation on the
device.

The first versions of fq_codel preserved this behavior: it would never
drop the last packet in any fq_codel queue. This (still) seems like
desirable behavior in the case of having nearly one queue per flow,
but it led inevitably to what I had called the horizontal standing
queue problem (where we could end up with 1024 queues all with one
packet and no longer meeting the latency target(s)). So eric made the
backlog maxpacket check global to all queues, and that's what's been
deployed ever since.

Later work, (I think) is showing, that in practice any inhibit at all
hurts on the architectures available, as htb or (bql and the tx-ring)
are already buffering up packets below where codel was dropping from
near-head.

More packets will always be along, later.

This patch disables the maxpacket check entirely, and results in a
space and cpu savings, without much observable negative or positive
effect on latency and utilization on the bandwidths available to me. I
remain a bit concerned about what happens with TSO and/or GRO enabled.

http://snapon.lab.bufferbloat.net/~cero2/0003-codel-eliminate-maxpacket-variable.patch

I'd love it if people tried it.

Of higher concern to me has long been more sanely applying hysteresis
in the drop rate over wildly varying high bandwidths and loads, but
not a lot of work has gone into codel since it's inception, as it was
so good to start with and so dramatically improved by fq_codel as to
be barely worth debating. But certainly better control laws are
welcomed!
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article