For the purposes of this prototype, analysis applications are instantiated locally, at the network node running the destination measurement module, and hence the need to ship any amount of measurement data over the network for the unidirectional in-line instrumentation is obviated. However, it is sometimes interesting to investigate Internet pathologies that relate to path asymmetries or to different performance experienced between the forward and reverse paths of traffic between two points in the network. For the connection-oriented TCP streams in particular, the ability to re-construct whole TCP sessions can prove valuable for the purposes of identifying among others, the (dis)similarity in performance experienced by the data and the acknowledgement paths whose traffic has different characteristics160, as well as details of the different TCP phases such as the connection setup time and duration161. Bi-directional in- line instrumentation of IPv6 traffic can be achieved between nodes by simultaneously running the source and destination measurement modules at each system, as shown in Figure 4-12.
Figure 4-12: Bi-directional In-line Measurement Instrumentation
160 The TCP reverse path consists of minimum-sized acknowledgment segments and, especially for
flows such as bulk TCP transfers, can experience very different performance from the medium or maximum-sized packets that are sent over the data path.
161 Connection setup is the time between a TCP SYN packet sent and a TCP SYN+ACK packet
received by a communication end; connection duration is the time between TCP SYN and the TCP FIN packets sent by a communication end.
The modules are attached to each system’s input and output IPv6 routines respectively (section 4.4.2.2), and outgoing datagrams are instrumented according to the specified configuration parameters, whereas incoming traffic is examined to identify the presence of certain in-line measurement option-bearing headers. The relevant packet header data is then extracted to user-space and stored locally, as described in the previous section. By the end of the actual instrumentation, the measurement data can be shipped over the network to either of the two nodes or even a third system that will deploy the post-analysis with the collective input. Post-processing re-constructs individual TCP flows between pairs of hosts and TCP source and destination ports, based on either a set of well-known TCP service ports or service ports manually specified during the analysis operation. The partial per-packet header data stored in the two trace files is read into a TCP record for each packet that contains not only the two-point in-line measurement indicators, but also relevant fields from the IPv6 and the TCP headers. Each TCP record is then used to update state information of the flow it is identified to belong to, in a linked list of hash tables, as shown in Figure 4-13.
Figure 4-13: TCP Connection Dictionary
If a record belongs to a flow selected to be reconstructed, but the relevant entry does not exist in the flow state list (i.e. it is the first packet read from the trace that belongs to the specified flow), then a new state entry is created based on the packet’s IPv6 source and destination IPv6 addresses and transport ports162. State for each flow holds information about the number of packets found in the partial trace files, the total time during which the flow was active, as well as the details of certain control packets that can be used to report internal information for a flow such as its connection setup time and whether it has been gracefully completed or it was interrupted. Furthermore, the measurement-related fields of each flow’s TCP records can be written to separate per-flow trace files to be fed into further visualisation applications.
162 It is assumed that during an in-line instrumentation interval only one flow could have been active
between specific pairs of IPv6 hosts and TCP ports, i.e. a client port will not have been re-used to access the same service port, between the same end-systems.
4.5
Summary
The implementation details of a prototype system that facilitates IPv6-based in-line measurement between two points in the network have been presented in this chapter. By adopting a highly modular design that lends itself well to a distributed measurement framework, the different realisation alternatives of the core measurement components as hardware, software or hybrid modules have been briefly discussed.
The selection of Linux as a platform to build the software-based in-line measurement prototype has been elaborated, and the operational design choices and implementation details of the prototype have been thoroughly discussed. Different actions are performed by the in- line measurement Loadable Kernel Modules (LKM)s, depending not only on the type of measurement they perform, but also on whether they operate at the source or at the destination of a unidirectional instrumented path.
Partial byte capture, packet filtering, and packet sampling are three distinct mechanisms that have been employed by the prototype to provide for configurable levels of scope and granularity and reduce the cost associated with the measurement process. In addition, enabling the instrumentation of connection-oriented flows that consist of maximum-sized datagrams has been taken into consideration and addressed through appropriate adjustment of the maximum transport layer Payload Data Unit (PDU).
Finally, the deployment and operation of user-space processes that complement the prototype by enabling the initialisation and handling of the core measurement components, as well as by synthesising raw, per-packet measurement data to implement a variety of performance metrics, have been presented.
Chapter 5
5
Instrumenting IPv6
Application Flows
5.1
Overview
An evaluation of the in-line measurement technique is presented in this chapter through the instrumentation of representative IPv6 application flows over different-capacity operational topologies. Native and tunnelled end-to-end IPv6 experiments over the Internet have been facilitated by the Mobile-IPv6 Systems Research Laboratory (MSRL) infrastructure whose topology and connectivity are described in the following sections. Representative performance metrics are implemented and presented to reveal numerous properties of interest for a diverse set of instrumented flows. Experiments are decomposed down to two categories instrumenting TCP and UDP flows, respectively. For each transport-based category the One-Way Delay (OWD) IPv6 measurement destination option is used to implement a set of time-related performance metrics, and the One-Way Loss (OWL) IPv6 measurement destination option to provide insight on unidirectional packet loss phenomena, such as dropped and retransmitted packets, as well as packets delivered out of order to the destination. Time synchronisation issues, as well as tactics to improve system clock accuracy over high-capacity paths are also briefly discussed. The overhead associated with the in-line measurement technique is evaluated, and two systematic sampling schemes are used to indicatively demonstrate the potential greater overhead reduction, together with its consequential influence in measurement accuracy due to the reduction of the sample space. Finally, the in-line measurement technique is compared to complementary measurement techniques and tools through both a quantitative analysis, and a qualitative discussion that concludes this chapter.