Re: is esfq discontinued ?

[Andy Furniss <adf.lists@gmail.com>]

Akshat Kakkar wrote:
> On Fri, Sep 11, 2015 at 2:38 PM, Andy Furniss <adf.lists@gmail.com>
> wrote:
>> Dave Taht wrote:
>>>
>>> I generally recommend retiring sfq in favor of fq_codel or cake.
>>
>>
>> Yea, though as flow hash keys doesn't get a mention in man
>> tc-fq_codel I didn't know if it would work.
>>
>> Testing I see it does, though hashing on src with either qdisc kind
>> of takes away the nice aspects of their behavior WRT giving
>> streams/new a chance over bulk/existing.
>>
>> From the point of view of "being a user" having all my traffic sent
>> to one queue is not really what I would call QOS. I like my games
>> to work even if I am uploading :-)
>
> Its all about being fair if bandwidth is shared across multiple
> users.
>
>> From the point of view of "being a user", I would not like my
> neighbour to do an upload at 10Mbps and enjoy network games at
> additonal 5 Mbps, and me (Oh! poor me) left with only 5 Mbps for my
> job in which I have to _manage_ upload and games both.

OK but in the case of 2 sharing 20mbit then htb per ip + fq_codel for
each would solve that (assuming you wanted a simple just ip
classification scheme). I know many cases will not be so simple - many
users + lower bandwidth and your game traffic ends up waiting too long
for its turn. HFSC in theory may do that better - but you have to start
classifying traffic types and work out how to use HFSC!.

> So in this case it should be fairly distributed as 10 - 10 Mbps
> between me and my neighbour. If I am not using, then my neighbour
> can use my 10 Mbps or vice versa.
>
> However, if the requirement is 10Mbps upload and 5 Mbps for Gaming,
> then my neighbour should have a network plan where he is allotted
> 15Mbps to him and that is only for him and not at all community
> shared and this should be handle by fq_codel per flow and not per
> IP.
>
> So, if plan is per user it should be fq_codel per flow, if it is
> shared plan then it should be fq_codel per src IP.

I like the idea of being able to do both - but it's not as easy to
do/may not scale so well.