Previous

Content

Next 

2.1. The domain  

For implementing QoS first step must be to define a domain where you will start to initiate your experiments. Donīt be afraid, yes, we are talking about experiments. To apply QoS you have to experiment first to validate your models, and after experiments conclude that you are in the right direction you can translate the proved model to the real world. With this I'm trying to tell you that never use your real and current network to implement QoS technologies, without previously testing and validating in a testbed what you suppose you are trying to implement.
A domain can be something as simple as your own workstation or something as complex as a complete autonomous system, but in any case defining it very well and exactly what its frontiers are going to be is a very important consideration. Initially being a beginner is a lot better not to be so ambitious and to select for our first experiences a limited domain, perhaps some little network formed by 4 to 8 workstation, a server, a switch and a router that connect all to the Internet. After you begin to study and understand QoS and you feel better and trusted in your knowledge and successful models implemented, you can go ahead and try with more complex stages.
How do you select the domain? Well, it would be very nice to select some section of a network where problems have been reported; this way it's going to be very simple to check and confirm that after applying QoS things go better, and it's going to be also easier to analize, deduce and implement a right solution.
After selecting what your domain is going to be next step will be to have a very clear perception of it. What we will try to do is to know this domain as better as is possible to know it. We are going to put the domain under a constant and attentive observation. Insisting in our observation we are going to know exactly what is occurring on it, which flows are entering and leaving the domain every minute, how those flows behave and travel inside the domain, and which are the events that take place and when they do take place. Searching will be our source of information to increase everyday our knowledge of this domain.
 
As soon as you understand as better as is possible your domain behavior it's going to be easy to figure out what is ocurring, to infere what's going on, to discover problems and mishaves and to find right solutions to fix those situations. We are going to start drawing a cloud that cover the all domain and identifying exactly how many points of the cloud have a relationship with the outside. These relationship are going to be identify by its connection to the outside world. Let us try with this simple drawing:
 

 
In our domain (the cloud) we have three points of communication with the outside world. It can be more or less of these points. I told you before that selecting a simple domain with just one point of communication with the outside world would be easier to work with, but it's going to be your decision and your problem to select a domain as complicated as you want. In our example, blue, red and green double arrows are connections or links with the outside world where flows enter and leave the domain. Our first task will be to identify completely every flow entering and every flow leaving the cloud. For now it doesn't matter what's occurring inside it, just how our domain communicate with the rest of the world.
 
   

 
We need now to define some way to identify the flows. Because we don't want to complicate things unnecessarely, let us use a simple 6-tuple of values forming by source address, destination address, source port, destination port, protocol and average bandwidth used. We also need some tools to sniff the links and getting the information we want. There are a broad selection of these tools (some free and some really very expensive) but because I'm not going to advertise any of them the site http://www.caida.org is the best place to start with when looking for the right tool for you.
 

 
Previous

Content

Next