Deliverable D1.0 Survey of state of the art

Sixth Framework STREP 045256 Deliverable 1.0 Commercial in Confidence

Version 4.0 Page 1 of 75 © Copyright 2007, the Members of the EC-GIN Consortium

Europe-China Grid Internetworking European Sixth Framework STREP FP6-2006-IST-045256

Deliverable D1.0 Survey of state of the art

The EC-Gin Consortium

Universität Innsbruck, UIBK, Austria

University of Zürich, UniZH, Switzerland

Institut National de Recherche en Informatique et Automatique, INRIA, France

Lancaster University, ULANC, U.K.

Justinmind, JIM, Spain

EXIS IT ltd, Greece

University of Surrey, UniS, U.K.

Beijing University of Posts and Telecommunications, BUPT, China

Institute of Software, Chinese Academy of Sciences, ISCAS, China

China Telecommunication Technology Labs, CTTL, China

China Mobile Group Design Institute Co., Ltd, CMDI, China

© Copyright 2007 the Members of the EC-GIN Consortium For more information on this document or the EC-GIN Project, please contact: Dr. Michael Welzl

Leopold-Franzens-University of Innsbruck

Institute of Computer Science

Technikerstr. 21a

A—6020 Innsbruck

Austria

Phone: +43 (512) 507-6110

Fax: +43 (512) 507-2758

E-mail: [email protected]



Document Control Title: Survey of state of the art Type: Public Editor(s): Werner Heiß, Michael Welzl E-mail(s): [email protected], [email protected] Author(s): Thomas Bocek, Dragana Damjanovic, Yehia El khatib, Linghang Fan,

Hasan, David Hausheer, Tao Liu, Cristian Morariu, Marcelo Pasin, Pascale Primet, Peter Racz, Gregor Schaffrath, Burkhard Stiller, Jin Wu, Chen Zhang, Lin Zhang, Shaohua Liu, Xiaolei Ma, Li Li, Chongwu Chen, Kun Wang, Wei Li

Doc ID: D1.0-v4.0.doc Delivery Date: 31. 5. 2007

Legal Notices The information in this document is subject to change without notice. The Members of the EC-GIN Consortium make no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of the EC-GIN Consortium shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.



Table of Contents1 Executive Summary 6

2 Introduction 7

2.1 Document Outline 8

3 A net-centric survey of Grid applications 9

3.1 Introduction 9 3.2 Survey Overview 9

3.2.1 Aim of the Survey 9 3.2.2 Initial Idea and Draft History 9 3.2.3 Contents of the Questionnaire 10 3.2.4 Target Audience 11 3.2.5 Dissemination & Collection 12

3.3 Results of the Survey 12 3.3.1 Research Field 12 3.3.2 Scale 13 3.3.3 Composition 13 3.3.4 Data Granularity 13 3.3.5 Data Timeliness 14 3.3.6 Encryption 15 3.3.7 Accounting 15 3.3.8 Data Replication 15 3.3.9 Data Path 15 3.3.10 Network Transport Protocol 16 3.3.11 Middleware 16 3.3.12 Special Network Services 16

3.4 Possible Improvements 17 3.5 Conclusion 17

4 Use Cases 19

4.1 OGF Use Cases 19 4.1.1 Path-oriented Use Case 19 4.1.2 Knowledge-based Use Cases 23

4.2 EC-GIN Use Cases 24 4.2.1 Data Access Service 25 4.2.2 Large File Transfer 27 4.2.3 P2P Video-over-IP 29 4.2.4 Botnet Detection 30 4.2.5 Mobile IPTV 31 4.2.6 Mobile Grid 37

5 Requirements 42

5.1 Requirements derived from the Questionnaire 42 5.2 Requirements derived from Use Cases 43

5.2.1 OGF Use Cases 43 5.2.2 EC-GIN Use Cases, part 1: OGF-like requirements 44 5.2.3 EC-GIN Use Cases, part 2: Grid Economics 45 5.2.4 EC-GIN Use Cases, part 3: Mobile Services 49

5.3 Application Awareness Support 51 5.3.1 The Requirements of Application Awareness 52 5.3.2 Main Principles 53 5.3.3 Trade-off Analysis in Existing Transparent Network Enhancements 53

5.4 Peer Awareness Support 58 5.4.1 Resource Management Techniques in P2P File Sharing Tools 59 5.4.2 Grid Resource Management Based on P2P Technology 62

6 Conclusion 65

7 References 67



8 Abbreviations 70

9 Acknowledgments 72

10 Appendices 73

10.1 Questionnaire for the Network Requirements of Grid Applications 73



(This page is left blank intentionally.)



1 Executive Summary The aim of this document is to provide a consolidated set of requirements that the GINTONIC architecture needs to take into account. These requirements are derived from a look at the state of the art, addressing the application's point of view — identifying the network peculiarities and needs of Grid applications — as well as the user's point of view. The network requirements of Grid applications are identified by looking at them in two ways: firstly, a survey in which Grid application programmers and users were asked about network-related details of their applications is presented and analyzed. Secondly, use cases of relevance to EC-GIN are examined. In addition to network performance, aspects such as Grid Economics and mobility are identified as a result of this investigation. The technological requirements of the GINTONIC architecture fall in the categories of "application awareness", where the right trade-off between transparently supporting applications and explicitly communicating with them must be found, and "peer awareness", where key functionality for locating potential helpers in the network must be included. These two aspects are addressed by means of a brief overview of related work.



2 Introduction The intention of EC-GIN Work Package 1 is to design the architecture of GINTONIC. The first step towards this goal, a requirements analysis based upon the state of the art, is taken with this document. The state of the art under consideration must encompass a large variety of Grid applications with their usage scenarios as well as technical work that is related to the foundation of the GINTONIC architecture; it should not be confused with related work on Grid-specific network mechanisms, which is the focus of Deliverable 3.0. Since the goal of the state of the art overview presented in this document is to derive requirements for the architecture, it consists of three distinct elements:

1. Network requirements of Grid applications, consisting of a. requirements which are already known b. requirements which still must be derived

2. Requirements of Grid Economics

3. Technical requirements that the GINTONIC architecture must address in order for

the mechanisms that will be embedded in it to carry out their envisioned tasks in an efficient and correct manner

For addressing 1 a) above, it was decided to carry out a survey of the network behavior and requirements of Grid applications. This survey was done by developing a questionnaire which was then given to Grid application users and programmers, both as a physical document (at the 20th OGF meeting in Manchester, UK) and via email, using an on-line version of the questionnaire. Use cases are another, extremely useful way to derive application requirements; thus, it was decided to address 1 b) above with a documentation of use cases. A number of relevant use cases have already been identified by the Grid High-Performance Networking Research Group (GHPN-RG) of the Open Grid Forum (OGF); thus, we begin our overview with an abridgment of the related OGF document ([Fer05]). This is complemented with several additional use cases that were identified by the EC-GIN consortium. For element 3) above, two key issues have been identified for the architecture underlying GINTONIC:

1) Application Awareness, which refers to the trade-off between transparent (i.e. unknown to the application) operation of a network enhancement within the stack on the one hand, and explicit communication between the application and the network stack on the other

2) Peer Awareness, which refers to the necessity of knowing about the existence and

location of other nodes such that they can aid in the provisioning of network enhancements for the sake of Grid applications



Regarding these two issues, a large set of frameworks and protocols have been developed in the past which partially meet some of the requirements and key functionality that EC-GIN needs to address. A re-use and extension of such components and mechanisms is essential; hence, a brief overview of such related work is included in the requirements analysis that is presented in this document.

2.1 Document Outline The survey of the network behavior and requirements of Grid applications is documented in chapter 3; the questionnaire that was used is included in the appendix. In chapter 4, use cases of Grid applications are described, highlighting the way these applications use the network. This chapter is split in two halves – an abridgment of the OGF document on use cases, and specific use cases that were identified in the EC-GIN project. Chapter 5 describes EC-GIN requirements on the basis of:

• The survey in chapter 3 • The use cases in chapter 4 • Related work where application awareness is an issue • Related work where peer awareness is an issue

Chapter 6 concludes with a brief summary of key lessons learned towards the fulfillment of the goals of EC-GIN.



3 A net-centric survey of Grid applications 3.1 Introduction Work-package 1 is concerned with the architectural design of the GINTONIC API, a comprehensive implementation of the EC-GIN mechanisms. GINTONIC will provide new programming abstractions that will improve the performance of network communication across the Grid. For this design, understanding the requirements of the applications is crucial. It might be easy enough to predict these requirements according to our perception of Grid applications. However, a close look at some applications that are in operation would yield a more realistic set of requirements. For this reason, we have conducted a survey of Grid applications. We have looked into the scale and characteristics of their Grids, their middleware environments, their traffic footprints, and most importantly their network requirements. The following section provides more information about the survey and the process of conducting it. Results from the survey are revealed in section 3.3. We discuss a few possible improvements that might be useful for future surveys in section 3.4, and conclude our analysis in section 3.5.

3.2 Survey Overview The survey was conducted by circulating a 2-page questionnaire amidst projects employing or developing Grid applications for scientific research. An electronic version of the questionnaire was also made available on the Internet. A set of 30 individual results was collected and analyzed. This section discusses the process of the survey and the contents of the questionnaire.

3.2.1 Aim of the Survey The aim of the survey is to draw a clearer picture of what the requirements are, based on the specifications of deployed Grid applications. The results give a recommendation of the services that need to be included in the API design. The results also describe some aspects of the applications such as scale, middleware, etc. The survey, however, is not intended to give a statistical analysis of the different aspects and characteristics of Grid applications.

3.2.2 Initial Idea and Draft History The idea and backbone of the questionnaire emerged from discussions within the consortium about our expectations with respect to the network requirements of Grid applications. A first draft was put together and presented to the EC-GIN partners. Several other versions of the questionnaire were developed based on the feedback received from our partners. After obtaining a fairly developed version of the questionnaire, an interview was held with a Grid application developer. The importance of this interview was two-fold; it produced the first result sample of the survey and, at the same time, it served to gauge the ease of filling



out the questionnaire by Grid application developers/administrators. The interview was very important for us to make the questionnaire self-explanatory and inviting to fill out. The final version of the questionnaire was reached by March 16th 2007. It can be found in Section 10.1.

3.2.3 Contents of the Questionnaire Considering that the questionnaire was not created for the purpose of conducting a thorough investigation of Grid application details, it was kept as simple as possible. The questionnaire is made up of two pages plus a front-page, and it consists of a collection of short multiple-choice questions as well as a final open-ended question. However, it is noteworthy that even the multiple-choice questions in the survey leave room for the participants to write further comments, considerations and/or supporting statements. The participants were asked to answer the questions to the best of their knowledge, using approximations for any numerical values. We also asked the participants to provide some background information (such as whether they are developers, administrators, or users of Grid applications). The questionnaire was divided into the following twelve sections:

• Description of the Grid application: In this section, the participants are asked to give a brief overview of the purpose of the application.

• Scale: This section enquires about the scale of the Grid used, in terms of the number of nodes and administration domains.

• Composition: The participants are asked about the device diversity in their Grid. This aims at getting a feel for the type and level of heterogeneity of the computational resources available in the Grid.

• Data granularity: It is often said that Grid computing requires the efficient transfer of large bulks of data across networks. However, in order to reach efficient communication, we need to know more about such “bulks of data” and about the traffic in general. This is where the importance of this section arises. Here, the participants are asked to provide approximations of the amount and pattern of the traffic.

• Data timeliness: Similar to the previous section, this section intends to find out more about the characteristics of the traffic. In this case, the quest is to learn about any delay-intolerant traffic and the reason behind such delay-sensitivity.

• Encryption: This section asks about the amount of the traffic which is encrypted, and about the provision of encryption services.

• Accounting: In this section, we ask the participants about the metrics their applications consider for accounting.

• Data replication: This section addresses the topic of replica management, which Grids utilize in order to optimize reliability, response latency, etc. We will use the results from this section to deduce whether or not GINTONIC is required (or rather expected) to facilitate such functionality.



• Data path: Here we enquire about any one-to-many communication services used by the application. Again, this is a service that we might want GINTONIC to provide.

• Network transport protocol: The intention of adding this section is to learn about the importance of connection-oriented communication as opposed to connectionless communication.

• Middleware: Here we ask about the middleware solutions employed.

• Special network services: This section enquires about more network services that might be supported by GINTONIC. Examples given in the questionnaire include Transfer Delay Prediction, Network Topology Information, etc. Participants were asked to add other services that are important to their application.

3.2.4 Target Audience The questionnaire was sent out to a number of projects which employ or are in the process of developing a Grid application. Due to the technical nature of some of the questions, we intentionally targeted people who have adequate experience with Grid applications. This includes the developers, administrators, and advanced users who have used the system enough to know about its behavior and requirements.

Project Application Name Austrian Grid WIEN2K Automatika Automatika Bridge Bridge ChinaGrid Course Online CNGrid PSDM (PreStack Depth Migration) Crown CROWN Dzero SAMGrid

EC-GIN GridFTP Mobile IPTV PPLive

EGEE EGEE WIEN2K

Epidaure Bronze Standards EXIS EXIS Bill Printing EuroGrid EuroGrid GeSRM GROWL GRASIL GRASIL GREDIA Mobile.News InGrid InGrid Invmod/Wasim Invmod LHC ATLAS Montage Montage MyTies.to MyTies.to POV-RAY POV-RAY QCDGrid DiGS (QCDGrid) TAG ray2mesh White Rose Grid DAME (Distributed Aircraft Maintenance Environment) -- DMSS (Distributed Media Service System) -- MeteoAG



-- Parallel FDTD (Finite-Difference Time-Domain Calculations)

Table 3-1: A List of the Surveyed Grid Applications and their Projects

3.2.5 Dissemination & Collection Once the final version was ready, the questionnaire was disseminated in Grid-related events (such as OGF20) and circulated via email to relevant mailing lists and to various projects where people work with Grid applications. The use of an interactive Web-based questionnaire made filling the questionnaire a more user-friendly experience and consequently more appealing to the participants. Not surprisingly, we received more responses using the online questionnaire than using hard copy. In a couple of cases, participants were asked for a short interview to get more details or to clarify their responses. Out of tens of projects that were approached, sixteen results were collected by April 15th 2007. Analysis of the results followed and the outcome was presented in the first version of this document submitted on July 4th 2007. Since then, fourteen more results were collected through the Web-based questionnaire. The last result was received on June 25th 2008. We added the new results to the previous ones and reanalyzed the whole set. Table 3-1 lists the names of the surveyed Grid applications and their corresponding projects (if any).

3.3 Results of the Survey In this section, we present the set of results compiled from every section of the questionnaire, as well as a brief commentary.

3.3.1 Research Field 23% of the applications we surveyed are used for Engineering; 10% are used for each of Mathematical Analysis, Meteorology, Particle Physics, and Visualization; 7% for each of Content Distribution, Medicine & Pharmaceuticals, and Social Sciences; and 3% for each of Education, Environmental Sciences and Software Development. Figure 3-1 illustrates this distribution.



Figure 3-1: Pie-chart illustrating the research fields of the surveyed applications

3.3.2 Scale 14% of the surveyed applications are deployed over Grids made up of 10 nodes or less, 57% over 100-400 nodes, and 29% over more than 1000 nodes. Almost all of these Grids span across 1-20 administrative domains. The single exception was a Grid that has nodes in more than 1000 different domains.

3.3.3 Composition Half of the surveyed applications are deployed solely on dedicated super-nodes and/or clusters. Only a single application is deployed on a Grid network free of dedicated super-nodes, consisting only of desktop computers. In the remaining Grids, the devices are divided as follows: 47% dedicated super-nodes, 44% desktop machines, and 9% mobile devices. It is worth noting that only one application uses small devices (such as embedded processors) and they hardly constitute 1% of the total number of devices in that Grid. Further inspection revealed some interesting relationships between certain application types and the composition of their Grids. All the surveyed image analysis applications, for instance, are deployed on Grids composed solely of super-computers; all surveyed simulation applications are deployed on almost 100% super-computers; and all surveyed data management applications are deployed over Grids where there is far more low performance, loosely-coupled computers than powerful, tightly-coupled super-computers.

3.3.4 Data Granularity Based on the (approximate) values given by the participants, the survey revealed that the three most common dataset sizes are around 10 MB. Figure 3-2 depicts the logistic distribution of dataset sizes, while Figure 3-3 illustrates the corresponding sigmoid curve. A closer look at the numbers shows that almost 10% of the datasets of all applications are in bulks smaller than 100 kB in size, 55% are in bulks of 1-100 MB, and 17% are in bulks of 10 GB or more. Although only to a limited extent, these numbers show how different



Grid traffic is when compared to generic IP traffic (such as Web traffic). It also illustrates how mixed the dataset sizes are.

Figure 3-2: The probability density function of dataset sizes

Figure 3-3: The cumulative distribution function of dataset sizes

3.3.5 Data Timeliness Time-critical applications need to enforce deadlines on the delivery of their packets. Packets that arrive later than the deadlines are considered of no use and are discarded. Embarrassingly parallel applications, on the other hand, do not typically impose such deadlines.



One of the applications we surveyed, for example, is being used for forecasting Alpine watersheds and thunderstorms based on parameter measurements from data collection points deployed in the field. Data that arrives late has to be discarded in order to process the data that is due. Besides this application, five other applications impose similar deadlines on the delivery of non-multimedia-stream data packets. These applications rely on the prompt return of results from service invocations. Even asynchronous services are subject to delivery deadlines. Interestingly enough, the time-sensitive part of the data in these six applications is mainly the part that is transferred as large bulks. Three other applications enforce deadlines on the transfer of multimedia traffic. The rest of the surveyed applications did not report any implemented deadline schemes.

3.3.6 Encryption Although security is a major concern in Grids, only 40% of the applications encrypt their data prior to sending it over the network. Of these applications, 50% rely entirely on the middleware to provide the encryption while 33% rely entirely on the network transport layer to encrypt the data. The remaining 17% used both the middleware and the transport layer to carry out the encryption. It was also observed that all surveyed Particle Physics applications utilized the middleware to encrypt 100% of their data, while all surveyed Social Sciences applications utilized the network transport layer to encrypt 100% of their data.

3.3.7 Accounting When asked about the metrics considered important for accounting measures, 73% of the participants chose CPU processing power, 50% chose available network bandwidth and 43% marked disk storage space. Some participants mentioned more specific accounting factors such as service invocations, number of employed CPUs, code generation number, and software licenses.

3.3.8 Data Replication 30% of all surveyed applications replicate at least a portion of the data they push into the network. On average, these applications replicate 73% of their traffic. It was noticed that all surveyed Particle Physics applications replicate all their data.

3.3.9 Data Path Overall, 66% of all traffic has more than one recipient. This portion of the traffic is created by only 27% of the surveyed applications, while the remaining 73% of the surveyed applications never use one-to-many communication schemes. All the applications that do send traffic to more than one destination employ multicast one way or another. Two thirds of these applications integrate a multicasting mechanism into the application, while the other third employs the middleware multicasting services. Besides multicast, the anycast scheme [Par93] is utilized by 33% of the applications. Scavenging (a more advanced anycast scheme where the recipients of the data are



chosen according to specific criteria set forth by the application and verified by the resource brokering element of the middleware) is also used by 33% of the applications.

3.3.10 Network Transport Protocol All surveyed applications utilize TCP as the main network transport protocol. This shows how important reliable communication is to Grid applications. 13% of the surveyed applications utilize UDP for transferring multimedia content. One of the applications also uses UDT (UDP-based Data Transfer Protocol), which is an application-level transport protocol designed for high-speed WANs [Gu07], for testing purposes only.

3.3.11 Middleware 57% of the surveyed applications run on top of a Globus-based Grid computing environment. Other applications use EGEE-LCG/gLite (20%), Askalon (10%), Condor (3%), DIET (3%), jBoss (3%), OAR & SCP (3%), GRIA (3%), or Unicore (3%). 17% of participants use proprietary middleware solutions specifically created for their respective projects. One of the unanticipated facts that the survey has revealed is that 37% of all applications run on top of more than one middleware solution. 30% of the applications use two middleware solutions, all of them having Globus as one of the two middleware solutions; 10% of the applications employ Globus along with Askalon, another 10% use Globus with EGEE-LCG/gLite, while 7% use Globus along with a proprietary middleware solution. Furthermore, some 7% of the applications use three middleware solutions, all of which included EGEE-LCG/gLite as one of the middleware solutions.

3.3.12 Special Network Services Although 32% of the participants were not aware of any transfer delay prediction services, most of them were aware and indeed 41% agreed that it would be very useful for their Grid applications. Only 14% were already using such services, while another 14% thought it was unnecessary for their application. As for advance network reservation, only 18% of the applications employ it to ensure the quality of communication before it commences, whereas 23% think that it would be useful for their application but they do not currently employ it. Also, 18% ruled out the use of advanced reservation completely while 41% were unsure about the vitality of such services. The provisioning of network topology information appears to be a new concept to almost 52% of the survey participants. There are some 24% of the participants who do not think that network topology information would be of any use to their respective applications. However, 19% of them said that their Grid application would most definitely make use of such service if available. These participants mentioned that knowledge obtained from such a service would help make data transfer operations more efficient. One participant said that the application his institution developed involves various operations where the knowledge of the closest node to any given node is very useful. Another participant said



that knowledge of the network topology would help their scheduler in distributing work in a more efficient manner. Two of the survey participants mentioned that their Grid applications require extra resource brokering on top of that provided by the middleware. One of these mentioned that they use SRB [Raj02] on top of Globus to manage shared memory across Grid nodes. The other said that the application they developed needs more information about CPU usage and availability across the Grid. This application runs over a proprietary middleware solution. One thing all participants seemed to agree on is that the API should maintain the ease of secure communication across multiple administration domains. The necessity of secure communication is an obvious requirement of our API or perhaps any similar integrated connectivity interface. In Grids, it is necessary to maintain interoperability at different levels across all domains and thus achieving security is made more difficult [Fos98]. Yet, according to the survey participants, achieving secure communication using any of the current middleware solutions is a cumbersome task. Lastly, most participants agreed that special network-related operating system services and special networking hardware are not required to run their applications.

3.4 Possible Improvements In retrospect, there are a small number of things that might have improved the process of conducting such a survey, but unfortunately were not thought of early enough. The introduction of such changes while the survey was already being carried out would have disrupted the process and caused it to require more time than at hand. However, we find it important to mention these possible improvements for future reference and for the benefit of any similar survey. A major improvement would have been to alter the goal of the survey to cover more Grid applications. Certainly, this would have required more time to collect the results as well as more time to analyze them. Nevertheless, a larger result set would grant the survey the potential to supply more concrete conclusions. The aim of our survey was to provide some direction for the GINTONIC API design phase. Therefore, although the survey was conducted over a short period of time (30 days) yielding a relatively small result set, the output from our analysis is still interesting and valuable in light of our purpose.

3.5 Conclusion We have conducted a survey in which we focused on the application features and characteristics that are relevant to the design of the GINTONIC API, including network functionality, network demands, and middleware interaction. Besides offering some general information about a few of the Grid applications currently in use for scientific research, the survey highlights the main expectations of the users from an API such as GINTONIC. At the very least, the API is expected to integrate a few services in its architecture. The survey results hint at the services that are considered important by Grid applications, and those that seem to be less important. The survey has also triggered



more questions about integrated services. For instance, does transfer delay prediction make advanced reservation of less use? Finally, the survey has fabled the belief that “the majority of Grid application traffic is made of enormous volumes of data”. Quite the opposite, the results demonstrate that Grid traffic comes in all shapes and sizes.



4 Use Cases Use cases are a valuable means for identifying requirements of a certain system. In this section, a number of use cases are described as a basis for designing GINTONIC, the architecture of which will be laid out in Deliverable 1.1. Long before EC-GIN started, the Grid High-Performance Networking Working Group (GHPN) of the Open Grid Forum (OGF) developed a document ([Fer05]) in which some use cases for network services were given. In an attempt to avoid reinventing the wheel, we begin this section with an abridgment of this document. Then, after a higher level view on the general requirements for GINTONIC, several use cases that were identified by the EC-GIN consortium are presented.

4.1 OGF Use Cases Network services are specialized in the handling of network-related or network-resident resources. A network service is further labeled as a Grid network service whenever it has roles and/or interfaces that are deemed to be specific to a Grid infrastructure. The OGF document [Fer05] provides a high-level, structured description of some well-understood Grid network services use cases. The purpose is to facilitate the identification of network services critical to the Grid middleware and user applications and to identify relationships between different Grid network services. Use cases are divided in two groups: path-oriented and knowledge-based. The former group includes use cases with various specific connectivity service level requirements, while the latter includes information-oriented use cases related to network monitoring and usage scenarios of performance data.

4.1.1 Path-oriented Use Case This section illustrates a number of use cases aiming at the usage of different types of network connectivity. In what follows we detail the individual scenarios. 4.1.1.1 Visualization Session Visualization is one of the key methods used to represent raw or processed data and especially remote visualization, tele-immersion, collaborative visualization, tele-operation, and distributed simulation analysis are requiring a significant amount of network resources. The users are applications requiring visualization analysis of very large data sets from remote locations. Depending on the configuration (if computation and rendering is performed on local or remote site), a significant amount of network resources can be used in the following case:

1. Streaming data to a site used to perform the processing and rendering: the network is used for streaming data from a storage device or from one or more data access devices (like a sensor, microscope etc.), or from computations performed on a remote site to a site where rendering is performed.



2. Streaming processed (rendered) data to a display: in case rendering is performed on a remote site, the generated data is streamed to a display site.

3. Interactive commands: Interactive commands from the end users may need new data from the sensors, data from several remote servers, or new computations to be performed before displaying the modified results, in some cases on a near-real-time basis.

All these services are latency and jitter sensitive, especially the last one involving interactive commands. It has been shown that in tightly coupled networked manipulation tasks involving distantly located collaborating partners, 200ms roundtrip latency is the maximum acceptable latency before the users resort to half-duplex interaction (i.e. both users cease to work simultaneously – instead they take turns to manipulate the environment, and wait to see what happens). However it has also been shown that network jitter has far greater impact because jitter makes it difficult for users to predict how their system will react.

4.1.1.2 Large Data Streaming coordinated with Job Execution The coordinated use of multiple resources is particularly challenging in Grid infrastructures, due to the distributed nature of the resources involved in complex workflows with internal dependencies. A Grid network service guaranteeing the timely access to remote resources allows the synchronization of the individual components of a complex workflow, with a consequent gain in terms of resource usage efficiency. In the specific case of data access, high-throughput file transfer with deadline allows for the synchronization of job execution with the transfer of input data. For example, input data can be pre-staged while in the meantime the corresponding job is waiting to be executed. The coordination of data streaming and job execution can be effectively used by any Grid application that is oriented to the processing of large volumes of data. Community schedulers need to control multiple distributed computational resources in order to serve individual workflows. By modeling of the data transport as an individual service with a predictable termination time, the scheduler can potentially create a service level agreement for the entire workflow, assuring a specific end-time even in case of input data not yet available locally.

4.1.1.3 High Energy Physics File Replica Management Use Cases The High Energy Physics experiments at CERN will record data sets of several petabytes per year. The analysis of the recorded data requires the transmission of raw data to remote sites for processing and the exchange of the processing results. Data centers are divided into four Tiers: Tier-0 is the experiment itself; Tier-0 and Tier-1 sites each have all the raw data; Tier-2 and 3 sites have subsets of raw and processed data. Tier-1 sites are distributed so that large geographical areas (on the scale of a country) are encompassed. Data is typically streamed from the detectors and resides on disk for a while before being translated to tape. While the files are on disk, Tier-1 sites can pull over any files they are interested in. Tier-1 processed data is then exchanged with other Tier-1 sites. There are three distinct file transfer use cases described in [Fer05]:



1. the retrieval of raw data from a Tier-0 to a Tier-1 site; 2. data reprocessing; 3. the file transfer needed for remote job execution.

Here, we focus on the first and third use case only. In the first use case there is the time limit for migrating the data from Tier-0 to Tier-1 sites. While the data is being recorded and constantly pushed to tape, there is only a certain time window within which the data is initially available for migration to the Tier-1 sites, so the data transfer services have to make the most efficient use of this window, maximizing the available bandwidth. After this phase each of the Tier-1 sites has a copy of the raw data set for one experiment. These data have already been processed once (as soon as they were recorded). Subsequently, the experiment management decides that enough further detector calibration has been performed for a complete data re-processing cycle to be performed. This requires that the complete raw data set is passed through and reprocessed again. For this phase the raw data need to be replicated at several sites and a process (not described here) selects three sites which will each run 1/3 of the processing. The sites are widely geographically separated (for example, one in the Asia-Pacific area, one in the EU and one in the US). It is required that the re-processing is completed within 2 weeks of commencement (assuming that enough CPU power has been identified for this), and it is also required that the re-processed data are distributed to all Tier-1 sites throughout the World and that this should be completed within one week of finishing the re-processing. The third use case involves submitting a job to the Resource Broker to be executed. The job specification contains all the restrictions and requirements on the CE (Compute Element) that must run it as well as the list of requested files and physical file name of any data produced by it. For choosing the CE the Resource Broker calculates the costs for transferring all necessary files to CE, for each CE and according to this calculation and other requirements the Resource Broker is choosing a certain CE. For this calculation, the Resource Broker can make use of information about the network and prediction of file transfers over network.

4.1.1.4 Emergency Application Technician Application with Integrated Wireless Sensors

iRevive is an Emergency Medical Technician (EMT) application, with integrated real-time medical vital sign wireless sensors, allowing electronic Patient Care Records (PCRs) from the point of first patient contact. Each iRevive patient has an attached real-time medical sensor that records vital sign data and also serves as a dynamic patient tag, allowing EMTs to record procedures performed on each patient. iRevive integrates the sensor data of each patient into the PCR for efficient and error free data entry, creating a more consistent and complete PCR. This sensor integration enables triaging of mass casualty events quickly. The primary users for this system are EMT teams in the field with patients. Secondary users are researchers that access data from aggregated PCRs in later data mining applications.



Real-time vital sign data might be critical to proper care, so QoS is required for latency, packet loss rate and bandwidth. Different sensors and different applications will require different QoS profiles. Furthermore, QoS network requirements will be dynamic as conditions change. The monitoring of the pulse and blood oxygen levels in a patient is an example. When normal, these vital signs might have a slow sampling rate, but as sensors detect that the levels cross a normal threshold, network bandwidth and latency requirements increase because more frequent sampling is required as the data is more critical.

4.1.1.5 Distributed Aircraft Maintenance Environment (DAME) The Distributed Aircraft Maintenance Environment (DAME) provides a Grid-based, collaborative and interactive workbench of remote services and tools for use by human experts. It currently supports remote analysis of vibration and performance data by various geographically dispersed users: local engineers and remote experts. The diagnosis environment is built around a workflow system, and an extensive set of data analysis tools and services, which can provide automated diagnosis for known conditions. Where automated diagnosis is not possible DAME provides remote experts with a collaborative and interactive diagnosis and analysis environment. An overview of the typical diagnostic scenario including escalation to the remote experts (Maintenance Analyst and possibly Domain Expert) is described below.

1. An aircraft lands, and data from the on-wing system (QUICK) is automatically downloaded to the associated local Ground Support System (GSS).

2. QUICK and its GSS indicate whether any abnormality (this is a detected condition for which there is a known cause) or novelty (this is a detected deviation from normality for which there is currently no known cause) has been detected.

3. DAME executes an automatic workflow to determine its diagnosis. This is a standard pre-programmed diagnostic sequence.

4. Depending on the result of the QUICK and DAME automatic diagnoses there are three outcomes: • Everything is normal – the engine is ready for the next flight. • A condition, which has a known cause, has been detected. This can be resolved

by immediate maintenance action or planned for future maintenance action, as appropriate.

• A condition, which currently does not have a clear cause, has been detected or there is some ambiguity about the cause. This case is referred to the remote experts (a Maintenance Analyst and possible a Domain Expert) for consideration.

Considering network resources, this use case makes use of fast relocation of a large amount of data. Each aircraft flight can produce up to 1 Gigabyte of data per engine, which, when scaled to the fleet level, represents a collection rate of the order of terabytes of data per year. The storage of this data also requires vast data repositories that may be distributed across many geographic and operational boundaries.

4.1.1.6 Networked Supercomputing Many enterprises use High Performance Computing (HPC) clusters to run commercial HPC applications in order to increase the enterprise’s profitability and competitiveness. These applications offer significant advantages, especially considering the amount of time



saved to generate results, as this may reduce the risk of development, or enable investments to be better aligned and spent, or reduce products to market time. While the use of these parallel HPC applications usually starts in a single data center with local networked supercomputing, a clear trend can be seen today towards operating distributed data centers, which then requires the appropriate WAN technologies to support networked supercomputing in a distributed way. Within HPC, each node within the cluster needs to be able to communicate with different resources (storage, for example) and to other nodes for control and inter-process communications. Generically, communications within a cluster can be broken down into four operations:

1. Access network – The access network provides user access to the cluster to allow job scheduling and viewing of graphical data. It may also provide connectivity to remote resources such as Network Attached Storage (NAS) or other clusters within the context of a Grid.

2. Management network – The management network is the clusters command and control network that enables the master node to schedule, start, checkpoint, and stop work that is executed on the cluster. It also allows the nodes to be monitored for troubleshooting purposes.

3. Storage or I/O network – In most HPC environments the cluster nodes download data from an external NAS or Storage Area Network (SAN) into their local disk and then perform the necessary calculations before writing the result back to the NAS or SAN. This requires high-speed access between the NAS/SAN systems and the cluster nodes.

4. IPC (Inter Process Communication) network – The IPC network provides high speed connectivity between cluster nodes such that IPC messages can be exchanged. Because the IPC network characteristics have the most effect on application performance, the IPC network uses high bandwidth and low latency network technologies.

4.1.2 Knowledge-based Use Cases This section includes use cases that are about the collection and usage of network performance information.

4.1.2.1 Passively Monitored Data Passively monitored data can be used by administrative personnel in two typical scenarios: for characterization of file transfers (statistic information about source and destination of the transfers as well as the size of the transferred files) and for early fault detection (an administrator runs software which will warn her or him if users start to experience poor performance). For this use case data is collected from CEs. Information that might be passively monitored, such as application data throughput, can be created on a very large scale (for example, every single file transfer within the Grid might produce a tuple). Conversely, the measurement of such information through active techniques, requiring the active injection of test traffic, is more likely to perturb the behavior of the system under monitoring, and is consequently more invasive and less scalable.



4.1.2.2 Administrative Setup of Schedules of Measurements Network performance data are gathered through measurement sessions, which can be triggered on a regular basis or on-demand. Administrators require regularly scheduled and ad-hoc measurements for a variety of reasons. On-demand measurement schedules can be of various types: a single ad-hoc measurements, temporary schedules and permanent schedules. Clients that may be interested in triggering on-demand measurement sessions are both administrators and middleware agents:

• administrators interested in the network state monitoring and availability of data for network problem diagnosis;

• administrators wishing to manually set up measurements to aid middleware in optimizing the functions of the Grid;

• administrators monitoring the performance of a Grid site to ensure that network resources are well provisioned and SLAs are being kept to;

• middleware services requiring measurements in response to changes in system configuration or usage patterns.

4.1.2.3 Service Optimization Network performance information can be used to optimize the behavior of both user applications and middleware in Grids. In fact, network performance metrics can be composed to generate a projected view of the status of a given network path. This type of information can then be used to drive the networked behavior of software agents to minimize the overall cost of transmission involved in a complex workflow. Cost models can vary depending on the application and/or middleware requirements, and depend on a set of network performance metrics. Network costs can be used to select the preferable destination nodes (clients, servers etc) from a set of candidates.

4.2 EC-GIN Use Cases Previous research efforts of Data Grid focus mainly on the integrated and collaborative use of resources at the end systems to meet the requirement of Data Grid applications. More precisely, previous research efforts are more or less focused on solving problems such as data representation, data location, replication, consistency, authorization and authentication. These efforts are based on an assumption where all resources at end systems are connected by high-performance networks. However, the continuous growth towards the size of a worldwide Grid brings new problems. Consider the situation where cross-continental-users are connected by Wide Area Networks – even though the endsystems collaborate well and resources are ideally allocated to meet the user’s requirements, the access of bulk data in remote places might easily cause a performance bottleneck due to network performance degradations. To make the Grid applicable under varied network conditions, network performance should be taken into account. The underlying communication infrastructure of Grids, moreover, is a complex interconnection of LANs and WANs that introduces potential bottlenecks and varying performance characteristics [Flo95]. In EC-GIN, we propose a new architecture that bridges the gap between the performance of the network and the Grid to provide some



sort of QoS guarantee for accessing data. Not only resources in end systems, but also network resources are integrated in order to deliver a data access service.

4.2.1 Data Access Service Figure 4-1 depicts the basic architecture of a Data Access Service for mainstream Grid platforms. A web-based data access service is exposed to the user. Users submit transfers, specify quality of service requirements, monitor status, or terminate transfers through message exchanges to the service. By providing a stateless interface, users organize and monitor data transfer through message passing to and from the data access service.

Figure 4-1: Conventional Data Access Service architecture in the Grid

The advantages of the architecture encompass the following aspects:

• The control flow is not passed to the user and held on the user end. A data transfer will be continued even when the user is disconnected.

• Detailed network information might not be passed to the user end. End users are allowed to interact with data transfers, e.g. for performance monitoring, only by using pre-agreed services.

• A Web Service can be used by several users simultaneously, which makes it possible in coordinating data transfers to reach optimum transmission resource consumption.

• A data access service can handle more network information and control strategies then what a single end system can do. It provides the possibility to more efficiently orchestrate the data movement (e.g. parallel transfers are possible). Moreover, data can be obtained from data replicas in different locations.

In this architecture, point-to-point data movement is a fundamental operation between two storage resources, and provides the foundation for replication, caching, and bulk data access. Replication acts as a high-level service that is built using basic data movement



function. It creates replicas to reduce access latency and network bandwidth consumption, maintain local control over transient and necessary data, and improve reliability and load balancing. However, widely used data access services in a Grid have little consideration in the communication network which supports the data movement. They emphasize more on the resource sharing at end-systems and simply assume that the communication network is transparent when an end-to-end connection is set up. This assumption sounds reasonable when the data access service is built on a high-performance network that connects resources geographically close enough. However, for a cross-continental Grid network covering a radius of several thousand miles, the complexities and uncertainties occurred within the communication network is an inevitable factor for the performance of a data access service. Therefore, as shown below, a new data access service architecture with network assistance is proposed.

Figure 4-2: Data Access Service Architecture with End-to-end Performance Management

In this architecture, the communication network is also considered as a resource and coordinated by the data access service. Therefore, three logical procedures can be identified for accessing a large file. First, data resources have to be identified. This is normally the effort to find out the location of the required data. Second, transmission resources have to be identified. Roughly, this is to find out the possible route from data source to destination. Finally, the best transmission plan in terms of performance is given and resource reservation is conducted accordingly. Orchestrating Data Access in a Grid Environment The detailed structure of data access with network assistance is shown in Figure 4-3.



Figure 4-3: Orchestrating Data Access

The design of a data management service is modular with several independent services interacting via the data management service. A Metadata Catalog service maintains associations between logical files and their representative characteristics. By providing representative characteristics, the service replies with its logical file identification. Replica location services serve as registries which define a mapping between a logical name and the service that can provide access to the data object. With the replication location services, replicas are not constrained as “bit-wise” copies. The Network Weather Service (NWS) is an external service and collects network operation information. Data resource location and network performance information are fed into the scheduler, which consequently determines the best data movement plan based on performance and consistency considerations. The transmission plan is passed to a broker, which makes sure that related resources are usable during the whole transmission process. The broker is a key part to coordinate the resources which can either belong to the end systems or to the network. Data transfer service is the underlying transport service and provides basic mechanisms for accessing and managing the data located in storage systems. These mechanisms provide abstractions for uniformly creating, deleting, accessing and modifying file instances across storage systems. Network performance service maintains abstraction and manipulation of network resources, provides predictions for file transfer.

4.2.2 Large File Transfer Figure 4-4 illustrates the scenario of a large file transfer from one Grid node (A) to another (B). For the ease of understanding the underlying network topology is a very simple one and it is shown in Figure 4-4. The links from each node to the closest router are assumed to have enough bandwidth to accommodate any requirement, while the links between the



routers have limited bandwidth. The key questions addressed by this scenario are the following: • When does it make sense to send a large file via multiple paths of an overlay network

in order to increase the file transfer throughput? • How could this functionality be exposed as a transport service? • What constraints can be considered in order to allow the delivery of a certain level of

QoS? • How could a large file transfer be authenticated and authorized by the intermediate

nodes? As the two depicted cases in Figure 4-4 show, the answer depends very much on the underlying network. If the overlay links do not share the same network bottleneck as in case a), sending a large file via multiple paths, i.e. path 1 (red, via node C) and path 2 (blue, direct) may indeed increase the overall throughput. However, if the two paths share the same bottleneck link as in case b), a multipath transfer does not improve the throughput at all but will only increase the transport overhead. Therefore, it is essential, that the overlay application is aware of the underlying network topology. Clearly, the described problem may also be solved on a lower layer, e.g., with MPLS on layer 2. However, since the Grid nodes shown in Figure 4-4 may be distributed all over the Internet, addressing the problem on layer 2 or 3 may not be feasible due to the heterogeneity of different ISP domains. Having a multi-path data transfer solution built in higher layers allows intermediate processing on the transferred data. As an example assume that node A wants to send to an application on B a file representing a database of medical imagery but the application running on B requires that each image is transformed into a different format. Using a multi-path transfer mechanism as the one proposed here, intermediate nodes may perform some of the processing required (however, this is an application-dependent behavior).

a) multipath file transfer is beneficial b) multipath file transfer is not beneficial

Figure 4-4: Large File Transfer Scenario with Network Bottleneck



4.2.2.1 Automatika As an example of the Large File Transfer scenario we describe Automatika, an application developed by JIM. Automatika is a system that automates software development in distributed systems. Automatika uses 3 basic elements: EVC clients (Easy Visual Creator Client - a stand alone java application), Factory servers and Showcase servers. EVC is a Rapid Prototyping & Simulation environment to define applications without programming. A Factory Server takes the prototype as an input and delivers a full functional web application (typically larger than 100 MB), which is then deployed in a test environment (the Showcase server). There are two different networks in Automatika: a network that links EVC clients with Factory servers and another one that links Factory Servers and Showcase Servers. GINTONIC will be applied in the Factory-Showcase network. At the moment a Factory chooses a Showcase based on how many showcases are available and on the number of projects loaded in a showcase. GINTONIC can equip the Factory server with valuable information about the network and hence make the application deployment considerably more efficient.

4.2.3 P2P Video-over-IP In this scenario, as depicted in Figure 4-5, a set of peers communicates with each other via video calls. Each peer might participate or host a video conference, relay call streams or share their PSTN connection with the rest and act as a Gateway. The goal is to distribute the task efficiently over the network, considering both node resources, like memory or processing power and network bandwidth or topology. Thus, this scenario extends the Large File Transfer Scenario by: • adding further parameters to be taken into account: node resources and potentially

policy decisions become important as well as NAT, delay or jitter constraints for partial flows.

• shifting the focus from the optimization of a single flow to the optimization of multiple flows, potentially migrating conferences dynamically from one node to another during the call.

Another side aspect that might be developed in this context might be cooperative detection of selfish nodes and unsolicited calls.



a) Setup of 1 conference b) Setup of 2 conferences

Figure 4-5: Peer-to-Peer Video-over-IP Scenario

4.2.4 Botnet Detection In this scenario, as depicted in Figure 4-6, Grid nodes work together as a cooperative Distributed Intrusion Detection System (DIDS), where information gathering and analysis tasks are distributed over the Grid. The key questions to be answered are: • How can the work be efficiently distributed over the set of instances, both balancing the

load, considering location constraints (e.g. due to sensor location) and not introducing too much delay due to transfers?

• Which nodes should be contacted for which information under which circumstances? In addition to load balancing and transmission speed aspects, this scenario will have important implications on policy and trust constraints. If detached from the specific use of Botnet detection, the communication mechanisms may be used for detection of intrusion within the Grid as well as identification and accounting on misbehavior of nodes.



a) Anomaly indication b) Setup of DIDS

Figure 4-6: Botnet Detection Scenario

4.2.5 Mobile IPTV IPTV is highly advocated in recent years. The general definition of IPTV includes four parts for business role models as shown in Figure 4-7. These parts are [ITU06]: 1) Contents: Video, audio (including voice), data, text and applications

- Business role model: contents provider.

2) Service Middleware Platform: Contents receiving, manipulating, value-added processing, and transmitting with security and management according to the service provider. - Business role model: service provider.

3) Network Carrier: Managed, controlled, and secured delivery of contents processed by a platform using QoS controlled Broadband IP network including wire and wireless. - Business role model: network provider.

4) Terminal: TV, PDA, Cellular, Mobile TV with an STB module (Subscriber Terminal Block) or similar device for the customer. - Business role model: Customer



Management of Content/Service/Delivery

Headend/Service Management Platform

Network Provider Mobile IPTV Service

Content Provider/

Integration/developer

Content Management/Delivery

Service MiddlewarePlatform Network Carrier Application

› Contract Management› DRM Management› Market Report› Content Management› Content Delivery› Policy Management

› Operation System Management› Customer Management› Security

Video Server

› Stream Transmission/ Capture/Periodic Download› Distributed Architecture› Multi-coding Supporting

› Multi-transmission› IP Enabled› Multi-Access

› Linear/Broadcast TV/EPG› VoD/NVoD/PPV› Consumer Originated Video› Web Service/Email› Advertising› Third Party Application

Figure 4-7: Overall definition and description of IPTV in the business role model

For this reason, from the customer point of view, IPTV is not only a quality guaranteed convergence service of telecommunication and broadcasting because the customer can use the telecommunication services (such as Internet access service, e-mail, SMS, VoIP and VoD), and broadcasting services (such as terrestrial (cable, satellite) channel and narrowcasting contents) simultaneously but also a ubiquitous service because the users can get multimedia contents at any time, at any place for their tastes. Due to the great demand of the IPTV service and ever-increasing number of people joining the mobile consumer field, we focus our scenario on Mobile IPTV, which allows users to watch TV on their mobile terminals. In detail, the services of Mobile IPTV are listed below:

Entertainment • Linear/Broadcast TV; • Video/TV on Demand (VoD); • Interactive TV (iTV); • Push VoD; • Consumer Originated Video; • Music (Audio); • Games; • Picture;

General Information

• Advertising; • Sports news; • Entertainment News; • Emergency Information;



• General News; • Travel Information; • Stock Exchange Information;

Educational

• Computer/STB based training; • Distance Learning;

Communication/Messaging

• Interactive/Communications Applications; • Email; • Video Telephone;

Service Information

• Interactive Program Guide (IPG/EPG); • Parental Services; • Notification Services;

In a traditional IPTV architecture, central servers are used to distribute video contents to each end user, resulting in high workload in dedicated servers and costly upload bandwidth. As the population of subscribing users is getting larger, the so-called client/server (C/S) system can easily be overwhelmed with limited service capacity. In a mobile environment, this problem will be more obvious, since the unpredictable disconnection is considered as a part of normal wireless communication. Some P2P based IPTV systems over the Internet have been proposed to overcome the problem mentioned above, such as PPLive [Hei06], PPStream [PPS07] as well as Gridmedia [Luo06]. P2P networks emerge as a scalable and efficient means to provide group communication with the turn of this century. The core concept in P2P is that each peer, also interchangeably called node or user, plays the role of both client and server at the same time. With each participant contributing individual computation, storage and bandwidth resources into collective pool, the overall system performance is hence amplified by hundred or even thousand times. Consider Gridmedia for example, its main structure is shown in Figure 4-8.

Figure 4-8: The structure of Gridmedia system



From the figure, we can see that the main elements of the Gridmedia system include the rendezvous point (RP) server, the streaming server, and peers. Only the streaming server and RP server are dedicated servers, and all the peers are the computers of end users. The functionality of a streaming server in Gridmedia is almost the same as with traditional C/S servers. When it is connected to a peer, it will send the live content to the peer. The RP server is used to facilitate the login process of new arriving peers. In our mobile IPTV scenario, we import mobile Grid technology to handle the problems appearing in traditional C/S mode. Mobile Grid computing [Mil05] is about making Grid Services available and accessible anytime anywhere from mobile devices. The main advantages of mobile Grid computing include mobile-to-mobile and mobile-to-desktop collaboration for resource sharing, improving user experience, convenience and contextual relevance and novel application scenarios. A Grid-based mobile environment would allow mobile devices to become more efficient by off-loading resource-demanding work to more powerful devices or computers. IPTV based on mobile Grid technology might have the architecture shown in Figure 4-9. In this figure, mobile terminals are distributed in various administration domains, or we can regard them as the terminals in various areas (Beijing, Shanghai and Guangzhou, for example). Each area has a domain streaming server which can send the live content to the terminals, and every domain streaming server must login to the Grid Service which also lies in the wired Grid, and will get the streaming list of all the domain streaming servers. In this way, if a mobile terminal wants content out of its domain streaming server’s scope, the server can check the list and find the nearest server holding it. Then it can contact that server to request the content; in this way, the problems appearing in the traditional C/S mode can be effectively controlled. As shown in Figure 4-9, the domain servers receive the contents from the wired Grid, in which many powerful machines can offer the content provisioning for guaranteeing that there are rich programs available to satisfy the consumer's requirements.

Figure 4-9: Mobile IPTV scenario

Moreover, because mobile devices are usually portable but resource-limited devices with various sorts of networking capability, a proxy-based solution is used in the mobile Grid



([Fer05], [Gua05]). Proxy devices might be a desktop computer or a small server available for nearby mobile devices via the local wireless LAN, which is also connected to the domain streaming server via a high-speed network. This is not shown in Figure 3-1. In the mobile IPTV scenario, when the mobile device moves from one proxy’s scope to another, how to do the hand-off transparently and seamlessly is still a problem that we are concerned about. An example of the VOD use case is shown in Figure 4-10. VOD (Video On Demand) is an important service provided by IPTV, as it makes the users obtain a personalized service.

Figure 4-10: VOD use case

Our achievement in EC-GIN can be used in this mobile IPTV scenario in the following ways: First, the outcome of the resource management efforts in EC-GIN will provide an effective resource discovery and management mechanism for mobile IPTV, which will make the domain streaming server quickly find the missing content and send it to the mobile terminal. In this way, the whole mobile IPTV service can be provided in a more effective manner. Second, the outcome of the Grid Economics effort in EC-GIN may improve the traffic problem through economic theory, and make the delivery of the IPTV service and accounting information more fluent. Moreover, other research efforts in the Grid Economics field, such as pricing, can support an effective charging mechanism that the service provider and the server may be concerned about. Third, because the wireless network is weaker than the wired network, security seems to be more important in mobile environment. The outcome of the security and trust mechanism in EC-GIN may be useful for mobile IPTV, where every mobile terminal should



register and hold the certificate to join and leave the system. A security and trust mechanism can protect the mobile IPTV network from malicious attacks and ensure that the service and accounting information can safely be delivered. Furthermore, successful implementation of Mobile IPTV includes two aspects: • efficient transmission of multimedia making multicast technology indispensable • abundant content and service of mobile IPTV requiring an efficient CDN (Content

Delivery Network)

As for multimedia transmission, the key technology is multicast, which solves the problem of single point send/multi-point receive and multi-point send/multi-point receive. It implements highly efficient point-to-multi-point data transmission, saves network bandwidth, and reduce network load, as illustrated in Figure 4-11. MBMS (Multicast Broadcast/Multicast Service) is an IP datacast (IPDC) type of service that can be offered via existing GSM and UMTS cellular networks. The infrastructure gives the possibility to use an uplink channel for the interactions between the service and the user. This is not a straightforward issue in usual broadcast networks, as for example conventional digital television is only a one-way (unicast) system.

Figure 4-11: Unicast vs. multicast

MBMS has been standardized in various groups of 3GPP, and the first phase standards are to be finalized for UMTS release 6. The service seems to be rather attractive, as quite a lot of operators, equipments manufactures and other representatives have participated in the standardization work. It can consequently be assumed that there will be several services offered via MBMS in the near future. MBMS provides a new method for transferring data to a number of users simultaneously. As a general rule of the evolution path of GSM and UMTS networks and terminals, backward compatibility issues apply also to MBMS. This means that MBMS will not

…

One data channel per user

…Over MBMS

One data channel per TV channel



interfere with already existing GSM and UMTS services, and mobile terminals not supporting MBMS will work in networks that offer MBMS for customers with MBMS-capable terminals.

Common evaluation parameters of Mobile IPTV include Throughput, Jitter, Join Latency, Leave Latency, Channel Overlap/Channel Gap, Channel Switch Delay, and Channel Change/Zap Delay.

4.2.6 Mobile Grid The telecommunication operator (represented by China Mobile) in China experiences a tremendous expansion of its user number. The type of service provided by the operator has increased from traditional telecommunication to data services, such as games, music and locating. All of these efforts are designated to ensure an increase in Average Revenue Per User (ARPU). The diversification of services increases the complexity of the value chain. The abundance of resources related to the new services makes the service resources transfer from centralization to distribution, which is the basis of the convergence between the Grid and telecommunication networks. On these grounds, the "Mobile IPTV" use case is here extended to the general scenario of the mobile Grid. Realizing service integration between different operators is the position of Grid technology in the telecom field and also the aim of Grid technology. The main issue of Grid technology is to share resources between different organizations so as to make the ordering and modularization of services that are cooperatively offered by different organizations better. Of course, this idea does not exclude the application of Grid technology in User Equipment (UE). However, it should be noted that, especially in a mobile network, it is less likely that the UE will realize Grid functions because this includes too many business oriented aspects (such as billing, for example), and in the whole process the UE is the receiver instead of being a resource provider. Therefore, in the current period the key point of the convergence between the Grid technology and the telecom network is not resource providing by the UE, but the integration of service resources across different telecom fields, i.e. the service providing ability. In this section, the term "Mobile Grid" therefore refers to the Mobile Operator’s Grid, which mainly focuses on service integration and provisioning in the service network.

4.2.6.1 Service Model The notion of a service that is considered for the Mobile Grid in EC-GIN combines the definitions of the TeleManagement Forum (TMF), Open Mobile Alliance (OMA) and the Open Grid Forum (OGF) to: “A service is ordered by a customer; it is an ability provided by the operator or the service provider according to the requirement specified in an SLA or a contract. This ability is a set of functions which form an integral part of one or more business processes.” As shown in Figure 4-12, this service model can be divided into four levels: service resource level, service component level, VO level and service level. Service resource can be divided into Grid resources and operator resources according to their ascription. Grid resources are the resources belonging to a third party except for the operator, which may



include the program, computer, data and software. The operator resources include not only the computing, data storage and software in the operator network but also network resource, such as the fixed and wireless access networks and network entities, such as billing center, network management system etc. OMA service enabler or OGSA/WSRF technology integrates these scattered service resources into a set of single functions which is called a service component. These function sets can be operator specific sets or new sets. The service resources used by each function are not limited by the operator but can be freely organized, and there may be intersections between two function sets. These functions include data synchronization, file distributed storage and directory management. Each virtual organization integrates these function sets in a service framework and presents the service to the user according to the SLA & Contract. Here, two points should be noted: one is that the user orders only one service from one service provider. The other is that in the virtual organization, the service combination relation between inner entities in the VO is limited according to the SLA & Contract, which is also a business process.

Service Resource

Other Network ResourcesOperator natural Resources

Service Component

New Function Set Operator inherent Function Set

WS Gateways , OSA Gateways , UDDI, Protal , GridEnhance Framework

VO

SLA&Contract

Service

OMA Service Enabler/OGSA /WSRF/Other

Operator leading Other

……

Figure 4-12: Service Model for Convergence

4.2.6.2 Network Reference Model Figure 4-13 shows a possible network model based on the current network architecture of the China Mobile Group Co. Ltd. (CMCC). The network service providing and management abilities are to be improved by adding logical elements within the operator’s packet-switched core network domain. These logical elements include service gateways, service management platforms etc. The Grid Function Network Element (GFNE) in the service resource network performs the integration of service resources and the provisioning of function sets. As mentioned above, these function sets are divided into operator resources and other network resources. The GFNEs in the two domains cooperate to perform the integration of service resources and the provisioning of services.



Figure 4-13: Reference Network Model

4.2.6.3 Typical Scenario Analysis Taking a streaming service as an example, how to apply the Grid technology in the current mobile operator’s network environment is discussed in this section. Premises: In the scenario analysis, the content provider and the mobile operator both have their specific media resource databases. The content provider provides media file resources, disk space and other possible resources to the mobile operator according to some business contracts, wherein these resources are geographically distributed but can dynamically join and leave; during a period, these resources are stable. The user can order and use services from the mobile operator. The copyright is not taken into account here. Scenario description: three streaming resource portals at Guangzhou, Shanghai and Beijing respectively perform the management of service resources and provide services. Since the key objectives of the three companies are different, their resources are also different. CPs providing service resources and the mobile operator constitute a VO, wherein the operator may be a company in one area, as shown in Figure 4-14.

LogiGF

GNod

GNod

UE

UE

UseAcces

Network

UTRAN

…

GERAN

GPR

GS /EDG

PS Domain

SGS GGSN

LogiGF

LogicGF

OtherNE

OtheNE

HL

GERAN : GSM EDGE Radio Access NetworkGGS : Gateway GPRS Support NodeSGS : Serving GPRS Support NodeCP: Content ProviderUTRAN : UMTS Terrestrial Radio Access Network

CP resource

Operatoresourc

GNE

Route

Route GNE

IP Service Resource network



Mobile Streaming Portal

GuangZhou

BeiJing ShangHai

Operator Source

Operator Source

SC1

SC2

SC2

SC3

SC5

SC4

Resource of CP



Figure 4-14: Scenario Diagram

Function Description of a Grid Enhancement Environment:

Taking Beijing as an example, a resource node of a Content Provider (CP) registers on the Portal via an effective security certificate and becomes a member of the VO; at the same time, it provides streaming resources, disk spaces, directory services and CPU etc.

A user accesses the Portal via the mobile operator’s network to query needed contents, wherein the directory service may be provided by the cooperation between the portal in Beijing and other portals or resources nodes.

The portal returns the resource server available and nearest to the user through the query function and can obtain the network data of user resource requirement and content provision through network detection, as many users in Beijing apply for resources in Shanghai and the service quality is poor (represented by transmission delay and jitter). Then the decision is made whether to push the files to the resource node near the user by the third party transmission control so as to realize the ability of a PUSH Network. Each portal and its serving domain should have the ability of load balancing.

The user obtains the streaming service according to the resource address returned from the portal.

・ The user obtains the billing information from the Gateway GPRS Support Node (GGSN) of the mobile operator while obtaining the service, such as the user identity, time information, traffic information etc. The central Business & Operation Support System (BOSS) is responsible for the service billing.

GGSN and other network elements cooperate to achieve the monitoring and balancing of the traffic so as to guarantee the QoS.



4.2.6.4 Operable TeleGrid Service Network The Grid services operated by some telecom operators which gain a business profit through offering highly stable, secure and reliable data services are called Operable TeleGrid Services (OTGS). And the Grid service network offering the operable teleGrid service is the Operable TeleGrid Service Network (OTGSN).

4.2.6.4.1 How to Make Use of OTGSN The field of how to utilize the operable teleGrid service can be divided into two parts. In the first part, telecom operators as a common enterprise use it just for themselves to enhance decision-making ability, improve the working efficiency, and to amend the production lines. Interestingly, the productions themselves cannot always be found to have any relationship with the Grid service network directly by the users. In the second part, the telecom operators offer the data service through operating an OTGSN to customers (enterprises or persons). In other words, what the telecom operator offers or sells to enterprises or persons is a standard Grid service interface. The prime difference between the two parts is whether the direct customers of the telecom operators can feel the existing Grid service interfaces and use (including develop) and consume them. In this section, the first part, that is, how the telecom operators use the OTGSN just for themselves will be discussed. Some ways for telecom operators to make use of the OTGSN to enhance their inherent strength are:

By integrating BI (Business Intelligence) into the operable teleGrid service, summarizing the further analysis outcomes for the decision makers.

Enhancing the telecom operator’s ability of offering data services and creating new attractive data services, and decreasing the cost.

Implementing the complex workflow management to improve work efficiency and decrease the cost.



5 Requirements This chapter presents an overview of the GINTONIC requirements that were identified; in addition to application requirements derived from the Grid application survey as well as use cases in the previous chapters, the issues of application awareness and peer awareness are addressed.

5.1 Requirements derived from the Questionnaire The survey of network requirements of Grid applications, as described in section 4, has offered us an overview of the applications currently in use. The outcome of the survey is also important as it guides the design requirements of GINTONIC. Observations from the survey can be used in order to ensure that GINTONIC addresses the issues faced by Grid applications. In this section we describe the significant recommendations for the design of GINTONIC as provided by the survey. One of the most significant observations recorded by the survey is the diversity of dataset sizes. The results portrayed how the size of the traffic generated by Grid applications can be in the order of kilobytes, megabytes, gigabytes or more. The coexistence of different flow sizes in the same network can affect the transmission performance of all the different flows. This is an important observation that should be taken into consideration when coming up with an API such as GINTONIC which is to enhance the performance of Grid networking. The need for prompt data delivery is essential for some Grid applications. The GINTONIC API needs to support delay and jitter sensitivity by providing QoS guarantees. Furthermore, it would also help if the API is augmented with mechanisms for performance prediction, if not determinism. Grid applications could benefit from such services that report whether or not the network has the capacity to satisfy the needs of the application at a particular time. This has also been reflected by the opinion of 54% of the participants that transfer delay prediction would be useful for their applications. It would be beneficial to integrate some services, such as data replication and network topology information, into the API as most applications tend to use them. However, it is evident that the abstraction of these services is just as important as their provisioning. From the point of view of the application, it does not really matter where the service is provided as long as it is implemented in a transparent manner. Providing such services through GINTONIC offers an integrated solution which promotes the use of the API and provides more control in order to optimize their performance. Reliable communication is a necessity for all the surveyed applications. Any network transport enhancements introduced by EC-GIN, therefore, should not compromise this aspect. Two participants mentioned that their applications would benefit from additional resource brokering. As GINTONIC would be separate from the middleware, GINTONIC could contribute in resource brokering by providing network services such as the network performance prediction services mentioned above. This would offer the middleware a



‘logical network cost’ for accessing each resource across the network. The resource brokering element of the middleware would benefit from such knowledge.

5.2 Requirements derived from Use Cases 5.2.1 OGF Use Cases In this section, we briefly summarize the most important requirements that can be found by investigating the use cases that the OGF GHPN-RG has described in [Fer05]. • The "Visualization Session" use case requires the following network services:

1. Network Capability Discovery Service: A Grid Resource Broker (GRB) will have to query for network capabilities like bandwidth and the latency between sites.

1. Network Resource Allocation Service: A GRB may need to allocate the right network Quality of Service (QoS) between the different visualization session locations. This QoS reservation might depend on a pre-negotiated SLA for the visualization session.

2. Network SLA Monitoring Service: This service might be used to monitor the ongoing network QoS for the visualization session and prompt the GRB, and in turn the application, in case the SLA negotiated is violated.

3. Network Advance Reservation Service: This service may be used if the visualization/collaborative session is planned in advance and the requirements for the session are known.

4. Network Security Service: It is possible for the visualization session to pass non-trusted network service providers. In this case, encryption, VPN, firewall or other network services might be requested by the GRB.

5. Network AAA Service: The GRB might need Authorization before allocating network resources and might need accounting records to provide to the application the amount of network resource used in a visualization session.

• The "Large Data Streaming coordinated with Job Execution" use case needs

support of file transfer with deadline, which requires: 1. mechanisms for the enforcement of the synchronization of the data streaming and

processing tasks to be selected according to the timing constraints; 2. the ability to negotiate the guaranty parameters, such as the amount of guaranteed

bandwidth, the end-points, and the time interval; 3. the availability of transport protocols guaranteeing high performance and efficiency; 4. the effective use of network resources during data streaming.

• The "High Energy Physics File Replica Management" use case needs good

information about the state of the network (for choosing the right CE (compute element)). For choosing the CE, the cost of transferring the files over the network is calculated. For this calculation, information about the network, and in particular a prediction of file transfer delays, can be useful.



• The "Emergency Application Technician Application with Integrated Wireless Sensors" use case has strict QoS and security requirements while assuming mobility. Specifically, the necessary network services are:

1. Network Resource Allocations Service: the EMT application may need to allocate bandwidth, latency, and packet loss rates.

2. Network Security and AAA Service: data must be end-to-end encrypted. In addition, multi-class authorization and secure authentication is required for the EMT application.

• The "Distributed Aircraft Maintenance Environment (DAME)" use case describes a

data intensive application, where large and widely distributed data repositories must be available and large amounts of data are transmitted between them.

• A wide variety of requirements can be deduced from the "Networked

Supercomputing" use case, depending on the specific scenario and type of supercomputing application. One key metric of interest in the scope of wide area networks (which is the focus of EC-GIN) is end-to-end message latency.

• The two use cases "Passively Monitored Data" and "Administrative Setup of

Schedules of Measurements" concern network measurements, underlining their usefulness in a Grid context; a point is made in favor of passive (as opposed to active) network measurements.

• The "Service Optimization" use case stresses the importance of a network

performance metric (a network "cost"). The network cost can be useful in a number of scenarios; resource brokers and data replication managers are two examples of possible customers who could use this information to optimize their networked sessions.

5.2.2 EC-GIN Use Cases, part 1: OGF-like requirements In this section, we look at two EC-GIN use cases which have requirements that resemble the requirements that were already identified for the OGF use cases; these results are therefore complementary to the previous ones. While Grid computing reaches further to geographically separated clusters, data warehouses, and disks, it poses demanding requirements on end-to-end performance [Mar05]. To meet the ever growing demands in accessing data, the current data management architecture is not enough. Users are increasingly using Grid platforms to share resources at numerous levels, from Intranets to networks across organizations, or even worldwide. This situation is addressed by the "Data Access Service" use case. Challenges for this use case mainly concern the following aspects:

Transparency of the underlying data access is one particularly important requirement, since users have to be shielded from the inevitable heterogeneity of data resources at end systems, from hardware, software, data structure, search scripts, etc.



Decentralization of control is also one important requirement. There will be no central point of control, as the size of data systems are growing in an enormous speed. Any centralized approach is not feasible in terms of scalability and stability concerns.

Replication of data sources is one important requirement for performance concerns. With well established replications, transmission delay will be greatly reduced and throughput will be enhanced. Moreover, the stability and robustness are also improved significantly.

Appropriate and predictable data access performance is required. In order to efficiently distribute data storage and transport resources under varied network condition, the data access platform should be able to handle fault or performance degradation generated by communication network.

These requirements are quite similar to the requirements that were identified for the OGF "High Energy Physics File Replica Management" use case. The "Large File Transfer" use case requires knowledge about the underlying topology of the overlay network that is formed by the Grid. While this requirement is similar to the requirements of the OGF "Passively Monitored Data" and "Administrative Setup of Schedules of Measurements" use cases, there is a particular emphasis on knowledge about shared network bottlenecks in this use case.

5.2.3 EC-GIN Use Cases, part 2: Grid Economics This "Large File Transfer" is extended by the "P2P Video-over-IP" use case, where more network parameters must be taken into account (e.g. the use of NAT, delay or jitter constraints), and the cooperative detection of selfish nodes and unsolicited calls is identified as a possible aspect. The "Botnet Detection" use case extends these requirements further to include policy and trust constraints. In particular, the underlying communication mechanisms that are needed for it can be used for intrusion detection within the Grid as well as identification and accounting on misbehavior of nodes. The "VOD use case", which is a part of the "IPTV use case", also indicates the importance of economic theory in a Grid setting as well as the need for security and trust mechanisms. While it cannot be claimed that they capture the full breadth of requirements in this field, these use cases conjointly stress the importance of Grid Economics. The following list of requirements defines the necessary properties that the EC-GIN architecture should offer in order to satisfy the needs of Grid Economics.

Authentication/Authorization It seems that user-based AA is not a key issue in EC-GIN, however there are other AA issues that should be explored, such as network-level authentication for IP flows. E.g., a certain level of QoS, a dedicated channel, or wavelength is assured between two points A and B in the network. Thus, the network becomes a "network of networks" which can be used for various purposes. However, a flow has to be authorized to use it.

Accounting Decentralized accounting mechanisms are necessary for P2P file sharing and beyond. This may require a correlation of accounting information between different domains and different services to support aggregation of services, similar to the Akogrimo project. If a job was submitted to multiple nodes, in order to achieve a certain level of reliability for the



result, the accounting mechanisms and the processes consuming the accounting data should be able differentiate between the services that produced useful results for the user and the other processes that crashed or were only started for verification in order to achieve the desired reliability. This can be looked at from 2 points of view: the user might be the one who chooses in how many instances he wants the job to be executed, thus accepting to pay X times more than if he would choose only one instance; or the SLA might oblige the provider to deliver the result within some parameters so it's the provider's job to (eventually) start several concurrent jobs. A dynamic accounting setup for a tailored accounting process based on the SLA in place, where accounting is not (only) for charging, but for network and traffic management, is also essential.

Network Monitoring and Traffic Management IP flow accounting is a key mechanism that should be applied to monitor the network of a Grid. When Grid nodes are idle they might be used to process flow information on a larger scale than the one traditionally performed within routers, thus enabling the deployment of "more intelligent" network monitoring/management applications. There might be an agreement between Grid infrastructure providers and network operators in which the network operators agree to sell bandwidth at a lower price if Grid providers dedicate some resources for IP flow processing. Application-centric network management needs to consider application-specific needs in network monitoring and management and not only IP-level bits and bytes. At the same time, traffic management in a Grid requires resource and service selection during dynamic negotiation based on the physical network topology, mainly for transport-intensive services, in order to reduce transport overhead and provide load balancing in the network. Therefore, considering QoS requirements and current load in the network is essential.

SLA Establishment and Monitoring Generally, in a service provisioning and consuming environment, where consumers do not belong to the same administrative domain as the service provider and where no full trust can be established between them, an agreement in the form of an SLA is required. This directly leads to the necessity of having an SLA establishment functionality. However, establishing an SLA does not make sense unless it is also enforced and audited. In order to support the monitoring function, the following mechanisms must also be in place: efficient and reliable measurements of performance parameters, reliable mechanisms to detect whether a party violates an SLA, timely corrective actions to avoid further violation or to reduce violation impacts on the provider as well as related customers.

Pricing Decentralized pricing and market mechanisms such as auctions are required to price Grid resources like bandwidth. Having a decentralized approach, doing pricing efficiently is difficult and a resource trading scheme needs to be set up. Such a scheme could, for example, be a trading of bandwidth, storage space, or CPU time. The result of applying this scheme results in smoothing the traffic and achieving a fair load among all participants in the Grid.

Charging and Billing Charging and billing are a challenge, since there is typically no central point of control in such applications. Therefore new business models and settlement schemes have to be developed. Related to business models for Grids, the different roles that a party can take



in their business relations have to be defined. Also those types of services beneficial to be built on top of Grid services must be determined along with appropriate cost factors and pricing schemes.

Intrusion Detection Securing the Grid against threats both from inside as well as outside attackers is important in order to assure a high availability. Intrusion Detection may serve two purposes in this context: • Since it is impossible to secure every aspect of the Grid in a complete way without

impacts on the usability, mechanisms for detection of intrusions have to be in place in order to minimize possible damage.

• Accounting over intrusions may serve as a basis for iterative and regular refinement of security schemes as well as incentive-based approaches.

The difficulty of this part would consist in the determination of the scope of events, communicational abstraction levels appropriate as well as the design of distribution approaches of ID tasks (e.g. measurement, information mining, correlation etc.) for efficient communication and cooperation. For these tasks, the Grid environment should provide mechanisms with semantic information. Another issue will probably consist in the integration of cooperation policies and anonymization/confidentiality issues. Findings on intrusions and misbehavior should be classified and accounted in a statistical manner in order to devise economic concepts as another line of 'security protection'. Research into this field might also bring economic security concerns into a closer relation to current security mechanisms mainly concerned with the treatment of atomic resources and lead to a streamlining of security efforts by focusing on attack classes that proved to have the largest impact on economic goals.

Decentralization Grid mechanisms have to be fully decentralized. Today, the Grid is centrally organized and resource allocation is done in a centralized manner. In contrast, in a P2P approach the resource allocation is decentralized, which makes the allocation more robust, scalable and fault-tolerant. A prominent example is Bittorrent, where a part of a file can only be downloaded if another part of the file has been uploaded. This direct relation where two peers exchange a resource works completely decentralized. In Grid environments, this decentralized resource allocation could be applied as well. However, a Grid application may have indirect relations, which means that another algorithm has to be found. Therefore, it is essential to investigate up to which point fully decentralized resource sharing is useful. Fully decentralized solutions might produce too much overhead in some cases. Alternative approaches such as resource brokers or structured P2P overlays with superpeers acting as brokers should also be considered.

Self-Configuration Self-management and self-configuration capabilities of the Grid network are essential. A motivation for a decentralized approach is that it will require no additional configuration, simply plug it in and it shall work. Additionally, if the system is decentralized, then a failure of the central element has no effect on the resource allocation. However, a drawback might be that the configuration policy has to be simple in order to be useful.



Scalability Scalability of Grid mechanisms, e.g., for search or reputation management is key. A reputation management scheme could be used to connect unknown and potentially malicious nodes without harming the Grid network. A very promising approach is the max flow algorithm. Unfortunately, the algorithm does not scale in terms of the number of flows and nodes in the Grid. A contribution to EC-GIN is to make the algorithm work better in a fully distributed environment. This contribution requires introducing an easily maintainable overlay structure, which can be part of the EC-GIN layer. Only one special parameter will be required for making use of this layer, which is termed as "ENABLE_P2P_RESOURCE_ALLOCATION".

Multi-Domain Support Multi-domain aspects need to be considered, i.e., a support of multi-provider, multi-consumer scenarios is essential. It requires the provision of an economic management scheme and their implementation in a fully decentralized multi-provider domain. Every provider in a domain can be seen as an untrusted peer. Hence, mechanisms for establishing SLAs and verifying commitments are required. Furthermore, to avoid the cheating problem, which may be observed at an initial glance here, the inclusion of distributed reputation mechanisms is essential. These will enable a multi-domain case to be commercially viable, since malicious players can be detected.

Virtualization Fully virtual networking environments are the key enabler for the provisioning of Grid applications such as networks on demand. The economics of such virtual environments is a key issue that needs to be addressed.

Incentives Suitable mechanisms, i.e. new incentive patterns are needed which provide appropriate incentives for Grid nodes to share resources. Selfish Grid nodes can lower the efficiency of a Grid network in a multi domain environment due to lack of control of every Grid node. It becomes essential to establish an incentive scheme where selfish nodes are being omitted or even punished. In a centralized Grid infrastructure, incentives can be monitored and enforced easily. However, if the Grid is not centralized, e.g., Grid networks from multiple domains are connected to join forces, then a centralized approach may not be feasible. New trading schemes have to be developed addressing the fact that Grid nodes are able to use as well as contribute resources/services, i.e. a combination of monetary and non-monetary incentive and settlement schemes is key.

Security and Reliability Appropriate mechanisms are needed against maliciousness, selfishness, and unreliability of Grid nodes. Decentralized Grid management mechanisms for untrusted domains are needed with the drawback of a much more complex security mechanism. The goal is to develop a P2P incentive compatible resource allocation which addresses security in untrusted domains. Since preventive measures cannot guarantee the exclusion of attacks under all circumstances, mechanisms for detection need to be in place. As the Grid itself is a distributed system, these mechanisms have to be distributed as well and should be enabled to cooperate over administrative domains in a largely autonomously managed fashion.



Event abstraction will be an important factor in this cooperation, so an abstraction framework relating events with potential attacks should be investigated in order to classify them w.r.t. their importance in order to avoid too high a traffic overhead or delay in the process.

Mobility Awareness There are different kinds of mobility that a Grid infrastructure might support, these include user, terminal, session, and service mobility. In case of user mobility the user is able to access services independent of his location. Terminal mobility enables a continuous service access even when the user is moving with his terminal. Session mobility enables the transfer of a running service from one node to another. Service mobility defines the possibility to access service independent of their location. Since in a Grid environment service provisioning nodes are usually dynamically selected based on available resources and capabilities, and a service or session might be transferred from one node to another based on resource usage and load conditions, session and service mobility are essential aspects. Therefore, mobility support shall be considered in the Grid services and supporting services (e.g. accounting, IDS, monitoring, SLA management) as well.

5.2.4 EC-GIN Use Cases, part 3: Mobile Services The "Mobile IPTV" and "Mobile Grid" use cases with its various elements is somewhat more complex than the others, rendering it impractical to simply list the network needs of a single Mobile IPTV or Mobile Grid application in this section. In what follows, we therefore introduce the general requirements for the Mobile Grid instead of a one-to-one mapping for a scenario described in the IPTV use case. Taking the scenario analysis of a streaming service in the Mobile Grid into account in addition to characteristics of the telecom operator, especially the mobile operator, and the proposed service model, the following requirements should be considered:

Orientation The emphasis of technical requirements should be the packet switched domain/core network and the service resource network shown in the reference model (Figure 4-13). The access network of the telecom operator may be in charge of the access management of the terminal and user security management.

Cooperation If the logical Grid function network element exists in the core network of the mobile operator as a single entity, necessary interfaces should be made to interconnect with the network management system, service management system and billing system, etc. of the operator so as to obtain necessary information.

Service Management Managing the whole implementation process of the service includes the following steps: (1) service access step, obtaining information about the user and the terminal and managing the adaptation of the service terminal, the access security of the service and the connection of the service; (2) service using step, locating service resources, balancing the traffic among clan service resources, managing the service process and monitoring the service quality; (3) service ending step, releasing the service resources, post-processing



the service data, improving the service quality by appropriate network mechanisms, such as the PUSH network described above.

Service Discovering The service discovering mechanisms for the user may be diversified through versatile mobile communication ways. The user may find the service by voluntarily accessing the portal website. The service access may be provided by any technology such as WAP, HTTP, SMS, WAP PUSH or MMS.

Resource Management Resource management includes managing the resources of distributed services. General resources include network resource, computing resource and storage resource. These resources may include different service content resource and corresponding entity resource for different services. It should be carefully considered in the service implementation process the effective registration, canceling, application, orientation and security guarantee of different type of services of each resource.

Service Distinguishing Since there are variable kinds of data services, service types such as IPTV and streaming should be distinguished during the service implementation process in order to satisfy the optimization of services and different QoS requirements.

Charging The Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN) in the mobile network may collect charging information of data services. Currently, the most often used charging information is collected by the GGSN, and the information includes a user identifier, service identifier, traffic, service time, service provider, etc. After the charging information is collected, the unified charging system will finish the charging.

Bandwidth Adaptation For different service types, terminals accessing the network and accessing rates, the bandwidth adaptation in accordance with the QoS should be performed and the bandwidth adaptation requires to obtain related information, and to be supported by new protocols.

Traffic Engineering Traffic should be monitored at the access side of the network (for example, GGSN as the access point of the transmission) for large service amount, especially for services such as large file transmission so as to guarantee the traffic balance in the transmission network. As telecom operators become involved in the application of the Grid service network, the offered products should be different from some common application of the Internet access services, the mode of which is all the work controlled by the terminal. The products offered by the telecom operators shall be the platform level with high quality so as to attract the industry customers and form a stable and profitable value chain. The products can work reliably and stably in a long time and bring the customers differentiated service and good experience. The main requirements for the Operable TeleGrid Service Network (OTGSN) are:

High reliability High flexibility



High stability High extensibility

OTGSN will bring many technical and commercial challenges to the telecom operators. The technical challenges will focus on the total solution design of the transport, storage and computation, and the secure and legal use of the massive data, etc; the commercial challenge will focus on how to make a value chain with the telecom operator being the intermediary.

5.3 Application Awareness Support We must strike a balance between the application awareness and application transparency. This is especially important in the mobile Grid context.

• Application transparency can make lower layers invisible to the application; for example, MIPv6 is a network layer which can let the mobile node roam in the networks at any places and any time. Thus transparency is an easy means for maintaining old applications.

• Application awareness can use information from the lower layer to optimize the

application performance, especially in mobile environments. For example, in the limited-bandwidth wireless networks, the multimedia application should retrieve transmission information such as transmission speed of the multimedia stream. If the wireless link is congested, the application layer can regulate its data generation speed though data-compression techniques. For the mobile publish/subscribe system, it can also use a limited delivery rate which drastically decreases resource consumption [Muh04].

Figure 5-1: GINTONIC

Figure 5-1 shows that GINTONIC can get the relevant information from the Network layer and MAC layer which can be transmitted to the application layer for use. GINTONIC can use its own reliable network measurement and prediction system to interact with lower layers and determine general path properties such as the bottleneck bandwidth between two end systems.



In mobile environments, GINTONIC is regarded as a mobility manager, responsible for the management of the host’s network mobility. The application needs to stay up to date with the state of the mobility process and the characteristics of the network resources connected to the GINTONIC using the mobility manager interface. The messages generated by the interface detection, access network detection, and access network selection are passed on to the clients. The application can then filter out the messages which are of particular interest.

5.3.1 The Requirements of Application Awareness In an environment of limited resources, applications must be aware of the computational resource limitations, unreliable and intermittent communication networks, energy supply limitations, mobility, dynamic environments, and reduced user interfaces. The limitations are inherent to the environment and cannot be superseded. The degree of application-awareness depends on the exact application requirement. In Table 5-1, we define several characteristics that we use for the classification of applications [Ped04] : 1) Whether or not the application is aware of the network bandwidth supply and wireless circumstances. 2) Whether or not the application is aware of the mobility process. 3) Whether or not the application itself is dealing with the management of its connections and sessions in the event of changing connected networks. Awareness of

wireless circumstances and network bandwidth supply

Aware of mobility process

Managing own connections / sessions

Type I application no no No Type II application

yes no no

Type III application

yes yes no

Type IV application

yes yes yes

Table 5-1: Classification of applications

A type I application is not aware of the network circumstances and the mobility process. This is the behavior of many applications that normally run in a non-mobile environment. A type II application is aware of network bandwidth supply. For example, when a video steam player is downloading a video from a media server, if the bandwidth is not satisfied, the player will try to regulate the media compression format. A type III application is aware of the network circumstances and the mobility process, but does not handle the mobility management and maintain its connections. It relies on the



lower layers to adapt to environment changes. For example, a video stream player depends on Mobile IP to ensure that the same UDP connection remains established while the host is handing over between two access points. A type IV application is aware of network circumstances and the mobility process, and it can manage its own connection. The application can make the connection switch from an old link to a new link or it reinitiates the connection that adapts to the new situation of the access point. In conclusion, it depends on the application requirement to choose the tradeoff between application-awareness and application-transparent.

5.3.2 Main Principles The most important principle that we use to choose the trade-off of application awareness and application transparency is: Under fixed circumstances and with non-real-time data transfer requirements, application-transparency is more suitable. The reason is that the fixed infrastructure has enough capacity to satisfy the bandwidth of fixed hosts. Applications on a mobile host however can benefit from information about the estimated bandwidth for the currently active access networks. In order to improve wireless transmission performance, it can use TCP enhancements to improve the last-hop performance of wireless networks. The available solutions for last-hop wireless enhancements of TCP can be broadly classified into two categories which are connection management related approaches and wireless loss related approaches [Sar06]. Over the years, TCP has been modified several times to improve its performance and, as a result, several important TCP versions have emerged, such as TCP Tahoe, TCP Reno, TCP Vegas, TCP New Reno, and TCP SACK. However the ideal TCP protocol that is suitable for the last-hop wireless networks should be investigated in epth.

between APs, the user agent will llow the user by migrating to the new access point.

ansparent Network Enhancements

d To handle the mobility of Grid nodes, mobile agent technology seems to be a natural choice for dealing with the changing requirements of mobile nodes [17]. When a mobile node enters the mobile area, a user agent is created in the corresponding Access Point (AP). This agent will represent the user which can remain connected to the network. The User Agent can communicate with the Personal User Agent present in the device in order to obtain all the information that is needed. The User Agent will have the main task of providing the user with the services that it needs, by respecting the QoS standards required by the services. At any time the user movesfo

5.3.3 Trade-off Analysis in Existing Tr5.3.3.1 Background and Introduction Grids are now a promising technology to build large scale, heterogeneously distributed applications, facilitating resource sharing and problem solving in dynamic multi-institutional virtual organizations. However, as stated in [Wel05], traditional network implementations



do not fit for new requirements brought by Grids; thereby, Grid specific network enhancements should be researched and instrumented into Grid infrastructures. A survey of networking requirements for Grids including high throughput, performance controllability, network resource allocation and reservation, high availability, and security controllability is presented in [San04]. All of these requirements should be studied and enhanced into

aditional networking infrastructure.

ever, this is not usable for existing applications or hard to use in mobile cenarios.

ld be done ansparently and which should be achieved by adding additional API features?

TCP enhancements, wireless scenarios, reliable multicast and ultimedia applications.

ncements in Different Areas

s are TCP slow start, congestion avoidance, onnection overhead and packet size.

tr There are two straightforward approaches to enhance the existing network capabilities, namely application visible or transparent which is keeping the applications known or unknown to the enhancement respectively. Both approaches have benefits as well as shortcomings. On the transparent side, network enhancements are made invisible to the application, which is easier for existing application migration or mobile nodes at the cost of limited enhancements can be gained at this low level. On the other side, a new set of enhanced network APIs is devised on top of the traditional network APIs. In this way, more application specific information can be used, resulting in more enhancements to be gained; hows EC-GIN uses a hybrid approach hoping that by striking a good trade-off balance of the visible and transparent approaches we can achieve an optimal result. More specifically, we will extend the traditional network APIs with additional functionality. The additional APIs are optional in that applications can decide to use or not use them at its own will. It aims at providing more application specific enhancements that are not achievable transparently. Thus the question that should first be addressed is: which enhancements shoutr This work is carried out aiming at providing suggestions and guidelines to tackle this problem by learning from transparent network enhancements in existing applications. To this end, we analyze mechanisms used in current transparent network enhancements in different areas, includingm

5.3.3.2 Typical Network Enha5.3.3.2.1 TCP Enhancements Standard TCP is not efficient in both interactive communications and in high bandwidth, large RTT networks. Based on [He05] there are many elements detriment to TCP high throughout. First of all, there is a semantic gap between operating system API exposed to user and TCP protocol capability. For example, many operating systems’ network API does not give user the ability to manage protocol parameters such as window scale, congestion windows, etc. What’s more there are also possible bottleneck in data exchange between kernel buffer and user buffer. A possible solution is using shared memory between kernel space and user space. Finally, the underlying TCP implementation may be itself inefficient. The possible causec A common strategy for improving traditional TCP performance is by modification of the AIMD congestion control algorithm. A lot of TCP variants fall in this category, such as HighSpeed TCP, Scalable TCP and FAST TCP. All of these enhancements are



transparent to applications with no change to the socket API and no requirements on the

tep forward in that we try to improve network performance for Grid specific requirements ditional interfaces to applications for further enhancement.

cumvent. In [Han04], a careful survey has been onducted on this topic. Concisely speaking, high error rates in the link layer and node

cal, it hould be solved locally, and that the transport layer does not need to be aware of the

s, avoiding congestion control if it was recognized as a transmission error. olutions falling in this category are selective ACK and explicit loss notifications. This

se f agents enables new abilities to be hidden from applications. Since all of these

k is that only specific applications can gain from is enhancement. On the positive side, it works in user space and applications need not

convey their requirements to the middleware, since the middleware is designed for them. A3 is implemented using network filters.

routers. In the Web100 project [Mat03], a different approach is used – the traditional TCP interface is extended. The intuition is that TCP hides all information in lower layers and this information loss is a possible cause for TCP inefficiency. The Web100 project created an advanced management interface for TCP. It contains instruments in the Linux TCP/IP stack. It is distributed in two pieces: a kernel patch adding the instruments and a suite of “userland” libraries and tools for accessing the kernel instrumentation. Therefore by exposing managing capabilities of TCP parameters, a user application can have the opportunity to fine-tune the parameters and achieve a performance gain. We think that the idea in Web100 is quite similar to and useful for our approach in that it is transparent yet giving the application the possibility to improve at its own will. However our work will be a stransparently while exposing ad

5.3.3.2.2 Wireless Scenarios There are many special network conditions in wireless scenarios thus demanding corresponding enhancements to circmobility are two detrimental factors. One possible solution is a reliable link layer protocol with some TCP layer knowledge [Bal95]. The intuition behind this approach is that, since the problem is loscharacteristics of the individual links. This approach is transparent to the transport layer and above. Another approach is by changing the TCP implementation to predict or differentiate causes of lost packetSapproach makes changes at the transport layer while maintaining transparent to the applications. Several other mechanisms used to enhance wireless network performances have been analyzed [Bal97], such as a cross-layer approach and the use of software agents. The uomechanisms aim at attacking specific problems in wireless networks, namely high error rate and hand-off delay, they can work fine while maintaining application unawareness. An application-aware middleware called "A3" is proposed to handle this same problem [Zhu06]. Though transport level transparent enhancements have been extensively proposed, as illustrated by the above discussion, limited performance can be gained for specific applications because of lack of application characteristics. A3 uses a higher level application-aware middleware to handle this issue; what’s more, this enhancement is transparent to applications. The drawbacth



5.3.3.2.3 Reliable Multicast Traditional TCP does not support multicast, while multicast based on UDP is unreliable;

enceforth, h reliable multicast is another network enhancement extensively studied in the

g strategy for which an epoch-based approach is proposed to support

ervice in the protocol while delegating application specific requirements to the application.

reliable. Moreover, multimedia applications usually require a large amount

tion.

d ensuring that ey fairly cooperate with other transport protocols, mostly the TCP family.

literature. It is infeasible to create a scalable reliable multicast protocol for all applications since the widely varying requirements of different applications for a scalable reliable multicast service are broad enough to prohibit a general purpose solution. However, it was tried to propose a “one size fits many” protocol. Reliable multicast can be divided into two categories by who is responsible to maintain the reliability: the sender or the receiver. Reference [Gem97] uses receiver-oriented reliability. The biggest roadblock for this way is he choice of cachintmost applications. Since different multicast applications have diverse requirements for reliability, an ALF (Application Level Framing) based approach is used in [Gem97]. ALF says that the best way to meet diverse application requirements is to leave as much functionality and lexibility as possible to the application. A framework is devised to support basic reliable fs

5.3.3.2.4 Multimedia Applications Multimedia applications bring several new requirements to the network layer, thereby introducing a lot of research efforts. A typical new problem of multimedia applications is that TCP is not usable due to its retransmission and congestion control mechanism.

DP/RTP is notUof bandwidth. One typical solution is to add the needed features to UDP based protocols. In streaming video and interactive game scenarios, the application cannot bear TCP’s connection overhead. Thus the UDP protocol is preferable. However congestion control is still required in these circumstances. Though applications can implement reliability by themselves, a standard protocol can help alleviate user’s burden. DCCP acts as a new ransport alternative. It supports different congestion control methods by negotiat

However, DCCP is not transparent in that it introduces a completely new set of APIs. The Datagram Congestion Control Protocol (DCCP) [Mil03] is a packet stream transport layer protocol designed for multimedia flows which was recently proposed by the IETF. DCCP provides bidirectional unicast connections for congestion-controlled unreliable transfer. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. DCCP is the protocol that gives priority to timeliness other than reliability, and is intended for applications that require the flow-based semantics of TCP, but are not much concerned about in-order delivery and reliability semantics. Such applications include streaming media and Voice over IP. The primary motivation for the development of DCCP is to provide a way for such applications to gain access to standard congestion control

echanisms without having to implement them at the application layer anmth



DCCP provides an alternative to the User Datagram Protocol (UDP) for efficiently delivering multimedia content and at the same time fairly cooperating with other transport protocols. Key features of DCCP include:

• The ability to support and use ECN and PMTUD. • Support for reliable connection setup and teardown enabling firewall traversal. • DCCP facilitates negotiation of connection properties (features) between end

nodes. • Support for DTLS as a transport layer security method, similar to TLS for TCP

sessions. • Support for partial checksum coverage similar to UDP-Lite. • Signaling to applications to discover the cause of packet loss by using the Data

Dropped option. • The ability to support other options and features by extension of the protocol.

A major problem tackled by DCCP is the congestion control problem. Although many DCCP sessions are expected to transfer data in a unidirectional flow, a DCCP connection also contains a flow of acknowledgment traffic in the return direction. This flow of ACKs informs a sender whether the transmitted packets have arrived, the actual path Round Trip Time (RTT), and whether any packets were ECN marked. Using this information, DCCP provides a standard way to implement congestion control and congestion control negotiation for multimedia applications. DCCP recognizes that not all multimedia applications require the same quality of transmission service, it therefore provides a choice of congestion control mechanisms for each half-connection. DCCP uses Congestion Control Identifiers (CCID) to specify the congestion control mechanism in needs on a half-connection. Currently, 3 types of CCID are defined.

• CCID 2 – TCP SACK-like Congestion Control [Flo06], is appropriate for DCCP flows that would like to receive as much bandwidth as possible over the long term, consistent with the use of end-to-end congestion control, and that can tolerate the large sending rate variations characteristic of AIMD congestion control, including halving of the congestion window in response to a congestion event.

• CCID 3 – TFRC congestion control, [Koh06_2], is appropriate for flows that would

prefer to minimize abrupt changes in the sending rate, including streaming media applications with small or moderate receiver buffering before playback.

• CCID 4 is quite new; The behavior resembles that of CCID3, but using small

packets, as proposed in [Flo07]. This CCID is designed to be optimized for services such as VoIP.

The current status of DCCP implementations are as follows: In parallel with the standardization of DCCP from draft status to standards-track RFC, several open source operating systems now support DCCP within their networking stacks. These are all marked by ongoing (and active) development.



A BSD-based implementation by Yoshifumi Nishida [Koh06_2] is a further development of the initial code developed at the Lulea University. The implementation uses the well-known KAME platform of the now concluded Japanese KAME project which developed a free IPv6 stack for BSD variants. Initial test results on NetBSD/FreeBSD were reported [Koh06_2], with support for CCIDs 2 and 3. Further work includes porting to

penBSD.

uting) to an up-to-date inux IPv6 stack. This serves as a foundation for DCCPv6 in Linux.

ote the use of CCP for delivering multimedia services over communication networks.

ndle specific multimedia application issues. However is solution is not transparent either.

ncement still working if application information is not resent (for application migration).

n about the network – nowledge about shared bottlenecks – is needed in this scenario).

sis of P2P research, and P2P source management, which is already applied in Grids.

O The Linux implementation of DCCP was written by one of the founders of the Conectiva distribution, now part of Mandriva, an international Linux and Open-Source leader. The Linux port has benefited from the Usagi efforts ([Man07]), an important Japanese IPv6 project whose objective it has been to develop a production-quality IPv6 and IPsec protocol stack for Linux. The active efforts of this project, as well as its collaboration with the KAME and WIDE projects, have contributed (and are still contribL DCCP is still a new standard. The effects of loss, delay and Bandwidth on Demand on DCCP have not yet been analyzed. Even though DCCP is anticipated to be the de facto transport protocol for multimedia services, work is still required to promD A middleware solution is proposed in [Li06]. A new layer between the transport layer and the application layer is deployed to hath

5.3.3.3 Summary Based on our analysis, we argue that, if the network enhancement can be general for most applications, it should be made transparent. Otherwise, if the enhancement depends on application characteristics, it should be made visible through the extended API. At the same time, it must keep the enhap

5.4 Peer Awareness Support Most of the envisioned network enhancements of GINTONIC are based on the notion of "peer awareness" – that is, nodes need to know about the existence as well as the location of other nodes, and maybe some additional characteristics related to their position in the network. Consider the Large File Transfer scenario depicted in Figure 4-4, for example: the sender node must be aware of the intermediate node in order to accordingly split the file across two paths (as a matter of fact, even more informatiok EC-GIN shares this requirement with Peer-to-Peer (P2P) systems. In order to identify the right level of peer awareness, we therefore provide an overview of P2P systems where we highlight this aspect. As the P2P field is almost endless, rendering any endeavor to provide a comprehensive overview impossible, two extreme ends of the spectrum are briefly introduced: file sharing tools, which form the bare



5.4.1 Resource Management Techniques in P2P File Sharing Tools P2P is a model of an Internet application in which each node serves the role of both client and server. It refers to a class of systems and applications that employ distributed resources to perform a function in a decentralized manner. The resources encompass computing power, data (storage and content), network bandwidth, and presence (computers, human, and other resources). The critical function can be distributed computing, data/content sharing, communication and collaboration, or platform services. Decentralization may apply to algorithms, data, and meta-data, or all of them. This does not preclude retaining centralization in some parts of the systems and applications.

ontent storage and exchange is one of the areas where P2P technology hC as been most

A, which allow for better scalability of the systems and less stress on

anagement algorithms and then compares their implementations in a few P2P systems.

en the peers. Napster’s

successful. Multimedia content, for instance, inherently requires large files. Three main resource management models exist today: the centralized directory model (Napster), the unstructured overlay model, where requests are flooded across the peer-to-peer network (Gnutella), and the structured overlay model, where routing depends on keys associated with the documents that are queried for (FreeNet). All P2P file sharing systems can be categorized into one of these three families, although hybrid variants do exist, such as extensions of the models with leader election mechanisms (automatic or manual lections) as in KaZae

the network [Mil03].

he following section presents an overview of the three common P2P resourceTm

5.4.1.1 Centralized Directory Model This model was made popular by Napster. Napster is the first P2P file sharing application to receive widespread use. It has had more than forty million client downloads and has led to numerous variants of file-sharing applications (such as Gnutella). Napster was originally developed to defeat the copying problem and to enable the sharing of music files over the Internet. Napster uses the centralized directory model to maintain a list of music files,

here the files are added and removed as individual users connect to and disconnect fromwthe system. Users submit search requests based on keywords such as “title,” “artist,” etc. The peers of the community connect to a central directory where they publish information about the content they offer for sharing (see Figure 5-2). Upon request from a peer, the central index will match the request with the best peer in its directory. The best peer could be the one that is cheapest, fastest, or the most available, depending on the user needs. Then a file exchange will occur directly between the two peers. Although Napster's search mechanism is centralized, the file sharing mechanism is ecentralized; the actual transfer of files is done directly betwed

centralized directory model inevitably yields scalability limitations. In some situations, the available bandwidth can be tremendously reduced by users downloading songs from one’s machine. Centralization simplifies the problem of obtaining a namespace and enables the realization of security mechanisms. This model also requires some managed infrastructure (the directory server), which hosts information about all participants in the community. This can cause the model to show



some scalability limits, because it requires bigger servers when the number of requests increase, and larger storage when the number of users increases [Mil03].

Figure 5-2: Central Index Algorithm

ly setting the TTL (Time To Live) parameter of the request messages, the nstructured overlay model can scale to a reachable horizon of hundreds and thousands

of nodes.

5.4.1.2 Unstructured Overlay Model The unstructured overlay model is different from the central index one. This is a pure P2P model in which no advertisement of shared resources occurs. Instead, each request from a peer is flooded (broadcast) to directly connected peers, which themselves flood their peers until the request is answered or a maximum number of flooding steps (typically 5 to 9) occur (see Figure 5-3). This model is used by Gnutella and requires a lot of network bandwidth. As a result, the scalability properties of the model are often confused with its reachability properties. If the goal is to reach all the peers in the network, then this model does not prove to be very scalable, but it is efficient in limited communities such as a company network. By manipulating the number of connections of each node and appropriateu

Figure 5-3: Flooded Requests Algorithm



Furthermore, some companies have developed “super-peer” client software that aggregates many requests. This leads to a much lower network bandwidth requirement, at

e expense of higher CPU consumption. Caching of recent search requests is also used

he download. When files are imported, the system automatically extracts meta-data from the contents of the files. This allows for much faster and more accurate searches [Mil03].

y model. Also, network partitioning can ad to an islanding problem, where the community splits into independent sub-

n Chord, each peer keeps track of other peers. The highly ptimized version of the algorithm only needs to notify other peers about the join/leave

events [Mil03].

thto improve scalability. KaZaA is an example of a P2P file sharing system that uses Super Nodes as local search hubs. These are powerful nodes on fast connections that are generated automatically. Peers connect to their local SuperNode to upload information about the files they share, and to perform searches in the network. KaZaA uses an intelligent download system to improve download speed and reliability. The system automatically finds and downloads files from the fastest connections, failed transfers are automatically resumed, and files are even downloaded from several sources simultaneously to speed up t

5.4.1.3 Structured Overlay Model The structured overlay model, used by FreeNet, is the most recent approach. Each peer from the network is assigned a random ID and each peer also knows a given number of peers (see Figure 5-4). When a document is published (shared) on such a system, an ID is assigned to the document based on a hash of the document’s contents and its name. Each peer will then route the document towards the peer with the ID that is most similar to the document ID. This process is repeated until the nearest peer ID is the current peer’s ID. Each routing operation also ensures that a local copy of the document is kept. When a peer requests the document from the P2P system, the request will go to the peer with the ID most similar to the document ID. This process is repeated until a copy of the document is found. Then the document is transferred back to the request originator, while each peer participating in the routing will keep a local copy. Although the structured overlay model is very efficient for large, global communities, it has the problem that the document IDs must be known before posting a request for a given document. Hence it is more difficult to implement a search than in the unstructured overlalecommunities, which don’t have links to each other. Four main algorithms have implemented the structured overlay model: Chord, CAN, Tapestry, and Pastry. The goals of each algorithm are similar: to reduce the number of P2P hops to locate a document of interest and to reduce the amount of routing state that must be kept at each peer. Each of the four algorithms either guarantees logarithmic bounds with respect to the size of the peer community, or it is argued that logarithmic bounds can be achieved with high probability. The differences in each approach are minimal; however each is more suitable for slightly different environments. Io



Figure 5-4: Document Routing Algorithm

5.4.2 Grid Resource Management Based on P2P Technology Grids provide resource sharing and resource virtualization to end users, allowing for computational resources to be accessed as a utility. To facilitate such Grid systems, effective resource management is required. Resource management and scheduling are key Grid services, where issues of load balancing represent a common concern for most Grid system developers. Different from distributed computing, the Grid computing environment presents some new challenges, for example cross-domain, dynamic and P2P ([Fos97], [Fre01]) characteristics. Many resource management technologies have been investigated by some projects, including Globus, Legion, Condor, Nimrod-G and Ninf-G. In a Grid environment, heterogeneous computational resources such as personal computers, clusters and online instruments may belong to different communities. They are made available to the Grid community based on highly diverse sharing policies. Resources of a computational Grid have various degrees of dynamism, from mostly static attributes, such as operating system version and storage space, to highly dynamic ones, such as available CPU load and network bandwidth. These properties must be addressed when implementing Grid resource management approaches. In such a dynamic environment, it is more efficient to forward requests than to disseminate resource information that soon becomes stale. The P2P based approach described in [Che00] can dynamically manage and schedule the Grid resources according to their real-time workload status. Unlike some existing systems which use the Globus toolkit [Fos97] to integrate with a Grid computing environment, including Condor-G [Fre01], Nimrod/G [Abr00] and Ninf-G [Tan01], the scheduling method introduced is based on a P2P overlay network and resource discovery. It has been used in the implementation of an agent-based resource management algorithm for a cycle-sharing Grid computing system, where each agent acts as a Grid service provider of a virtual organization. Agents cooperate with each other to discover available resources for tasks. In order to find a satisfactory computational resource as fast as possible, task requests will be forwarded following the Chord [Sto01] routing protocol instead of a random walking one in [Che04]. The resource scheduling process does not aim to find the best service for each task, but endeavors to find an available Grid computational resource service provider.



5.4.2.1 P2P Based Resource Management Approach Resource management problems in Grid environments consist of: i. Wide-area scheduling of the tasks requested for computational resources into

satisfying hosts belong to one or more virtual organizations.

ii. Local scheduling or fine-grained resource management inside of a Grid host after code of the application has been exported to the host.

This section focuses on the first one. The resource scheduling problem is considered as the discovery of Grid resources that provide satisfying execution performance for globally Grid-submitted tasks.

5.4.2.2 P2P Overlay Management According to the dynamic characteristics of Grid environment, P2P technologies can be introduced into Grid computing systems to overcome the problems of single point failure, hosts frequently coming and going and fast changing of hosts’ workload. The components of the P2P-like architecture described in [Che00], as shown in Figure 5-5, highlight the research issues to be addressed in the design of any Grid resource management approach.



Figure 5-5: P2P-like architecture of Grid resource management

In the P2P-like Grid architecture, hosts become Grid resource providers if they would like to donate their resources to a Grid application system. A resource provider can be a personal computer, a cluster with many processing nodes, or just an online instrument. Firstly, hosts join a virtual organization (VO), depending on how they would like to donate their resources, such as interest, geography or trust. It is assumed that each host has a local management node which is responsible for its local scheduling. For example, if a host is a cluster, the local management node is its global management node. If a personal computer becomes a Grid host, then the local management node is the PC itself. Information of a VO’s available resources will be kept in a resource management agent (RMA). Each local management node submits its service information to corresponding RMAs. A high level representation is enhanced by organizing the RMAs into a P2P overlay network, where available resource information provided by each host can be published throughout the overlay and RMAs can cooperate with each other to discover available resources.



6 Conclusion The goal of this document was to identify requirements for the GINTONIC architecture based on an investigation of the state of the art. Except for the two technical requirements of application awareness and peer awareness, requirements were presented together with a discussion of the Grid application questionnaire and use cases. Thus, due to inevitable overlap between the different applications and scenarios under consideration, some of these requirements were listed multiple times. We therefore summarize them once again in Table 6-1, listing each one only once and pointing to the use cases where it was identified (or the questionnaire, respectively). Note that a missing connection between a requirement and a use case does not indicate that meeting the requirement would not be beneficial to the use case in question – the goal is to list the most important requirements, and show that some of them were identified multiple times, stressing their importance (but not indicating minor importance of requirements which were identified only once). In some cases, meeting the requirements is indispensable (e.g. file transfer with deadline cannot work without strict delay guarantees), whereas in others the use case can better be supported if certain requirements are met, but the described scenario would still be feasible otherwise. Again, as Table 6-1 is just a list of the requirements which the GINTONIC architecture should meet, this distinction is not made for the sake of clarity. Finally, some requirements of extremely broad utility not only to the Grid but almost any Internet application were omitted (e.g. "high performance data access", "reliable data transfer" and "scalability"). OGF use cases are designated as such; the "P2P Video-over-IP" and "Botnet Detection" use cases are combined into "Grid Economics" (as was done in Section 5.2.3), and the "Mobile IPTV" and "Mobile Grid" use cases are combined into "Mobile Services" (as was done in Section 5.2.4). In closing, we can say that both the number and the heterogeneity of network requirements that Grid applications have are remarkable. While this means that trying to meet as many of them as possible is a very challenging endeavor, it also underlines the urgent need for the Grid specific network enhancements that EC-GIN will develop.



Requirement Identified in Support for diverse (including exceptionally large) dataset sizes

Questionnaire, OGF Distributed Aircraft Maintenance Environment (DAME)

Support for delay and jitter sensitivity Questionnaire, OGF Networked Supercomputing Mechanisms for the enforcement of synchronization between data streaming and processing tasks OGF Large Data Streaming coordinated with Job Execution

General QoS guarantees (advance reservation etc.)

Questionnaire, OGF Visualization Session, OGF Emergency Application Technician Application with Integrated Wireless Sensors

SLA establishment and monitoring OGF Visualization Session, Grid Economics

Performance prediction (e.g. file transfer delay)

Questionnaire (if no QoS guarantees available), OGF High Energy Physics File Replica Management, Data Access Service

Bandwidth adaptation Mobile Services Access to topology information Questionnaire, Large File Transfer

General information about the state of the network (including measurements and on-line monitoring)

OGF High Energy Physics File Replica Management, OGF Passively Monitored Data, OGF Administrative Setup of Schedules of Measurements, Grid Economics, Mobile Services (for bandwidth adaptation)

Abstraction from network details (e.g. via a "cost" metric) / virtualization

Questionnaire, OGF Service Optimization, Data Access Service, Grid Economics

Data replication service Questionnaire, Data Access Service Resource brokering / discovery service Questionnaire, OGF Visualization Session, Mobile Services

Security (including AAA and intrusion detection) and Reliability

OGF Visualization Session, OGF Emergency Application Technician Application with Integrated Wireless Sensors, Grid Economics, Mobile Services

Mobility (and awareness thereof) OGF Emergency Application Technician Application with Integrated Wireless Sensors, Grid Economics

Decentralization (of control) / self-management, self-configuration Data Access Service, Grid Economics Traffic Management Grid Economics, Mobile Services Pricing Grid Economics Charging, Billing Grid Economics, Mobile Services Multi-Domain Support Grid Economics Support for incentive schemes Grid Economics Emphasis on core network and service resource network (instead of access network) Mobile Services Interfaces to network management systems Mobile Services Service and resource management, service distinguishing Mobile Services

Table 6-1: GINTONIC requirements (excluding application awareness and peer awareness)



7 References [Abr00] D. Abramson, J. Giddy, L. Kotler: “High performance parametric modeling with Nimrod/G: killer application for the global Grid?”. Proc. 14th International Parallel and Distributed Processing Symposium, Cancun, Mexico, 2000 [Bal95] H. Balakrishnan, S. Seshan, R. H. Katz: “Improving reliable transport and handoff performance in cellular wireless networks”. ACM Wireless Networks, vol. 1, Dec. 1995 [Bal97] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, R. H. Katz: “A comparison of mechanisms for improving TCP performance over wireless links”. IEEE/ACM Transactions on Networking, Volume 5, Issue 6 (Dec. 1997), pages: 756-769 [Che00] Shudong Chen, Xuefeng Du, Fanyuan Ma, Jianhua Shen: “A Grid Resource Management Approach Based on P2P Technology”. IEEE Proceedings of the 8th International Conference on High-Performance Computing, Amsterdam, The Netherlands, May 8-10, 2000 [Che04] Shudong Chen, Wenju Zhang, Fanyuan Ma, Jianhua Shen: “A Novel Agent-Based Load Balancing Algorithm for Grid Computing”. GCC2004, Wuhan, Nov. 2004 [Fer05] T. Ferrari: “Grid Network Services Use Cases”. Grid High Performance Networking Working Group, OGF, work in progress, June 2005 [Flo06] S. Floyd, E. Kohler: “Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control”. RFC 4341, 2006 [Flo07] S. Floyd, E. Kohler: “TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant”. RFC 4828, 2007 [Flo95] S. Floyd, V. Jacobson: “Link-sharing and resource management models for packet networks”. IEEE/ACM Transaction on Networking, vol. 3, pp. 365–386, Aug. 1995 [Fos01] I. Foster, C. Kesselman, S. Tuecke: “The Anatomy of the Grid: Enabling Scalable Virtual Organizations”. International J. Supercomputer Applications, 15(3), 2001 [Fos97] I. Foster, C. Kesselman: “Globus: a metacomputing infrastructure toolkit”. Int. J. High Performance Computing Applications 2 (1997), 115-128 [Fos98] I. Foster, C. Kesselman, G. Tsudik, S. Tuecke: “A Security Architecture for Computational Grids”. Proceedings of the 5th ACM conference on Computer and communications security, San Francisco, California, United States, pp 83-92, 1998, ISBN:1-58113-007-4 [Fre01] J. Frey, T. Tannenbaum, I. Foster, M. Livny, S. Tuecke: “Condor-G: a computation management agent for multiinstitutional Grids”. Proc.10th IEEE Symposium on High Performance Distributed Computing, San Francisco, CA, USA, 2001 [Gem97] J. Gemmell, J. Leibeherr, D. Bassett: ”In Search of an API for Scalable Reliable Multicast”. Technical Report, MSR-TR-97-17 [Gu07] Yunhong Gu, R. L. Grossman: “UDT: UDP-based data transfer for high-speed wide area networks”. Computer Networks: The International Journal of Computer and Telecommunications Networking, Volume 51, Issue 7 (May 2007), pp 1777-1799, ISSN: 1389-1286



[Gua05] T. Guan, E. Zaluska, D. Roure: “A Grid service infrastructure for mobile devices”. First International Conference on Semantics, Knowledge and Grid, China, 2005 [Han04] A. A. Hanbali, E. Altman, P. Nain: “A Survey of TCP over Mobile Ad Hoc Networks”. RFC 5182, 2004 [He05] E. He (ed.), P. Vicat-Blanc Primet (ed.), M. Welzl (ed.), M. Goutelle, Yunhong Gu, S. Hegde, R. Kettimuthu, J. Leigh, Chaoyue Xiong, M. Yousaf: "A Survey of Transport Protocols other than Standard TCP". Global Grid Forum Document GFD.55, Data Transport Research Group, 23 November 2005 [Hei06] Xiaojun Hei, Chao Liang, Jian Liang, Yong Liu, “Insights into PPLive: A measurement study of a large-scale P2P IPTV system”. WWW’06 Edinburgh, Scotland, 2006 [ITU06] INTERNATIONAL TELECOMMUNICATION UNION(ITU) ,Overall definition and description of IPTV in the business role model,10-14 July 2006, URL: www.itu.int/ITU-T/IPTV/events/072006/docs/ID/FGIPTV-ID-0025e.doc [Kam] “The Kame project”, April 1986- March 2006, URL: http://www.kame.net [Koh06]. E. Kohler, M. Handley, S. Floyd: "Datagram Congestion Control Protocol". RFC 4340, 2006 [Koh06_2]. E. Kohler, M. Handley, J. Padhye: “Profile for DCCP Congestion Control ID 3: TFRC Congestion Control”. RFC 4342, 2006 [Kou04] M. Koutsopoulou, A. Kaloxylos, A. Alonistioti, L. Merakos, K. Kawamura: "Charging, Accounting and Billing Management Schemes in Mobile Telecommunication Networks and the Internet". IEEE Communications Surveys, Vol. 6, No. 1, 2004 [Li06] H. Li, M. Li, B. Prabhakaran: ”Middleware for streaming 3D progressive meshes over lossy networks”. ACM Transactions on Multimedia Computing, Communications and Applications (TOMCCAP), Volume 2, Issue 4, 2006 [Luo06] Jian-Guang Luo, Yun Tang, Meng Zhang, et al.: “Design and deployment of a peer-to-peer based IPTV system over global Internet”. First International Conference on Communications and Networking, China, 2006 [Man07] Mandriva, About Mandriva Linux, 2007, URL: http://www.mandriva.com/en/community/resources/about_mandriva_linux [Mar05] L. Marchal, P. Vicat-Blanc Primet, Y. Robert, J. Zeng : “Optimizing Network Resource Sharing in Grids”. IEEE GLOBECOM 2005 [Mat03] M. Mathis, J. Heffner, R. Reddy: “Web100: extended TCP instrumentation for research, education and diagnosis”. ACM SIGCOMM Computer Communication Review, Volume 33, Issue 3 (July 2003), Pages: 69 - 79 [Mil03] D. S. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins, Zhichen Xu: “HP Laboratories Palo Alto: Peer-to-Peer Computing”. HPL-2002-57 (R.1) July 3rd , 2003 [Mil05] D. Millard, A. Woukeu, F. B. Tao, H. Davis: “Experiences with writing Grid clients for mobile devices”. First International ELeGl Conference on Advanced Technology for Enhanced Learning, Italy, 2005 [Muh04] G. Muhl, A. Ulbrich, K. Herrmann, T. Weis: "Disseminating information to mobile clients using publish-subscribe". IEEE Internet Computing, May-June 2004

http://www.kame.net/



[Par93] C. Partridge, T. Mendez, W. Milliken: “Host Anycasting Service”. RFC 1546, November 1993 [Ped04] A. Peddemors, H. Zandbelt, M. Bargh: “A mechanism for host mobility management supporting application awareness”. MobiSys’04, June 2004 [PPS07] PPStream, Inc., PPStream Contact and Cooperation, 2007, URL: http://www.ppstream.com/business.php [Raj02] A. Rajasekar, M. Wan, R. Moore: “MySRB & SRB -- Components of a Data Grid”. 11th International Symposium on High Performance Distributed Computing (HPDC-11), Edinburgh, Scotland, 2002 [San04] V. Sander (ed.), W. Allcock, P. Cong Duc, J. Crowcroft, M. Gaynor, D. B. Hoang, I. Monga, P. Padala, M. Tana, F. Travostino, P. Vicat-Blanc Primet, M. Welzl: "Networking Issues for Grid Infrastructures". Global Grid Forum Document GFD.37 (informational), Grid High Performance Networking Research Group, 22 November 2004 [Sar06] B. Sardar, D. Saha: “A survey of TCP enhancements for last-hop wireless networks”. IEEE Communications Surveys & Tutorials, 3td Quarter 2006 [Sto01] I. Stoica, R. Morris, D. Karger, F. Kaashoek, H. Balakrishnan: “Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications”. ACM SIGCOMM 2001, Sep. 2001 [Tan01] Y. Tanaka, Ninf-G: “Grid RPC system based on the Globus toolkit”. The 2001 Globus Retreat, San Francisco, CA, USA, 2001 [Wel05] M. Welzl, M. Yousaf: "Grid-Specific Network Enhancements: A Research Gap?". Proceedings of IEEE/IFIP International Workshop on Autonomic Grid Networking and Management (AGNM'05), Barcelona, Spain, 28 October 2005 [Zhu06] Z. Zhuang, T. Y. Chang, R. Sivakumar, A. Velayutham: ”A3: application-aware acceleration for wireless data networks”. International Conference on Mobile Computing and Networking, 2006



8 Abbreviations 3GPP 3rd Generation Partnership Project AAA Authentication, Authorization, Accounting ACK Acknowledgment ALF Application Level Framing AP Access Point ARPU Average Revenue Per User BI Business Intelligence BOSS Business & Operation Support System BPM Business Process Management BUPT Beijing University of Posts and Telecommunications CCID Congestion Control Identifier CDN Content Delivery Network CE Compute Element CMCC China Mobile Group Co. Ltd. CMDI China Mobile Group Design Institute Co. Ltd. CN Core Network CP Content Provider CPE Customer Premises Equipment CRBT Color Ring Back Tone C/S Client-Server CS Circuit switched domain CTTL China Telecommunication Technology Labs DAME Distributed Aircraft Maintenance Environment DCCP Datagram Congestion Control Protocol DF Delay Factor DIDS Distributed Intrusion Detection System DTLS Datagram TLS EC-GIN Europe-China Grid Internetworking ECN Explicit Congestion Notification EMT Emergency Medical Technician EVC Easy Visual Creator EXIS IT EXIS IT (Affiliation Name) FMC Fixed Mobile Convergence FMCA Fixed Mobile Convergence Association GFNE Grid Function Network Element GHPN Grid High Performance Networking Working Group GINTONIC Grid Internetworking TOolbox Nestled In the Core GSS Ground Support System HPC High Performance Computing IETF Internet Engineering Task Force IM Instant message IMS IP Multimedia Subsystem INRIA Institut National de Recherche en Informatique et Automatique IPC Inter Process Communication IPDC IP datacast



IPG/EPG Interactive Program Guide ISCAS Institute of Software, Chinese Academy of Sciences ISP Internet Service Provider JIM Justinmind MBMS Mobile Broadcast / Multicast Service MDI Media Delivery Index MDVO Mobile Dynamic Virtual Organization MLR Media Loss Rate MMS Multimedia message MPI Message Passing Interface MPLS Multi Protocol Label Switching NAS Network Attached Storage NAT Network Address Translator NWS Network Weather Service OGF Open Grid Forum OGSA Open Grid Service Architecture OGSI Open Grid Service Infrastructure OMA Open Mobile Alliance OTGS Operable TeleGrid Service OTGSN Operable TeleGrid Service Network PCR Patient Care Record PMTUD Path MTU Discovery PoC Push to talk over Cellular PS Packet switched domain PSTN Packet Switched Telephone Network QoS Quality of Service RP Rendezvous Point RMA Resource Management Agent RTP Real-time Transport Protocol RTT Round-Trip Time SACK Selective Acknowledgment SAN Storage Area Network SLA Service Level Agreement SMS Short message SNI Service Node Interface SP Service Provider STB Subscriber Terminal Block STREP Specific Targeted Research or Innovation Project TCP Transmission Control Protocol TFRC TCP-Friendly Rate Control (protocol) TLS Transport Layer Security TMF TeleManagement Forum TTL Time To Live UE User Equipment UDDI Universal Description, Discovery and Integration repository UDP User Datagram Protocol UDT UDP-based Data Transfer Protocol UIBK Universität Innsbruck U.K. United Kingdom ULANC Lancaster University



UNI User Network Interface UniS University of Surrey UniZH University of Zürich VO Virtual Organization VOD Video On Demand VSP Virtual Service Provider WSRF Web Service Resource Framework

9 Acknowledgments This deliverable was made possible due to the large and open help of the WP1 team in the EC-GIN project, which includes several actors besides the deliverable authors as indicated in the document control. Many thanks to all of them. Additionally, we would like to thank our colleagues who completed and returned the questionnaire.



10 Appendices

10.1 Questionnaire for the Network Requirements of Grid Applications

Europe-China Grid Internetworking www.ec-gin.eu

EC-GIN is an EU-funded project aimed at making the Grid work better by providing network technologies that have been tailored to address the scientific requirements of the Grid. In order to reach this goal, we need to build an understanding of the network requirements of Grid applications. We are conducting a survey of the requirements of Grid applications. Please help us by filling out this questionnaire. We want an overview of the Grid applications you are familiar with. Please use a separate questionnaire for each different Grid application. Answer the questions to the best of your knowledge, and leave blank the fields you are not sure about. When asked about numerical values, if no exact figures are available approximations will do just fine. Grid application name: ......................................................................................................................................... Application URL♦: ................................................................................................................................................... Project name♦: ....................................................................................................................................................... Project URL♦: ........................................................................................................................................................... ♦ if any



1. Please provide a brief description of the application. ............................................................................................................................................................................... ............................................................................................................................................................................... ............................................................................................................................................................................... ...............................................................................................................................................................................

2. Scale: We would like to know about the size of the Grid on which the application runs. Please provide approximate figures for the number of nodes and domains that make up the network. [ ] nodes across [ ] administration domains

3. Composition: Please help give us a picture of the device diversity found in your Grid (total should add up to 100%, i.e. the number of nodes mentioned in the previous section). [ ] % of the nodes are super-nodes/clusters [ ] % of the nodes are desktop machines [ ] % of the nodes are small devices (e.g. embedded processors) [ ] % of the nodes are mobile nodes (e.g. wireless sensor nodes, handheld devices)

4. Data granularity: We would like to know about the amount and pattern of traffic the application usually deals with. Please specify the most common dataset sizes used in communication and the frequency of use of each (total should add up to 100%). e.g. [ 60 ] % of all data is transferred in datasets of approximately [ 10 ] Mbytes

[ ] % of all data is transferred in datasets of approximately [ ] …Bytes [ ] % of all data is transferred in datasets of approximately [ ] …Bytes [ ] % of all data is transferred in datasets of approximately [ ] …Bytes [ ] % of all data is transferred in datasets of approximately [ ] …Bytes [ ] % of all data is transferred in datasets of approximately [ ] …Bytes

5. Data timeliness: Some applications impose a deadline on the delivery of its data packets across the underlying network. In such cases, data delivered beyond its deadline is considered useless and is discarded. If your application implements such mechanisms, please answer the following:

• Approximately how much of the data is time-sensitive? [ ] % of all traffic • How much of this is live multimedia streams? [ ] % of all time-sensitive traffic • How strict are the deadlines for traffic delivery and why are such deadlines enforced?

...............................................................................................................................................................................

...............................................................................................................................................................................

...............................................................................................................................................................................

6. Encryption: We would like to know if any of the data is encrypted before being sent through the network. If so, please state how much of the data is encrypted and at which level does the encryption happen. [ ] % by middleware [ ] % at network transport layer

7. Accounting: Please indicate the resources considered important by your application when it comes to accounting. CPU time disk storage network bandwidth others: ...........................................................................................................................

8. Data replication:



Many Grid applications replicate some or all of the data they communicate across the Grid. If your application carries out such measures, how much of the traffic is usually replicated?

[ ] % of all traffic

9. Data path: Please indicate how much data is forwarded through the network (total should add up to 100%).

[ ] % of all data has a single recipient [ ] % of all data has multiple recipients, by the following means:

Implementation of multiple recipients: Not

used by middleware by application other (please specify) Anycast Multicast

Scavenging

10. Network transport protocol: Please give the approximate frequency of use of every transport protocol.

TCP, with [ ] % of all traffic UDP, with [ ] % of all traffic Other: ......., with [ ] % of all traffic ......., with [ ] % of all traffic

11. Middleware: Which middleware package do you use? Globus (version .......) EGEE-LCG (version .......) NorduGrid (version .......) Condor (version .......) Legion (version .......) other: .............................. proprietary middleware solution: ........................................................................................

12. Special (network) services: Please give as much detail as possible about special network services that your application needs. Mention any services that do not appear below.

Used (with

percentage of all data)

Would be used if

available Unnecessary Unsure

Transfer delay prediction with [ ] % Advance network reservation with [ ] % Network topology information with [ ] % Customised transport protocol with [ ] % Special networking hardware with [ ] %

Special OS demands with [ ] % with [ ] % with [ ] % with [ ] %

Please use this space to mention any more network-related details and/or to elaborate on any of the previous points. Following are a few examples:

• Which network resource, if any, is most important to reserve in advance? • How is network topology information obtained? How would such information help? • What types of special OS services, if any, are used?

...............................................................................................................................................................................

...............................................................................................................................................................................

...............................................................................................................................................................................

...............................................................................................................................................................................

...............................................................................................................................................................................

...............................................................................................................................................................................