Re: Auditing a broken and basic traffic shaping setup - PRIO

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Dec 6, 2014 at 11:32 AM, OmegaPhil <OmegaPhil@xxxxxxxxxxxxx> wrote:
> Disclaimer: I don't do this very often so there is probably a retard
> error in here somewhere. I'm not expecting people to do my work for me,
> I'm just after a better understanding of the problem so I can get more
> control of the situation.

A couple quick notes:

1) strict priority queuing as you do here is generally a hugely bad
idea, as the higher classes can completely starve the rest.

DRR with weights or QFQ with weights are better alternatives, or htb
if you want to strictly rate limit each class. (and been working on
something easier to setup than all that called cake... aint done yet,
if you want patches to test, contact me off list).

Here for example, I ran a netperf-wrapper rrul test, and the EF class
was completely starved.

http://pastebin.com/WaKRDATx

2) ToS as used here, was obsoleted in *1998* by the ietf and replaced
with Diffserv and ECN.

http://en.wikipedia.org/wiki/Type_of_service

CS1 would have been the right thing for minimize-cost in particular.

> tldr: Custom priomap + iptables TOS isn't sorting packets correctly,
> Wireshark won't even filter on TOS...
>
> ----
>
> I'm currently attempting to implement a 4 band prio shaper with fq_codel
> queues on a 100Mbit connection (Debian Testing server):
>
> ======================================================================
>
> tc qdisc add dev eth0 root handle 1: htb default 1
> tc class add dev eth0 parent 1:0 classid 1:1 htb rate 12800kibps ceil
> 12800kibps
> tc qdisc add dev eth0 parent 1:1 handle 100: prio bands 4 priomap  1 3 1
> 3 2 3 2 3 0 3 0 3 1 3 1 3
> tc qdisc add dev eth0 parent 100:1 handle 1001: fq_codel
> tc qdisc add dev eth0 parent 100:2 handle 1002: fq_codel
> tc qdisc add dev eth0 parent 100:3 handle 1003: fq_codel
> tc qdisc add dev eth0 parent 100:4 handle 1004: fq_codel
>
> ======================================================================
>
> Packets are tagged for the various prio queues via iptables:
>
> ======================================================================
>
> # ICMP
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -p icmp -j TOS --set-tos
> Minimize-Delay
>
> # TCP control packets
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -p tcp --tcp-flags
> FIN,SYN,RST,ACK FIN,ACK -j TOS --set-tos Minimize-Delay
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -p tcp --tcp-flags
> FIN,SYN,RST,ACK SYN,ACK -j TOS --set-tos Minimize-Delay
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -p tcp --tcp-flags
> FIN,SYN,RST,ACK RST,ACK -j TOS --set-tos Minimize-Delay
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -p tcp --tcp-flags
> FIN,SYN,RST,ACK RST -j TOS --set-tos Minimize-Delay
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -p tcp --syn -j TOS --set-tos
> Minimize-Delay
>
> # TCP ACK packets with no or very little data payload (p2p traffic sets
> all packets to ACK packets otherwise, source of size: http://phix.me/dm/)
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -p tcp --tcp-flags
> FIN,SYN,RST,ACK ACK -m length --length 40:89 -j TOS --set-tos Minimize-Delay
>
> # Band 2 prioritisation
> # Torrenting
> $IPTABLES -t mangle -A POSTROUTING -o eth0 -m owner --uid-owner deluge
> -j TOS --set-tos Maximize-Throughput
>
> # Band 3 prioritisation
> #$IPTABLES -t mangle -A POSTROUTING -o eth0 -m owner --uid-owner user1
> -j TOS --set-tos Minimize-Cost
> #$IPTABLES -t mangle -A POSTROUTING -o eth0 -m owner --uid-owner user2
> -j TOS --set-tos Minimize-Cost


> ======================================================================
>
> This is based on an otherwise-successful configuration on a local Ubuntu
> server that admittedly doesn't originate traffic itself, without a
> custom priomap.
>
> The general idea is:
>
> Band 0: High priority TCP packets, Minimize Delay,

By peeing on the markings here you are messing with the intent of the sender.

and there is no need to fiddle with the lower level tcp flags here at all.

fq_codel automagically recognises sparse flows (like tcp syns) and
does the right thing already. IF you are on an asymmetric network you
might want to use fq_codel with a lower quantum so to give acks a
little more priority that way.

> Band 1: Normal (nothing targetted here)
> Band 2: Torrenting, Maximize Throughput

No, this should be Background, CS1. IF you have control over your
torrent clients, most support setting the CS1 bit in their
configuration....

> Band 3: Special programs, Minimize Monetary Cost

totally obsolete bit. dont do that. see ecn.

>
> When I let the above run, virtually all packets get dumped into band 1,
> whereas by far the bulk of the traffic is torrenting - the shaping code
> is behaving like iptables isn't tagging the packets properly, however
> 'iptables -v -L -t mangle' is showing a lot of packets going through the
> TOS rules.
>
> I next captured packets and opened up with Wireshark to see what was
> going on (it would be nice if I could just capture from the queues
> directly but I've found no evidence this is possible), however the
> following expressions fail to return anything:
>
> ip.tos
> ip.tos==8
> ip.tos==0x8
>
> etc with other values - I then moved to ip.dsfield.dscp, this failed in
> a different way - ip.dsfield.dscp==2 returned packets with
> 'Differentiated Services Field: 0x08', ip.dsfield.dscp==2 returned 0x10
> - why?
>
> At this point I stopped as I clearly didn't know what I was doing. Any
> pointers?
>
> Thanks for any help.
>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux