Results

DORII applications have been examined with respect to their communication needs, and requirements in terms of communication parameters and performance indexes have been identifiec. These include:

• The type of traffic generated by each specific application (real-time interactive, video streaming, data, etc.)
• The statistical characteristics of the traffic (CBR, VBR, …) and (to some extent) its degree of burstiness
• The connectivity situation of the application with respect to access networks
• The connectivity offered by the corresponding NREN
• The bandwidth needs
• The QoS constraints, if any, that should be met (tolerable delay, delay jitter, packet loss, etc.)

According to the results of this analysis, DORII applications have been classified into two different groups:

1. Applications that process pre-collected data
   • Network Centric Seismic Simulation (NCSS)
   • Oceanographic and coastal observation and modelling Mediterranean Ocean Observing Network (FLOAT, GLIDER, OPATM-BFM)
   • Oceanographic and coastal observation and modelling using imaging (HORUS Bench – two cases: Application to test algorithms, Application running numerical models with information coming from the camera stations)
2. Applications working on data acquired in real time
   • Earthquake Early Warning System (EEWS)
   • Simulation and Monitoring system for Inland Waters and Reservoirs (SMIWR)
   • On-line Data Analysis in Experimental Science (three cases: SAXS, SYRMEP, SRD)
     

For each group, the following network requirements have been identified:

1. Applications that process pre-collected data
   • Multicast or point-to-multipoint LSPs (Label Switched Paths) are not necessary
   • Bandwidth requirements cover a wide range – from 1 to 100 Mb/s, but none needs very large data pipes (in the order of a few Gb/s)
   • All applications require low packet loss, but (with the exception of one) they can tolerate some delay and jitter;
   • The nature of the majority of traffic sources is VBR (Variable Bit Rate), i.e., the sources are bursty
2. Applications working on data acquired in real time
   • Multicast or point-to-multipoint LSPs are not necessary
   • Bandwidth requirements cover a wide range, but no large data pipes are needed
   • There are variable requirements in terms of packet loss (from very low to high) and jitter (from none to high) that may be tolerated
   • The nature of the traffic is bursty

For further details see DSA1.1

Guidelines

• Bandwidth reservation with book-ahead scheduling may be useful and should indeed be applied in some cases.
• High reliability is always required.
• It would be advisable to upgrade local access networks (LANs) to the Gigabit level and to introduce traffic priority mechanisms. Layer 2 VPNs and, in some cases, point-to-point guaranteed bandwidth connections should be implemented on the backbone.
• Bandwidth on Demand (BoD) and the adoption of IPv6 are not strictly necessary, but they would be worth experimenting for some applications.

To evaluate the impact of network performance on DORII applications, two complementary approaches have ben adopted:

1. The first one relies on the deployment of a passive measurement infrastructure and requires installing, enabling and configuring SNMP on all routers and grid resources (IEs, CEs, SEs). Traffic statistics are collected by a central management system and later analyzed. However, it is sometimes difficult to follow this approach because the configuration of all the routers and hosts involved in the network infrastructure to be monitored requires the cooperation of several counterparts and, moreover, data export may represent a network security hole.
2. The second one includes the deployment of active measurement tools for delay and bandwidth measurement at client side, the collection of traffic statistics and then the correlation of client-side measurements with network performance statistics collected at the network level.

This approach is depicted in the following figure.

The basic idea behind this approach is to infer the impact of the network on the performance of the applications by measuring several QoS (Quality of Service) network metrics and trying to correlate such metrics with QoE (Quality of Experience) metrics at application level. Basicallu, the following procedure may be followed for performance evaluation:

1. The user selects the IE from the VCR. A bandwidth estimation tool (BET) and a latency measurement tool can be used to measure the available bandwidth and the latency between the sites where the VCR and the IE are located.
2. The user selects a SE and performs data acquisition by using the IE and records the date, time and duration of the operation. A bandwidth estimation tool (BET) and a latency measurement tool can be used to measure the available bandwidth and the latency between the sites where the SE and the IE are located.
3. The user selects the CE. A bandwidth estimation tool (BET) and a latency measurement tool can be used to measure the available bandwidth and the latency between the sites where the SE and the CE are located.
4. The user transfers data to the CE and records the time and duration of the operation. The processing time is also measured.
5. The user selects the SE for the output data. A bandwidth estimation tool (BET) and a latency measurement tool can be used to measure the available bandwidth and the latency between the sites where the SE and the CE are located.
6. Data are transferred to the SE. The user records the date, time and duration of the operation

The performance evaluation procedure has been customized for each pilot application as described in DSA1.3

The network monitoring platform deployed for the DORII project (click here) consists of the following tools:

• Smokeping, for network latency measurement
• Pathload, for the estimation of the available bandwidth along a network path;
• SNMP-based Web applications, for monitoring network interface utilization.

Smokeping is a software tool that can be used to measure the network latency. More specifically, a Smokeping probe sends test packets out to the network and measures the amount of time they need to travel to a target host node and back. The RRDtool is used to maintain a long-term data-store with latency measurement, and the presentation of the data on the web is done by means of a CGI with some AJAX capabilities for interactive graph exploration. In the framework of the DORII project, Smokeping is used in master/slave mode: this way, Smokeping probes (slaves) are allowed to run remotely and to perform latency measurements from multiple locations to the target hosts. As shown in the figure, Smokeping has been deployed as follows:

• the Smokeping master is located at CNIT [20]; it maintains a configuration file with a specific section for each slave, and it stores and presents all monitoring data collected by the slaves.
• Remote probes (Smokeping slaves) have been installed at DORII partners’ sites EUCENTRE, ELETTRA, GRNET, CSIC-IFCA, OGS and PSNC. Based on settings contained in the configuration file retrieved from the master (e.g., measurement utility, target host address, measurement length and period, etc.), each slave performs latency measurements and sends back the results to the Master server by using the HTTP protocol. In the DORII network infrastructure, the following targets have been identified: Computing Elements (CEs), Storage Elements (SEs), Instrument Elements (IEs), remote sites’ Access Gateways (AGs).

Pathload is a monitoring tool that estimates the available bandwidth of a network path. The basic idea behind Pathload is that the one-way delays of a periodic packet stream show an increasing trend when the stream rate is larger than the available bandwidth. Pathload is based on a client-server architecture and consists of two main components:

• pathload_snd that listens on TCP port 55002 and acts as a traffic generator;
• pathload_rcv that starts a Pathload session and acts as a traffic receiver.

Pathload has been customized for the DORII project. In addition to the previous components, some scripts have been introduced to monitor the status of the sender and receiver processes and to automatically export the measurement data collected by the receiver to the management station located at CNIT via HTTP. The tool has been installed as follows:

• Pathload_sender: at each site where CEs and/or SEs of the DORII e- Infrastrcture are located (GRNET, PSNC, CSIC-IFCA);
• Pathload_receiver: at each site where IEs are deployed (EUCENTRE, OGS, ELETTRA, UC, etc.) and, therefore, DORII applications are running.

This way, the bandwidth available from the sites hosting CEs and SEs to the sites with applications (IEs and VCR) can be estimated.

Various applications exist to collect and consolidate network usage information. At a basic level, such applications (also called managers) use the Simple Network Management Protocol (SNMP) to read statistics from each monitored device (router or host) where an SNMP agent is configured and running. A standard Management Information Base (MIB) collects counters of the number of datagrams and bytes sent and received on each interface of a device, and it also gives the number of packets discarded because of congestion. An SNMP application can periodically poll each device and convert the returned information into a view of usage across the whole network. SNMP can also help identify network interface failures or outage conditions. In the framework of the DORII, SNMP is required to be enabled on IEs, CEs, SEs and routers. Data are collected by an SNMP manager and interfaced with a Web server by using ad-hoc CGI programs.

• EEWS for seismic applications ====
• OPATM-BFM for environmental applications
• SYRMEP for experimental science applications