The combinations of source and destination LKMs deployed to implement a certain performance computation, are able to instrument IPv6 datagrams at configurable levels of granularity. The modules exploit three main strategies to reduce the processing load imposed on the instrumented nodes, as well as the volume of measurement data, both of which, together with the inherent properties of the in-line technique can reduce significantly the costs of the measurement process. Partial byte capture, packet filtering, and packet sampling are
146 IOCTL is a special function that handles read, write and communication with a device through a
single file descriptor, and can be used to pass almost anything from a process to the kernel, such as in this case, a pointer to a structure.
147 As an example, an extreme upper bound requirement can be for an application not to loose packets
when the destination module operates at full line speed with minimum-sized packets. One can consider a software implementation on a commodity PC able to process minimum-sized IP packets at 100 Mb/s Ethernet link. Studies have shown that the smallest popular MTU is around 44 bytes for TCP control and acknowledgement segments (which, using IPv6 would be 64 bytes). If the node is able to actually process 64-byte (512-bit) packets at 100 Mb/s, and assuming that the destination measurement module would process every single packet (highly unlikely), then the application would have to read the queue every 5.12 µsec, in order to make sure no packets will be dropped.
mainly used by measurement systems that operate under un-controlled conditions and observe network traffic passing through a link (as discussed in section 3.5.2).
Partial byte capture has been implemented by each destination LKM which concludes a two- point in-line measurement, and passes the related per-packet data to applications for further processing and analysis. After performing a node-local computation or a simple observation on an incoming already instrumented IPv6 datagram, the module then only stores partial header data to be passed to user-space processes. This data could in theory be as little as 8 or even 4 bytes per packet (for one-way delay and loss, respectively) in case the module performed the complete computation in real-time and only stored its final outcome. For the purposes of this prototype, however, the destination module only performs the time-critical measurement actions and stores all the network and transport layer headers of the packet in its memory-resident queue. This can result in capturing from 56 to 84 bytes per instrumented
packet148, which are already a fraction of the overall traffic passing through the node and can be further reduced when measurement data is written on disk (section 4.4.4). In addition, it is important to note that the multi-point nature of the in-line technique enables this amount of per-packet data to be captured (stored) at a single point in the network, while containing all the necessary information for a two-point measurement. This property essentially reduces almost in half the amount of measurement-related data that would be necessary in order to perform a two-point measurement using conventional passive monitoring techniques149, and it obviates the need for shipping and correlation of per-packet data from multiple points in the network, probably over the network itself.
Although the in-line measurement modules observe the operational IPv6 traffic passing through certain network nodes in a similar manner to passive monitoring approaches, the actual instrumentation can be targeted on certain subsets of the IPv6 traffic. Choice of a particular subset of traffic to be instrumented with the in-line measurement headers depends on the filtering and sampling parameters configured upon loading or during operation of a
source measurement module, which is the initiator of the in-line measurement activity over a specific instrumented path. The relevant destination LKM will then only process packets encapsulating the appropriate IPv6 destination options; hence, it will operate on the same
148 For this prototype implementation, the best case scenario is an instrumented UDP/IPv6 (8 + 40
bytes) packet carrying an OWL destination option (8 bytes) in a single option-bearing extension header; the worst case scenario is a TCP/IPv6 (20 + 40 bytes) packet carrying an OWD destination option (24 bytes).
149 The in-line measurement technique is only compared and contrasted to passive monitoring
techniques here, because they also operate on the actual network traffic. Active measurement techniques operate on special-purpose traffic under controlled conditions.
subset of the traffic instrumented by the source LKM. Packet filtering is implemented by a
control structure passed to a source measurement module containing five entries that comprise a filter specification, namely the source and destination IPv6 addresses of a datagram, the transport protocol, and the source and destination ports of the transport layer header. Subject to this filter specification, the measurement granularity of the module can be as fine as instrumenting only certain application flows (specified by the complete 5-tuple) or as coarse as instrumenting every datagram passing through the IPv6 instance of the node. Any of the 5-tuple entries can be replaced with a wildcard filter that evaluates to true for any value found at the corresponding header field of an examined packet, and constitutes the packet eligible for instrumentation. At an intermediate granularity level, the source module can instrument, for example, packets exchanged between two specific IPv6 interfaces, packets originating at or addressed to specific IPv6 networks, and packets belonging to the same application-level service, as this can be identified by a particular transport protocol and port number. Of course, a particular filter specification should be configured in a reasonable accordance with the specific implementation and topological setup of the in-line measurement modules. For example, for a standalone, two-point implementation, instrumenting every single packet passing through the source LKM would not be ideal, since only a fraction of these packets would also pass through the corresponding destination module. Inter-operation with not-instrumented nodes would still apply, however, instrumenting packets which will not be eventually subject to the two-point measurement can be considered as a waste of resources. In contrast, under a network-wide in-line measurements scenario where source measurement modules are deployed on every ingress node and destination modules on every egress node respectively, such wildcard filter specification could be used to instrument and eventually measure a performance characteristic of all transit IPv6 traffic.
Proper use of packet filtering can minimise the intrusiveness of the in-line measurement technique regarding the associated per-instrumented-packet overhead. This includes the bytes of measurement data added to selected packets, but also the processing time required to perform the measurement tasks both at the source and the destination of the instrumented path. Together with partial byte capture, packet filtering can also reduce the measurement data aggregate volume and hence its storage requirements. However, nodes running the source measurement module, still have to process the internals of each outgoing packet, in order to decide whether it should be instrumented or not. This overall system processing overhead can be even further reduced by the deployment of packet sampling schemes which can further improve the scalability of the implementation by minimising the additional real-time actions on the overall packet population. For the purposes of this prototype implementation, two
systematic sampling schemes have been deployed, one event-based and one time-based, as shown in Figure 4-9. Similarly to packet filtering, the sampling schemes are deployed at the
source measurement module to select packets to be instrumented based on some simple systematic algorithm. The destination measurement module will then process only the packets already instrumented, honouring the chosen sampling strategy. The event-based scheme uses packet counts to instrument with measurement extension header options only one-in-N
packets (Figure 4-9). A counter is incremented each time a packet is passed to the LKM’s processing routine, and the packet is sampled only if (N-1) packets have been already observed since the most recently instrumented datagram. Similarly, the time-based scheme uses the packet ‘arrival time’150 to trigger the selection of a packet for inclusion to the sample and to instrument at most one packet every M microseconds (Figure 4-9). A packet is eligible for instrumentation only if at least a specified number of microseconds have elapsed since the previously instrumented datagram.
Figure 4-9: Systematic Sampling Schemes
When a sampling scheme is enabled and packets are checked against it as soon as they enter the source measurement module, then for packets not eligible for instrumentation the processing overhead of the corresponding node is minimised to only perform a simple comparison over the chosen sampling strategy and not process the packet internals. However, the sampling algorithm in such a scenario is applied to all the packets passing through the IPv6 instance of the instrumented node, which do not necessarily resemble the parent population of the measurement process. This is because in-line measurement is a targeted
150 Arrival time here refers to the time a packet ‘arrives’ at the source module’s processing routine. In
technique that although it can be applied to all traffic passing through an instrumented node (similar to passive monitoring), its great benefit is that it can instrument only specific subsets of traffic determined by a chosen filter specification at a configurable granularity. In other words, the packets shown in Figure 4-9 that are actually chosen by the sampling process do not automatically qualify for instrumentation, since they might not satisfy the filtering criteria. Hence, for example, when choosing one-in-N packets to be instrumented while the module only operates on traffic of a particular application flow, then every Nth packet observed by the module might not belong to the specific flow, and moreover there is a greater probability that the packet will not be the Nth packet of that flow. Therefore, for the purposes of examining the statistical significance of a sampling algorithm with respect to a specific parent population, then the scheme should be applied only to packets that qualify the measurement-specific filtering criteria151. However, in this case the deployment of the sampling scheme does not greatly reduce the processing overhead of the instrumented system since every packet’s internals are first examined by the filter tests; yet it can still serve the purposes of measurement-data and per-packet byte overhead reduction. Sampling at the node running the in-line measurement destination module is also an option, since this module only examines the appropriately instrumented datagrams, hence a sampling scheme can be applied only at certain traffic related to the measurement process.