[LARTC] tc rules for Internet Radio

[LARTC] tc rules for Internet Radio

[Martin Ward]

I am currently using the ultimate-tc script from 
http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
and I want to make sure that internet radio packets (mp3 streaming audio)
will always get through no matter what. I have added some iptables commands
like this:

iptables -A OUTPUT -t mangle -p tcp --dport 8000 -j TOS --set-tos 
Minimize-Delay
iptables -A OUTPUT -t mangle -p tcp --sport 8000 -j TOS --set-tos 
Minimize-Delay

with the aim of marking the streaming audio packets so that they will get
a higher priority: but I'm not sure if this is needed or exactly how it works!

Some audio streams come in with the incoming packets marked [tos 0x40] and
the outgoing packets marked [tos 0x10] (according to tcpdump) but not all.

The ultimate-tc script ends with these ingress rules:

########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent 
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:

tc qdisc add dev $DEV handle ffff: ingress

# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1


This will drop packets to keep the download rate just below the maximum
capacity of the link: which will keep the ISP's queue empty and improve
latency. But I am concerned that if there are a *lot* of other download
streams going at the same time as my audio stream, then these rules
may drop lots of packets from the audio stream and cause it to skip.

Should I add rules to drop audio stream packets at ${DOWNLINK}kbit rate
and drop all other traffic at $[9*$DOWNLINK/10]kbit rate, in the same way
that ultimate-tc does for outgoing traffic? If so, what should the rules look
like?

Something else I don't understand about ultimate-tc is that the high priority
class gets a rate of ${UPLINK}kbit and the low priority class gets
$[9*$UPLINK/10]kbit: but doesn't the rate refer to traffic *in that class*.
Traffic-Control-HOWTO Section 7.1.5. (Rules) says:
"Ideally, the sum of the rates of the children classes would match the rate of
the parent class, allowing the parent class to distribute leftover bandwidth
(ceil - rate) among the children classes." but this isn't the case for the
ultimate-tc script. 

-- 
			Martin

Martin.Ward@durham.ac.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc rules for Internet Radio

[Andy Furniss]

Martin Ward wrote:
> I am currently using the ultimate-tc script from 
> http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
> and I want to make sure that internet radio packets (mp3 streaming audio)
> will always get through no matter what. I have added some iptables commands
> like this:
> 
> iptables -A OUTPUT -t mangle -p tcp --dport 8000 -j TOS --set-tos 
> Minimize-Delay
> iptables -A OUTPUT -t mangle -p tcp --sport 8000 -j TOS --set-tos 
> Minimize-Delay

OUTPUT only sees locally generated packets.

> 
> with the aim of marking the streaming audio packets so that they will get
> a higher priority: but I'm not sure if this is needed or exactly how it works!
> 
> Some audio streams come in with the incoming packets marked [tos 0x40] and
> the outgoing packets marked [tos 0x10] (according to tcpdump) but not all.
> 

I would use MARK as other traffic may have TOS set, see below.

> The ultimate-tc script ends with these ingress rules:
> 
> ########## downlink #############
> # slow downloads down to somewhat less than the real speed  to prevent 
> # queuing at our ISP. Tune to see how high you can set it.
> # ISPs tend to have *huge* queues to make sure big downloads are fast
> #
> # attach ingress policer:
> 
> tc qdisc add dev $DEV handle ffff: ingress
> 
> # filter *everything* to it (0.0.0.0/0), drop everything that's
> # coming in too fast:
> 
> tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
>    0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
> 
> 
> This will drop packets to keep the download rate just below the maximum
> capacity of the link: which will keep the ISP's queue empty and improve
> latency. But I am concerned that if there are a *lot* of other download
> streams going at the same time as my audio stream, then these rules
> may drop lots of packets from the audio stream and cause it to skip.
> 
> Should I add rules to drop audio stream packets at ${DOWNLINK}kbit rate
> and drop all other traffic at $[9*$DOWNLINK/10]kbit rate, in the same way
> that ultimate-tc does for outgoing traffic? If so, what should the rules look
> like?

There are lots of complicated things you can do with policers/u32 but I 
have no experience.

First thoughts are to mark all that aren't -sport 8000 and change the 
police rule to police to police marked.

iptables -A PREROUTING -t mangle -p tcp ! --sport 8000 -j MARK --set-mark 1

tc qdisc add dev $DEV handle ffff: ingress

tc filter add dev $DEV parent ffff: protocol ip prio 1 handle 1 fw 
police rate ${DOWNLINK}kbit burst 10k drop flowid :1

I haven't tested that.


> 
> Something else I don't understand about ultimate-tc is that the high priority
> class gets a rate of ${UPLINK}kbit and the low priority class gets
> $[9*$UPLINK/10]kbit: but doesn't the rate refer to traffic *in that class*.
> Traffic-Control-HOWTO Section 7.1.5. (Rules) says:
> "Ideally, the sum of the rates of the children classes would match the rate of
> the parent class, allowing the parent class to distribute leftover bandwidth
> (ceil - rate) among the children classes." but this isn't the case for the
> ultimate-tc script. 
> 

I don't do it like that - I use ceil and like my rates to add up - but I 
suppose it works OK.

Andy.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc rules for Internet Radio

[Andy Furniss]

Andy Furniss wrote:

> There are lots of complicated things you can do with policers/u32 but I 
> have no experience.
> 
> First thoughts are to mark all that aren't -sport 8000 and change the 
> police rule to police to police marked.
> 
> iptables -A PREROUTING -t mangle -p tcp ! --sport 8000 -j MARK --set-mark 1
> 
> tc qdisc add dev $DEV handle ffff: ingress
> 
> tc filter add dev $DEV parent ffff: protocol ip prio 1 handle 1 fw 
> police rate ${DOWNLINK}kbit burst 10k drop flowid :1
> 
> I haven't tested that.

Ignore that - it's no good if your stream(s) use much bandwidth.

If you only have one LAN interfave you can shape ingress by seting up 
queues on that.

Andy.


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/