[Asterisk-Dev] Anyone doing QOS routing on Linux for SIP/RTP?

[Alberto Bertogli]

On Tue, May 13, 2003 at 02:10:40PM +1000, Adam Goryachev wrote:
> > Otherwise FreeBSD has the 'dummynet' feature that will do a certain amount
> > of traffic shaping.  NetBSD (and OpenBSD) have ALTQ for similar features.
> 
> yep, and linux has some equiv or other...

Yes, Linux has had since 2.2 a really advanced QoS framework with several
algorithms for classes, queues and filters.

At first it might look a bit complex because it's extremely flexible, you
have a _lot_ of options and parameters to handle.

But it allows you to do anything, not only traffic shaping but fair
queueing and congestion notification (for instance when using RED, instead
of dropping packets it can use ECN for TCP flows), and you can combine it
with iptables to do packet marking, so you use iptables to mark the
packets and then use the mark to select how the traffic is handled.

In your case, you might want to take a look at the HTB algorithm which is
fairly new and fits this cases quite well, allowing you to reserve
bandwidth, allows borrowing and lending, and priorities too. Also take a
look to SFQ which makes fair queues (and can, of course, be put under
HTB).

 
> > Obviously you really want QoS so you can run at full speed and have your
> > ISP router handle congestion.
> 
> right, they are all just really bad hacks. I mean, we probably aren't on the
> phone *most* of the time, so we want internet access to be as fast as
> possible when we aren't on the phone. (actually, always faster is even
> better :)
> 
> For the people trying to say that email is TCP and it will simply back off,
> that doesn't really work very well, because you need the TCP connection to
> back WAAAY off almost immediately, not over the next few minutes. ie, the
> caller would have hung up the phone thinking it's a *really* bad line or
> something before your TCP connection dropped off at all. (At least this
> would hold true for me).

Yes i agree with this, TCP has some kind of slow exponential backoff so
you _will_ have congestion. This only gets worse with several flows, and
so on. SFQ and a ECN enabled routers would probably help a lot, but it
won't help enough.

However, what he wants can be easily accomplished with HTB, by creating a
class with the max bandwidth, and underneath two classes: one for voip
with highest priority and a given waranteed rate, and another with all the
rest. And then you allow borrowing from each other, so if voip is not
used, the other one can 'borrow' from it. Simple, isn't it?


> As a few people have pointed out, the greater the bandwidth available, the
> less this is an issue, especially when you look at some of the backbone
> connections. (Consider the CPU requirements to do QoS on a OC3...)

At that level, probably some form of RED is the most logical choice =)


> > Meanwhile, I was talking to a buddy SIP phone to SIP phone over an IPSEC
> > tunnel.  RTT for ping was about 600ms due to congestion on his cable modem
> > provider's network, but our voice call was perfectly fine.  It definitely
> > did not have 600ms of latency!  The Cisco 7960 will set the TOS bits based
> > on a configuration option.
> >
> > So some ISPs apparently support QoS without really advertising it.
> 
> Most routers as standard will always give ICMP lower priority ... incl
> Cisco. Try a tcpping or udpping etc... Also RTT for ping is 600ms which
> means audio only passes 300ms to get from one end to the other. AFAIK, it is
> also more important to avoid packet loss than to avoid packet delay... Well,
> they both are important and lead to different problems, but at 30% packet
> loss most things stop working.... (seen from experience!)

True, but in Cisco equipment this is highlighted by their poor
performance.  You might get improvements by touching the scheduler timers
(there are a few tunables available) but just don't expect it to perform.
This is by design in the IOS so it's probably not going to change until
they build an ASIC to handle ICMP =)

That's why most Cisco stuff used to fall apart (some of them still do)
under ping -f.


> So, all this still says not much except that if you have enough bandwidth
> you don't need QoS, which means a lot of people will find QoS useful. So,
> does anyone have useful examples/howto's/information/etc that might help?

http://lartc.org is the best site for this stuff under Linux. You'll find
there also a lot of intresting references too. About QoS in general (more
theorical information), Sally Floyd's website (sorry i don't remember the
url) is great.


Thanks,
		Alberto