Paul,
: I have used tcng to help start me with some tc code that i can
: put into a bash script and call from a c program. I have to
: dynamically
:
: 1. Add filters for communications between different nodes.
: 2. Delete these filters as communications cease between the
: nodes and
: 3. Make sure they have enough bandwidth by limiting everything
: else.
:
: e.g > Node 1 wants to make a voip call to Node 2. My c program
: recieves both ip's, both ports and the bw that the call requires.
: I then have to add/change the tc rules/filters to allow this to
: happen. Then i recieve a request for another call, same thing.
: Then call 1 hangs up, i delete that filter and change other
: necessary info.
I have seen a number of people try dynamic class and filter
insertion. I can't say that I've ever seen it work particularly
elegantly. I hope somebody will also show you what s/he has done
to deal with this problem, but here's how I'd solve the problem:
Build a class hierarchy that accommodates the total number of VoIP
calls that your network can support at any one time.
class $root, rate $MAX, ceil $MAX
|
+- classes $voip, rate $VOIPMAX, ceil $VOIPMAX
| |
| + class $voip.0 rate $PCR, ceil $PCR
| + class $voip.1 rate $PCR, ceil $PCR
| [ ... ]
| + class $voip.N rate $PCR, ceil $PCR
|
+- class $rest, rate $RESTMIN, ceil $MAX
N = total number of VoIP clients
PCR = per call rate (64kbit?)
VOIPMAX = PCR * N
MAX = total bandwidth available to you
RESTMIN = minimum guaranteed bandwidth for bulk, should, roughly
MAX - VOIPMAX - <a little bit>
You simply classify any VoIP UDP flows into the $voip.0, $voip.1 ...
$voip.N classes and you forget about it. (See also toward the
bottom of this message.)
Now every one of your N-VoIP clients can have guaranteed access at
per-call-rate (PCR). This is most distinctly not dynamic, and
probably rather hackish by comparison to something more RSVP-like.
What's the beauty of the above model? First, you don't have to
fiddle with it at all once it's installed. Second, HTB will take
care of sharing the bandwidth between your VoIP callers and the
rest of the traffic ($rest).
What's the shortcoming of the model? You have to have enough
bandwidth to allocate one VoIP class to each of your VoIP users
without hitting your $MAX rate. Viewed from another angle, you must
not have more potential VoIP callers than you have available
bandwidth.
: I am finding this extremely difficult. i.e > I have
: little/nothing working.
The concept of dynamic traffic control structures has come up
periodically on this list, and you may find some benefit to trawling
the archives for earlier discussions. I'm quite certain there are
some nuggets of knowledge available in the archive.
: Do you know what might be the best way to approach this problem ?
:
: Currently i'm simply trying to write a bash script containing tc
: commands and call that bash script from my c code.
One other thing you could consider is building the above structure,
but not installing any filters. While I have not used the netfilter
CLASSIFY target, you could have your bash script insert CLASSIFY
rules into a custom chain.
Then, you have a set of traffic control structures in the kernel and
you use netfilter rules to select which flows go into the VoIP
classes.
Good luck,
-Martin
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
