From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Furniss <andy.furniss@dsl.pipex.com>
Date: Fri, 19 Nov 2004 21:30:59 +0000
Subject: Re: [LARTC] tc rules for Internet Radio
Message-Id: <419E6613.7040905@dsl.pipex.com>
List-Id: <lartc.vger.kernel.org>
References: <200411161702.45717.Martin.Ward@durham.ac.uk>
In-Reply-To: <200411161702.45717.Martin.Ward@durham.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: lartc@vger.kernel.org

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/