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

[Adam Goryachev]

> 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