On 05/31/2007 07:35:25 PM, ECEG / Daniel Duerr wrote:
I don't care about bandwidth numbers
and I'm afraid to even set them because I don't want to impose limits
on my bandwidth.
Specifically, there are a couple scenarios I need help with:
1) Asterisk server inside the colo with a bunch of IAX clients on the
outside; IAX sends/receives on a single udp port (4569, I believe).
I need to give these packets really high priority.
2) Web servers inside the colo, traffic comes in on ports 80 or 443
but leaves on random ports. I'd like to prioritize web server
traffic so as to provide the highest throughput on file downloads.
Some thoughts, while I think out loud.
My first suggestion would be to write something and post it
here for comment.
You do have a maximum bandwidth, the speed of your interfaces.
To ignore bandwidth the easiest thing would be priority queuing.
There's probably a 3rd catagory of traffic, empty ack datagrams.
You can assign these with 'queue (q1, q2)' where q2 is your
empty ack queue. To maximize downloads you want to be sure
the downloading server gets acks quick so it fills the pipe.
Oh and then there's probably ssh, or whatever else you use to
manage the boxes. Don't want to give that low priority.
(And then there's the "everything else" catagory. There
must be other traffic or you wouldn't need to prioritize web
traffic.)
So:
1) IAX traffic.
2) SSH traffic.
3) Empty Acks
3) HTTP, HTTPS
4) everything else
Depending on your level of paranoia 1 and 2 can be the
same thing. It'd probably be a good idea to have ssh
to your firewall box and to your Asterisk box(s)
have the same priority as the IAX traffic, to ensure
that you can always reach the boxes that might be
causing trouble with too much IAX traffic.
You will want to queue on both interfaces. My experience
has been that the TCP throttling mechanisim works well
enough that throttling back, for example, inbound HTTP traffic
keeps IAX from choking even when the limiting factor is
inbound bandwidth. (Your inbound HTTP will probably be
download requests, whereas mine is download data, so
the details won't work out the same for you as me. The
theory works like this: A large amount of inbound TCP data
can be throttled enough for IAX to work, at least
when the TCP traffic is part of longer lived flows.
Because of the bursty nature of IAX this approach
works best when you know your inbound bandwidth and
throttle so that there's _always_ some room left in the
pipe for IAX traffic.)
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
