Traffic Analysis and model synthesis of remote instrumentation - dorii

contract # 213110
Deliverable DSA1.5 (Update)
Traffic Analysis and model synthesis of remote instrumentation
Abstract
This report updates DSA1.5 with further experimental results.
workpackage SA1
lead editor CNIT
partners CNIT, GRNET, USTUTT
document classification public

Delivery Slip
Name Partner Date Signature
Document Log
# Date Summary of Changes Authors
1 20/07/2010 Table of Contents Davide Adami
2 27/07/2010 Section 4, Section 3 Davide Adami, Alexey Cheptsov, Giorgio
Bolzon, Kasia Bylec
3 30/07/2010 Section 5 Davide Adami, Matteo Lanati, Anastasios
Zafeiropolous
4 31/07/2010 Introduction, Conclusions,
revision
Franco Davoli
DSA1.5 PUBLIC 2

Table of Contents
1. INTRODUCTION...........................................................................................................................6
2. NETWORK INFRASTRUCTURE ...................................................................................................7
2.1. Best effort IPv4 ........................................................................................................................7
2.2. IPv6 Testbed.............................................................................................................................8
3. PERFORMANCE EVALUATION PROCEDURE .............................................................................9
4. PERFORMANCE MONITORING.................................................................................................10
4.1. EEWS .....................................................................................................................................10
4.1.1. TEST DESCRIPTION ..............................................................................................................10
4.1.2. EXPERIMENTAL RESULTS WITH A BEST EFFORT NETWORK.................................................11
4.2. OPATM-BFM ........................................................................................................................17
4.2.1. TEST DESCRIPTION ..............................................................................................................17
4.2.2. EXPERIMENTAL RESULTS ....................................................................................................18
5. IPV6 TESTBED DEPLOYMENT..................................................................................................22
5.1.1. IPV6 TESTBED EXTENSION..................................................................................................22
6. CONCLUSIONS ..........................................................................................................................25
7. LIST OF ACRONYMS .................................................................................................................26
REFERENCES....................................................................................................................................28
CONTACT INFORMATION ................................................................................................................29
DSA1.5 PUBLIC 3

Illustration Index
Figure 1 DORII Network Infrastructure .............................................................................................7
Figure 2 IPv6 Testbed.........................................................................................................................8
Figure 3 Performance evaluation procedure.......................................................................................9
Figure 4 Earthquake Early Warning System data storage and processing .......................................10
Figure 5 EEWS Test Scenario – Block Diagram and network monitoring ......................................11
Figure 6 Input/Output Rate at ie-01.eucentre.interface via SNMP monitoring ................................12
Figure 7 Latency from EUCENTRE to se01.kallisto.hellasgrid.gr ..................................................12
Figure 8 Latency from EUCENTRE to se01.ariagni.hellasgrid.gr...................................................12
Figure 9 Latency from EUCENTRE to se01.marie.hellasgrid.gr.....................................................13
Figure 10 Latency from EUCENTRE to se.reef.man.poznan.pl ......................................................13
Figure 11 Pathload output: available bandwidth estimated from GRNET to EUCENTRE .............13
Figure 12 Pathload output: available bandwidth estimated from PSNC to EUCENTRE.................14
Figure 13 Pathload output: available bandwidth estimated from PSNC to GRNET ........................14
Figure 14 Input and output rate (Byte/s) at se01.kallisto.hellasgrid.gr interface on July 6, 2010 ....16
Figure 15 OPATM-BFM -Test Scenario: Block Diagram and Network Monitoring.......................18
Figure 16 Latency between OGS and se01.kallisto.hellasgrid.it (week 24).....................................19
Figure 17 Latency between PSNC and se01.kallisto.hellasgrid.it (week 25) ...................................19
Figure 18 Input and output rate (Byte/s) at se01.kallisto.hellasgrid.gr interface on June 17, 2010..20
Figure 19 Pathload output: available bandwidth from PSNC to GRNET on June 23, 2010 ............20
Figure 20 Input and output rate (Byte/s) at se01.kallisto.hellasgrid.gr interface on June 23, 2010..21
Figure 21 Traffic Volume in Bit/s between Hellasgrid and OGS (week 25)....................................21
Figure 22 Traffic Volume in Bit/s between Hellasgrid and PSNC during week 25.........................21
Figure 23 Test bed Setup ..................................................................................................................23
Figure 24 IPv6 Traffic Monitoring ...................................................................................................24
Figure 25 IPv6 Traffic traces between the VCR and the IE .............................................................24
DSA1.5 PUBLIC 4

Executive Summary
The content of the present document is aimed at updating deliverable DSA1.5 “Traffic Analysis
and model synthesis of remote instrumentation” with the results of further experiments and
measurement campaign carried out during the last three months of the project.
With respect to the previous release of DSA1.5, some relevant results have been added, especially
as far as the IPv6 deployment is concerned. Besides the set-up of the IPv6 test bed between
EUCENTRE and GRNET, two fundamental components developed in DORII (VCR and IE) have
been ported to IPv6 and the Earthquake Early Warning System (EEWS) application from
EUCENTRE is now IPv6-enabled for all communications between the VCR and the IE. Therefore,
if the end-used is connected to a network offering IPv6 support, other than the traditional IPv4, he
can choose between IPv4 and IPv6 when connecting to that VCR, since IPV6 is fully supported as
for the tools (VCR) and middleware (IE) developed in DORII. Unfortunately, since gLite does not
fully support IPv6, communications with CE and SE are only possible via IPv4. The same
consideration applies for the certification procedure.
Finally, further tests have been carried out for EEWS and OPTAM-BFM applications.
DSA1.5 PUBLIC 5

1. Introduction
The deployment of DORII applications in their final form has allowed conducting more significant
tests and evaluations also from the point of view of the networking infrastructure. In particular, the
implementations of an IPv6-compliant VCR version and of an IPv6-compliant IE for the EEWS
application of EUCENTRE have made possible to conduct connectivity and functionality tests on
an IPv6 enabled network portion between EUCENTRE and HellasGrid sites at GRNET.
At the same time, further network performance measurements have been conducted under the IPv4
best effort service, still on EEWS and on OPATM-BFM.
The present document reports the results of these tests, and it is organized as follows. We describe
the updated networking infrastructure in Section 2, and briefly recall the performance evaluation
methodology in Section 3. New experimental evaluation results for the two previously mentioned
applications are reported and discussed in Section 4, whereas Section 5 highlights the IPv6 test bed
and measurements. Section 6 contains the conclusions.
DSA1.5 PUBLIC 6

Vacuum
slits
Monochromator
Beam stopper
Al filters
SS
Air Slits
SETUP
SYRM EP
Fast
Mammographic station
shutters
Ionization
chambers
BEAM
2. Network Infrastructure
Two different network scenarios are taken into account:
• IPv 4 best effort network infrastructure
• Best effort network infrastructure with IPv6 Support
A short description is provided in the following sub-sections.
2.1. Best effort IPv4
The basic DORII network infrastructure is reported in Figure 1 and has been extensively discussed
in [1], [2]. Since the network infrastructure is used as is, i.e., in an “Internet-like” fashion, only a
best effort packet delivery service is provided.
© YSI
© YSI
Figure 1 DORII Network Infrastructure
Figure 1 also highlights the location of the clients and servers deployed to monitor the available
bandwidth and the Round-Trip Time (RTT), by using Pathload and Smokeping, respectively.
DSA1.5 PUBLIC 7

2.2. IPv6 Testbed
Figure 2 shows the IPv6 test bed that has been setup in the DORII project.
LMU
USTUTT
DFN
PIONIER
(IPv4)
PSNC
UC
RedIRIS
GEANT
(IPv6 Transport Network)
GRNET
(IPv6)
CSIC
IPv4
Island
EUCENTRE
(IPv6)
OGS
GARR
(IPv6)
CNIT
ELETTRA
IPv4
Island
Native IPv6
Figure 2 IPv6 Testbed
Within the DORII network native IPv6 connectivity is provided from GRNET and PSNC through
the GRNET and PIONEER networks that are connected through the GÉANT2 network.
Furthermore, an IPv6 Test bed is set-up within EUCENTRE and a HellasGrid site in GRNET.
Native IPv6 connectivity has been enabled in the access network for EUCENTRE and
ariagni.hellasgrid.gr that is a HellasGrid site in Crete. In EUCENTRE, IPv6 is supported in the
EUCENTRE LAN, the hosting IE and the VCR, while in ariagni.hellasgrid.gr IPv6 is supported in
all the hosts of the Grid site. IPv6 connection between EUCENTRE and ariagni.hellasgrid.gr is
provided through the native IPv6 network of GRNET, GÉANT and GARR. The topology of the
connection is shown in Figure 2.
The EUCENTRE application is written in Java, and thus IPv6 is transparently supported for this
application. However, since the gLite middleware is only partially ported to IPv6 at this moment,
we were unable to execute tests with IPv6 to the HellasGrid sites. Thus, in order to make some
pilot tests with IPv6 support, by using the DORII developed middleware, a special IPv6 enabled
test bed is being created. In this test bed, an IPv6 enabled VCR is installed in GRNET in order to
be accessible via IPv6 from the IE in EUCENTRE.
More specifically, native IPv6 connectivity has been enabled between EUCENTRE and GRNET:
• EUCENTRE LAN, hosting the IE
• Italian NREN (GARR), GÉANT2
• Greek NREN (GRNET), hosting VCR (IPv6-enabled), SEs and CEs
DSA1.5 PUBLIC 8

3. Performance Evaluation Procedure
As discussed in [3], to evaluate how the behavior of DORII applications is affected by the network
performance, the evaluation procedure illustrated in Figure 3 has been defined.
The basic idea behind our approach is to infer the impact of the network on the performance of the
applications by measuring QoS metrics at the network layer and correlating them with metrics
observed at the application level.
Test
Definition
Test
Running
QoE
Evaluation
Statistics
Statistics
vs. QoE
Network Parameter
Configuration
Guidelines
Figure 3 Performance evaluation procedure
More specifically, while running each application under test, network statistics are collected:
indeed, the network monitoring platform provides delay and bandwidth measurements between
specific couples of DORII sites, whereas the IEs, CEs and SEs are monitored by means of SNMP.
At the application level, for each step, the end-user has to measure the performance metrics (e.g.,
the overall execution time) that have to be optimized to improve the QoE from the user’s
perspective.
DSA1.5 PUBLIC 9

4. Performance Monitoring
4.1. EEWS
The EEWS application aims at recording seismic data from sensors, possibly in real time, and at
processing them in order to extract time history for ground speed, ground acceleration and
displacements, the amplitude spectrum and the response spectrum. All the operations are performed
remotely and on the grid, employing the DORII infrastructure. The VCR plays the role of the user
interface: all the actions are performed and all the resources are accessed through this web portal.
Figure 4 Earthquake Early Warning System data storage and processing
The IE is located at EUCENTRE (Pavia, Italy) and it hosts the IM devoted to access the server
collecting data from sensors (by means of the Java client library). This node is in Genoa, Italy,
while the seismic sensors are spread over the Liguria Region. Measurements from each channel are
time-stamped and saved locally on the IE in a separate file, then moved to a SE. Finally, a CE
retrieves each file from the SE and performs the computation. This task is carried out on a single
binary, statically compiled and specified in the Input Sandbox. The user is asked only to select the
input folder on the right SE. The output is downloaded to the home folder on the VCR. An
alternative approach is represented by the Workflow Manager, a graphical and friendly interface to
specify the parameters.
4.1.1. Test Description
The test scenario is depicted in Figure 5. Several tests have been performed by selecting different
SEs and CEs.
DSA1.5 PUBLIC 10

•1: Input Data Transfer
•2: Data Retrieval
•3: Data Processing
•4: Output Data Transfer
SE
Seismic
Sensor Network
IE/IM
Ie-01.unicentre.it
1
(B, D)
(B, D)
2
4
EUCENTRE
(4)
SE
Network Metrics
B = Bandwidth
D = Delay
CE, SE, IE: SNMP-enabled interfaces
3
CE
Figure 5 EEWS Test Scenario – Block Diagram and network monitoring
4.1.2. Experimental Results with a best effort network
The sequence of operations illustrated in Figure 5 represents the starting point for the test bed setup.
Moreover, the performance of the network interconnecting the grid infrastructure is monitored
during the entire life cycle of the application execution. Figure 5 also shows the network
parameters monitored for each network path between couples of DORII grid resources. In the
experiments, we skipped the acquisition phase, since the server gathering seismic sensors data is
not part of the infrastructure, unlike the IE sending the query. Moreover, the required network
resources are very limited: as a matter of fact, a single station channel only needs few kbps.
The size of the file containing the initial data set for the computation is about 203 MB and
corresponds to measurement data coming from two channels and collected for a whole day. The
archive is stored on a server at EUCENTRE that acts as IE and VCR; then, it is transferred to
different SEs at GRNET and PSNC. The average throughput varies from 1.2 MB/s to 2.2 MB/s, the
data transfer time goes from a minimum of 96 s to a maximum of 173 s, whereas the latency is low
ranging from 30 ms to 55 ms (see Table 1 and Figure 7, Figure 8, Figure 9, Figure 10). The
achieved results highlight that, in this experiment, the transfer time to the SE at PSNC is always
less than the transfer times from EUCENTRE to different SEs located at GRNET.
SE
Upload
Start Time
Upload
Time [s]
Throughput
[Mb/s]
Average
Latency
[ms]
se01.kallisto.hellasgrid.gr Jul 06, 12:01: 2010 165 1.25 53
se01.ariagni.hellasgrid.gr Jul 06, 12:18: 2010 173 1.2 55
se01.marie.hellasgrid.gr Jul 06, 12:23: 2010 156 1.3 50
se01.reef.man.poznan.pl Jul 06, 12:27: 2010 96 2.2 30
Table 1 Upload time from ie-01.eucentre.it to each SE (File Size: 203 MB)
DSA1.5 PUBLIC 11

Figure 6 shows the input/output traffic rate measured by using SNMP-based monitoring tools at ie-
01.eucentre,it (daily graph, 5 minutes average). It is easy to identify the traffic generated by
moving the input file from the IE to the SEs (outbound direction). It is relevant to highlight that the
max peak rate measured by SNMP is 949.3 kB/s, owing to the fact that SNMP computes the
average over 5 minutes, whereas the file transfer length is always less than 5 minutes.
Figure 6 Input/Output Rate at ie-01.eucentre.interface via SNMP monitoring
Figure 7 Latency from EUCENTRE to se01.kallisto.hellasgrid.gr
Figure 8 Latency from EUCENTRE to se01.ariagni.hellasgrid.gr
DSA1.5 PUBLIC 12

Figure 9 Latency from EUCENTRE to se01.marie.hellasgrid.gr
Figure 10 Latency from EUCENTRE to se.reef.man.poznan.pl
Figure 11 Pathload output: available bandwidth estimated from GRNET to EUCENTRE
DSA1.5 PUBLIC 13

Figure 12 Pathload output: available bandwidth estimated from PSNC to EUCENTRE
The analysis of the data collected by the seismic sensor network is carried out by a parametric job,
where the parameters correspond to different settings for the two seismic stations being monitored,
so a single execution of the application produces two children nodes. The job is launched two
times, and the target CEs are located at different sites: GRNET (ce01.athena.hellasgrid.gr), PSNC
(ce.reef.man.poznan.pl) and IFCA-CSIC (egeece01.ifca.es).
Table 2 reports the time necessary to upload the file from a specific SE (se01.kallisto.hellasgrid.gr)
to each CE. As expected, the upload time is really low and the throughput is very high when we
choose a CE located in the same network as the SE, whereas we have the highest upload time when
the CE is located at IFCA-CSIC. It is relevant to highlight that although the available bandwidth
between PSNC and GRNET estimated by using Pathload is more than 100 Mb/s (see Figure 13) ,
when the selected CE is located at PSNC (ce.reef.man.poznan.pl) the throughput is less than 45
Mb/s.
CE
Job Upload Time Throughput
Submission Time [s]
[MB/s]
ce01.athena.hellasgrid.gr Jul 6 2010 12:45 6 35.8
ce01.athena.hellasgrid.gr Jul 6 2010 12:45 8 24.1
egeece01.ifca.es Jul 6 2010 12:46 99 2.1
egeece01.ifca.es Jul 6 2010 12:46 87 2.4
ce.reef.man.poznan.pl Jul 7 2010 16:57 36 5.5
ce.reef.man.poznan.pl Jul 7 2010 16:57 43 4.9
Table 2 EEWS Upload Time from se01.kallisto.hellasgrid.gr
Figure 13 Pathload output: available bandwidth estimated from PSNC to GRNET
DSA1.5 PUBLIC 14

Table 3 reports the processing time for each CE and the time necessary to download the output file
to the selected SE (in this experiment, se01.kallisto.hellasgrid.gr again).
Start
CE
Computation
Time
ce01.athena.hellasgrid.gr Jul 6 2010
12:45:49
ce01.athena.hellasgrid.gr Jul 6 2010
12:45:50
egeece01.ifca.es Jul 6 2010
12:48:29
egeece01.ifca.es Jul 6 2010
12:48:20
ce.reef.man.poznan.pl Jul 7 2010
Processing
Time [s]
Start Getting
Output
Download
Time [s]
Throughput
[MB/s]
87 s Jul 6 2010
12:47:16
3 83.0
7 s Jul 6 2010 8 17.9
12:45:57
62 s Jul 6 2010 22 9.8
12:49:41
4 s Jul 6 2010 36 5.9
12:48:24
62 Jul 7 2010 13 16.4
16:58:02
16:59:04
4 Jul 7 2010 19 11.4
16:58:13
Table 3 Processing Time and Output Data Download Time
ce.reef.man.poznan.pl Jul 7 2010
16:58:09
As clearly shown in the table, the processing time depends on the complexity of the job and on the
processing power of the CE. In all the experiments, the time required for the first job to be
processed (62 s -87 s) is greater than the time necessary for the second job (4 s - 7 s).
The output files are retrieved, by using the VCR at EUCENTRE, which allows to control the
movement of the files and to select the SE. Table 3 reports the time necessary to download the
output files temporarily stored by each CE to se01.kallisto.hellasgrid.gr.
Finally, Table 4 reports the overall time for the execution of the application. As clearly shown in the
table, the amount of time necessary for exchanging the data may significantly affect the
performance of the application and represents (except for the first and third case) the major
component of the overall execution time.
CE
Total Time Processing Communication
[s]
Time [s] Time [s]
ce01.athena.hellasgrid.gr 96 87 9
ce01.athena.hellasgrid.gr 23 7 16
ce.reef.man.poznan.pl 111 62 49
ce.reef.man.poznan.pl 66 4 62
egeece01.ifca.es 183 62 121
egeece01.ifca.es 127 4 123
Table 4 Total Time4
As previously highlighted, the network-monitoring platform allows collecting information about
the status of the network while the application is running.
Errore. L'origine riferimento non è stata trovata., Figure 14 and Errore. L'origine riferimento
non è stata trovata. show the input and output rate measured on July 6, 2010 at
se01.kallisto.hellasgrid.gr by using SNMP.
DSA1.5 PUBLIC 15

"Daily" Graph (5 Minute Average)
Figure 14 Input and output rate (Byte/s) at se01.kallisto.hellasgrid.gr interface on July 6, 2010
In summary, the upload and download time heavily affect the performance of the application and,
in most cases, they represent the main components of the overall execution time. High data transfer
time and low average throughput are achieved although the network is not congested, and this is
probably due to the systems (WfMS, CE, SE) load and the protocol architecture.
DSA1.5 PUBLIC 16

4.2. OPATM-BFM
4.2.1. Test Description
This application deals with the users belonging to the oceanographic modeling community: they
work with numerical models and with their data to get information about the past, the present or the
future state of the marine environment or to study a specific process over limited space or time
scales. The test consists of the following steps:
1. Registration: the user has to apply to INFN for a personal certification.
2. Login: the user opens the DORII VCR page hosted by OGS and asks for an account.
3. Credential Management: once the user has both a valid certificate and a valid VCR
account, the user can upload the public and the private key to the VCR in order to create a
valid proxy at each connection.
4. The workflow (from melisa.man.poznan.pl) may launch the simulation model with either
(a) the most recent data or (b) historical data already stored on a SE.
5. Logout
a) In this case, the workflow asks the user to select the SE and the path where input
data have to be uploaded from the IE (eva.ogs.trieste.it), the CE where simulations
have to be run and finally the SE and the path where output data have to be
downloaded. To optimize the performance of the application it is necessary to
minimize the overall execution time. Therefore, from the end-user’s perspective,
the following metrics have to be measured:
• Data set upload time from IE to SE
• Data set download time from SE to CE
• Run time at CE
• Data set upload time from CE to SE
b) In this case, the workflow asks the user to select the SE and the path where input
data are located, the CE where simulations have to be run and finally the SE and
the path where output data have to be downloaded. To optimize the performance of
the application it is necessary to minimize the overall execution time. Therefore,
from the end-user’s perspective, the following metrics have to be measured:
• Data set download time from SE to CE
• Run time at CE
• Data set upload time from CE to SE
DSA1.5 PUBLIC 17

•1: Input Data Transfer
•2: Data Retrieval
•3: Data Processing
•4: Output Data Transfer
CINECA
Repository
The logic diagram depicted in
GRNET
IE/IM
1
eva.ogs.trieste.it
(B, D)
SE
se01.kallisto.hellasgrid.gr
(B, D)
2
4
CINECA
OGS
(4)
Network Metrics
B = Bandwidth
D = Delay
CE, SE, IE: SNMP-enabled interfaces
PSNC
3
CE
ce.reef.man.poznan.pl
Figure 15 shows how data are transferred among the grid resources used by OPATM-BFM for
retrieving the input data, running the simulations and archiving the output data.
•1: Input Data Transfer
•2: Data Retrieval
•3: Data Processing
•4: Output Data Transfer
CINECA
Repository
IE/IM
eva.ogs.trieste.it
GRNET
1
(B, D)
SE
se01.kallisto.hellasgrid.gr
(B, D)
2
4
CINECA
OGS
(4)
Network Metrics
B = Bandwidth
D = Delay
CE, SE, IE: SNMP-enabled interfaces
PSNC
3
CE
ce.reef.man.poznan.pl
DSA1.5 PUBLIC 18

Figure 15 OPATM-BFM -Test Scenario: Block Diagram and Network Monitoring
4.2.2. Experimental Results
This sub-section reports the results of experimental tests carried out with the OPATM-BFM
application. The time necessary to perform each operation detailed in
•1: Input Data Transfer
•2: Data Retrieval
•3: Data Processing
•4: Output Data Transfer
CINECA
Repository
IE/IM
eva.ogs.trieste.it
GRNET
1
(B, D)
SE
se01.kallisto.hellasgrid.gr
(B, D)
2
4
CINECA
Network Metrics
B = Bandwidth
D = Delay
CE, SE, IE: SNMP-enabled interfaces
OGS
PSNC
3
(4)
CE
ce.reef.man.poznan.pl
Figure 15 has been measured at the application level.
In this test, input data are initially located at OGS (adamo.ogs.trieste.it) and are transferred to a SE
(se01.kallisto.hellasgrid.gr) located at GRNET.
a) from IE (eva.ogs.trieste.it) to SE (se01.kallisto.hellasgrid.gr). Input Data: 8 files, 8 GB
totally). The following table reports the data transfer time, whereas Figure 16 shows the
latency measured between OGS and se01.kallisto.hellasgrid.gr over one month. When the
data transfer was performed the latency was less than 100 ms, but highly varying
SE Start Upload Time Data Transfer Time
se01.kallisto.hellasgrid.gr Jun 17 2010 10:30 892 s (8.9 MB/s)
DSA1.5 PUBLIC 19

Figure 16 Latency between OGS and se01.kallisto.hellasgrid.it (week 24)
b) from SE (se01.kallisto.hellasgrid.gr) to CE (ce.reef.man.poznan.pl). Input Data: 1 File, 940 MB.
The following table reports the data transfer time, whereas Figure 17 shows the latency
measured between PSNC and se01.kallisto.hellasgrid.gr over one month. When the data
transfer was performed the latency was around 65 ms.
CE Start Upload Time Data Transfer Time
ce.reef.man.poznan.pl Jun 23 2010 10:30 159 s (5.9 MB/s)
Figure 17 Latency between PSNC and se01.kallisto.hellasgrid.it (week 25)
c) The following table reports CE Processing Time (ce.reef.man.poznan.pl).
CE Start Computation Time Run Time
ce.reef.man.poznan.pl Jun 23 2010 10:33 360 s
d) from CE (ce.reef.man.poznan.pl) to SE (se01.kallisto.hellasgrid.gr) Output Data: 1 File, 4.6 GB.
The following table reports the data transfer time,
DSA1.5 PUBLIC 20

SE Start Upload Time Data Transfer Time
se01.kallisto.hellasgrid.gr Jun 23 2010 10:40 1240 s (3.7 MB/s)
The total execution time was 1513 s. Since the computation time was 360 s), the main percentage
of the total execution time (76%) is due to the data transfer time and therefore it is necessary to
investigate how the network bandwidth is used by the application.
Figure 18 highlights the throughput measured at the interface of kallisto.hellasgrid.gr on June 17,
2010 (step a). As shown in the graph, the maximum inbound throughput was 9.69 MB/s.
Figure 18 Input and output rate (Byte/s) at se01.kallisto.hellasgrid.gr interface on June 17, 2010
Figure 19 shows the available bandwidth from PSNC to GRNET estimated by using pathload on
June 23, 2010 and highlights that the during the data transfers (step b and step d) the available
bandwidth is not completely used.
Figure 19 Pathload output: available bandwidth from PSNC to GRNET on June 23, 2010
Figure 20 illustrates the throughput, measured by using SNMP, at se01.kallisto.hellasgrid.gr
interface on June 23, 2010. Both data transfers (step b and d) are highlighted.
DSA1.5 PUBLIC 21

Figure 20 Input and output rate (Byte/s) at se01.kallisto.hellasgrid.gr interface on June 23, 2010
Finally, Figure 21 and Figure 22 shows the traffic volume measured between Hellasgrid and OGS
(week 25) as well as between Hellasgrid and PSNC (see Wednesday 23 June, 2010 when the
experimental test was performed.
Figure 21 Traffic Volume in Bit/s between Hellasgrid and OGS (week 25)
Figure 22 Traffic Volume in Bit/s between Hellasgrid and PSNC during week 25
DSA1.5 PUBLIC 22

5. IPv6 Testbed Deployment
5.1.1. IPv6 Testbed Extension
This section reports the results of some “pilot” tests that were carried out to demonstrate IPv6
support in the VCR and IE components. These tests involved EUCENTRE and GRNET and the
network infrastructure is shown in Figure 2. It is important to note that EUCENTRE’s EEWS
application is written in Java and thus IPv6 is transparently supported by this application. However,
since the gLite middleware is partially ported to IPv6 at the time of writing, we were unable to
execute tests with IPv6 on the HellasGrid sites. Thus, in order to make some pilot tests with IPv6
support, by using the DORII developed middleware, a special IPv6 enabled test bed was created
and an-hoc IPv6-enabled VCR installed.
The testing scenario includes the above mentioned components (VCR, IE), but EUCENTRE’s
EEWS application workflow was executed without the integration of the gLite security
components, which -at the time of executing the experiments- are not yet IPv6 enabled. It is
envisaged that when the gLite security components will support IPv6, the final integration with the
testing setup will be easy.
In the test bed, a virtual machine is set up at GRNET where the VCR for the EUCENTRE
application is hosted. The virtual machine is IPv6 enabled with the following network setup:
• Hostname: dorii-vcr-v6.admin.grnet.gr
• IPv4 address: 195.251.28.138
• IPv6 address: 2001:648:2320:7:250:56ff:fe9b:4806
On the EUCENTRE site the IE is set up in an IPv6 enabled machine and network, with the
following network setup:
• Hostname: ie-01.eucentre.it
• IPv4 address: 193.296.66.121
• IPv6 address: 2001:760:2000:2000::28
A traceroute command between these sites was launched to check IPv6 reachability, as shown in
the following:
[root@dorii-vcr-v6 ~]# traceroute 2001:760:2000:2000::28
traceroute to 2001:760:2000:2000::28 (2001:760:2000:2000::28), 30 hops max, 40 byte packets
1 2001:648:2320:7::2 (2001:648:2320:7::2) 0.932 ms 0.952 ms 0.986 ms
2 grnetrouter.grnet-admin.athens-3.access-link.grnet.gr (2001:648:2ffd:f057:1::1) 2.561 ms * *
3 eie2-to-ath3.backbone.grnet.gr (2001:648:2fff:1103::1) 92.446 ms 188.988 ms 188.954 ms
4 grnet.rt1.ath2.gr.geant2.net (2001:798:19:10aa::1) 163.544 ms 163.595 ms 163.693 ms
5 as0.rt1.vie.at.geant2.net (2001:798:cc:1001:1901::5) 171.833 ms 172.003 ms 172.042 ms
6 so-3-0-0.rt1.mil.it.geant2.net (2001:798:cc:1001:1e01::2) 184.599 ms 179.513 ms 176.494 ms
7 garr-gw.rt1.mil.it.geant2.net (2001:798:1e:10aa::2) 173.280 ms 173.424 ms 93.156 ms
8 rt1-mi1-rt-mi3.mi3.garr.net (2001:760:ffff:ffff::f7) 45.704 ms 45.758 ms 45.731 ms
9 rt-mi3-rc-pv.pv.garr.net (2001:760:ffff:ffff::e5) 46.521 ms 46.470 ms 46.601 ms
10 rc-pv-ru-unipv.pv.garr.net (2001:760:ffff:16c::41) 47.184 ms 47.211 ms 47.161 ms
DSA1.5 PUBLIC 23

11 2001:760:2000::8 (2001:760:2000::8) 47.167 ms 47.023 ms 46.995 ms
12 2001:760:2000:2000::28 (2001:760:2000:2000::28) 46.591 ms 46.575 ms 46.534 ms
Browser
Instrument element
(EUCENTRE)
2001:760:2000:2000::28
Virtual control room
(GRNET)
2001:648:2320:7:250:56FF:FE9B:4806
VCR
Ipv6 connection
Seismic
Network
Unversity of
Genoa through
GARR
Ipv4 connection
Figure 23 Test bed Setup
Figure 23 summarizes the basic components of the DORII middleware and how they interact in this
application. The web portal in the VCR acts as the user interface in order to perform all the
operations. The IE is the gateway to the instrument that in this case is a seismic sensors network.
The IE is in charge of the monitoring and local storage of seismograms, in case that a potential
seismic event is detected.
The user launches the following computation procedure: the files are moved to a SE in order to be
accessed from everywhere in the grid domain. The executable is passed to a CE, which then stores
the results back to the SE. The results are the input seismic data in binary format provided with the
P-wave onset time reference. Moreover, the details of the event and the P wave are shown to the
user through the VCR. It is clear that the workflow is made up of two different parts: interaction
with instrument and computation.
Furthermore, Figure 24 shows a snapshot concerning the monitoring of the IPv6 traffic between
EUCENTRE and GRNET during a testing period.
Finally, Figure 25 highlights a traffic trace between the VCR and the IE captured by using
TCPDUMP.
DSA1.5 PUBLIC 24

Figure 24 IPv6 Traffic Monitoring
Figure 25 IPv6 Traffic traces between the VCR and the IE
DSA1.5 PUBLIC 25

6. Conclusions
This document has updated the previous deliverable DSA1.5 with new results of experimental tests
concerning two of the deployed DORII applications (EEWS and OPATM-BFM). It has also
provided a description of the IPv6 test bed setup, and reported some data on the evaluation
conducted on it.
The results confirm that currently the network is not likely to be a bottleneck for the DORII
applications under examination, and that IPv6 connectivity can be enabled with relatively limited
effort, and extended globally upon completion of a full adaptation of gLite and security
components.
DSA1.5 PUBLIC 26

7. List of Acronyms
AAI
AN
API
ATM
BoD
CE
CERT
CTD
DAC
DS
DSCP
DVB
DVB-RCS
DWDM
EEWS
ER
ETSI
FTP
GDAC
GGF
GHPN
GMPLS
GS
GUI
IE
IETF
INGV
ISP
LAN
LBE
LSP
MAN
MC&A
MDM
MPLS
NCC
NCSS
NOAA
NREN
OGF
OGSA
PDH
PERT
Authorization and Authentication Infrastructure
Access Network
Application Programming Interface
Asynchronous Transfer Mode
Bandwidth on Demand
Computing Element
Computer Emergency Response Team
Conductivity, Temperature, and Depth
Data Assembly Centres
Differentiated Services
Differentiated Services Code Point
Digital Video Broadcasting
Digital Video Broadcasting with Return Channel Satellite
Dense Wavelength Division Multiplexing
Earthquake Early Warning System
Edge Router
European Telecommunications Standards Institute
File Transfer Protocol
Global Data Assembly Centre
Global Grid Forum
Grid High Performance Networking
Generalized-MPLS
Guaranteed Service
Graphical User Interface
Instrument Element
Internet Engineering Task Force
Istituto Nazionale Geofisica e Vulcanologia (Bologna, Italia)
Internet Service Provider
Local Area Network
Less than Best Effort
Label Switched Path
Metropolitan Area Network
Measurement, Control & Automation
Multi Domain Monitoring
Multiprotocol Label Switching
Network Control Centre
Network Centric Seismic Simulation
National Oceanic Atmospheric Agency
National Research Network
Open Grid Forum
Open Grid Service Architecture
Plesiochronous Digital Hierarchy
Performance Enhancement and Response Team
DSA1.5 PUBLIC 27

PHB
PIP
PoP
PTS
QoS
RFC
RIPE
RIS
RSVP-TE
SAXS
SE
SLA
SMIWR
SOA
SON
SYRMEP
TCP
UDP
VBR
VCR
VLAN
VO
VPN
WAN
Wi-Fi
WN
WOCE
WSN
XRD
Per-Hop Behaviour
Premium IP
Point of Presence
PERT Ticket System
Quality of Service
Request For Comments
Réseaux IP Europeens
Remote Instrumentation Service
Resource resSerVation Protocol with Tunnel Extensions
Small Angle X-ray Scattering
Storage Element
Service Level Agreement
Simulation and Monitoring System for Inland Waters and Reservoirs
Service Oriented Architecture
Service Oriented Network
SYnchrotron Radiation for Medical Physics
Transmission Control Protocol
User Datagram Protocol
Variable Bit Rate
Virtual Control Room
Virtual LAN
Virtual Organization
Virtual Private Network
Wide Area Network
Wireless Fidelity
Working Node
World Ocean circulation Experiment
Wireless Sensor Network
X-Ray Diffraction
DSA1.5 PUBLIC 28

References
[1] EU DORII Project - Deliverable DSA1.1, http://www.dorii.eu
[2] EU DORII Project - Deliverable DSA1.2, http://www.dorii.eu
[3] EU DORII Project - Deliverable DSA1.3, http://www.dorii.eu
[4] EU DORII Project - Deliverable DNA3.2 – http://www.dorii.eu
[5] EU DORII Project - Deliverable DSA1.5 – http://www.dorii.eu
[6] IETF RFC 2330, “Framework for IP Performance Metrics”, http://www.ietf.org/rfc/rfc2330.txt
[7] SmokePing Home Page, http://oss.oetiker.ch/smokeping/
[8] RRDTool, http://oss.oetiker.ch/rrdtool/
[9] Pathload Home Page, http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/bw-est/pathload.html
[10] IETF RFC 1157, “SNMP” http://www.ietf.org/rfc/rfc1157.txt
[11] Nagios Home Page, http://www.nagios.org
[12] NagiosGrapher, http://sourceforge.net/projects/nagiosgrapher/
[13] GARR, The Italian Academic & Research Network, http://www.garr.it/garr-b-home-engl.shtml
[14] RedIRIS, The national research and education network (NREN) for Spain, http://www.rediris.es/index.en.html
[15] PIONIER: Polish Optical Internet - Advanced Applications, Services and Technologies for Information Society,
http://www.pionier.gov.pl/project/program.htm
[16] DFN, The national research and education network (NREN) for Germany,
http://www.dfn.de/index.php?id=74989&L=2
[17] GRNET, The national research and education network (NREN) for Greece,
http://www.grnet.gr/default.asp?pid=1&la=2
[18] GÉANT2, The seventh generation of pan-European research and education network, http://www.geant2.net/
[19] IETF RFC 3493, “Basic Socket Interface Extensions for IPv6”, http://www.ietf.org/rfc/rfc3493.txt
[20] IETF RFC 3542, “Advanced Sockets API for IPv6”, http://www.ietf.org/rfc/rfc3542.txt
[21] IETF RFC 2732, “Format for Literal IPv6 Addresses in URL's”, http://www.ietf.org/rfc/rfc2732.txt
DSA1.5 PUBLIC 29

Contact Information
All authors affiliation:
Poznań Supercomputing and Networking Center
ul. Noskowskiego 10
61-704 Poznań, Poland
URL: http://www.dorii.eu/
Franco Davoli
Davide Adami
Anastasios Zafeiropoulos
Stefano Vignola
franco.davoli@cnit.it
davide.adami@cnit.it
tzafeir@admin.grnet.gr
stefano.vignola@cnit.it
DSA1.5 PUBLIC 30