Re: [Bloat] Fw: video about QFQ+ and DRR

[Paolo Valente <paolo.valente@unimore.it>]

Il giorno 09/ago/2013, alle ore 10:48, MUSCARIELLO Luca OLNC/OLN ha scritto:

> Hi,
> 
> few questions in line.
> 
> Luca
> 
> 
> On 08/09/2013 09:58 AM, Paolo Valente wrote:
>> Il giorno 09/ago/2013, alle ore 08:45, MUSCARIELLO Luca OLNC/OLN ha scritto:
>> 
>>> Hi,
>>> 
>>> nice demo.
>>> 
>> Thanks.
>> 
>>> While I am not surprised about the good performance of QFQ+,
>>> I do not understand why DRR (I guess linux SFQ, i.e. per-flow DRR+SQdrop)
>>> works so bad.
>>> 
>>> If the two schedulers are serving the same kind of flow (IP 5-tuple) the level
>>> of protection to low rate (< fair rate) flows should be the same (approx).
>>> 
>> That 'approx' plays a critical role for the bad results with DRR. In particular, problems arise because of the following theoretical issue.
>> Consider the packet service time for a flow, i.e., the time to transmit one maximum-size packet of the flow at the rate reserved to the flow. For each flow, the worst-case packet delay/jitter guaranteed by QFQ+, with respect to packet completion times in an ideal, perfectly fair system, is equal to a few times the packet service time for the flow. In contrast, with DRR this delay/jitter is independent of the packet service time, and grows linearly with the number of flows.
>> Hence, the shorter the packet service time is, the higher this delay becomes with respect to the packet service time.
>> 
>> In the In the test,
>> 1) the total number of flows N is equal to 501,
>> 2) the video-streaming server is reserved a bandwidth such that its packet service time complies with the frame playback period,
>> 3) the time to transmit 500 maximum-size packets at line rate is much higher than the packet service for the video-streaming server, and hence, of the frame period.
> 
> 1) AFAIK, sch_drr.c is class-based queuing and not per-flow queuing (correct me if I am wrong).
Certainly it is a classful queueing discipline. Just to sync with you, what do you mean with per-flow as opposed to class-based?
Do you mean that the scheduler internally and autonomously differentiates packets into distinct flows according to some internal classification rule (as it is the case for SFQ)?
If so, then you are right.

> So, when you say N = 501 flows, do you mean that in your demo you configured class = flow (e.g. 5-tuple)
> or you have multiple applications in the same class sharing a single (class) queue?
> 
500 classes, one for each UDP flow, plus one class for the video stream.

> 2) do you mean that the class "video" gets a weight (per-class weight, with one single video flow in this case?)
> such that, in average, it gets a weighted fair share large enough for the video rate?
> 
Yes

> 3) can you plug other qdiscs in QFQ+?
If you mean creating a hierarchy in which some of the classes scheduled by QFQ+ contain both a different queueing discipline and other classes scheduled by that internal discipline, then yes.

> Is  QFQ+  a candidate to replace HTB (or DRR) in Linux?,
Of course in my position I can answer such a question only in principle. HTB does things that QFQ+ does not, such as rate limitation. In my demo I used exactly HTB to limit the rate.
Instead, as for DRR, its final goal perfectly matches that of QFQ+. There are however scenarios where DRR is faster than QFQ+, and may even provide a better delay/jitter. Basically, it happens when all flows/classes have the same weight and the same packet length, i.e., exactly in the cases where you do not need a more accurate fair-queueing scheduler than DRR.

> or maybe  HTB is already outdated and sch_drr.c  might replace sch_htb.c in linux 3.7.
> 
>> As a consequence, when DRR incurs its physiological O(N) delay, the playback buffer on the client side runs out of frames.
>> 
>>> Maybe Paolo said that in the talk and I might have missed something.
>>> Is QFQ+ working on a different definition of flow than DRR?,
>> No, on the same.
> what is the definition of flow used or class?
> 
flow = class in the test

Paolo

--
Paolo Valente                                                 
Algogroup
Dipartimento di Fisica, Informatica e Matematica		
Via Campi, 213/B
41125 Modena - Italy        				  
homepage:  http://algogroup.unimore.it/people/paolo/