[Asterisk-Users] Bandwidth: to seperate or not to seperate

[Rich Adamson]

inline...

> You said:
> "Help us understand exactly what this "incoming traffic flooding the
> bandwidth" is suppose to mean. Are you running something else besides web
> and voip through this link?  If not, then what is "flooding" your 
> bandwidth?"
> 
> You are right about web page serving not using much incoming bandwidth (good for one-sided QoS 
management).  I was inaccurate by saying "hosting webpages" - we also have all email traffic and 
host racked servers for customers of ours too (and I have them on a lower QoS in the 
Netfilter/Wondershaper setup).  Actually, typically, the servers are business customers and 
probably don't use much bandwidth at all but I can't be sure that one of them would not, at any 
time, upload data from their mega-high-speed office connection - its a bit of an unknown.
> 

The above comments would be of some concern, particularly if some sends an email
to the server with a large attachment (or whatever). Given all the "other" traffic,
you're faced with a choice to micro-manage the existing bandwidth, or, do as you
mentioned providing two paths.

Some time ago, someone on the list suggested a QoS-like app (maybe it was wondershaper,
don't remember) that does impact inbound traffic. My understanding is the app delays
TCP response packets (from your server to the external user) essentially slowing the
inbound flow of traffic. If you think about how TCP functions, an ACK packet is
required after approximately three inbound packets acknowledging the receipt of
those three packets; if the ACK packet is delayed by xxx milliseconds, it essentially
impacts the speed at which incoming packets arrive. No such thing for UDP traffic
though. Since web and email traffic uses TCP, that might be something to look into.

> It's a bit of a bummer that inbound traffic shaping cannot be done - considering that its a 
data-center setup as opposed to an office/home setup (kind of a so-close-but-so-far type thing).
> 

True inbound packet shaping would actually require the "sender" to prioritize all
packets, and assumes every layer-2 and layer-3 device between the sender and your
hardware respect QoS settings. That's not going to happen anytime soon, although
some Internet providers do in fact respect it.

> Thinking about it now, before paying money for something we don't need, I should probably try to 
graph bandwidth usage (which opens a can of worms too - I'm used to MRTG but it would only show a 
5 minute average and not instant peaks that would affect VoIP quality - have you ever used any 
other graphing tools?).
> 

You might try STG to graph the usage. Its available everywhere on the Internet and
can be set to poll at one second intervals "if" that's actually necessary. I use
it a lot with five or ten second polling to see peaks, etc.

Rich