The One-Way Loss (OWL) measurement exhibits different characteristics from the one-way delay measurement both at a conceptual and at an implementation level. The focus of the prototype is on the two-point implementation of the one-way packet loss metric between two end-points of an instrumented path that deploy the corresponding OWL source and
destination LKMs, respectively. However, in contrast to the stateless operation of the OWD measurement modules, the two-point packet loss implementation needs to maintain common state throughout the measurement period at both instrumented points, as this has been explicitly discussed in section 3.8.2. This is mainly because packet loss is a metric related to a particular series of packets rather than a self-contained per-packet characteristic, and it is
computed based on the presence and the sequence of a portion of network traffic, which is used to infer the absence (the actual loss phenomenon), the retransmission, and the out-of- order delivery of specific datagrams. Active measurement infrastructures that use software processes to perform two-point packet loss measurements based on injected traffic can know in advance the characteristics, the sequence and the number of the packets sent and received, and can hence implement the metric on their portion of the traffic. However, this is not possible for a measurement module that implements IP-based sequencing on existing network traffic and it hence needs to employ its own criteria which will enable a meaningful sequencing of somehow related IP datagrams.
The source OWL LKM maintains state using the notion of a flow (section 2.3.2) to create groups of packets that share common characteristics among some of their protocol fields, at their adjacent network and transport layer headers. Then, sequencing of packets processed by the module is not absolute but relative to the flow each packet is identified to belong to. Upon loading of the source LKM, a linked structure is initialised to hold a flow table for the entire duration of the measurement. Each element of this structure represents a flow entry which can be identified by the source and destination IPv6 address, the transport protocol, and the transport protocol’s source and destination port numbers of each observed packet. The flow element also contains two 32-bit integers, one to store the sequence number of the last packet seen to belong to the specific flow, and one to store the time this last packet was processed by the instrumented node. The granularity of the flow table can be made coarser, either at initialisation of the module or at runtime, by replacing any of 5-tuple’s elements with a wildcard filter144.
The OWL-specific operations performed by the source module upon receiving an IPv6 outgoing packet through the in-line measurement hooks include the insertion of the static values of the TLV, the identification of the packet’s flow, and ultimately, the computation and insertion of the IP-based packet’s sequence number to the TLV’s appropriate field. The packet headers’ fields that correspond to the flow identification tuple are compared against the entries of the module’s flow table. If an identical flow entry exists, and the time between the processing of the previous packet belonging to the same flow and this last packet does not exceed a certain threshold, then the sequence number stored for this flow entry is incremented by one and inserted to the packet’s OWL TLV; the timestamp of the specific flow entry is updated accordingly. Otherwise, if such a flow entry does not exist or if its timeout value has expired, then either a new flow entry is created or the sequence number of the existing entry is reset to one (1).
144 The module can be configured, for example, to mark packets coming from or addressed to specific
The OWL destination LKM running on a node receives incoming IPv6 datagrams and if these contain an OWL destination option, the module simply observes and stores the contents of the main IPv6 header, the OWL destination option and the transport layer header into its associated queue structure for post analysis, which will in turn compute any packet loss and/or packet re-ordering and retransmission phenomena. The option-bearing header is then removed from the packet structure if it solely contains the already processed OWL option.
The decision for the OWL destination module not to perform a real-time computation of the packet loss metric was taken primarily for two reasons. The first is to emphasise that an in- line measurement (destination) module can simply observe an appropriately-instrumented packet, and record its contents for further offline processing. And second, to avoid the additional overhead of re-determining the packet’s flow in real-time. This approach essentially moves the concern of communicating common state information with the source OWL module. Identical flow classification can be conducted by a higher-level measurement analysis application. At the same time, by keeping the modules’ operation minimal, a potential broader measurement framework could account for one-to-many relationships between source and
destination OWL modules. These can be operational scenarios under which multiple source LKMs instrument packets that are examined by a single destination LKM and vice versa. Measurement data populated by the destination modules can then be cumulatively processed to identify losses over an overall network topology. In this case, the OWL TLV might also need to be re-designed to include tags of the different nodes that instrumented and/or processed different packets. However, such operational enhancement of the measurement modules and their integration with network-wide measurement infrastructures are beyond the purposes of this two-point prototype implementation, and further details are outside the scope of this thesis.