Broken Traffic Control

From Funtoo Linux
Revision as of 17:34, 4 January 2011 by Drobbins (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The following traffic control examples should work, but are broken in the current implementation of Linux traffic control, as tested by Daniel Robbins.

Prioritizing Outgoing UDP packets

These rules should be able to give outgoing UDP traffic a higher priority than other outgoing traffic, which could reduce the latency of outgoing UDP packets if your system (or ideally, your Linux router, which is the ideal point to use these shaping rules) is sending a lot of data all at once to a remote host.

However, currently, these rules do not work.

wanif=eth0
tc qdisc add dev $wanif root handle 1: prio bands 3
tc qdisc add dev $wanif parent 1:1 handle 10: sfq perturb 10
tc qdisc add dev $wanif parent 1:2 handle 20: sfq perturb 10
tc qdisc add dev $wanif parent 1:3 handle 30: sfq perturb 10
 
tc filter add dev $wanif protocol ip parent 1: prio 1 u32 match ip protocol 0x11 0xff flowid 1:1
tc filter add dev $wanif protocol ip parent 1: prio 1 u32 match ip dst 0.0.0.0/0 flowid 1:2

This code above causes much data to be lost, since the code is not properly routing all unmatched traffic to the lowest priority (leaf) class (1:3).

If the following line is added, which is intended to match all other IP traffic, then all traffic other than ARP packets are still discarded by the prio qdisc and the discarded counter of the qdisc is incremented accordingly:

tc filter add dev $wanif protocol ip parent 1: prio 1 u32 match ip src 0.0.0.0/0 flowid 1:3

I have also experienced issues where the priomap does not work properly, and the majority of traffic flows into the wrong child class. It also appears that the first tc filter command, which is supposed to prioritize UDP traffic, has the effect of placing all traffic into class 1:2.

This code was tested on a physical interface that was part of a Linux bridge, as well as on the Linux bridge device ('brwan') itself. In both cases, prio exhibited strange and unusual behavior that deviated significantly from documented behavior. The kernel being used for this testing is a stable Red Hat Enterprise Linux 5.x kernel with OpenVZ patches (2.6.18-028stab079.2).

Based on this testing, prio appears to not work correctly at all, at least when used in this configuration, and should be avoided by Linux traffic control users.

Personal tools
Namespaces

Variants
Actions
Categories
Toolbox
Stuff