ISSN Vol.06,Issue.05, August-2014, Pages:

Transcription

1 ISSN Vol.06,Issue.05, August-2014, Pages: Improve the Performance of Content Delivery Networks Based on Distributed Control Law for Load Balancing CHITRA SIVANANDA 1, MRS.M.RADHA 2 1 PG Scholar, Dept of CS, RGMCET, Nandyala, AP, India, sivananda91@gmail.com. 2 Asst Prof, Dept of CSE, RGMCET, Nandyala, AP, India, radha.mails@gmail.com. Abstract: In this paper, we face the challenging issue of defining and implementing an effective law for load balancing in Content Delivery Networks (CDNs). We base our proposal on a formal study of a CDN system, carried out through the exploitation of a fluid flow model characterization of the network of servers. Starting from such characterization, we derive and prove a lemma about the network queues equilibrium. This result is then leveraged in order to devise a novel distributed and time-continuous algorithm for load balancing, which is also reformulated in a time-discrete version. The discrete formulation of the proposed balancing law is eventually discussed in terms of its actual implementation in a real-world scenario. Finally, the overall approach is validated by means of simulations. Keywords: Content Delivery Network (CDN), Control Theory, Request Balancing. I. INTRODUCTION A Content Delivery Network (CDN) represents a popular and useful solution to effectively support emerging Web applications by adopting a distributed overlay of servers [3] [5]. By replicating content on several servers, a CDN is capable to partially solve congestion issues due to high client request rates, thus reducing latency while at the same time increasing content availability. Usually, a CDN (see Fig.1) consists of an original server (called back-end server) containing new data to be diffused, together with one or more distribution servers, called surrogate servers. Periodically, the surrogate servers are actively updated by the back-end server. Surrogate servers are typically used to store static data, while dynamic information (i.e., data that change in time) is just stored in a small number of backend servers. In some typical scenarios, there is a server called redirector, which dynamically redirects client requests based on selected policies. The most important performance improvements derived from the adoption of such a network concern two aspects: 1) overall system throughput, that is, the average number of requests served in a time unit (optimized also on the basis of the processing capabilities of the available servers); 2) response time experienced by clients after issuing a request. The decision process about these two aspects could be in contraposition. As an example, a better response time server is usually chosen based on geographical distance from the client, i.e., network proximity; on the other hand, the overall system throughput is typically optimized through load balancing across a set of servers. Although the exact combination of factors employed by commercial systems is not clearly defined in the literature, evidence suggests that the scale is tipped in favor of reducing response time. Akamai [6], Lime Light [7], and CD Networks [8] are well known commercial CDN projects that provide support to the most popular Internet and media companies, including BBC, Microsoft, DreamWorks, EA, and Yahoo!. Several academic projects have also been proposed, like Coral CDN [9] at New York University and Co DeeN [10] at Princeton University, both running on the Planet Lab test bed. A critical component of CDN architecture is the request routing mechanism. It allows to direct users requests for content to the appropriate server based on a specified set of parameters. The proximity principle, by means of which a request is always served by the server that is closest to the client, can sometimes fail. Indeed, the routing process associated with a request might take into account several parameters (like traffic load, bandwidth, and servers computational capabilities) in order to provide the best performance in terms of time of service, delay, etc. Furthermore, an effective request routing mechanism should be able to face temporary, and potentially localized, high request rates (the so-called flash crowds) in order to avoid affecting the quality of service perceived by other users. Depending on the network layers and mechanisms involved in the process, generally request routing techniques can be classified in DNS request routing, transport-layer request routing, and application-layer request routing [11]. With a DNS-based approach, a specialized DNS server is able to provide a request-balancing mechanism based on welldefined policies and metrics [12]. For every address resolution request received, the DNS server selects the most appropriate surrogate server in a cluster of available servers and replies to the client with both the selected IP 2014 SEMAR GROUPS TECHNICAL SOCIETY. All rights reserved.

2 address and a time-to-live (TTL). The latter allows defining a period of validity for the mapping process. Typical implementations of this approach can provide either a single surrogate address or a record of multiple surrogate addresses, in the last case leaving to the client the choice of the server to contact (e.g., in a round-robin fashion). CHITRA SIVANANDA, MRS.M.RADHA nature occurring in practice. This approach is widely used in the communication and control communities (see, for example, and references therein). In a similar way, in this paper we first design a suitable load-balancing law that assures equilibrium of the queues in a balanced CDN by using a fluid flow model for the network of servers. Then, we discuss the most notable implementation issues associated with the proposed load-balancing strategy. Finally, we validate our model in more realistic scenarios by means of ns-2 simulations. Fig.1. Content Delivery Network. With transport-layer request routing, a layer-4 switch usually inspects information contained in the request header in order to select the most appropriate surrogate server. Information about the client s IP address and port (and more generally all layer-4 protocol data) can be analyzed. Specific policies and traffic metrics have been defined for a correct server selection. Generally, the routing to the server is achieved either by rewriting the IP destination of each incoming packet, or by a packettunneling mechanism, or by a forwarding mechanism at the MAC layer. With application-layer request routing, the task of selecting the surrogate server is typically carried out by a layer-7 application, or by the contacted Web server itself. In particular, in the presence of a Web-server routing mechanism, the server can decide to either serve or redirect a client request to a remote node. Differently from the previous mechanism, which usually needs a centralized element, a Web-server routing solution is usually designed in a distributed fashion. URL rewriting and HTTP redirection are typical solutions based on this approach. In the former case, a contacted server can dynamically change the links of embedded objects in a requested page in order to let them point to other nodes. The latter technique instead exploits the redirection mechanism of the HTTP protocol to appropriately balance the load on several nodes. In this paper, we will focus our attention on the application layer request routing mechanism. More precisely, we will provide a solution for load balancing in the context of the HTTP redirection approaches. In most of the papers available in the literature, the design of a proper network management law is carried out by assuming a continuous fluid flow model of the network. Validation and testing are then provided by exploiting a discrete packet simulator (e.g., ns-2, Opnet, etc.) in order to take into account the effects of discretization and nonlinear We present a new mechanism for redirecting incoming client requests to the most appropriate server, thus balancing the overall system requests load. Our mechanism leverages local balancing in order to achieve global balancing. This is carried out through a periodic interaction among the system nodes. The rest of this paper is organized as follows. Content Delivery Networks in Section II Section III discusses the Literature Survey IV proposes an in-depth discussion of the most critical features of our solution. Finally, Section V concludes the paper by providing final remarks, as well as some pointers to open issues and related directions of future investigation. II. CONTENT DELIVERY NETWORKS Global CDNs are typically implemented as a distributed network of servers hosting replicated content. Servers may be located at geographically-diverse data centers, providing content to users in a given region. Web clients issue requests to fetch content from the CDN, which are satisfied by content servers according to a particular mapping strategy. A goal of the CDN is to minimize total request time, i.e., the time until a client has successfully retrieved desired content. Load awareness. For a CDN to be load-aware there must be a mechanism that balances load between content servers. This may be the done by, for example, distributing requests uniformly across all content servers or redirecting requests to the least-loaded server If content requests go to overloaded servers, clients experience poor performance. In our model, we distinguish between load balancing for computational load and network congestion. (1) Computational load at a content server is caused by the processing associated with content requests. This involves request parsing, retrieval of cached content if there is a cache hit and content delivery to the client. (2) Network congestion is caused by the limited capacity of network paths to carry traffic. This creates bottleneck links that determine the throughput at which content can be delivered to clients. Considering the Internet path from client to server, the bottleneck may be: (a) at the client's access link, in which case only the performance of this client is affected and the CDN cannot provide any remedy; (b) at the client's upstream ISP or Internet backbone, affecting a larger number of clients. Here, the choice of a different content server may lead to improved performance; (c) at the

3 Improve the Performance of Content Delivery Networks Based On Distributed Control Law for Load Balancing content servers' access link, affecting all client requests to this server. In this case, the CDN should redirect requests away from the congested server. Locality awareness A CDN is locality-aware if network paths are kept short. For example, a CDN can take request origins into account and return content from nearby servers with low load. Proximity may be defined in terms of geographic distance, latency, number of routing hops or overlap between address prefixes. By minimizing network path lengths, clients are more likely to experience better QoS. Intuitively, this is because: (1) short paths offer low latencies. This helps TCP obtain high throughput quickly therefore reducing transmission times for small content; (2) short paths are less likely to encounter congestion hotspots, resulting in improved throughput; (3) short paths tend to be more reliable as they involve fewer network links and routers; (4) short paths decrease overall network saturation, leaving more spare network capacity for other traffic. It is challenging to design a CDN that makes a trade between load- and locality-awareness simple CDNs that always redirect clients to geographically-closest content servers lack load-balancing and suffer from overload when local con-tent popularity increases. More advanced CDNs that are based on distributed hash tables (DHTs) primarily focus on load-balancing. They use network locality only as a tiebreaker between multiple servers, leading to suboptimal decisions about network locality. State-of-the-art CDNs such as Akamai are proprietary, with little public knowledge on the types of complex optimizations that they perform. the bottleneck problems and the most promising are based on the awareness of the content that has to be delivered. The traditional content-blind network infrastructures are not sufficient to ensure quality of service to all users in a dynamic and ever increasing traffic situation. New protocols and integrated solutions must be in place both on the network and on the server side to distribute, locate and download contents through the Internet. The enhancement of computer networks by means of a content aware overlay creates the new architectural paradigm of the CDN. Today s CDN act upon the traditional network protocol stack at various levels, relying on dynamic and proactive content caching and on automatic application deployment and migration at the edge of the network, in proximity to the final users. Content replicas in a CDN are geographically distributed, to enable fast and reliable delivery to any end-user location: through CDN services, up-to-date content can be retrieved by end-users locally rather than remotely. CDNs were born to distribute heavily requested contents from popular web servers, most of all image files. Nowadays, a CDN supports the delivery of any type of dynamic content, including various forms of interactive media streaming. CDN providers are companies devoted to hosting in their servers the content of thirdparty content providers, to mirroring or replicating such contents on several servers spread over the world, and to transparently redirecting the customers requests to the best replica (e.g. the closest replica, or the one from which the customer would access content at the lowest latency). In this paper, we describe a new type of CDN that uses load-aware network coordinates (LANCs) to capture naturally the tension between load and locality awareness. LANCs are synthetic coordinates (calculated using a metric embedding of application-level delay measurements) that incorporate network location and load of content servers. Our CDN uses LANCs to map clients dynamically to the most appropriate server in a decentralized fashion. Popular content is replicated among nearby content servers with low load. By combining locality and load using the unified mechanism of LANCs, we simplify the design of the CDN and discard the need for ad-hoc solutions. III. LITERATURE SURVEY The commercial success of the Internet and e-services, together with the exploding use of complex media content online has paved the way for the birth and growing interest in Content Delivery Networks (CDN). Internet traffic often encounters performance difficulties characteristic of a non dedicated, best effort environment. The user s urgent request for guarantees on quality of service have brought about the need to study and develop new network architectures and technologies to improve the user s perceived performance while limiting the costs paid by providers. Many solutions have been proposed to alleviate Designing a complete solution for CDN therefore requires addressing a number of technical issues: which kind of content should be hosted (if any) at a given CDN server (replica placement), how the content must be kept updated, which is the best replica for a given customer, who mechanisms must be in place to transparently redirect the user to such replica. A proper placement of replica servers shortens the path from servers to clients thus lowering the risk of encountering bottlenecks in the nondedicated environment of the Internet. A request redirection mechanism is provided at the access routers level to ensure that the best suited replica is selected to answer any given request of possibly different types of services with different quality of service agreements. The CDN architecture also relies on a measurement activity that is performed by cooperative access routers to evaluate the traffic conditions and the computational capacity and availability of each replica capable of serving the given request. Successfully implemented, a CDN can accelerate end user access to content, reduce network traffic, and reduce content provider hardware requirements. IV. SYSTEM EVALUATION The effectiveness of our algorithm is evaluated through a simulation-based comparison with the most interesting existing techniques (both static and dynamic). We provide

4 extensive simulation tests by using the ns2 network simulator.2 since no suitable tool for CDN simulation is provided with the standard simulator package; we introduced a new library to support such a scenario. CHITRA SIVANANDA, MRS.M.RADHA qualitative evaluation of the solution proposed with respect to the existing algorithms. In we will demonstrate that the results herein achieved can be extended to larger scale topologies due to the high scalability of our solution. A. Balancing Performance The simulations for the comparative analysis have been carried out using the network topology. We suppose to have 10 servers connected in the overlay, as well as 10 clients, each of them connected to a single server. We model each server i as an M/M/1 queue with service rate µ i, and the generation requests from client i as a Poisson process with arrival rate λ i. Fig.2. Queue length behavior (T = 0.5s). (a) RAND. (b) RR. (c) LL. (d) 2RC. (e) CLB. TABLE I: Servers Parameters In order to correctly evaluate the capability of the algorithms to balance the load among the servers, we suppose different initial conditions for each of them by setting different initial queue lengths, q i (0) = q i0. Furthermore, we consider a critical scenario of a saturated network characterized by (1) Such an assumption allows us to test the balancing algorithm in a critical network condition. In Table I, we report the values used in the simulations. Moreover, in a scenario characterized by initial load conditions similar to those indicated in Table I, with arrival rates λ i = λ = 7 req/s and service rates µ i = µ = 10 req/s, we also simulate a flash-crowd phenomenon by increasing the arrival rate λ 7 to 200 req/s in the time interval t 0 = 200s and t 1 = 250s. We observe that the above scenarios represent simplified deployments when compared to a realistic CDN topology. Though in this section, we exclusively want to provide a We implemented the Random (RAND) and the Round Robin (RR) static algorithms, as well as the Least Loaded (LL) and the Two Random Choices (2RC) dynamic algorithms to make a comparison to our solution [Control- Law Balancing (CLB)]. Then, for each algorithm, we first evaluated each server s queue length behavior over time, together with the average value among all servers. Such a parameter represents an excellent indicator of the request distribution degree achieved by the CDN. Another important parameter is the Response Time (RT), which evaluates the efficiency of the algorithm in terms of enduser s satisfaction. For such a parameter, we evaluated both the average value and the standard deviation σ RT. We also introduce an Unbalancing Index to estimate the capability of the algorithms to effectively balance requests among the available servers. Such an index is computed as the standard deviation of queue lengths of all the servers over time; clearly, the lower such value, the better the balancing result. Finally, since some of the proposed mechanisms provide multiple redirections, we also considered a parameter associated with communication overhead due to the redirection of a single request. Such a parameter is computed as the ratio of the number of requests due to redirections to the overall number of requests injected into the system. Fig.2 shows the simulation results related to the profiles of each server s queue length with an update interval T equal to 0.5s. As expected, static mechanisms provide worse performance since servers queue lengths exhibit unpredictable behaviors due to a lack of knowledge about the real status of the server loads. On the other hand, dynamic mechanisms provide better behaviors, and in particular, our solution clearly achieves the best performance since it limits both the number of enquired requests and their oscillations over time, thus reducing the impact on delay jitter. This confirms the effectiveness of the proposed mechanism, as well as its capability to fairly distribute load among the servers. Fig.3. Queue length behavior (T = 1s). (a) LL. (b) 2RC. (c) CLB.

5 Improve the Performance of Content Delivery Networks Based On Distributed Control Law for Load Balancing mechanisms. Also in this case, our solution shows excellent results when compared to the other proposals. This is confirmed by the values in Table III, where we again observe the advantages deriving from the adoption of our algorithm. TABLE IV: Performance Evaluation With Flash- Crowd (T = 05s) Fig.4. Queue length behavior in the presence of a flash crowd (T = 05s). (a) LL. (b) 2RC. (c) CLB. TABLE II: Performance Evaluation (T = 05s). The quality of our solution can be further appreciated by analyzing the performance parameters reported in Table II. As it comes out from the table, the average queue length value is the lowest among the analyzed algorithms. The proposed mechanism also exhibits an excellent average Response Time, which is only comparable to the value obtained by the 2RC algorithm. The value associated with σ RT is also fairly low. The excellent performance of our mechanism might be paid in terms of a significant number of redirections. Since the redirection process is common to all the algorithms analyzed, we exclusively evaluate the percentage of requests redirected more than once over the total number of requests generated. By simulations we verify that multiple redirections happen for about 33% of the total requests served by the CDN, in a normal operational scenario. This problem can clearly be mitigated by limiting the number of redirections for each request. TABLE III: Performance Evaluation (T = 1) Coming to the flash-crowd scenario, simulations once again demonstrate how our solution outperforms the analyzed competitor algorithms both in terms of response time and average queue length, as it can be appreciated by looking at the data reported in Table IV. Even more interestingly, Fig.4 clearly shows how CLB is the best algorithm in terms of capability to recover from the overload situation due to the presence of excess traffic generated during the flash-crowd interval. In fact, as it comes out from the pictures, the 2RC algorithm hardly succeeds in reachieving the steady state condition prior to the flash Fig.5. Unbalancing index behavior. TABLE V: Unbalancing Index However, we show how the multiple redirections phenomenon does not affect the actual performance of our algorithm. In Fig. 3 we report the queue dynamics for an interval T of 1s. We exclusively considered the dynamic algorithms since the variation of the interval update does not affect the overall performance of the static crowd. On the other hand, the LL and the CLB approaches both react quite effectively to the transient abnormal conditions by quickly bringing back queue occupancies to their steady-state levels. However, this is achieved by the

6 CLB with a fairer balancing among the available servers, as it is further confirmed by the analysis of the unbalancing index in Table V. In fact, in such a table we report the values of the unbalancing index analysis for both the normal and the flash-crowd scenarios. We point out once again the low degree of unbalancing exhibited by our solution with respect to the evaluated counterparts. Such a result confirms that the algorithm provides an optimized balancing mechanism. A thorough analysis of the unbalancing index behavior as a function of the update interval T is carried out in Fig. 5, which reports results achieved with the 10 nodes topology of, which employs the 2RC, the LL, or our CLB algorithm. In particular, we observe that the performance of the CLB is definitely much higher than the one achieved by the 2RC, as well as always better than the LL, which nonetheless represents the best performing competitor. As a final consideration, we point out that our solution outperforms the mentioned LL algorithm also with respect to queue stabilization, thus reducing jitter delay in the CDN, as already remarked when commenting on the results in both Figs.3 and 4. The selection of an appropriate interval value can obviously be done by considering the trend of the unbalancing index over time. B. Scalability Analysis Before providing the testing results, we briefly discuss the scalability properties of the algorithm in terms of overhead introduced by the status update process. By adopting a local data exchange, we can considerably reduce the amount of overhead traffic produced with respect to a solution requiring data exchanging across the whole network. TABLE VI: Network Degree CHITRA SIVANANDA, MRS.M.RADHA number of logical links connecting the cooperating servers. In the case of the proposed algorithm is the average degree of a network (corresponding to a logical average number of neighbors) that in a realistic network topology scales as a power law with value between 3 and 4. On the other side, the global balancing approach, which requires the exchange of status information with all the nodes N, is logically assimilated to a full-mesh topology. In this scenario, the worst case of logical average neighbor s number occurs with linearly dependent on the number of nodes (N): = N-1. In any case, even if more sophisticated mechanisms, such as flooding, might be implemented for the global data dissemination process, the total number of packets exchanged, as well as their size, increases as long as the network grows in size. The results show the advantages of using a local information exchange with respect to providing all nodes with status information. In order to confirm such theoretical results, we generated several scale-free network topologies by using the BRITE topology generator. We evaluated by simulations the scalability of our solution by adopting the Barabási Albert model to generate several topologies with an increasing number of nodes (from 5 to 25 nodes, with an increasing step of 5 nodes between each pair of subsequent topologies). Furthermore, we considered an update interval T varying in the set {0.5s, 1s, 1.5s, 20s. We also made sure that the traffic parameter varied according to (1). First, we have evaluated the rate of control packets at every node due to the server status update process. Clearly, such a rate decreases as long as the interval T increases. In Fig.6, we have reported the average control rate corresponding to different network sizes. We also report the expected value based on (2) for each topology generated. We observe a limited increase in Considering a fixed packet size, the amount of data exchanging for the implemented algorithm exclusively depends on the average number of neighbors at each server. The average neighbor s number can be estimated by the degree of the network Where L is the number of links connecting the servers and N the total number of servers. For example, in Table VI, we observe a constant value for ring topologies and an asymptotical behavior for the chain. We remark that the average control data rate can be analytically estimated through (2), supposing that L is the (2) Fig.6. Control data rate. the rate for each interval T with an increasing number of nodes. In particular, the results for T = 1s exactly match

7 Improve the Performance of Content Delivery Networks Based On Distributed Control Law for Load Balancing the value estimated by formula (2). Such results confirm that the traffic due to algorithm control data has no strict dependence on the size of the network. Furthermore, the capability of our solution to properly scale is also evaluated by analyzing the impact of an increasing request load on the CDN in terms of response time, which, as already said, does represent a very good measure of the Quality of Experience of the CDN users. In particular, we have progressively increased the request rate while maintaining a fixed service rate at all servers in the network. Furthermore, we have also considered increasing network topology sizes. We have adopted an initial request rate λ = 0.8[req/s] and a service rate µ = 10[req/s]. The simulations consider an interval T of 0.5 and 2.0 s, respectively. The results of simulations are depicted in Fig. 7, showing Response Time as a function of the arrival rate, which has been properly scaled in subsequent simulations as follows: λ =s.λ 0, with λ 0 = 0.8 and s = In both graphs, we observe a very limited increase in average response time for each request load value, except for a request rate equal to10λ 0, in which case the request rate approximates the service rate, thus bringing the overall system towards instability. We also observe that the value of is unaffected by network size increases, which confirms the correctness of our solution. Finally, in Fig. 8 we present an analysis of the Response Time as a function of a so-called Scale Factor, obtained by properly scaling with equal factors both the arrival rate λ (whose starting value has been set to 0.8 [req/s]) and the network size, in terms of number of nodes N (whose initial value has instead been set to 5 nodes). The picture shows that if we keep the pace of increase of the arrival rate by properly scaling the number of nodes in the CDN, the average Response Time remains almost constant, which is by definition a scalability property of the overall system we designed and presented in the paper. Fig.7. Scalability with respect to load (a) T = 0.5s (b) T =2.0s. Fig.8. Overall system scalability. V. CONCLUSION AND FUTURE WORK In this paper, we presented a novel load-balancing law for cooperative CDN networks. We first defined a model of such networks based on a fluid flow characterization. We hence moved to the definition of an algorithm that aims at achieving load balancing in the network by removing local queue instability conditions through redistribution of potential excess traffic to the set of neighbors of the congested server. The algorithm is first introduced in its time-continuous formulation and then put in a discrete version specifically conceived for its actual implementation and deployment in an operational scenario. Through the help of simulations, we demonstrated both the scalability and the effectiveness of our proposal, which outperforms most of the potential alternatives that have been proposed in the past. The present work represents for us a first step toward the realization of a complete solution for load balancing in a cooperative, distributed environment. Our future work will be devoted to the actual implementation of our solution in a real system, so to arrive at a first prototype of a load-balanced, cooperative CDN network to be used both as a proof-of-concept implementation of the results obtained through simulations and as a playground for further research in the more generic field of content-centric network management.

8 CHITRA SIVANANDA, MRS.M.RADHA VI. REFERENCES [1] Sabato Manfredi, Member, IEEE, Francesco Oliviero, Member, IEEE, and Simon Pietro Romano, Member, IEEE, A Distributed Control Law for Load Balancing in Content Delivery Networks, IEEE/ACM Transactions on Networking, Vol. 21, No. 1, February [2] S. Manfredi, F. Oliviero, and S. P. Romano, Distributed management for load balancing in content delivery networks, in Proc. IEEE GLOBECOM Workshop, Miami, FL, Dec. 2010, pp [3] H. Yin, X. Liu, G. Min, and C. Lin, Content delivery networks: A Bridge between emerging applications and future IP networks, IEEE Net w., vol. 24, no. 4, pp , Jul. Aug [4] J. D. Pineda and C. P. Salvador, On using content delivery networks to improve MOG performance, Int. J. Adv. Media Commun., vol. 4, no. 2, pp , Mar [5] D. D. Sorte, M. Femminella, A. Parisi, and G. Reali, Network delivery of live events in a digital cinema scenario, in Proc. ONDM, Mar. 2008, pp [6] Akamai, Akamai, 2011 [Online]. Available: Com/index.html. [7] Limelight Networks, Limelight Networks, 2011 [Online]. Available: [8] CD Networks, CD Networks, 2011 [Online]. Available: [9] Coral, The Coral Content Distribution Network, 2004 [Online]. Available: [10] Network Systems Group, Projects, Princeton University, Princeton, NJ, 2008 [Online]. Available: [11] A. Barbir, B. Cain, and R. Nair, Known content network (CN) request-routing mechanisms, IETF, RFC 3568 Internet Draft, Jul [Online]. Available: [12] T. Brisco, DNS support for load balancing, IETF, RFC 1794 Internet Draft, Apr [Online]. Available: Author s Details: Chitra Sivananda DEPT: CSE, M.Tech BRANCH: CS, Rajeev Gandhi Memorial College of Engineering & Technology (Autonomous) (RGMCET), Nandyala, sivananda91@gmail.com. Mrs. M.Radha, M.Tech, Asst professor, DEPT: CSE, Rajeev Gandhi Memorial College of Engineering & Technology (Autonomous) (RGMCET), Nandyala, id: radha.mails@gmail.com