[NCLUG] Bandwidth throttling when SIP connection is in progress.

[John Gilmore]

I've had serious and ongoing call quality issues. Related to both
upload bandwidth being occupied, and download bandwidth being
occupied. Mostly the issue is ping time rather than packet loss.
Packet loss DOES play a significant roll, but mostly in calls that
have horrible ping times ANYWAY, and since that's unacceptable as well
I've decided to focus on packet loss.

I am amazed at my wife's patience.

I didn't actually try that script. I looked at it long and hard, and
rewrote most of it to match my situation. I can't classify packets
nearly as easily b/c asterisk is running on the firewall. I've found
no way to classify the SIP packets except to say "they're UDP". I got
to the bit about actually allocating bandwidth, and couldn't find a
simple way to rewrite it to regulate incoming and outgoing easily. I'm
sure doing so would be relatively easy, but I decided not to do it, as
I had a much simpler solution readily to hand.

Much of that descion has do to with simplicity, ease of deployment,
and risk. I need something that will gaurunntee acceptable call
quality NOW. I'm not even sure what my upload/download speeds actually
are. And guessing at them based on what "system guard" reports doesn't
seem reliable enough.

Any solution which *always* regulated packets will have to be adjusted
fairly precisely to actual network capacity, or risk significantly
slower downloads on one hand or call quality issues on the other. On
the other hand, if I'm regulating packets only when actually needed,
the problem is MUCH less sensitive to adjustment errors - as long as
web pages eventually load, I'm good. Anything else is gravy. Now, it's
not as good as detecting SIP calls in the kernel network code and
adjusting routing rules based on that, as it does depend on asterisk
calling the correct script at the end of each call to stop throttling
traffic. But it's good enough: quite paranoid about call quality, and
doesn't interfere with bittorrent download rates at all.

And so that's why I decided not to use your script. I am grateful for
it though, examining and modifying it did crystalise my thoughts about
what my actual requirements where. And I gained significant
familiarity with tc and the iproute2 tools.

There are two activities which we've noticed affecting call quality:
Watching youtube and other online movies, and bittorrent. Both will
cause long ping times and high packet loss, though of course
bittorrent is the worst offender. Both are also things that can easily
be stopped or slowed down significantly without serious impact to user
experience. So, given that phone calls are usually fairly short and
infrequent, it makes sense to significantly slow down or even stop
these activities when someone is using the phone. Other's phone use
patterns may differ, but around here long calls happen only during the
day, when nobody else is home to be using the internet anyway.

On Thu, Oct 16, 2008 at 4:21 PM, Scott Scriven <nclug at toykeeper.net> wrote:
> * John Gilmore <jgilmore at glycou.com> wrote:
>> I really don't want to use that script.
>
> So, you didn't try it?
>
>> The download bandwidth is throttled,
>
> Where did you get that idea?
>
>> I get 100% when not using SIP, and about 10% when using SIP.
>> Since SIP is fairly rare, it's a better solution that 90% 100%
>> of the time.
>
> Would you say it's better to transfer at 95% capacity with 0%
> packet loss, or at 100% capacity with 5% packet loss?  Which do
> you think produces smoother SIP calls?
>
> BTW, have you actually had any call quality issues, or is this
> all theoretical?
>
>
> -- Scott
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://www.nclug.org/mailman/listinfo/nclug
>