PRIO qdisc traffic does not work as expected

PRIO qdisc traffic does not work as expected

[GGounot]

Hello,

This is a simple case I started from lartc howto but I can't make it work.

The idea is :
* 3 priorities
* ftp.free.fr on prio 1
* 0.0.0.0/0 prio 2
* ftp.lip6.fr prio 3

Or, when Internet line is saturated and I download from ftp.free.fr, my 
download should supersede all other downloads (my download should take 
all bandwidth). On the other hand a download from ftp.lip6.fr should 
occur only when there is some available bandwidth.

But actually, when I download from ftp.free.fr and from ftp.lip6.fr at 
the same time, both downloads have the same speed.

This is the script :
_________________
#!/bin/bash

tc=/sbin/tc
ETH=eth1 #connected to the LAN

$tc qdisc del dev $ETH root 2>/dev/null
$tc qdisc del dev $ETH ingress 2>/dev/null

### PRIO ###
# qdisc "prio", 3 levels
$tc qdisc add dev $ETH root handle 1: prio
$tc qdisc add dev $ETH parent 1:1 handle 10: pfifo
$tc qdisc add dev $ETH parent 1:2 handle 20: pfifo
$tc qdisc add dev $ETH parent 1:3 handle 30: pfifo

PRIO1="212.27.60.27" #ftp.free.fr
PRIO2="0.0.0.0/0"
PRIO3="195.83.118.1" #ftp.lip6.fr
#
echo Prio 1 : $PRIO1
echo Prio 2 : $PRIO2
echo Prio 3 : $PRIO3

$tc filter add dev $ETH parent 1:0 prio 1 protocol ip u32 match ip src 
$PRIO1 flowid :1
$tc filter add dev $ETH parent 1:0 prio 3 protocol ip u32 match ip src 
$PRIO2 flowid :2
$tc filter add dev $ETH parent 1:0 prio 2 protocol ip u32 match ip src 
$PRIO3 flowid :3
_________________


When I run :
  tc -s qdisc ls dev eth1
I see the 2 FIFOs showing traffic going through.
I don't understand what I am doing wrong, any help will be appreciated.

Regards.
GG

Re: PRIO qdisc traffic does not work as expected

[Andy Furniss]

GGounot wrote:
> Hello,
>
> This is a simple case I started from lartc howto but I can't make it
> work.
>
> The idea is : * 3 priorities * ftp.free.fr on prio 1 * 0.0.0.0/0 prio
> 2 * ftp.lip6.fr prio 3
>
> Or, when Internet line is saturated and I download from ftp.free.fr,
> my download should supersede all other downloads (my download should
> take all bandwidth). On the other hand a download from ftp.lip6.fr
> should occur only when there is some available bandwidth.
>
> But actually, when I download from ftp.free.fr and from ftp.lip6.fr
> at the same time, both downloads have the same speed.
>
> This is the script : _________________ #!/bin/bash
>
> tc=/sbin/tc ETH=eth1 #connected to the LAN
>
> $tc qdisc del dev $ETH root 2>/dev/null $tc qdisc del dev $ETH
> ingress 2>/dev/null
>
> ### PRIO ### # qdisc "prio", 3 levels $tc qdisc add dev $ETH root
> handle 1: prio $tc qdisc add dev $ETH parent 1:1 handle 10: pfifo $tc
> qdisc add dev $ETH parent 1:2 handle 20: pfifo $tc qdisc add dev $ETH
> parent 1:3 handle 30: pfifo
>
> PRIO1="212.27.60.27" #ftp.free.fr PRIO2="0.0.0.0/0"
> PRIO3="195.83.118.1" #ftp.lip6.fr # echo Prio 1 : $PRIO1 echo Prio 2
> : $PRIO2 echo Prio 3 : $PRIO3
>
> $tc filter add dev $ETH parent 1:0 prio 1 protocol ip u32 match ip
> src $PRIO1 flowid :1 $tc filter add dev $ETH parent 1:0 prio 3
> protocol ip u32 match ip src $PRIO2 flowid :2 $tc filter add dev $ETH
> parent 1:0 prio 2 protocol ip u32 match ip src $PRIO3 flowid :3
> _________________
>
>
> When I run : tc -s qdisc ls dev eth1 I see the 2 FIFOs showing
> traffic going through. I don't understand what I am doing wrong, any
> help will be appreciated.

I don't understand your setup so 2 options.

1.

You are only shaping the outgoing traffic, which isn't going to help
with downloads incoming traffic. There isn't a perfect solution for
shaping from the wrong end of a bottleneck, but you can sort of do it by
using ifb and limiting the the rate to say 10-20% below the incoming
bandwidth with htb/hfsc/etc.

2.

Your shaping is actually seeing the download traffic leaving eth but not
working because there is further buffering downstream after the prio so
you would need to again use something where you can set the
rates/overheads to make sure you are the bottleneck - this time you
shouldn't need to sacrifice bandwidth.

Re: PRIO qdisc traffic does not work as expected

[GGounot]

Le 19/06/2014 12:33, Andy Furniss a écrit :
> GGounot wrote:
>> Hello,
>>
>> This is a simple case I started from lartc howto but I can't make it
>> work.
>>
>> The idea is : * 3 priorities * ftp.free.fr on prio 1 * 0.0.0.0/0 prio
>> 2 * ftp.lip6.fr prio 3
>>
>> Or, when Internet line is saturated and I download from ftp.free.fr,
>> my download should supersede all other downloads (my download should
>> take all bandwidth). On the other hand a download from ftp.lip6.fr
>> should occur only when there is some available bandwidth.
>>
>> But actually, when I download from ftp.free.fr and from ftp.lip6.fr
>> at the same time, both downloads have the same speed.
>>
>> This is the script : _________________ #!/bin/bash
>>
>> tc=/sbin/tc ETH=eth1 #connected to the LAN
>>
>> $tc qdisc del dev $ETH root 2>/dev/null $tc qdisc del dev $ETH
>> ingress 2>/dev/null
>>
>> ### PRIO ### # qdisc "prio", 3 levels $tc qdisc add dev $ETH root
>> handle 1: prio $tc qdisc add dev $ETH parent 1:1 handle 10: pfifo $tc
>> qdisc add dev $ETH parent 1:2 handle 20: pfifo $tc qdisc add dev $ETH
>> parent 1:3 handle 30: pfifo
>>
>> PRIO1="212.27.60.27" #ftp.free.fr PRIO2="0.0.0.0/0"
>> PRIO3="195.83.118.1" #ftp.lip6.fr # echo Prio 1 : $PRIO1 echo Prio 2
>> : $PRIO2 echo Prio 3 : $PRIO3
>>
>> $tc filter add dev $ETH parent 1:0 prio 1 protocol ip u32 match ip
>> src $PRIO1 flowid :1 $tc filter add dev $ETH parent 1:0 prio 3
>> protocol ip u32 match ip src $PRIO2 flowid :2 $tc filter add dev $ETH
>> parent 1:0 prio 2 protocol ip u32 match ip src $PRIO3 flowid :3
>> _________________
>>
>>
>> When I run : tc -s qdisc ls dev eth1 I see the 2 FIFOs showing
>> traffic going through. I don't understand what I am doing wrong, any
>> help will be appreciated.
>
> I don't understand your setup so 2 options.
>
> 1.
>
> You are only shaping the outgoing traffic, which isn't going to help
> with downloads incoming traffic. There isn't a perfect solution for
> shaping from the wrong end of a bottleneck, but you can sort of do it by
> using ifb and limiting the the rate to say 10-20% below the incoming
> bandwidth with htb/hfsc/etc.
>
> 2.
>
> Your shaping is actually seeing the download traffic leaving eth but not
> working because there is further buffering downstream after the prio so
> you would need to again use something where you can set the
> rates/overheads to make sure you are the bottleneck - this time you
> shouldn't need to sacrifice bandwidth.
>


Thanks for your answer.

The diagram is :
Internet <=> eth0 <=> eth1 <=> Client computer (which downloads using 
Firefox)

So shaping on eth1 outgoing traffic should limit the rate Client 
receives data from Internet.

Would shaping on eth0 using :
  tc qdisc add dev eth0handle ffff: ingress
  ifconfig ifb0 up
  tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 
action mirred egress redirect dev ifb0
and run the script on ifb0 be a better solution ?


Other way :
eth0 has a public IP (is directly connected to Internet).

eth0 and eth1 are 100Mb/s network PCI cards.

The Internet link has a rate of ~4000Kb/s.

Is the use of PRIO qdisc the problem ? (since it (maybe) acts on the 
network card rate, not the actual Internet connection rate)

Re: PRIO qdisc traffic does not work as expected

[Andy Furniss]

GGounot wrote:


> The diagram is : Internet <=> eth0 <=> eth1 <=> Client computer
> (which downloads using Firefox)
>
> So shaping on eth1 outgoing traffic should limit the rate Client
> receives data from Internet.
>
> Would shaping on eth0 using : tc qdisc add dev eth0handle ffff:
> ingress ifconfig ifb0 up tc filter add dev eth0 parent ffff: protocol
> all u32 match u32 0 0 action mirred egress redirect dev ifb0 and run
> the script on ifb0 be a better solution ?

You could but don't need to as you can do it on eth1.

Which ever way you are going to be shaping from the wrong end of the
bottleneck so will need to sacrifice some bandwidth for it to work.

My previous answer 2. was a bit misleading as it would only have applied
if you were maxing eth speed.

> Other way : eth0 has a public IP (is directly connected to
> Internet).
>
> eth0 and eth1 are 100Mb/s network PCI cards.
>
> The Internet link has a rate of ~4000Kb/s.
>
> Is the use of PRIO qdisc the problem ? (since it (maybe) acts on the
>  network card rate, not the actual Internet connection rate)

Yes, prio is the problem you need to send the traffic from the internet
to something like htb with the rate set to eg. 3500kbit then you can use
htb classes to give prio for some traffic over other. You could if you
wanted use prio qdisc as a child of htb.

Re: PRIO qdisc traffic does not work as expected

[Dave Taht]

I'm not huge on strict prio queues. And you need to ratelimit in both
directions, and ifb is best.

On Thu, Jun 19, 2014 at 6:58 AM, Andy Furniss <adf.lists@gmail.com> wrote:
> GGounot wrote:
>
>
>> The diagram is : Internet <=> eth0 <=> eth1 <=> Client computer
>> (which downloads using Firefox)
>>
>> So shaping on eth1 outgoing traffic should limit the rate Client
>> receives data from Internet.
>>
>> Would shaping on eth0 using : tc qdisc add dev eth0handle ffff:
>> ingress ifconfig ifb0 up tc filter add dev eth0 parent ffff: protocol
>> all u32 match u32 0 0 action mirred egress redirect dev ifb0 and run
>> the script on ifb0 be a better solution ?
>
>
> You could but don't need to as you can do it on eth1.
>
> Which ever way you are going to be shaping from the wrong end of the
> bottleneck so will need to sacrifice some bandwidth for it to work.
>
> My previous answer 2. was a bit misleading as it would only have applied
> if you were maxing eth speed.
>
>
>> Other way : eth0 has a public IP (is directly connected to
>> Internet).
>>
>> eth0 and eth1 are 100Mb/s network PCI cards.
>>
>> The Internet link has a rate of ~4000Kb/s.
>>
>> Is the use of PRIO qdisc the problem ? (since it (maybe) acts on the
>>  network card rate, not the actual Internet connection rate)
>
>
> Yes, prio is the problem you need to send the traffic from the internet
> to something like htb with the rate set to eg. 3500kbit then you can use
> htb classes to give prio for some traffic over other. You could if you
> wanted use prio qdisc as a child of htb.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht

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

Re: PRIO qdisc traffic does not work as expected

[GGounot]

I've made the following script.. It should redirect traffic according to 
TOS, but SSH, SCP, HTTP download, etc., but it does not and everything 
goes through 1:2.

Any idea ?

I can see that using :
  tc -s qdisc ls dev ifb0
  tc -s class ls dev ifb0

_________________
DOWNRATE\x1500

tc=/sbin/tc
EHT=eth0
IFB=ifb0
modprobe ifb
modprobe act_mirred
ethtool -K $EHT tso off gso off gro off

$tc qdisc del dev $EHT root 2>/dev/null
$tc qdisc del dev $EHT ingress 2>/dev/null
$tc qdisc del dev $IFB root 2>/dev/null
$tc qdisc del dev $IFB ingress 2>/dev/null

### INGRESS ###
$tc qdisc add dev $EHT handle ffff: ingress
ifconfig $IFB up
$tc filter add dev $EHT parent ffff: protocol all u32 match u32 0 0 
action mirred egress redirect dev $IFB

### HTB ##
$tc qdisc add dev $IFB root handle 1:0 htb default 1
$tc class add dev $IFB parent 1:0 classid 1:1 htb rate ${DOWNRATE}kbps

### PRIO ###
$tc qdisc add dev $IFB parent 1:1 handle 10: prio
$tc qdisc add dev $IFB parent 10:1 handle 101: sfq
$tc qdisc add dev $IFB parent 10:2 handle 102: sfq
$tc qdisc add dev $IFB parent 10:3 handle 103: sfq
___________________


Le 19/06/2014 21:06, Dave Taht a écrit :
> I'm not huge on strict prio queues. And you need to ratelimit in both
> directions, and ifb is best.
>
> On Thu, Jun 19, 2014 at 6:58 AM, Andy Furniss <adf.lists@gmail.com> wrote:
>> GGounot wrote:
>>
>>
>>> The diagram is : Internet <=> eth0 <=> eth1 <=> Client computer
>>> (which downloads using Firefox)
>>>
>>> So shaping on eth1 outgoing traffic should limit the rate Client
>>> receives data from Internet.
>>>
>>> Would shaping on eth0 using : tc qdisc add dev eth0handle ffff:
>>> ingress ifconfig ifb0 up tc filter add dev eth0 parent ffff: protocol
>>> all u32 match u32 0 0 action mirred egress redirect dev ifb0 and run
>>> the script on ifb0 be a better solution ?
>>
>> You could but don't need to as you can do it on eth1.
>>
>> Which ever way you are going to be shaping from the wrong end of the
>> bottleneck so will need to sacrifice some bandwidth for it to work.
>>
>> My previous answer 2. was a bit misleading as it would only have applied
>> if you were maxing eth speed.
>>
>>
>>> Other way : eth0 has a public IP (is directly connected to
>>> Internet).
>>>
>>> eth0 and eth1 are 100Mb/s network PCI cards.
>>>
>>> The Internet link has a rate of ~4000Kb/s.
>>>
>>> Is the use of PRIO qdisc the problem ? (since it (maybe) acts on the
>>>   network card rate, not the actual Internet connection rate)
>>
>> Yes, prio is the problem you need to send the traffic from the internet
>> to something like htb with the rate set to eg. 3500kbit then you can use
>> htb classes to give prio for some traffic over other. You could if you
>> wanted use prio qdisc as a child of htb.
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe lartc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: PRIO qdisc traffic does not work as expected

[Andy Furniss]

GGounot wrote:
> I've made the following script.. It should redirect traffic according
> to TOS, but SSH, SCP, HTTP download, etc., but it does not and
> everything goes through 1:2.

Like David said - prio is not the best way to go as it may totally
block. I have never personally used it, prefering to do prio with htb -
still leaving the lowest class with a trickle.

If you are catching incoming traffic then it's possiblr that TOS won't
work as it could be cleared upstream. I have never relied on TOS for
shaping.

If you are only shaping through traffic on the box then you don't need
to use IFB at all. Just shape on local and wan facing IFs, this could be
an advantage in allowing the use of iptables eg. to mark/classify.