From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alan Goodman <notifications@yescomputersolutions.com>
Date: Wed, 06 Aug 2014 21:21:33 +0000
Subject: Re: SFQ + speed caps
Message-Id: <53E29C5D.1090700@yescomputersolutions.com>
List-Id: <lartc.vger.kernel.org>
References: <53E1EE68.8030503@gmail.com>
In-Reply-To: <53E1EE68.8030503@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: lartc@vger.kernel.org


>  .. but this way I am getting the capped pc out of the SFQ round robin 
> allowing it to monopolize the line up to its hard limit and in excess 
> of what is currently fair. If, for example, the capped pc speed is set 
> at 40% of the line speed and there are 5 active pcs on the lan then 
> the capped pc will managed to steal more than it's fair share of the 
> line. It could manage to go all the way up to 40% instead of 20%.
>
> It appears that HTB must be placed on top of SFQ for this to work:
>
> interface
>  |
> +--- SFQ
>         |
> +---- HTB --- class 1 (capped pc)
>                |
>                +----- class 2  (everything else)
>
> Only problem is, you can't attach a qdisc on top of another qdisc. You 
> can only attach a qdisc on top of a class and SFQ is a classless qdisc.

I believe that this is correct.  You cant feed out of sfq into any 
classfull qdisc.  Your simple SFQ based fairness will also very probably 
break badly if someone sends or receives small packets too...  The 
person sending the larger packets will get a much larger share than the 
person sending smaller packets...

Using htb you could have each user hitting a separate class, each with a 
RATE and a common CEIL so that they can all burst if the line isnt 
contended...  Then feed each of those that info BFIFO with limit set 
just over 2x MTU sized packets (if the connection is relatively slow).  
Alternatively if your O/S has it check out fq_codel.

Alan