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

[MUSCARIELLO Luca OLNC/OLN <luca.muscariello@orange.com>]

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

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?

3) can you plug other qdiscs in QFQ+? Is  QFQ+  a candidate to replace 
HTB (or DRR) in Linux?,
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?