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

[John Gilmore]

I'm desperate - I'll try it.

I have discovered the following:
In iptables, the condition match doesn't compile, and is worthless.
The "recent" match has a --rdest flag, which in combination with
--name can almost be used to set a "condition" for a certain time.
Except that there isn't any way to match RTP traffic, and SIP traffic
patterns around a SIP call aren't distinctive enough to be useful.

The "system()" function in asterisk has problems. I wrote a
handy-dandy little shell script which will turn on and off throttling,
but it doesn't work AT ALL when called from asterisk - "sudo -u
asterisk bash" gives me a command prompt as the asterisk user, and
"sudo /usr/local/sbin/throttle.sh" works fine from there, but NOT from
a script that I know is otherwise called at the end of every SIP call
(2wav2mp3.sh, converts the two .wav files from a  monitored call into
an mp3) or when called directly by the "system" function in asterisk.

So I after a day and half of effort, I have no workable solutions. I
don't WANT to sacrifice 10% of my bandwidth, but I see no alternative.

Thank you for the script, I'll look at it and see where it takes me.

On Mon, Oct 13, 2008 at 4:43 AM, Scott Scriven <nclug at toykeeper.net> wrote:
> * John Gilmore <jgilmore at glycou.com> wrote:
>> HTB doesn't have an equivalent to the "condition" match, so I'd
>> have to create or modify the rules when a SIP connection
>> started, and destroy or modify them when it stopped.
>
> No, that's not necessary.  When your high-priority SIP bucket is
> active, it will automatically tone down the other traffic
> appropriately.
>
> I had a voip phone for a while...  and a roommate who insisted on
> running 30+ torrents all the time.  He kept the connection
> completely saturated and refused to stop, so I fixed it.  He was
> bogging things down so much that ping times to my ISP ranged from
> 1000ms to 6000ms, and the phone was completely unusable.
>
> With a bit of QoS on my router, I reduced latency by two orders
> of magnitude and got the phone working nicely.  As a bonus, my
> ssh sessions also became responsive, no matter how overloaded the
> network got.
>
>> My understanding is that since my upstream provider (USCable)
>> doesn't implement QOS, to eliminate latency for the SIP calls
>> would require that I throttle bandwidth to quite a bit lower
>> than the actual limit - say 700KBps on a 1.2Mbps connection.
>
> I've found it works well to limit upstream bandwidth use to about
> 15/16ths of the capacity, though really anything from about 90%
> to 95% is probably good.
>
> Basically, that gives you just enough wiggle room to prevent lost
> packets, so your router decides what gets sent, instead of random
> chance.
>
>> Mostly this is a desire on my part to avoid the time-consuming
>> empirical testing ...
>
> I've done a bit of voip testing under load, and made something
> which works.  It's primitive, but you're free to use it if you
> like.  I've put a shortened version online:
>
>  http://narthex.xyzz.org/qos-init.sh
>
> You'll need to adjust the part which matches your voip packets.
> I had a voip appliance on its own IP address, so matching was
> easy.  You may need to do it based on tcp port instead, or
> whatever other mechanism is appropriate.  Also, be sure to set
> CEIL to about 90% of your uplink capacity.
>
>
> -- Scott
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://www.nclug.org/mailman/listinfo/nclug
>