Previous

Content

Next 

2.3. Classes of flows  

Next, you have to define your classes of flows. How many classes you define will depend of your particular environment and the vision you are wishing to implement. For example, you could start with 3 classes (Gold, Silver and Bronze), or, depending of your specific requirements, define a more complex hierarchy having more classes with different levels of priorities, depending of importance of the application, its bandwidth and delay requirement. When doing this, do not forget that some flows, like UDP flows, require to be analized carefully, because they are not self-controlled and have a tendency to starve well behave flows, as those based on TCP.
Where to classify each flow is more a matter of common sense that of pre-established cookbooks. Take your time to read the application's specifications and have some words with designers, providers and users of the applications. Some of these applications are designed having internal control of bandwidth consumption; some other are less elaborated and will consume resources as soon as they are available. Users interchange of points of view is also a very convenient way to discover the information you require. 
After doing your job you will have the information you need, it means, where every flow can be classified, and within it class, how much are its requirements in bandwidth and delay resources. Your data table corresponding to flows generated or consumed into the domain could be something like this; this time you will order the table by class been the higher priority on top and the lower priority at bottom.

After finishing with the inner domain flow analysis and classification, you have to step forward with those flows that just travel through the domain, crossing it to go from other sources to other destinations. This time you have to be more strict. Imagine, for this part of the work, that you are a farmer and your farm, the domain, has to be used by other similars as a path for reaching the markets because your location is privileged and you have to administer this authority.
Well, everyone that need to cross through your farm can, but you have to protect yourself and your ownership. What can you do? First, you have to know exactly who are going to cross to line; second, you have to know how many vehicles and how much equipment they are going to move over your lands and roads; third, you have to know also when they are intented to use your services, because you have to be prepared to manage all these circumstances; fourth, everyone crossing your land has to respect your rules and follow, strictly, the specification they gave about how much of your resources they would be using; and last but not least, all of them have to act as good citizens. You are not going to permit fights, abuses, ecological damages, etc. You will pay attention about people conduct and you know that some people, definitely, are not welcome and you will be prepared to prevent them from entering your ownership.
Doing this similarity it's going to be easier for you to approach the work of establishing how your domain could be used by flows that just travel through it. This time your work will be very similar that you did before for inner flows, it means, for each of these flows we have to investigate, again:
  1. Where this flow is coming from?
  2. Where this flow is going to?
  3. What is the source application that generate the flow?
  4. What is the destination application that consume the flow?
  5. Is it possible to identify other flows between source and destination or viceversa that are related to this flow? It means, that correspond to the same application and indeed, can not be separated?
  

Having this information on hand it will be the time to try to reach the same two goals reached before when dealing with inner flows, it means:
  1. To know, exactly, how important is a flow, it means, at which level of priority it could be classified related to other flows crossing the same link.
  2. To know, as exactly as is possible, what is the real bandwidth and delay requirements of every flow, without over estimation induced by users thinking that they have to have all the bandwidth they want.
But now it's going to be a little bit harder. Why? Because these traveling flows are for other applications that are not under your domain control. This time "politeness" will be a new weapon to be used to investigate where or how to classify those flows. Again, a judicious search about the nature of the flows; the applications that generate and/or consume these flows; a deep interaction with people that used to work with these applications; a conscientious study of the applications' specifications; some time to be taken to have some meeting with applications' designers and providers; and finally a little dosage of commom sense are going to be very useful to take better decisions.
Don't miss the goal that what you are trying to get is something like table #2. You have to judge, for every flow crossing the domain, what are the mean and maximum throughput to be injected into the domain; what is the maximum delay that these flows can accept without performance application debasement, and finally, how to select a class where each of them could be located. Later, after selecting a class, it's going to be very important to be honest with potential users having some words with them for talking about your work, for talking about the flows they are using and the classification you selected for these flows; and the reason and motivation you took when you decided to put them in that classification. These 'petite' meetings are going to be very useful to reclassify some flows and for having a better understanding of what you are doing.
Note: there is some good examples of how to sniffing flows in my work at An study of network load.
When finishing this second round of the job you must have in your hands two tables (inner domain flows and travelling domain flows) where classification of every flow is decided, having also an unvaluable information about resource requirements in terms of bandwidth consumptions and maximum delays supported. As you will observe later, being in the stage of implementing your ideas your steps can be walked back to revise and refine your original tables, perhaps adjusting over here and over there, when a better knowledge of the domain behavior emerges as you dive in its innermost.
Next step will be to locate guards in every outside door of our domain. These guards are going to be dedicated to control flows flowing from the domain to the external world and from the external world to the domain. These control guards will enforce our particular vision of how our domain has to respond to external conditions interrelated with it. But for assembling our guards we need some weapons. For QoS implementation our weapons are going to be "the QoS tools".
A brief comment: after finishing this part of the QoS implementation and having on hands your traffic tables would be a good idea to revise the domain infrastructure and compare it against the traffic to be moved. Some questions could be revisited: has this domain enough infrastructure to support its load? Knowing better the traffic to be managed; can we assure that our network is sustainable? As it was told before, this theme is out of the scope of this document but having the expected consumption already estimated it would be very nice to check that our domain is okay before stepping ahead with our work.
   

Previous

Content

Next