On 04/08/2011 12:07 PM, Tom DeReggi wrote: > There is definately a need for different queue types at different points on > the network. Multiple Queue types have been developed because there are > different problems to solve for different situations. This is true.
> What I question is when it is necessary to solve a problem. I hardly justify > a complete network queueing standard overhaul, just to satisfy the abilty to > perform a single stream TCP test to Speak easy at full speed, when most > business circuits serve many TCP streams at a time to fill capacity. This is a very good point. The current trending of internet traffic is geared toward more and more streams. Of the available queue types, only SFQ (or one of it's derivative types) and RED make much sense. FIFO queues, without properly managing the traffic entering those queues, will cause customers to sit up and take notice in a negative way. The problem with SFQ is that the algorithm used to implement this is fairly slow. It doesn't work well under heavy load. More specifically, it falls apart when the volume of traffic is excessive. Mikrotik adds another queue type called PCQ, which is sort of like FIFO queues grouped by some classifier such as source addresses and/or ports OR destination addresses and/or ports OR some wicked combination of all of the above. PCQ is an alternative, as it allows you to set per classification speed limits, but in the end, it is still FIFO per class, which requires very careful crafting of defining traffic types to be sorted into these queues. As to WHEN you need to begin managing network traffic, I personally feel it is ALWAYS necessary. The reality is that even with sufficient bandwidth available, some of that traffic is more sensitive than others to network latencies. Even if you are not creating a QOS policy, you have one. Every interface has an output queue. All a policy does is inform the operating system as to what your preferred order is when placing packets into that queue. There is obviously SOME added latency involved in doing that, but usually that added time can result in a better end user experience. QOS enables you to manage not only high bandwidth use, but high packet rates. You are not limiting packet rates per se, but when that increases (especially on a wireless network), you are more likely to experience collisions. QOS enables you to make those collisions less problematic because you are managing the output side of the interface and know that the "important" traffic will go first. > So it boils down to weighing the scale of how bad the problem is and how > badly the customers notices it. There can be a very fine line on which > Queueing methods are required for specific cases, and sometimes picking one > makes it easier to consistently implement, even if there are some trade > offs. On our core routers we've found RED to work well. But we also have > other areas where we queue where we use other things, such building routers > or customer routers. QOS involves speed limits, but is not always about limiting speeds. A more accurate description of what QOS is would be something like: Management of network traffic policies such that periods of low utilization permit full access to network resources and periods of high utilization will permit preferred access to certain traffic types. Additionally, QOS policies enable an admistrator to level out peaks during very high utilization periods such that all traffic is permitted to pass the policy, but in an orderly fashion. I spent almost 1 minute coming up with that definition, so give me some slack. :-) -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * * NOTE THE NEW PHONE NUMBER: 702-537-0979 * ******************************************************************** -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
