Previous

Content

Next 

2.2. Sniffing the flows  

After you select your tool and familiarize with it you have to build the strategic you will implement to sniff the external link connection to your domain. We need to obtain: 1.- The identification of all and every flow that travel by each link. 2.- The average throughput consumed by each of them. 3.- The frecuency or some time pattern of when and how long every flow cross through the links.
It's not easy, and patient has to be our first weapon. Sniffing is like spying. Apples are not going to fall from the tree; you have to work hard to get the information you need. We know that large variety of aleatory flows don't make things easy but persisting is the answer to what we want to do. Finally you have to get some tables like sketched below with information about the links and flows.

Note: there is some good examples of how to sniffing flows in my work at An study of network load.
It's recommended to ignore those flows having very low throughput; always they can be identify later. Initially you have to concentrate on those flows that have a considerable weight, because they are that influence larger the QoS behavior. Also to have a better way to deal with them, pay more attention to those that have higher average throughput multiplied by active time. Try then to order your registers inversely by throughput, or throughput per time to have a better understanding of which are that affect higher the environment.
Our strategic will be to drill from top to bottom from our tables. Always take the next flow on the top to be analized and when ready, go ahead and take the next one. Perhaps you late a year but when finishing, no one can talk you about this domain without being an expert, because you are going to be the person who better know this domain, its behavior and tricks.
 
After sorting your registers as was indicated, let's start now to pay attention to those addresses (source and destination) that correspond to the domain. What we want to do is to split our table into two new one: the first, it's going to have all flows with addresses corresponding to the domain; the second, it's going to have all flows with addresses not corresponding to the domain, it means, those flows that travel through the domain but entering and leaving it, where the domain is just only a forwarding mechanism for them.
 
After doing this work, if your second table is empty, it means that the domain is not used as a transit domain, and this is a great advantage; you can concentrate on it without been worried about other flows that you would have to forward too, increasing bandwidth resource requeriment to be needed and complicating the domain management.
 
But, if instead of been the second table, is the first table that is empty, then your domain does not generate and does not consume any flow, and is only a transit path for flows generated and consumed in other domains.
 
Finally if both tables are not empty, the domain is an hibrid, having some flows that just travel through it and some other generated and consumed on it. Whatever your final table(s) was (were) we are going to begin our job with the table of flows generated and/or consumed in the domain. As was told before, drilling from top to bottom we take the first register and focus on it; now for each of these flows we have to investigate: 
 
  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?
 
   

 
Our interest in having an answer to all these questions are not the answers by themselves, but instead, having a path to reach these goals:
  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.
To get the answers to the first five questions you have to investigate about each flow; study which application generate and/or consume it; study the application specifications to understand better how it works and how much are really its requirements, having perhaps a conversation with its designers and providers; and finally having a contact with their users for looking what they are doing. Trying to get these answers you will be gained a better understanding of how the domain interacts with the rest of the world.
Having those questions answered, now it's time to try to get an answer for your final goals represented by the last two requirements. Requirement number 2 has to be estimated after doing a judicious analysis of the application, based in your knowledge about its specifications and your knowledge about the people that work with it. This analysis should give you an answer that represent as better as is possible the mean and maximum bandwidth consumed by the application, and the maximum delay that the application can support.
By the way, when trying to recognize a flow and things become harder try with NBAR (Network-Based Application Recognition) by Cisco. It is a new classification engine that can recognize a wide variety of applications, including Web-based applications and client/server applications that dynamically assign TCP or UDP port numbers.
   

Previous

Content

Next