Optimizing the Grid for Critical healthcare services

Sudeepta Das, M.E. Computer Science, BITS Pilani, India [email protected]

Vikas Agrawal, M.Sc. (Hons.) Chemistry, BITS Pilani, India [email protected]

Abstract

various network parameters in the fabric layer and then mapping them to application level functions.

One of the few known challenges in Quality of Service (QoS) aware Grid computing is to device a mechanism which enables Grid applications requiring QoS support. We propose a method to enable grid middleware to inform the user of the present status of the services and actively assure the service level. To provide Application Layer QoS, the middleware should provide higher level abstractions that are used to request desired level services. The network/system parameter values are obtained from Management Information Base (MIB) of various nodes and mapped to quantitative values or qualitative levels of service which is used by the middleware to assure desired service. Simple Network Management Protocol (SNMP) is used to collect the varied parameter valued from the MIB’s. The inherent extensibility of SNMP allows adding more monitoring parameters as per requirements and helps to set the traffic class values that control traffic mechanisms at the router.

Section II provides a brief overview of QoS and discusses related issues. Section III describes the problem and the solution that we propose along with a brief description of the test-bed. Section IV discusses our results and analysis for different scenarios and demonstrates the benefits of dynamic traffic control policy.

2. Quality of Service Initially all networks used to run on a “Best Effort” system with no QoS measures. However, there were many things that could happen to packets as they traveled from origin to destination and that resulted in the problems [1], [2], [3] like dropped packets, delay and out of order delivery.

1. Introduction We have tried to investigate the problem of providing essential health services. The immense spread of a country like India makes it difficult to provide public services that can claim to uniformity in their standards. The aim is to provide a ubiquitous, low cost solution keeping in mind the various aspects of the problem. The application layer of the grid middleware provides an interface to the users who need not know the underlying mechanisms. In studies related to the problems faced by users of Grids [4], it has been found that users would like to have more control over the type of service they get without being involved in the actual working of the lower layers. Providing QoS in this scenario requires the acquisition and analysis of

Figure 1. QoS Levels While referring to Grids and hence the fabric layer, which also provides multimedia services, the concept of QoS not only involves the network performance characteristics but also end-to-end systems. Figure 1 shows the abstracted view of the common elements of

these architectures to support end-to-end QoS. The user perception parameter needs to be mapped to lower level parameters • Application QoS parameters include media quality, end-to-end delay requirements, inter/intra stream synchronization and others derived from user’s QoS specifications. • System level QoS has two components. 1: Device level QoS specifies timing and throughput requirements. 2: Network QoS parameters, which include Timeliness (Delay, Response Time, Jitter), Bandwidth (System Level and Application Level data rate, Transaction rate), and Reliability. Also enforcement of a global SLA (Service Level Agreement) requires that the local SLA’s are first satisfied. This is an important issue in grids [4] because grids are composed of various sub-networks which may have their own QoS demands and these need to be collated and combined.

3. Design Network characteristics for Grids can either be obtained directly from the values extracted from the MIB or may be derived from these values.

Figure 2. Case Diagram for ip group of MIB - II MIB has various groups dealing with protocols that include IP, TCP and UDP. We shall consider the IP group to show the QoS metrics that we can derive using. Figure 2 shows the case diagram for some of the IP group identifiers. We can observe that ipInReceives = ipInHdrErrors + ipInAddrErrors + ipReasmReqds + ipForwDatagrams – ipReasmOKs + ipInDiscards + ipInUnknownProtos + ipInDelivers. a: The terms ipInHdrErrors, ipInAddrErrors denote

header and address errors giving an indication of the number of errors. b:The ipReasmReqds object identifier is a count of the IP fragments received at the entity which had to be reassembled. This is an indication of the proportion of traffic that has to undergo fragmentation which is an overhead and adds to the delay. c: The ipReasmFails value is an indicator of the reliability of the network since the IP packets that failed reassembly were probably tampered before reaching the entity. In the Interfaces group we have object identifiers like ifOutQLen indicating the length of the output queue at the interface, ifSpeed giving an estimate of the interface’s current data rate capacity and error object identifiers which give a count of the various types of errors. Thus we are able to get information which form the basis for defining measures of availability, reliability, error rate, delay and other network QoS measures. This information after being extracted needs to be mapped so that the users can interpret the data in terms of proportions and qualitative measures. There needs to be a standardization in defining qualitative levels which is possible in this case since MIB II values are the uniform basis. The following steps define the manner in which our approach seeks to obtain, analyze and utilize these values. 1: The application level users are provided with functions and APIs that can be used to request QoS levels which are defined in qualitative terms. The middleware maps these user specified levels to exact quantitative values as threshold measures. The request sent by the user to the grid manager for the job is thus sent along with this information. 2: The manager already has some previously stored minimal information about the nodes that have been authenticated and joined the grid. 3: The middleware on each node records the MIB values at intervals which may be periodic or defined while configuration. It’s assumed that the nodes that join the grid would allow the querying of its middleware by the manager. 4: The packets being sent have their DSCP(Differentiated Service Code Point) values set so that all intermediate nodes will provide a differentiated service if they are compliant. 5: The information that is received by the manager is used by it to classify traffic according to the best possible manner to achieve the desired levels of QoS. The last step involves traffic control which implies the actions that need to be taken to classify, mark,

meter, drop and shape IP packets based on the policy being followed. This can be done through the tc tool. The desired level of performance for a particular flow is specified by the user or the default values are set by the middleware. A file is generated by the middleware after using the parameter values extracted through SNMP to map to quantitative values. These are used as parameters by the tc tool to fulfill the requirements for the corresponding flow.

by seeking the fabric QoS metrics from manager at regular intervals. 5: On violation, middleware informs manager. Workflow at Grid Manager: 1: Receive query from node about desired QoS availability and provisioning. 2: Check user credentials, service status and Grid network’s present performance status to see if the desired QoS is feasible and reply. 3: Signal all intermediate routers with appropriate parameters based on the application’s requirements if changes have to be made in traffic control policies for the new traffic that the application will generate. 4: If Grid node reports some violation, signal routers with modified parameters. Workflow at routers: 1: On receiving values from Grid manager, check if traffic control policy needs to be modified. 2: If yes, then implement this change dynamically. 3: Police traffic and shape as per the new policy by reading the appropriate packet fields.

Figure 3. Design architecture Figure 3 shows the architecture in which Fabric QoS parameters are extracted and mapped to Application QoS. The traffic control done at the intermediate nodes cannot always be under the control of the grid since they can be part of the global Internet. But the end routers which lie in the sub network that is a part of the Grid can be predictably configured and controlled so that we have localized QoS frameworks. These localized frameworks coalesce to provide a global QoS whenever DiffServ enabled routers are traversed. Data grids which transact heavy multimedia traffic stand the most to gain when all intermediate network routing entities become DiffServ capable. Workflow at user node: 1: Node enters the Grid after authentication and registering with the Grid Authorization manager 2: The application that seeks QoS informs the middleware some well defined values in QoS metric terms like packet loss, delay, and throughput. 3: The middleware component on the node checks to see if the requested QoS can be provided based on the user’s credentials and Grid’s capabilities. On positive confirmation from the manager, the application is allowed to use the Grid’s resources else the application is informed of the lack of requisite QoS guarantee. 4: After the job starts executing, the middleware has to keep on checking if the assured QoS is being provided

4. Results and Analysis We have set up a test-bed of nodes running on Linux and Windows platforms. The routers have been configured for traffic control. We have created functions that need to be merged with the middleware. They provide functionalities of extracting MIB information using SNMP, setting values in the MIB, giving the user the means to specify QoS requirements, generate files that are sent to routers to configure traffic control at intermediate intervals.

Figure 4. Experimental Test-bed All the experiments were done by sending traffic between Host A – Host B and Host A – Host C. OpenIMP tool was used to measure the various characteristics of One-way delay, delay distribution and jitter with the traffic being monitored at the interfaces of DS-Router 2 and DS-Router 3. MGEN

was used to generate traffic flows while ICMP ping packets were used to measure delays and average packet losses at various intervals to check the Grid network’s state. We used time synchronization to get consistent results by reducing the skew in the clocks of the various Grid nodes and routers. We shall discuss four cases and validate the conclusion that dynamically varying the traffic control policy based on results obtained by monitoring interface and protocol metrics as provided by MIB-II leads to improved application and fabric layer QoS. CASE 1: In this experiment we sought to see the performance of the network when 5 different streams are transmitted from Host B to Host A with a total bandwidth of 10Mbps. Since this is same as the bandwidth offered between the routers and well below 100Mbps capacity of the links connecting the hosts to the routers the very low delay was expected. We observed that the minimum delay and average delay are almost same which is what should be the case when traffic is sent without interference on adequate capacity networks. CASE 2: This experiment was conducted using 2 streams, of which one was multimedia traffic while the other was normal periodic traffic. The bandwidth required is 12Mbps which is greater than 10Mbps link capacity and hence the delays increase as compared to experiment 1. The multimedia traffic being Periodic with regular bursts, it was expected the delays would increase abruptly at burst instances when the traffic bandwidth required would be much greater than that available. The queuing delays increase and average delay shoots up. Table 1 is the traffic profile. Table 1. Traffic profile for Case 2 Stream

Type

Rate (pkts/s)

Size(bytes)

Multimedi a

Periodic

4500

1024

Burst(4.5s)

4500

1024

Normal

Periodic

3000

1024

Figure 5 shows the one-way delay over a period of 3 minutes with the burst instances being observable by the peaks at regular intervals. Some packet loss was also observed at such bursts when the queue lengths proved to be inadequate to sustain the incoming flows. Thus it can be observed that some sort of traffic control is required if we are to assure QoS for a flow. If bandwidth were to be reserved for the second flow in this experiment, none of its packets would have suffered increased delay when the multimedia flow demonstrated bursts.

Figure 5. One-Way Delay for 3 min period for multimedia and a normal traffic CASE 3: This experiment was conducted using 2 streams, of which one was multimedia traffic while the other was normal Poisson traffic. The bandwidth required is 13Mbps which is greater than 10Mbps link capacity and hence the delays increase as compared to experiment 1. The multimedia traffic being Periodic with random bursts, it was expected the delays would increase abruptly at burst instances when the traffic bandwidth required would be much greater than that available. The queuing delays increase and average delay shoots up. Table 2 is the traffic profile. We implemented static traffic control at the router. Three classes were created under root, multimedia traffic being filtered to first class (sfq) with higher priority and 60% of available bandwidth, normal traffic to next class (tbf) with 20 % of available bandwidth(not bounded), and rest traffic to third default class. Table 2. Traffic profile for Case 3 Stream

Type

Rate (pkts/s)

Size(bytes )

Multimedi a

Periodic Burst (randomized)

4500

1024

5000

1024

X1 (dest. port:5454)

Periodic

3500

1024

The TOS field of the packets was used to filter the flows and assign them to different classes. The orange stream is the bursty traffic while the red stream is a non-bursty one. When there is a burst in orange flow, the delays increase for both the flows. As we observed in experiment 2, these bursts would often lead to packet losses. We also wanted that red traffic should not have delays beyond a certain threshold. So it was assigned a higher priority through the traffic control policy at the routers. This led to higher packet losses for orange flow because the red packets would get

queued and transmitted earlier and thus the QoS guarantee of low delay and negligible packet loss was maintained.

buffer size for the class containing orange traffic. Thus we can see that its burst delays spreads and increases slightly and packet losses too decrease as a result of this. The burst delay for orange traffic is now seen to be of the magnitude of 90 milliseconds instead of the average 150 milliseconds witnessed in static traffic control experiment.

5. Conclusion

Figure 6 One Way Delay for two different traffic streams after being shaped

CASE 4: The traffic profile is same as that of Experiment 3. As we saw in experiment 3, statically setting the traffic policy helps in ensuring the QoS for a particular stream. But since we are speaking of a heterogeneous environment where the user levels may change dynamically and new nodes with varied QoS requirements join the Grid from time-to-time, traffic policy also needs to reflect this dynamic character that is inherent in such cases. For example, suppose the orange stream, which was earlier getting the lowest grade of QoS, suddenly becomes eligible for higher QoS due to the improvement in the Grid membership grade of the node receiving it then there needs to be a way to change the traffic control rules at the routers.

A problem of interest in the area of distributed processing and dynamic Grid provisioning in the context of healthcare Grid, has been examined. The idea leads to a breakthrough in delivering specialized consultation (via Video conferencing/ Textual conversation/ Image Analysis) and First Aid utilizing urban resources by collecting data , getting it processed and served by specialists in related field. The project has illustrated requirements and delivery of QoS whenever desired. The crucial part is to integrate these technical breakthroughs in the interest of participating players in healthcare, physicians, healthcare centers, administrators, and common mass. Our experimental results show that our approach is a viable and cost effective way to increase the reliability and throughput of multimedia and other prioritized transactions.

Acknowledgement The authors would like to thank Dr Rahul Banerjee, the Co-ordinator for Centre for Software Development (CSD), BITS Pilani, India for the guidance in developing and testing the framework proposed, the members of Project GridOne Team for their help and the CSD staff for their cooperation.

References Figure 7. Case 3 with Dynamic shaping The SNMP monitoring data that is collected by the Grid manager gives account of various performance metrics related to the interfaces and protocols. In this experiment, when the manager realizes that overall traffic is witnessing excessive packet losses due to the current traffic policy it signals the routers to change the policy. In this case, host A which we have assumed to be a virtual manager in our test bed scenario, sends a file to the routers with the new parameters that is utilized by a script running at the routers to increase

[1] Sanjay Jha, Mahbub Hassan, “Engineering Internet QoS”, Artech House Inc. 2002. [2] Lowekamp, Swany et al., A Hierarchy of Network Performance Characteristics for Grid Applications and Services, GFD-R-P.023 (Proposed Recommendation), May 2004. [3] Volker Sander, Networking Issues for Grid Infrastructure, GFD-I.037,Grid High Performance Networking Research Group,November 2004. [4] D.Menasce, E Cassalicchio, “Quality of Service Aspects and Metrics in Grid Computing”, Proceedings of Computer measurement Group Conference, Las Vegas, December 2004.