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

Really excellent, Fred, on a first reading!

nit 1) drops tend to happen in bursts on a tail drop queue (not
necessarily on this bottleneck, but elsewhere on the network). By
breaking up flows into sequences of distinctly different packets, this
applies minor damage to more flows, instead of severe damage to one
flow.

I don't know where to put this or how to express it anywhere near as
well as you expressed everything else.

2) weighted FQ algos like QFQ and WFQ are interesting from a
take-advantage-of-diffserv perspective. I keep hoping to get a
simplified and more fq_codel-like implementation of QFQ, in
particular.

3) sch_fq is a *perfect* fq algo, instead of using a hash, it uses a
red-black tree to keep track of all flows. While memory and compute
intensive for a router, it's pretty awesome on hosts, and makes it
possible to schedule (and pace) tcp flows at a level much closer to
the driver hardware, using the same new/sparse vs persistent queue
distinction fq_codel does.

4) While I think I finally understand your longstanding criticism of
how aqm and scheduling technologies are indeed distinct, there is a
parameter that must be
shared globally between the two algorithms: the maximum overall queue
length (governing worst case drop behavior). This is the basic flaw of
applying
(at least in linux) sfq, drr, qfq, htb, etc naively with a drop tail
queue, as the maximum overall queue length is additive.

Take for example a simple QoS setup

filter that breaks up stuff into 4 QoS queues:

drr 1 -> sfq limit 127 (prio)
drr 2 -> sfq limit 127 (video)
drr 3 -> sfq limit 127 (BE)
drr 4 -> sfq limit 127 (background)

So you end up with worst case drop tail and delay behavior for drr +
sfq queue of 4*127 packets. If using weighted drr, the proportions
change, but the worst case drop behavior does not. If using something
like htb, the background queue has a worst case drop tail and delay
behavior of 4*127, be, 3*127, and so on. Having a shared overall queue
size is extremely important for being able to classify queues and get
sane behavior. You could, for example, try using 32 packet queues to
get the same overall worst case latency guarantee but you'd sacrifice
bandwidth if the majority of traffic was BE only.

This is less important with a system that tries to measure latency and
be intelligent about drop behavior, but you still have worst case
behavior that is additive in the case of non-responsive flows.

4a) The problem with using individual queues for something like
pie-per-fq'd_queue, is that pie depends on being able to sample X
number of packets in order to determine it's drop decision, which it
may not get relevant to the overall load on the system for flows that
are too small to tweak pie's estimator, yet worth dropping a packet
from.

4b) and the opposite problem in codel, with a single codel queue
taking fq'd packets (rather than one codel queue per fq) is the
reliance on timestamps for dropping in and out of drop state, which
doesn't work if you don't do the timestamp in the right place.

(I'll no doubt find more nits later :) )

On Fri, Jun 13, 2014 at 3:07 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> I’d be interested in comments on this.
>
>> From: <internet-drafts@ietf.org>
>> Subject: New Version Notification for draft-baker-aqm-sfq-implementation-00.txt
>> Date: June 13, 2014 at 2:52:07 PM PDT
>> To: Fred Baker <fred@cisco.com>, Rong Pan <ropan@cisco.com>, Fred Baker <fred@cisco.com>, Rong Pan <ropan@cisco.com>
>>
>>
>> A new version of I-D, draft-baker-aqm-sfq-implementation-00.txt
>> has been successfully submitted by Fred Baker and posted to the
>> IETF repository.
>>
>> Name:         draft-baker-aqm-sfq-implementation
>> Revision:     00
>> Title:                On Queuing, Marking, and Dropping
>> Document date:        2014-06-13
>> Group:                Individual Submission
>> Pages:                14
>> URL:            http://www.ietf.org/internet-drafts/draft-baker-aqm-sfq-implementation-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-baker-aqm-sfq-implementation/
>> Htmlized:       http://tools.ietf.org/html/draft-baker-aqm-sfq-implementation-00
>>
>>
>> Abstract:
>>   This note discusses implementation strategies for coupled queuing and
>>   mark/drop algorithms.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Dave Täht

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