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

[Steve Radich]

Some of you may want to look into www.mikrotik.com it's based on linux and
easier to use for this kind of stuff.  If your needs are small it's a cheap
license to get you an easy to use interface to the QoS stuff.  I've talked
to some people using it for bandwidth limiters and they like it, we recently
rolled out a few of them to see if they are worth the rack space.

There's two factors to bandwitdh limiting:
	a) Inbound
	b) Outbound

Inbound: Relatively hard to limit (not exceptionally, but relatively).  I've
never had an occasion to care about inbound as typical of a hosting company
our network is 80+ outbound and inbound is never even close to worried
about.  If I understand right you'd have to limit the ACK packets back to
the host that's sending you.  Your upstream could do this limit easier but
most don't.

Outbound: Relatively easy to limit - you can easily count the bytes and set
max rates. This probably isn't the concern though of most of you.

Mikrotik, if I remember right, claimed to have something easy to use for
inbound.  They primarily sell the wireless market it seems where inbound
would be more interesting to limit than outbound.

Steve Radich
BitShop, Inc.


-----Original Message-----
From: Adam Goryachev [mailto:mailinglists at websitemanagers.com.au]
Sent: Tuesday, May 13, 2003 12:11 AM
To: asterisk-dev at lists.digium.com
Subject: RE: [Asterisk-Dev] Anyone doing QOS routing on Linux for
SIP/RTP?


> You can lower your maximum receive window size and your maximum segment
> size so the email machine is not able to use 144Kbit/s.
>
> This is just a hack, but would force TCP connections to your ISP to
> run slower.
>
> 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...

> 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).

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...)
This is similar to how I used to look at contention ratios for dialup modem
lines (ISP side). If you have 20 customers, you really need to have at least
15 lines, as during peak times, it is likely that most of them will want to
be online at the same time. A ratio of 3:4. If you now had 20,000 customers,
you could probably provide the same level of service with only 2,000 lines,
a ratio of 10:1... (I'm plucking numbers out of the air, but you get the
idea). With the larger number of subscribers, sure, during peak time most of
them want to be online, but probably only 30 minutes out of the whole peak
period, so it is likely someone else is logging off when the next person
wants to login... Internet bandwidth is even more bursty, a web transaction
is usually only a few kB's which might last a couple of seconds, so even on
a low bandwidth line, you can share that between a lot of people (I once
hosted around 40 websites behind a 33.6kbps modem for a few months, doing
around 30,000 hits per month)...

> 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!)

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?

Worst case is I'll just go and do it one day when I have some time and let
you all know whether it helped or not afterward...

Regards,
Adam

_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev