Previous

Content

Next 

1.0. Why QoS need to be applied?  

Being sure that your network is sustainable perhaps you are thinking: but now, why do I have to apply QoS? If load is manageable and my network is well designed, why am I going to need QoS? Is not QoS a consequence of the good quality of my network? This means, is not QoS a consequence of plenty of resources and a well designed and behaved network?
The answer to the last two questions is yes. QoS is always better if your network is sustainable and well designed. If you have in your network plenty of resources and it is well designed, the first consequence is going to be that it behavior will be better and quality of service will be an observable phenomenom.
 
But, beware, let me give you a list of some reason to apply QoS even on a well behave network:
 
  1. Load and needs grow very fast, always faster than any good network designer can estimate it's going to be without being outstanding as a squanderer.
     
  2. Because of this you have to put under strict control original and new requeriments; doing this you will discover sooner than later that looking over the original requirements, some of them violate almost immediately its initial bandwidth consumption estimation; and looking over the new requeriments some of them are unexpected, some of them are expected but superfluous, and some of them are expected and necessary but no one estimated than they could appear in the near future.
     
  3. On the unexpected side of new requeriments, one causing a lot of problems are e-mail viruses and spam e-mails which propagate and grow very fast stealing the useful bandwidth; it's incredible that you have to consider them as a requeriment, but they in fact exist, and you have to take into account its pernicious effects and to foresee them as an additional bandwidth requeriment. Also it is very important to identify and quarantine those flows, and for doing this you have to applied QoS besides other technologies.
     
  4. On the expected side there are a lot of old and new superfluous requeriments, most of them caused by the frenetic use of Internet facilities by people, users and customers. Downloading and uploading of big files (images, video, music, games, etc.), frequent access to multimedia sites, e-mails with heavy attachments, chating, voice and video interactions, and all those activities that people develop but are not directly related to the business processes and can be cataloged as superfluous.
     
  5. Also on the expected and necessary side, even when you have to accept some of these new requeriments, it is very important to establish a policy of priorities. Not all requeriments, current and future, are of the same importance. Establishing in advance a clear policy of priorities is the best way to guarantee the good utilization of network resources. Do not leave at random the network bandwidth resource distribution. Applying the indolent policy of the "best effort" is like not having a policy at all. It's like a no law country.
 
   

 
  1. Every requeriment, old or new generates a flow and all flows are not equal. Continuing with the country parallelism, some flows are good citizens, this means, they are designed to be self controlled and congestion avoidance like those based on the TCP protocol; but some other are bad guys, misbehave flows, as those based on the UDP protocol, and they starve well behave flows. UDP flows and some other of the same characteristics have to be maintained under strict control and observation. It's also very important to say that realtime traffic as audio, video and multimedia, run most of them over UDP, worsening even more things taken into account the exponential grow of the utilization of this kind of applications.
     
  2. After classifying flows it is very important to control, prioritize and model network traffic; this way you will be sure that gold users and customers, critical servers and applications are receiving a guaranteed quantity of the available bandwidth. 
     
  3. If you are an ISP and you apply QoS to your network, you can begin to sell different qualities of services at different rates, allowing to increase earnings by expanding your customer base, and classifying them as gold, silver and bronze, depending of QoS serviced to each group.
     
  4. Service prioritization is fundamental. Critical user, customer and application accesses can be minimized or even completely deactivated by non-critical users, customers and applications; for example, people down/uploading heavy files through www or ftp, or watching multimedia application through Internet.
     
  5. Some regular use services, aleatory but of less prority, like e-mails with heavy attachments, long printer spool files, backup traffic, copy, movement and file transfers, etc., when they coincide, reduce the available bandwidth and may cause delay and network congestion; in consequence critical applications like organization's SQL database may collapse.
     
  6. Customers making purchases and users consulting information through the organization's portals, could and should receive an special treatment and a bigger bandwidth than other people that are downloading a song from Kazaa or just simply surfing the net for adult sites; the sales staff, senior executives and strategic mobile personal in remote locations, should have guaranteed a minimal required bandwidth in order to execute transactions without troubles and unnecessary waste of time.
     
  7. In class-A organizations with remote offices the WAN traffic prioritization is critic. The WAN links are very expensive and bandwidth limited. Many critical applications like ERP, voice over IP, remote application servers, critic information consults, etc., require defined and guaranteed bandwidth. Without a service prioritization and a right bandwidth distribution this services could collapse and timeouts are more frequent and endless.
In this first approach to QoS we talk about requeriments identification, and because every requeriment generate one or multiple flows, we pay special attention to these flows trying to identify them undoubtedly to classify and prioritize later. However identifying, classifying and prioritizing flows is just one side of the problem. Also it's very important to figure out how flows reach its destination, it means, which path flows travel to go from the sender to the receiver.
Because flow routing selection affect how load is balanced over the network, and this in fact can provoke that some path experiment congestion while others remain almost idle, it does matter to study these phenomena's using knowledge offered by QoS routing and traffic engineering.
 
Last assertion indeed is more important because network routing selection is normally left to dynamic routing protocols like RIP, OSPF, IS-IS, IGRP, etc. And these protocols select a route using a mechanism based on what is called a metric. Actually, routing protocol metrics are simple values indicating number of hops of the route, installed bandwidth of the link, maximum latency, cost, expected losses or some combination of these factors. Always the route with the best metric is selected and when two or more routes offer the same metric, balance path routing is used (load is evenly distributed through the different paths available), in those cases when routing protocol implement this capability. 
 
But, why this behavior is not the right answer? Well, first of all QoS routing is an incipient technology. Studies are in progress to improve the right selection of routes. Path for flows must be determined based in some knowledge of resource availability and not resource capability of links. Criteria that do not take into account current state of the path to be selected (how much the route is loaded, has the link experiencing transient or permanent congestion, has the route the availability to offer the QoS level that the new flow is requiring, exists another route with lesser capacity but higher bandwidth availability at this moment, etc.) always take the same (perhaps wrong) decision, overloading links with lower metric in favor of those with higher one, unbalancing the network and creating congestion spots somewhere.
 
All this say to us that we must not leave absolutely to dynamic routing protocols the right selection of routes; we need to pay more attention to this problem, and in some cases, to modify or improve the selection using static routes based in human criteria, or better yet, using policy based routing where final selection will depend on previous identification and QoS classification of the flow or flows to be routed. 
 
To improve the QoS behavior of our networks we have to expand the classical tuple definition for flows from [source address, source port, destination address, destination port, protocol] to [source address, source port, destination address, destination port, protocol, QoS]. Last column of our new flow definition put aside the indolent and lazy policy of consider that all flows are equal, and because they are equal must be treated with the same "best-effort" policy. Shifting your way of thinking to this new approach will be the first step to improve network behavior and to offer better and expanded services to your users and customers.
 
Last paragraphs discussion supports this conclusion: keeping the network sound requires avoiding any possible congestion; also is true that if the network is well designed and load is sustainable permanent congestion is only possible due to unbalances. Load balance using QoS routing decisions to select alternate path routing for congestion avoidance is another reason why QoS need to be applied. Better, faster and more intelligent routing selection is being addressed with new emerging technologies like MPLS (Multi-Protocol Label Switching) and QOSPF (QoS-OSPF).
 
   

 
 

 
Previous

Content

Next