Need for Sampling

The rapidly increasing data rates of communication networks impose growing measurement demands in both processing and storage capacity, especially for finer-grained techniques, such as flow measurements and packet monitoring. For example, it has been reported that software- based Netflow running on high-speed routers that implement forwarding in hardware, can cause significant overhead due to unusually large increase in CPU utilisation [NFLP]. Furthermore, the approximately 50 MB of storage requirement for daily SNMP statistics collected over the T1 NSFNET backbone [ClPB93b], and the more than 650 MB 24-hour- long packet trace for a single entrance interface into the T3 NSFNET backbone in 1993 [ClPB93c], have evolved -in less than a decade- to the 1.2 TB of disk space required for a 24- hour-long trace from 11 IPMON systems over the Sprint backbone network [FrDL01].

Passive measurements are inherently more dependent (than active) on such efficiency and performance constraints, since they operate under uncontrolled conditions, by monitoring the non-stationary operational traffic of the network. Additionally, their seamless operation is particularly desirable when the network exhibits extreme or abnormal conditions, and these constraints are even more stringent.

At the finest measurement granularity level, packet monitors employ three main techniques to reduce the processing load and the volume of measurement data: Packet filtering enables only capturing a specific subset of packets, mainly based on the fields of the network and transport layer headers. Partial byte capture is used to only record a limited number of bytes for each packet, usually containing the most valuable network and transport layer headers’ information. Finally, packet sampling can be performed to limit the fraction of packets that need to be captured and further processed. While packet filtering and partial byte capture can provide for reduction in data volume and storage requirements, they can only marginally decrease the per-packet processing overhead, since they still have to process in detail the

56 _{PacketScopes (section 2.3.3.4) have also been used within NetScope to provide fine-grained packet}

internals of every packet observed on the link. In contrast, packet sampling can also greatly reduce the amount of per-packet overhead, and can hence be used to improve the scalability and performance of real-time network measurement and operations. This is particularly crucial for monitoring functions that are enabled on forwarding elements of the network. For example, Sampled Netflow is highly recommended for high-speed routers’ interfaces since it keeps the measurement overhead low, by allowing most packets to be switched faster without additional NetFlow processing.

Sampling algorithms heavily depend on the application domain so, for example, we briefly referred to algorithms targeted at identifying and keeping state for only large flows on Netflow-enabled devices (section 2.3.2.2).

Early studies applied different sampling methodologies to single-point packet monitoring data, and tried to evaluate the accuracy and resemblance of sampled traffic characteristics to the characteristics of the parent population (i.e. the overall traffic volume seen on the particular link for a specified time interval). Packet sizes and packet inter-arrival times were among the most popularly used assessment targets, and a number of statistics have been used to indicate similarity between the sampled and the parent distributions [ClPB93c, AmCa89]. Three classes of sampling schemes that have been widely considered are the systematic sampling, stratified random sampling and the simple random sampling. For any one of these classes, particular sampling fractions can be implemented using either event-based or timer- based mechanisms. Hence, packet counters or timers can trigger the selection of a packet for inclusion in the sample.

Systematic sampling describes the process of deterministically selecting every kth element of a trace. The process configures its granularity by selecting the starting points and the duration of the selection intervals. A systematic sampling algorithm can select every nth packet arriving at a monitored interface, or all packets arriving at pre-defined time intervals (e.g. select one packet every U seconds). Stratified random sampling is similar to systematic and it describes the process of randomly (rather than deterministically) selecting an element from within a specified subset of the parent population. The elements of the parent population are first grouped into subsets in accordance to a given characteristic (time or counter-based). Then, an element from each subset is selected at random (e.g. randomly select a packet from within each 30 second interval of a trace). Simple random sampling describes the process of randomly selecting k elements from the total population. Random sampling requires the generation of random numbers, and can achieve unbiased estimators by avoiding using strict periodic descriptors that might resemble possible periodic characteristics of the observed phenomenon. Random sampling is considered to be the most dependable representation of the parent population, but it imposes greater implementation cost in obtaining the random value. Packet count-triggered sampling techniques have been reported to perform better than time-

triggered ones, especially for assessing packet inter-arrival times, mainly due to the frequent bursty periods when many packets arrive on a link with small inter-arrival times (often missed by timer-based sampling) [ClPB93c].

2.3.5.1

Trajectory Sampling

More recently, a highly-cited study suggested packet-content-triggered sampling by matching the invariable contents of a packet against a hashing function to select a representative sample of traffic across a measurement domain. Trajectory sampling [DuGr01] is a method for network-wide (multi-point) packet sampling, and provides an estimator for the path matrix through direct traffic observation. Instead of randomly sample packets at each link, this method makes a sampling decision based on a deterministic hash function over the packet’s content and hence, by using the same hash function across a domain to sample packets, it ensures that a packet is either sampled on every link or on no link at all. The hash function, although deterministic, it resembles a random sampling process, so that the subset of sampled packets are not statistically biased in any way. When a packet is selected to be sampled, a second hash function is used to obtain a unique packet identifier (label) within the domain, based again, on the packet’s content. Each link within the domain that selects a packet to sample, it then computes a label which is sent to a measurement system. By matching labels generated from different links in the domain, the path that a packet followed from ingress to egress can be inferred. The uniqueness57 _{of labels generated for different packets within a} measurement period, as well as the degree of pseudo-randomness of the sampling process both depend on choosing the appropriate hash functions.

Implementation of this, network-wide, trajectory sampling requires that each link interface is capable of computing both the sampling and the label hashes. However, it does not require router state other than a small label buffer, and it is claimed that it can be implemented using state-of-the art Digital Signal Processors (DSP)s even for the highest interface speeds available today. In addition, the label generated for each sampled packet in each interface that then needs to be transferred to a measurement system for correlation and post-processing can be as small as 20 bits. By being a direct traffic measurement method, trajectory sampling does not require any status information from the network, and can produce a sample of the path matrix that dynamically adjusts to alterations in the traffic flow of the network.

57 _{Some identical labels can be disambiguated to unique trajectories, depending on the network}

2.3.5.2

The IETF Packet SAMPling (PSAMP) Working Group

Within the Internet community, the IETF’s Packet SAMPling (PSAMP) Working Group has relatively recently been established to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. Sampling capabilities should be computationally simple in order to be implemented ubiquitously at maximal line rate, but at the same time, they should be able to support a range of existing and emerging measurement-based applications [PSAM].

The main objective of the working group is to standardise the way a fraction of traffic can be sampled, collected and transported as opaque objects under three main processes. A selection process inspects each packet at an observation point to determine whether it should be sampled. Observation points can be a shared medium, a single port of a router, or a point-to- point link to which a probe is attached. Selection process can maintain state information by updating variables such as packet sequence numbers and arrival timestamps. A packet can be sampled based on the packet content, on information derived from packet’s treatment at the observation point, or on any state information maintained by the selection process. A

reporting process constructs a report stream on packets selected by the selection process, in preparation for export. Packet reports can contain a subset of the packet content, together with selection state and packet treatment information. An exporting process sends, in the form of export packets, the reports collected from one or more selection/reporting processes to one or more collectors [Duff05]. Interestingly, it has been suggested that the IPFIX protocol (section 2.3.2.3) will be used for export of the report stream.

A PSAMP device should host at least one observation point and an instance of a selection, a reporting, and an exporting process.

The PSAMP working group targets at specifically providing standards for the exact packet information that should be available for reporting, the exact format of the report constructed by the network element, the format of the stream of the packet reports, as well as the interface for presentation of reports to on-board applications. Additionally, the definition of a packet sampler MIB to include parameters for packet selection, packet report and stream format is scheduled, which can potentially increase the popularity and widespread deployment of PSAMP functionality within SNMP agents.