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

[John Gilmore]

My phone is now working fine even under adverse conditions, i.e. when
somebody is browsing the web and bittorrent is running.

I think I understand it pretty well. But the effort to implement it isn't
worth it in my situation. I'd still need either:
1. Userspace "call is starting" to modify packet routing rules.
or
2. Careful tuning to my individual link, which requires at least some
empirical testing, and probably LOTS* of testing to really be sure I have it
right.

Now, I may still implement it, as it would allow web browsing to be
relatively unaffected by bittorrent. But not today. I did read a couple of
excellent articles about  it though, and if your traffic isn't as periodic
as mine or you actually need various guarantees, it'd be the only game in
town.

- John

*Probably at least five or six phone calls, spread over several days. Total
time maybe an hour on call, and another three or four hours tweaking. I
could be wrong, but I have little interest in finding out.

On Sat, Oct 18, 2008 at 2:54 PM, Michael Milligan <milli at acmeps.com> wrote:

> Scott Scriven 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 don't think John gets it, and this may not something you can really do
> justice in email.  This really requires a whiteboard discussion.  :-/
>
> Still, John, in a nutshell, you give certain traffic guaranteed
> bandwidth over other traffic.  You are not just giving some traffic
> priority over other traffic, you use HTB to *guarantee* certain traffic
> *always* has a specific amount of bandwidth available.  It's called
> (Hierarchical) Token Bucket for this reason.
>
> E.g., you can lump all traffic into a top-level bucket set at 1Mb/sec
> (or whatever is just shy of your upstream bandwidth), then define a
> child bucket that gets 32Kb/s of that 1Mb/sec as guaranteed bandwidth
> for VoIP traffic.  Defining it this way means all *non*-VoIP traffic
> uses what's left of the bandwidth defined in the parent bucket (1Mb/sec
> minus 32Kb/sec when VoIP traffic is present).  That's about as simple as
> you can make it to do what you want.  At any given moment then, when
> VoIP traffic is present, the VoIP traffic will always gets at least
> 32Kb/s of bandwidth and the rest of the traffic is queued and has to
> wait for wire time.
>
> The end result is low "ping" times (really, stable round-trip times with
> minimal jitter) and no packet drops for VoIP traffic.  Provided, of
> course, that 32Kb/s is enough for the VoIP traffic as outlined in my
> example.  That may need to be higher... measurements would need to be done.
>
> To identify VoIP traffic, you can identified and tag by UDP ports, or if
> you have a VLAN capable switch, put the VoIP equipment on it's own VLAN
> and then tag all traffic coming from your voice VLAN so the HTB traffic
> shaping engine knows what is VoIP traffic and what is not.  You "tag"
> this traffic using the --set-mark feature of iptables.
>
> Looks to me like this is all pretty well spelled out in Scott's script.
>  The hard part is just understanding the config directives and what they
> do, hence the real need here for a whiteboard.
>
> You could ignore all the TOS-related stuff to try and get your head
> around this.  I have found trying to use TOS to generally be useless.
> At least for me.  My ISP doesn't honor those flags, and I don't know of
> any that do (unless you pay more for it).
>
> Regards,
> Mike
>
> --
> Michael Milligan                                   -> milli at acmeps.com
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://www.nclug.org/mailman/listinfo/nclug
>