F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

flow-monitor: clarify the manual

Browse Source
This commit is contained in:
Tommaso Pecorella
2020-01-17 17:15:21 +01:00
parent 57147641ff
commit a891808f53
1 changed files with 20 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
src/flow-monitor/doc/flow-monitor.rst
View File

@@ -18,13 +18,13 @@ The source code for the new module lives in the directory ``src/flow-monitor``.
The Flow Monitor module goal is to provide a flexible system to measure the
performance of network protocols. The module uses probes, installed in network
nodes, to track the packets exchanged by the nodes, and it will measure
a number of parameters. Packets are divided according to the flow they belong
a number of parameters. Packets are divided according to the flow they belong
to, where each flow is defined according to the probe's characteristics (e.g.,
for IP, a flow is defined as the packets with the same {protocol, source (IP, port),
for IP, a flow is defined as the packets with the same {protocol, source (IP, port),
destination (IP, port)} tuple.
The statistics are collected for each flow can be exported in XML format. Moreover,
the user can access the probes directly to request specific stats about each flow.
the user can access the probes directly to request specific stats about each flow.
Design
======
@@ -54,7 +54,7 @@ basic packet's data, useful for the packet's classification.
It must be underlined that only L4 (TCP, UDP) packets are, so far, classified.
Moreover, only unicast packets will be classified.
These limitations may be removed in the future.
These limitations may be removed in the future.
The data collected for each flow are:
@@ -71,12 +71,11 @@ The data collected for each flow are:
* delayHistogram, jitterHistogram, packetSizeHistogram: histogram versions for the delay, jitter, and packet sizes, respectively;
* packetsDropped, bytesDropped: the number of lost packets and bytes, divided according to the loss reason code (defined in the probe).
It is worth pointing out that the probes measure the packet bytes including IP headers.
It is worth pointing out that the probes measure the packet bytes including IP headers.
The L2 headers are not included in the measure.
These stats will be written in XML form upon request (see the Usage section).
References
==========
@@ -101,19 +100,29 @@ The typical use is::
the ``SerializeToXmlFile ()`` function 2nd and 3rd parameters are used respectively to
activate/deactivate the histograms and the per-probe detailed stats.
Other possible alternatives can be found in the Doxygen documentation.
It is important to keep in mind that Flow Monitor records the packets statistics by
intercepting them at IP level. As a consequence, when the simulation ends, any
packet queued for transmission below the IP level will be considered as lost.
It is strongly suggested to consider this point when using Flow Monitor. The user can choose to:
* Ignore the lost packets (if their number is a statistically irrelevant quantity), or
* Stop the Applications before the actual Simulation End time, leaving enough time between the two for the queued packets to be processed.
The second method is the suggested one. Usually a few seconds are enough (the
exact value depends on the network type).
Helpers
=======
The helper API follows the pattern usage of normal helpers.
Through the helper you can install the monitor in the nodes, set the monitor attributes, and
Through the helper you can install the monitor in the nodes, set the monitor attributes, and
print the statistics.
One important thing is: the :cpp:class:`ns3::FlowMonitorHelper` must be instantiated only
once in the main.
once in the main.
Attributes
==========
@@ -163,10 +172,10 @@ The main model output is an XML formatted report about flow statistics. An examp
The output was generated by a TCP flow from 10.1.3.1 to 10.1.2.2.
It is worth noticing that the index 2 probe is reporting more packets and more bytes than the other probes.
It is worth noticing that the index 2 probe is reporting more packets and more bytes than the other probes.
That's a perfectly normal behaviour, as packets are fragmented at IP level in that node.
It should also be observed that the receiving node's probe (index 4) doesn't count the fragments, as the
It should also be observed that the receiving node's probe (index 4) doesn't count the fragments, as the
reassembly is done before the probing point.
Examples