• No results found

The Active Measurement Project (AMP) and the Internet Performance Measurement

2.2 Active Measurements and Performance Metrics

2.2.5 The Active Measurement Project (AMP) and the Internet Performance Measurement

The Active Measurement Project (AMP) was initiated at the National Laboratory for Applied Network Research (NLANR) in 1998 with a focus at conducting site-to-site active measurements and analyses between campuses connected by high performance networks. Currently, there are approximately 150 AMP monitors deployed across High Performance Connection (HPC) sites in the U.S. and internationally15. Across all participating sites, Round- Trip Time (RTT), packet loss, topology, and user and event-driven throughput are measured. Each of the AMP monitors sends a single, 64-byte ICMP packet to each of the others every minute, and records the time until a reply is received, or a loss if no reply is received. Additionally, the route to each other monitor is recorded using traceroute, every 10 minutes. Throughput tests can be run between any pair of the monitors using a web-based throughput test request, able to measure bulk TCP and UDP data transfer, and treno

throughput [McBr01]. Due to their high cost in terms of network traffic, throughput tests are only run on-demand and are not scheduled by default.

AMP monitors conduct measurements independently and the collected data is sent to a central site for processing and web-publication. Due to the continuous nature of the measurements and the lack of an end-time at which to send data for central processing, AMP designers developed an active mirror system to update the published results within minutes, and give a near-real-time nature to the overall infrastructure [McBB00].

More recently, AMP started collecting IPv6 performance information between a mesh of twelve active monitors with an aim to assess the infrastructure improvements to the IPv6 component of HPC networks, relative to the performance seen by IPv4 paths. It has been observed that a general characteristic of IPv6 paths is that they experience a larger delay, delay variation, and packet loss compared to IPv4 paths, a characteristic that is mainly attributed to IPv6 tunnelled paths following a less-than optimal physical path. However, continuous improvements are seen to IPv6 paths as IPv6-in-IPv4 tunnels are replaced with native IPv6 paths and the IPv6 forwarding capability of routers in the path is improved16. At the early days of the project, a variety of active measurements techniques were deployed, using ICMP as well as TCP and UDP-based measurement processes to measure a variety of performance characteristics over the AMP infrastructure. This attribute gave some uniqueness to AMP, in relation to other active measurements infrastructures that either focused on Round-trip (ICMP-based) or on one-way (UDP/TCP-based) performance measurements. What made AMP an even more unique project over the years though was the decision to specify a new measurement protocol to be used as an alternative to ICMP across the AMP infrastructure. The IP Measurement Protocol (IPMP) has been proposed as a customised active measurement protocol to contain facilities to carry timestamps and path information, with a view of being potentially implemented in the forwarding path of routers [McBr00]. The protocol is based on an echo request and reply packet exchange for measuring packet delay and associated path metrics, and is very similar to the technique ping uses with the ICMP echo capabilities. IPMP is carried directly inside of an IP datagram in order to make an echo packet obvious to the routers along a measurement path [LuMB01]. Similarly to the ICMP echo request and reply messages, the IPMP echo reply message has been designed so that an echo host constructs it with minimal modifications to the echo request packet. Figure 2-6 shows the IPMP echo packet format.

Figure 2-6: The IPMP Echo Packet

The packet format provides some sophisticated processing capabilities including the selection of certain processing queues in routers that implement priority queuing. Through the Protocol Queue field the packet identifies how it should be prioritised, e.g. by setting it to IPROTO_TCP the echo packet requests to be prioritised as a TCP packet. Whether a packet is an echo request or an echo response is identified by the Type field. The allocation of the filler,

type, returned TTL, and return type bytes allows the echo request packet to be transformed into an echo response by swapping the two 16-bit words in place17, without requiring checksum re-calculation. The Path Pointer field specifies where in the packet the next Path Record should be inserted, providing direct access. The Source and Destination Port Queue

fields can be used to queue or filter the packet according to a more synthetic tuple than the simple Protocol Queue field [LuMc02].

When network nodes that support IPMP send, forward, or receive an echo packet, they insert their forwarding address and a 64-bit departure or arrival timestamp, in the form of a Path Record (Figure 2-7).

Figure 2-7: Path Record Format

A host can perform an echo measurement by creating an echo request packet, addressing it to the target host, and sending it onto the network. IPMP-capable routers along the path can

17 The Returned TTL is set to zero in the echo request packet. If it is updated by the target host, the

insert their path records signifying the time the packet arrived on their interface. Non-IPMP- capable routers simply forward the packet. Upon arrival at the target echo host, another path record is inserted, and the packet is transformed into an echo reply message and routed back to the originating host.

Using this procedure, IPMP can measure end-to-end and intermediate one-way delay in both the forward and reverse directions, and also deduce path length in hops in each direction. Increasing the size of the packet by the size of a path record is an issue, but since IPMP does not carry additional payload data, even the 576 bytes minimum MTU supported by IPv4 allows for 45 path records to be stored in an echo packet.

IPMP seeks the cooperation of the routers along an instrumented path and it maintains a format that can potentially be processed in an efficient manner at routers’ line cards. If it is only supported by instrumented end-systems it can provide similar capabilities to the ICMP

timestamp request and reply messages. Additional IPMP message types provide a mechanism for time synchronisation information to be collected from hosts and routers, in order to estimate the accuracy of their individual clocks [LuMB01]. IPMP is now in its fourth version as a work-in-progress document within the IETF, and might soon be proposed for a standard18.

It is the intention of AMP researchers to gradually replace the ICMP delay and loss measurements that are currently collected with IPMP and further exploit the protocol’s capabilities. Experiments have been conducted to compare the differences in round-trip delay and loss measurements between the ICMP and the IPMP echo protocols within the AMP infrastructure. Preliminary results revealed that the majority of measured paths showed no bias, yet 8% of the paths returned smaller and 10% of the paths larger average delays when measured with IPMP echo packets. However, the differences between the average delays were more significant when IPMP echo packets reported smaller values than ICMP, leaving only a 0.006% of paths to show at least a 10 millisecond larger average delay with IPMP than with ICMP echo packets. Packet loss indications were very similar between the two protocols, not revealing that anyone was more or less likely to lose packets than the other [LuMc02].

Outline

Related documents