[rescue] VOIP

[Joshua Snyder]

On Mon, 13 Oct 2003, Geoffrey S. Mendelson wrote:
<snip>
>
> I'm the only one here who does uploads, my oldest son is forbidden from
> using Kaazza or simlar software, and I do it rarely. I've read the
> technical discussions about using a Linux box as a router and setting up
> QOS (quality of service routing) to help keep VoIP running smoothly, but
> the result is claimed to be better much than not using it and far less
> than the Cisco to Cisco option.
>

I might regret saying this here because I know some peoples opinions on
using Linux in critical operations; and a router is a critical operation
if I ever heard of one.  But I work for a company that builds Linux based
routers.  And I am the resident expert (as much as I can say that) on
Linux Qos at the user level.  We do have a guy on staff who has done a lot
of kernel programming in the Qos layers so he is quite good at it also.
That being said I can tell you that you can get very good results using
Linux Qos for VoIP I have done it several times.  You just have to know
what your doing and it is not very easy to setup the first time.  It can
also be greatly complicated by not have your upstream router running Qos.
In most cases that I have been involved with you have a Linux box on the
client side and you have no control over the upstream provider.  In those
cases you can some times do things to help out but you might not be able
to improve things too much.

It is easy to make sure that all VoIP packets leave your router before any
other packet.  But the tricky part is making sure that you get your VoIP
packet prioritized coming to you.  If you have a Cisco on the other end
and it is setup for VoIP this might not be much of a problem.  Most VoIP
hardware will mark packets with the TOS bit set to 0xB8.  Cisco routers
that have been setup for VoIP will normally give priority to these packets
and it is very easy to do the same for Linux.  But if your upstream
provider doesn't do this you might have problems.  The problem is caused
by buffers on most broadband equipment.  Many times the Dsl or Cable box
at the Isp end can have large Send/Receive buffers to help downloading
speed (I have seen 256KB buffers on Dsl lines) if these buffers fill up
they kill your latency.  Case in point, if you have a 768/128kbit line
with a 256KB buffer that is full, a packet getting to your Isp's equipment
will wait in the buffer for 2.6 seconds (2604ms) before you will see that
packet on your end of the line.  This can be a real problem.

The only way to get around this is to make sure that the buffer never gets
filled on the Isp side.  This is much easier said than done.  Normally what
you do is limit the speed at which your router(Linux Box) sends traffic
into your network at a speed less than the speed of your Internet
connection.  The reason that this even works has to tcp acks and window
sizes.  And this doesn't even work very well unless you have only one tcp
session active on the line at one time.  So it's not a great solution.  It
doesn't help that some programs (Kazza and other p2p stuff) open as many
connection as possible when downloading files.

I guess I am rambling a little bit, it is almost 5am so I guess that is
to blame.  So I guess what I am trying to say is that you can get good
results with Linux Qos assuming that you don't have other problems.  Most
of the time when people try to use Linux to do Qos they have many of the
problems that I outlined above.  I think that contributes to the poor
success that many people have when doing this.  Now if your deploying Linux
on both sides it's easy to do.  But otherwise setting up good Qos rules
become VERY complex and even then you still have fundamental problems that
you will not be able to completely over come.

			josh

p.s. if anyone ever needs help setting up Qos stuff in Linux just ask I
will be happy to help.