Georg Carle, Sebastian Zander, Tanja Zseby
GMD FOKUS; Global Networking (GloNe)
Traffic engineering and validation of service level agreements (SLAs) require measurement of quality of service parameters such as delay in specific sections of the network. Due to frequent asymmetries of forward and backward paths, in many cases the measurement of one-way metrics is required.
Active measurement methods, which allow to survey large parts of the Internet with a high precision, is an active research area (see, e.g., [PaAM00], [KaZe99], [PaMA98], [UiKo97]). Active measurements rely on sending of test traffic through the network. The approach has the disadvantage of generating additional load on network links and routers, which can significantly affect the measurement results. Active measurements have additional disadvantages, as test traffic may bother intermediate providers especially if test traffic is not recognizable as such, and as it may lead to additional costs in case of usage-based charging.
In contrast, passive measurements are based on already existing traffic in the network. While passive methods may lead to additional traffic as a result of the measurement, these methods avoid the negative impact of test traffic. At the same time, passive measurements lack the advantages of test traffic generated by active methods, as the test traffic leads to controllable experiments, where pre-defined traffic patterns suitable for the measurement goals are sent over the path of interest. Nevertheless, for some applications (e.g. SLA validation, traffic engineering) the measurement goal is to provide performance results for the treatment of real customer traffic. The traffic of interest is already present in the network. In this cases the measurement goal can be achieved efficiently by passive measurements avoiding the effort and the disadvantages of sending test traffic.
An approach to passively measure one-way-delay is to generate a timestamp and a unique packet ID for each packet of interest at the involved measurement points. In [GrDM98], a solution based on this approach is presented that uses with dedicated hardware and a 32 bit CRC as packet ID. In [DuGr00], an approach identifying paths followed by packets of certain IP flows for is presented, where a simple hash function over the first 40 bytes is used for the generation of a packet ID.
We have implemented a modular passive meter based on an extended Linux netfilter classifier which is suitable for passive measurement of one-way-delays. The meter has a modular structure which allows to use and compare different packet id generation functions. In this paper, we investigate requirements of a passive measurement system for one-way-delay measurements, i.e. classification demands, required accuracy etc. We first define the following major building blocks for the system: packet capturing, timestamping, classification, packet-id generation and result data transfer (Figure 1). Based on these building blocks, we investigate alternative methods for implementing them, in order to find the most efficient way to fulfill specific tasks. After capturing of a packet (pkt), a timestamp (t1) is applied. If measurements are done for multiple flow specifications simultaneously, the flow identifier (identifying traffic aggregate or microflow) can be provided as an additional information element after classification. Subsequently, a packet identifier (packet-ID) is generated. From both measurement points involved in a one-way-delay measurement, the packet-ID (id) and the timestamp (t1) are transferred together with an measurement point identifier (c.f. MP1 or MP2 in figure 1) to a analysis application where the delay is calculated. Based on this model we investigate how the selection of algorithms and parameters of the different building blocks influence the performance (resource consumption, speed) of the overall system. In the paper we focus on the analysis and comparison of different packet ID generation functions. For this we investigate the usage of a simple combination of highly variable header bytes, a CRC function, the scheme used in [DuGr00] and the MD5 message-digest algorithm [RFC1321, Touc95a]. We present the influence of this functions to the performance (speed and accuracy) and the resource consumption of the system.