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 _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
