Measurements based on packet traces allow for fine-grained insight into details of network resource usages. As the Internet continues to grow, a thorough understanding of traffic behavior at major aggregation points is important. Since these aggregation points often connect to an ATM substrate, the availability of tools such as oc3mon, which can tap into ATM connections, becomes valuable. This is an initial characterization of a trace collected by oc3mon on a major aggregation point, and about 70 seconds in duration. All graphs and data here is based on that single trace. All host references are to source hosts only, particularly how many source hosts inject traffic during an observation period.

What is unknown in these statistics is how many entities contribute to the traffic, such as the number of source hosts. Packet traces can yield answers to this, such as:

If time series are not needed, a perhaps more revealing representation can be made via cumulative histograms, as per the following graphic:

If we normalize the values of the X-axes to compares the curves of the three objects, we can overlay all three graophs:

Focusing on the hosts, an interesting consideration is possible dominance of the network by few hosts. An example implemented here considers the packet and byte impact of the number of hosts for the 5th, 10th, 25th, 50th, 75th, 90th, and 95th percentiles of the traffic.

The output format of the analysis program used here, which allows the selection of the oc3mon interface as well as the time increment, is:

time  packs  bytes   hosts  host percs for packets    host percs  for bytes
                             5 10  25  50  75   90   95    5 10 25  50  75  90   95
1.000 15709 55512408 5478 : 11 26 128 616 1985 3908 4693 : 5 12 42 183 597 1236 1786 :

which can then be post processed. The first 5 seconds output of the trace as seen with a 1 second delta-time is:

1.000 15709 55512408 5478 : 11 26 128 616 1985 3908 4693 : 5 12 42 183 597 1236 1786 :
2.000 15854 53794528 5560 : 11 27 132 637 2054 3975 4768 : 4 12 45 192 623 1276 1848 :
3.000 15668 54649736 5446 : 9  23 123 603 1973 3880 4663 : 2 8  38 174 578 1221 1755 :
4.000 15883 54884640 5369 : 8  22 114 583 1921 3781 4575 : 3 8  40 179 609 1255 1772 :
5.000 15952 55020576 5410 : 9  23 112 597 1930 3815 4613 : 3 9  37 169 578 1229 1785 :

trying the same for the first 500 msec for a 0.1 seconds time increment:

0.100 1555 5604160 1075 : 8 19 86 298 687 920 998 : 2 5 25 94 211 339 443 :
0.200 1549 5702776 1044 : 8 19 75 270 657 890 967 : 4 7 28 90 207 324 424 :
0.300 1534 5574912 1046 : 8 21 80 279 663 893 970 : 4 8 25 87 203 341 440 :
0.400 1549 5469416 1039 : 9 22 82 265 652 885 962 : 3 8 29 93 206 329 428 :
0.500 1513 5618208 1012 : 7 17 76 256 634 861 937 : 4 9 31 92 208 332 424 :

Note that for the 5th and 10th percentile there is not that much of a difference between a 1 second and a 0.1 second time increment, and even at the higher percentiles the numbers are sill comfortably close, suggesting significant traffic aggregation going on, even at microscopic time steps. Nevertheless around 10 of about 5500 hosts in the 1 second time interval analysis consume about 5% of the used resources, and about 23 out of 5500 consume one tenth. While significant aggregation is happening, there is also obviously a strong dominance of few hosts consuming disproportionate fractions of the available resources.

Details of the distribution by percentile are illustrated in the following graphs, which display the number of hosts for the 5th, 10th, 25th, 50th, 75th, 90th, and 95th traffic percentiles.

Redoing the same at a 0.1 second timer resolution reveals very similar curves:

The data sets used were generated from the raw binary data with the the conversion program oc32bysrc.pl.

For completeness reasons, a simple oc32asc.pl converter from the binary file to ASCII is available.