NETWORK PERFORMANCE METRICS

As discussed above, network performance metrics can be classified into two areas, passive and active measurements. Please note that for immediate implementations, only active metrics are considered.

ACTIVE

RTT & jitter

The RTT is the time taken to traverse a path from one host to another and back again to the original host. Tools that measure RTT usually send ICMP Echo messages, that allows a packet of a user defined length to a remote node and have it echoed back. The time the echo request takes to come back is regarded as the RTT. Technically, RTT is regarded as the sum of the propagation times at each host plus the time occurred from delays from the hops associated with a particular path.

A measure of the variation of the RTT should be also be considered (and consequently the variation in the arrival times of successive samples of RTT, i.e. jitter or IPDV). This can be calculated with a sample of RTTs from a given pair of endpoints to give a better indication of the status of the internet.

As the state of the internet can not be known at any instance, the RTT can be influenced by router queuing, unreliable remote hosts or packet damage. Hence, frequent measurements (e.g. once every 15 minutes or less) would yield a good indication of the network performance quality.

Packet loss

Packet loss provides a good measure of the quality of the route between end points and is especially important for connection orientated protocols such as TCP/IP. As such, knowing how 'lossy' a particular path is would be valuable information in selecting a particular transfer path.

As packet loss can be attributed to many different factors (such as router queuing from network traffic or the lack of receiver-side acknowledgement) the amount of loss on a path can change quickly. Hence it is proposed that measurements be taken frequently (as frequently as RTT) without being too intrusive and that statistical measurements be made to record the minimum, maximum and average values for various sized packets. Information such as the deviation in loss percentages would also be valuable.

Aggregate network throughput (bandwidth)

The bandwidth is the total maximum throughput of data from one endpoint to another. This may measure the current utilization as a rate (volume/time) or as a proportion of the total bandwidth capability within the path across the network.

In order to supply these 'active' measurements of the throughput, we need to measure network capability with tools that throttle the network with as much data as possible and measuring the resulting bandwidth of data successfully transferred. As such, active measurements of bandwidth are resource intensive, and hence highly intrusive. It is therefore suggested that the frequency of this measurement should be kept low, perhaps performed only once or twice every day during off-peak times.

Number of hops

This metric is a measure of the number of hops required for a local host to reach a remote host. The information provided within this metric will highlight potential problems with, say, an increase in RTT, which could be due to differing routing tables implemented by routers along the path.

As it is often rare that routing tables change, the measurement of the number of hops should be infrequent - perhaps once a day. It is worth noting that programs such as traceroute, which supplies information about the total number of hops can also supply information about the RTT. This metric would become important with the implementation of Quality of Service and DiffServ/MPLS routing.

PASSIVE

Per flow application throughput with GridFTP

GridFTP [GridFTP] is an extension of the standard FTP mechanism for use in a Grid environment. It is envisaged that it will be used as a standard protocol for data transfer. Per flow application throughput defines the throughput measured for a specific GridFTP transfer between specified end-points. It will be based on a 'passive' measurement of the data transferred - i.e. only the information transferred - not additional (test) data.

The passive measurement of GridFTP transfers means that information collected from a GridFTP transfer should be stored locally on the sending machine and then be polled by the GRIS server for storage into the LDAP DIT.

The data that shall be stored regarding a GridFTP transfer is as follows,
· Source
· Destination
· Total Bytes / Filesize
· Number of Streams Used
· TCP buffer size
· Aggregate Bandwidth
· Transfer Rate (Mbytes/sec)
· Time Transfer Started
· Time Transfer Ended
· Total Time

A schema proposed by Sudharshan Vazhkudai [RepSel] utilizes a patched version of GridFTP in which transfers are recorded and summary data stored; this is incorporated into our scheme.

Future incarnations of GridFTP propose to incorporate features such as automatic negotiation of TCP buffer/window sizes and parallel data transfer, and reliable data transfer. These should make some of the object class and associated attributes subject to modification.

Grid volume

To supply a measurement of the volume of data transferred on the grid as a function of time (daily/weekly/monthly/yearly), we propose that information from data transfer across the grid be aggregated as transfers proceed. Should GridFTP be used for data transfer, then the various variables shall be obtained from GridFTP measurements and simply added. Otherwise the software used for transfers should account for this. This may or may not include data transferred from active (test) data.

The results from such measurements shall be stored on the sending site as the receiver is assured by acknowledgements and shall be updated as frequently as GridFTP transfers (and or active measurements) are opened.

Fri, 17 August, 2001 4:18