International Journal of Research and Reviews in Next Generation Networks (IJRRNGN) Vol. 1, No. 2, December 2011, ISSN: 2046-6897 © Science Academy Publisher, United Kingdom www.sciacademypublisher.com
44
Scalability and Signaling Architecture Sivasothy Shanmugalingam1, Noel Crespi2 and Paul Labrogere 3 1,2 1,3
Institut Telecom, Telecom SudParis, 9, rue Charles Fourier, 91011, Evry, France Alcatel-Lucent Bell Labs France, Centre de Villarceaux, 91620, Nozay, France.
Abstract – Scalability is an important aspect in the Web 2.0 era where services need to be massively scalable. Building massive scaled services without failure and complexity is a challenging task. Meanwhile, in practice, communication services consist of two layers: signaling layer and media layer. The signaling architecture should be scalable when a number of users and calls keep on increasing. However, scalability is not well-defined for the signaling architecture and is considered as an afterthought. The main goal of this paper is to characterize the scalability aspect for the signaling architecture and present an analytical comparison of the existing signaling architectures – IP Multimedia Subsystem (IMS)/ Session Initiation Protocol (SIP), Peer-to-Peer (P2P) SIP, along with our new signaling architecture, My Own Communication Service Provider (MOCSP). Keywords – Scalability, Signaling Architecture, Performance
1.
Introduction
In the Web 2.0 era, Web-based services should be Internet-scale services in order to accommodate many requests in an instant across the world. However, building massively scaled services without failure and complexity is a challenging task [1]. Communication services such as video/voice-over-IP are developed using two layers: signaling and media layer. The signaling layer facilitates session establishment (and termination) between users. Therefore, the signaling architecture supports signaling message routing between origin and destination. In addition, the signaling architecture may host services, for example Back-to-Back User Agent in IMS. The media layer transports different media between users as decided by the signaling protocol. The architecture for the signaling layer should be scalable when a number of users and calls keep on increasing. Another factor is also the call holding time (how long the call exists). The term scalability has been defined based on the context in the literature [1], [2]. To the best of our knowledge, we did not find any definition for scalability that is linked with a signaling architecture. Therefore, we consider four parameters to characterize the scalability aspect for a signaling architecture: how scalable, complexity level, needed computing resources and session setup latency. Our intention is to consider a signaling architecture as a whole, not an individual component in the signaling architecture. How scalable means that up to which point a signaling architecture performs without failure. For example, architecture will work as long as any number of users is added into the architecture. This means that what factor limits scalability. Complexity level means that when a call rate varies, any new functional entity should be added into the architecture and how easy to coordinate all the entities to accomplish goals. Needed computing resources refer to the overall system
costs in terms of computing resources (e.g. CPU, and memory). Session setup latency is an important parameter for communication services. This parameter enables to show how latency is influenced during the scale up and down. Based on the above listed parameters, we compare the signaling architectures while they experience low to high call rates (billions per second). These signaling architectures are assumed to serve the entire population of the world (assume 6+ billions). In this paper, we analytically compare existing architectures, IMS, P2P SIP, along with our new signaling architecture based on My Own Communication Service Provider (MOCSP). The rest of the paper is organized as follows: Section 2 discusses existing approaches for scaling up the signaling architecture based on IP Multimedia Subsystem (IMS), followed by a scalability analysis with the four defined parameters. Similarly, we analyze scalability in Peer-to-Peer (P2P) Session Initiation Protocol (SIP) in Section 3. We leverage our MOCSP system [3] for a high call rate (e.g. 3 billion calls per second) and a higher number of users severed. Section 4 discusses of the MOCSP proposal. This is followed by a scalability analysis based on MOCSP. We conclude in Section 5 with suggestions for future work.
2.
IP Multimedia Subsystem (IMS)
2.1. Introduction The Third Generation Partnership Project (3GPP) has specified the IP Multimedia Subsystem (IMS) as an architectural framework for delivering multimedia services [4]. The IETF protocol, Session Initiation Protocol (SIP) was chosen as a signaling protocol in IMS. SIP is a transactionbased protocol that is designed to establish and tear down media sessions between end points [5]. The IMS signaling architecture is grouped into two layers, a service control layer and a service layer. We describe each
S. Shanmugalingam et al. / IJRRNGN, Vol. 1, No. 2, pp. 44-50, December 2011
layer and point out our particular interest. With IMS, we are most interested in the architecture shown in Figure 1 in which entities are involved in executing network-based session services, for example user mobility [6]. Figure 1 also shows two different administrative regions that are marked with suffix 1 and 2 in proxies.
Figure 1. IMS architecture connecting two differ administrative domains (suffix 1 and 2)
2.1.1. Service Control Layer This layer is responsible for routing, address resolution, accounting and authentication, as well as registration/location and session management. These functions are deployed in proxies that are shown in Figure 1. Even though some other factors (ex. a location server) may impede the scalability in the service control layer, we are only concerned with the routing aspect here. To route SIP requests from SIP User Agent (UA)1 to SIP UA 2 (similar to caller and callee in Figure 1), IMS specifications have defined three proxies, P-CSCF, I-CSCF, and S-CSCF. I-CSCF is not shown in Figure 1. These SIP proxies perform host discovery, routing, maintaining states (for retransmissions, accounting etc.) and authentication. During a UA registration process, I-CSCF assigns the SCSCF. Thereafter, P-CSCF sends the SIP messages directly to the S-CSCF. In this case, I-CSCF behaves like a load balancer. This is different from the dynamic assignment (see Section 2.3) that performs load balancing during the session initiation. For routing messages, the following operation modes demand different computing resources (e.g. CPU resources) in a proxy [7]: Stateless with No Lookup Stateless with Lookup Transaction Stateful with Lookup Dialog Stateful with Lookup Dialog Stateful with Authentication In addition, a proxy needs additional computing resources to maintain states [7]. Therefore, we assume that SCSCF only performs dialog stateful, and that the other proxies (P-CSCF and I-CSCF) are stateless. This means that each call needs one dialog stateful with lookup and one or
45
more stateless with lookup actions. This enables to reduce the needed computing resources for a single session. 2.1.2. Service Layer Application servers (AS) are located in the services layer to provide value-added services, e.g. presence. ASs are interfaced with S-CSCF. However, Figure 1 has a Back to Back User Agent (B2BUA) function in AS, therefore, use cases that are similar to user mobility [6] are implemented. AS is shown only in network 2, but it is possible to have AS in network 1. Apart from the two layers, we assume that functions (PCSCF and S-CSCF) are included into one physical node for our comparison. However, keeping two functions into two nodes does not make any influence on our comparison. The capacity of a physical node is finite, so a number of physical nodes should be placed in the one administrative network during the high call rate. We classify the allocation of physical nodes into two – pre-defined and dynamic assignment, based on call rate and number of users severed. The following two sub-sections discuss about of the allocation of physical nodes and its influence on scalability. 2.2. Pre-defined Assignment Based on the capacity of the physical node, users are predefined to one physical node. It will exist for a long period whether the user makes calls or receives calls. This can be achieved in two ways. One is making settings in DNS. This means that allocating a set of users is by default to one server. For example, from
[email protected] to user500domain1.com is statically defined to one physical node (we assume that is maximum capacity). Other is based on the unique domain names for a set of users, like
[email protected],
[email protected]. These servers only serve for assigned users. Since call arrival rate varies (low to high over time), keeping the physical nodes for signaling purpose is not an economically viable solution (over-provisioned). To address this problem, assigning a server is dynamically considered when user requests arrive. The next sub-section details of the dynamic assignment. 2.3. Dynamic Assignment When many requests arrive simultaneously, all the requests should be divided into servers based on servers’ capacity. The users are dynamically assigned to proxies with help of a load balancer (LB). In this setup, there are many proxy physical nodes. Based on the algorithm, each user is assigned to a particular server by the load balancer. User requests go first to a load balancer that forwards the request to a right proxy. It is important that transactions corresponding to the same call must be routed to same server due to the session-oriented nature of SIP. This aspect should be taken into account when employing the load balancer. The load balancer is either fine-grained or coarse-grained. In a session, all the requests and responses go through the load-balancer; then we called it as a fine-grained. In coarsegrained LB, initial message (e.g. INVITE) goes through the LB and then the subsequent messages for the same session go directly to the proxy that is selected by the LB; a main
S. Shanmugalingam et al. / IJRRNGN, Vol. 1, No. 2, pp. 44-50, December 2011
challenge is to collect instantaneous information from proxies for effective decision making in LB. In the literature, load balancing across many nodes can be achieved by many different algorithms, such as Hash, FNVHash, Round Robin and response-time Weighted Moving Average (RWMA), Call-Join-Shortest-Queue (CJSQ), Transaction-Join-Shortest Queue (TJSQ), and Transaction-least-Work-Left (TLWL) [8]. We describe two different load balancers and its employed algorithm before getting into the scalability analysis. 2.3.1. Fine-grained Load Balancer Authors [8] propose an algorithm (select a server for handling requests) called Transaction-Least-Work-Left (TLWL) and deployed with a fine-grained load balancer. Based on this algorithm, new call is routed to a SIP proxy that has the least work. In this case, the load balancer knows in advance how many transactions each server can handle and cost of each transaction. Authors found that 1.75:1 is a cost ratio between INVITE and BYE in a SIP session. H. Jiang et al claim that TLWL-1.75 can linearly increase throughput when the number of nodes increases (up to 10 nodes) [8]. In the TLWL approach, the load balancer is finegrained (i.e. all requests and responses pass through the load balancer) and is compatible with SIP (can deal with variability in call lengths, distinguish transactions within calls, and can assess different processing costs for different SIP transaction types). A fine-grained load balancer requires high computing resources (processes all of the incoming and outgoing messages) and increases the session setup delay (by one hop). Another problem is the scalability of a load balancer. This problem becomes recursive; a solution for increasing the capacity of a load balancer must be found. Therefore, the scalability presents a major bottleneck for real-life deployment with high call rates (in the thousands). 2.3.2. Coarse-grained Load Balancer After the first message, all the messages are routed to the proxy without going through LB. For effective decision making at the load-balancer, LB should monitor all the available servers over the time whether assigned jobs in proxies are finished or not. In this case, the heartbeat mechanism is used to convey information between proxies and load balancer as explained in [9]. There is a considerable overhead in sending information between proxies and LB. Effectiveness of the heartbeat mechanism in the context of signaling architecture remains a question. More importantly, we did not find any work (with results) that that is linked any algorithm (like round-robin) with a coarse-grained load balancer including in [9]. Coarse-grained LB can scale well compared to finegrained because the coarse-grained LB only processes the first message of each session. However, both approaches consider only in balancing the originating requests from UAs. As per Figure 1, callees are assigned to particular B2BUA, SCSCF and P-CSCF. In this case, callees are willing to receive call via this particular setup. It is not clear how to use (both) load balancing techniques along with an efficient routing configuration in this situation.
46
2.4. Analysis 2.4.1. Scalability The scalability can be achieved by deploying needed resources in advance based on the pre-defined approach. But scalability is a bottleneck with a load balancer in the dynamic assignment approach especially during a high call rate. The capacity planning for the IMS signaling architecture is an important aspect in both approaches. If the capacity of an IMS network (i.e. capacity of each proxy) is not sufficient during the high call rate, the IMS network experiences overload and likely causes throughput collapse [10]. In addition, recovering the throughput is also very slow. To avoid throughput collapse in overload situations, several suggestions for the overload control method have been presented [10]-[11] (not a complete list). Before applying these prevention mechanisms (i.e. preventing throughput collapse), the IMS network should know when and which proxies are under overload. In addition, it is very clear that these overload control solutions are complex and demand computing resources for implementing the overload control mechanisms. More importantly, when deploying the dynamic assignment approach, more efforts should be devoted for the overload situation and throughput collapse because these factors affect the scalability. 2.4.2. Complexity The pre-defined approach is straightforward and complexity is only associated with properly defining the SIP routing rules. On other hand, complexity is related with the load balancer and load balancing algorithm in the dynamic assignment approach. Moreover, overload control mechanisms also add complexity in developing the overall system. 2.4.3. Needed Computing Resources This is associated with the number of users connected to the network and the number of intermediate entities between callee and caller. In IMS, minimum three nodes (P-CSCF1 and S-CSCF1, B2BUA2, and P-CSCF2 and S-CSCF2) are between callee and caller (see Figure 1). If deployed the dynamic assignment approach, the load balancer is also added into the overall system. During the low to moderate call rate, the dynamic assignment approach uses computing resources effectively compared to the pre-defined approach. 2.4.4. Session Setup Latency As mentioned in the previous sub-section, session setup latency is also associated with traversing three nodes (See Figure 1). In the dynamic assignment approach, load balancer also contributes the latency also.
3.
P2P SIP based Architecture
3.1. Introduction Peer-to-Peer (P2P) overlay is a network of nodes where there is no a central entity/server. While overcoming a single point of failure, P2P overlay is scalable and reliable. In P2P overlay, each user is a peer that helps each other in order achieve certain objectives such as locating files and users.
S. Shanmugalingam et al. / IJRRNGN, Vol. 1, No. 2, pp. 44-50, December 2011
The main goal of P2P SIP is to enable communication services over a distributed P2P overlay where the signaling protocol is SIP. A P2P SIP system can thus avoid being dependant upon central server components, as is the case with IMS networks. The P2P overlay architecture can be classified as structured [14] or unstructured. Because of the higher lookup delay, unstructured P2P overlay is not considered in this analysis; the higher number of nodes in the overlay means a higher latency. The one available method is to organize users in clusters or super-nodes based on a distributed hash table [13], [14]. The super-node has information of nodes that are connected directly and communicates with other super-nodes for locating users. This approach is called Chord based overlay and its lookup is O(log(N))-hops. To be precise, there are many other overlays that have the same lookup time [15]. The message overhead per node (M) in a Chord ring depends on the [14]: keep-alive and finger table refresh rate; call arrival distribution ; user registration refresh interval; and the node join, leave, and failure rates. M={rs+ rf(log(N))2} + c*log(N) + (k/t)log(N) + (log(N))2/N
47
entity (like a load balancer in IMS) in order to bear the high call rate. However, organizing the P2P overlay will be cumbersome when a large number of peers are connected (e.g. big distributed hash table). This factor will add complexity in to the overall system. 3.2.3. Needed Computing Resources A P2P SIP signaling architecture has huge message overhead as shown in (1). This message processing requires huge computing resources. Since it is not easy to quantify this parameter, we are sure that computing resources are needed more in P2P SIP than MOCSP based system. Because at least signaling messages should traverse log(N) hops in P2P SIP. Traversing many super nodes demands extra processing power. In sum, the message overhead associated with overlay maintenance is high. This implies that a larger network has higher overhead. Moreover, for the sake of simplicity, we only consider the message overhead in initiating calls. 3.2.4. Session Setup Latency Session setup delay is high; it is always log(N). N is the number of super nodes. When the number of users is high, there should be many super nodes. This means high latency. In addition, the call setup latency is associated with node dynamics (joining/leaving) [13] in P2P SIP.
(1) where k is the number of keys stored per node, rs is the REGISTER refresh rate to successors and predecessors to keep the Chord ring correct, rf is the refresh rate for finger table entry, call arrival is poisson distributed with mean c per node, user registration is uniformly distributed with mean interval t per user, and node joining and leaving are poisson distributed with mean . A few services (offline messages, multiparty conferences) are developed in the P2P SIP system beyond the interpersonal voice/video over IP services. To the best of our knowledge, we have not found any network-based services such as user mobility [6] and partial session transfer and retrieval [16] based on P2P SIP infrastructure. These services add unique requirements to the core network (except end points).
4.
MOCSP based Signaling Architecture
4.1. Proposal We initially proposed MOCSP in [3] for providing the control of the signaling protocol to end users. The motivation of giving the control of the signaling protocol of voice/video communication services to end users is to empower the user innovation. Each user becomes a services provider for his communication services in MOCSP. Later, we propose two new use cases, user mobility in [6] and partial session transfer and retrieval in [16] based on the MOCSP system. However, we have not provided a detailed analysis of scalability, relying on the MOCSP architecture. Natively, MOCSP is scalable. Therefore, this paper intends to position the MOCSP architecture with existing architectures in terms of scalability.
3.2. Analysis 3.2.1. Scalability Theoretically, P2P overlay is scalable. Therefore, P2PSIP architecture is also scalable as long as many nodes join the overlay. However, one limitation is the capacity (CPU, memory and bandwidth) of the super-node. Second limitation is that P2P SIP overlay has much message overhead from peer nodes during registration, refresh, session establishment and node joining and leaving. By taking the message overhead into account, dimensioning the right set of supernodes enables scalability during the high call rate. This is more linked with the latency aspect also (see in Section 3.2.4). 3.2.2. Complexity P2P SIP infrastructure does not need a new functional
Figure 2. A digram of the signaling message path between caller and callee in the MOCSP system.
Each user should have a unique MOCSP instance in the Web platform, identified by a global Web identifier. In addition, callers and callees use their web browser for their sessions. A MOCSP instance provides relevant logic (e.g. implemented in Java Script) for callers and the callee and deploys a network box in the web server. The network box,
S. Shanmugalingam et al. / IJRRNGN, Vol. 1, No. 2, pp. 44-50, December 2011
signaling layer entity (proposed in [6]) in Figure 2 manages a session between caller and callee. The specific service intelligence is also deployed in the network box. For example, [6] proposes user mobility service intelligence to the network box and service logic for partial session transfer and retrieval is also placed in the network box [16]. The simple message flow path diagram between caller and callee is shown in Figure 2. More details can be found in [3], [6]. To be clear, it is not necessary to use a specific signaling protocol in the MOCSP system, but the user can choose one that satisfies his needs. We assume that media streaming between callers and callees is established in a direct peer-to-peer manner. We do not focus on media streaming in this paper.
Figure 3. A scalable architecture for communication services. Each dot represents a user/callee.
Overall architecture can be diagrammatically shown in Figure 3, where users do not depend on each other for locating other users. Simply, this approach is running MOCSP systems individually. Moreover, the number of circles is equal to the number of users who are using the MOCSP system. For example, providing services to 6 billion people, there should be 6 billion MOCSP instances. Each dot in Figure 3 is expanded as in Figure 2. The following paragraphs discuss three aspects: impact on Domain Name System (DNS), roles of a service provider, and failure of a single physical node. Since the MOCSP system is based on the Web platform, there is one entity, DNS which is not visible to users. Because each user has an unique address, we assume the number of DNS records should be equal to the number of users using the MOCSP system. These entries are static, meaning that IP address of the MOCSP instance will not change over the time (i.e. no need to change the IP address of the network box). For example, for the dynamic assignment, SIP UA1 connects one time to P-CSCF1, later this UA1 connects to another P-CSCF2 because P-CSCF1 is under overload. Whenever a callee logs into the MOCSP system, the callee depends on the DNS to resolve the address. In this case, local cache of DNS resolver helps at the callee side. Similarly, callers also depend on DNS resolving. Dependency of the local cache of the DNS resolvers is associated with how often a caller makes a call with a particular callee. The MOCSP system does not assign any
48
new functions to DNS, but only depends on it for address resolution. This resolution is similar to SIP where proxies and SIP ASs need to resolve SIP URI (which can be identifiers for users) to an IP address. Another important aspect of the MOCSP system is how users deploy their MOCSP system in the Web platform. The user has to do two things: the first is to pick his unique Web address (e.g. URL) and the second is to host his MOCSP system on a physical web server. For these two needs, users may need to depend on a service provider who can allocate a unique Web address and physical space on the Web server. Another aspect related to the service provider is to support virtual hosting/shared web hosting. Therefore, single physical server can support many web sites. If the namebased technique is used for the virtual hosting, IP addresses will be efficiently used. We discuss what will happen if one physical server fails. In this case, if one physical server fails, until recovered, users who deploy their MOCSP systems will not able to receive calls (they can still make calls because of communication hyperlinks [3]). If other physical servers do not fail, those physical servers will perform as usual and will not receive more traffic. During high call rate periods, the failure of some super nodes compels an outage of the overall system [20], because other super nodes receive more traffic including many retransmission messages. Therefore, P2P SIP-based infrastructure is less reliable compared to our proposal, in which the network boxes are separated individually. 4.2. Analysis 4.2.1. Linear Scalability By default, each MOCSP instance is separate and individual. Therefore, it is easy to adopt an approach of vertical scalability. This means that a number of MOCSP instances that can be added are limited by the capacity of a single physical server. Based on this approach, overall system is scalable. Moreover, we consider scalability to be linear, because required computing resources for a communication session will not vary. This means that resources have to scale linearly along with the number of network boxes deployed and the number of calls received. 4.2.2. Complexity The MOCSP architecture is a straightforward and simple architecture. Users who implement the MOCSP systems do not need to implement load balancing techniques and do not worry about routing aspect defined specially in SIP and P2P overlay. A session is established between two users, based on TCP connections. Messages needed for a session are sent back and forth between two web browsers via a network box. 4.2.3. Needed Computing Resources This sub-section discusses how many network boxes can be deployed on a Web server. For a session, a network box consists of two TCP connections. In addition, the network box should handle the session and perform state management for caller and callee. In the MOCSP system, only one entity is between caller and
S. Shanmugalingam et al. / IJRRNGN, Vol. 1, No. 2, pp. 44-50, December 2011
callee and a network box needs computing resources only for state management. This means our approach eliminates unnecessary lookup services that happen in many intermediate nodes. Therefore, needed computing resources are less than IMS and P2P SIP. To support vertical scalability, we propose a simple assumption for calculating the needed resources. The simple assumption is that if a Web server can support 10 concurrent TCP connections, we will deploy only five network boxes. Because five TCP connections are used for the callee side and the remaining five connections are used for the caller side. In other words, the Web server hosts a number of network boxes that should be half the number of concurrent TCP connections that the Web server can handle at one time. In parallel, we found that the Apache Web server can manage around 50 000 concurrent connections in a server [17], [18]. The work presented in [18] indicates that all the concurrent connections support to download large data content as specified in SPEC web 2005 [19]. Based on the benchmark of the Apache Web server, we extrapolated calculation to 6 billion people using the MOCSP systems and 3 billion people calling the other 3 billion people. For the aforementioned situation, we need approximately 240 000 similar Web servers [18]. A single Web server can host 25 000 network boxes or serve 25 000 users. To be more precise, the role of the service provider is clarified again here. There might be a single provider who can install all the needed Web servers (roughly 240 000 physical servers). However, obtaining an unique name and Web space is the role of the end user who has to design the signaling protocol based on his needs and deploy in the Web server. In relation to the pre-defined assignment approach in IMS, a number of pre-assigned physical servers are less in the MOCSP approach because only one entity is between caller and callee. 4.2.4. Session Setup Latency Obviously, the session setup latency can be made independent of number of calls made in the MOCSP system. Table 1. Comparison of signaling architectures Properties
IMS (pre-defined)
P2P SIP
MOCSP
Scalability
Well (need proper capacity planning). SIP routing configuration
Well
Well
Arrangement of the overlay.
Needed computing resources
Higher than MOCSP
Session setup latency
Higher than MOCSP
Allocating resources for message overhead (proportion to O(log(N))) Olog(N)
Only Web hosting of the MOCSP instance Low, because of single entity – network box.
Complexity
O(1)
This is possible to achieve always because of linear scalability and single entity (i.e. O(1)) between caller and callee.
5.
49
Conclusion
We analyzed the scalability of a signaling architecture for inter-personal communication services based on four criteria – how scalable, complexity, needed computing resources and session setup latency. The MOCSP based architecture outperforms two other existing architectures, IMS and P2P SIP. Table 1 lists the summary of the comparison. MOCSP based architecture scales linearly, without adding complexity. Since the complexity of MOCSP is O(1), needed computing resources and session setup latency is less than IMS and P2P SIP signaling architecture. More importantly, the number of calls does not influence the session setup time. However, computing resources are not efficiently used when a single web server hosts the maximum possible number of network boxes. This means call rate varies over the time and if the call arrival rate is less than expected, computing resources at a single web server will not be used completely. In this case, we plan to investigate the cloud computing concept for efficient usage of computing resources in the future. Therefore, the MOCSP system can also perform very well during low to moderate call rate. We consider scalability only for the inter-personal communication services. But today IMS/SIP infrastructure support many other services such as presence services/event notification services. The MOCSP system does not support presence services/event notification. In the future, we are planning to compare the different signaling architectures with different services that they offer during high loads.
References [1]
Jeffrey Dean. 2009. Challenges in building large-scale information retrieval systems: invited talk. In Proceedings of the Second ACM International Conference on Web Search and Data Mining (WSDM '09), Ricardo Baeza-Yates, Paolo Boldi, Berthier Ribeiro-Neto, and B. Barla Cambazoglu (Eds.). ACM, New York, NY, USA, 1-1 [2] André B. Bondi, “Characteristics of scalability and their impact on performance”, Proceedings of the 2nd international workshop on Software and performance, Ottawa, Ontario, Canada, 2000,ISBN 158113-195-X, pages 195 - 203 [3] Shanmugalingam, S.; Crespi, N.; Labrogere, P. , "My Own Communication Service Provider," Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT), 2010 International Congress on , pp.260-266, 18-20 Oct. 2010. [4] 3GPP: Third Generation Partnership Project (www.3gpp.org) [5] J. Rosenberg , H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson R. Sparks, M. Handley and E. Schooler. SIP: Session Initiation Protocol. IETF Network Working Group Request for Comments 3621, 2002. [6] Shanmugalingam, S.; Crespi, N.; Labrogere, P.; , "User mobility in a Web-based communication system," Internet Multimedia Services Architecture and Application(IMSAA), 2010 IEEE 4th International Conference on , 15-17 Dec. 2010. [7] Vijay A. Balasubramaniyan, Arup Acharya, Mustaque Ahamad, Mudhakar Srivatsa, Italo Dacosta, Charles P. Wright, "SERvartuka: Dynamic Distribution of State to Improve SIP Server Scalability," icdcs, pp.562-572, 2008 The 28th International Conference on Distributed Computing Systems, 2008. [8] H. Jiang, A. Iyengar, E. Nahum, W. Segmuller, A. Tantawi, and C. P. Wright, “Load Balancing for SIP Server Clusters”, Proceedings of the IEEE INFOCOM 2009, pp. 2286–2294 (2009). [9] George Kambourakis, Dimitris Geniatakis, Tasos Dagiuklas, Costas Lambrinoudakis, and Stefanos Gritzalis, “Towards effective SIP Load Balancing”,3rd VoIP Security Workshop, Berlin, Germany, June 2006 [10] V. Hilt and I. Widjaja. “Controlling overload in networks of SIP servers.” In Network Protocols, 2008. ICNP 2008. IEEE International Conference on, pages 83–93, Oct. 2008 . [11] Yang Hong, Changcheng Huang, and James Yan. 2011. “Modeling and simulation of SIP tandem server with finite buffer.” ACM Trans. Model. Comput. Simul. 21, 2, Article 11 (February 2011), 27 pages.
S. Shanmugalingam et al. / IJRRNGN, Vol. 1, No. 2, pp. 44-50, December 2011 [12] Charles Shen and Henning Schulzrinne. 2010. “On TCP-based SIP server overload control.” In Principles, Systems and Applications of IP Telecommunications (IPTComm '10), Georg Carle, Helmut Reiser, Gonzalo Camarillo, and Vijay K. Gurbani (Eds.). ACM, New York, NY, USA, 71-83. [13] Maenpaa, J.; Camarillo, G.; , "Analysis of Delays in a Peer-to-Peer Session Initiation Protocol Overlay Network," Consumer Communications and Networking Conference (CCNC), 2010 7th IEEE , pp.1-6, 9-12 Jan. 2010. [14] Kundan Singh and Henning Schulzrinne. “Peer to peer telephony using SIP.” In Proceedings of the International Workshop on Network and Operating System Support for Digital Video and Audio 2005, pages 63-68. ACM, 2005. [15] Jani Hautakorpi and Gonzalo Camarillo. 2007. “Evaluation of DHTs from the viewpoint of interpersonal communications.” In Proceedings of the 6th international conference on Mobile and ubiquitous multimedia (MUM '07). ACM, New York, NY, USA, 74-83. [16] Shanmugalingam, S.; Crespi, N.; Labrogere, P. , "A Solution for Audio-Video Partial Session Transfer and Retrieval," WPMC 11, Oct.2011, Brest, France. [17] C. MacCarthaigh, Scaling httpd 2.x to 50,000 Concurrent Downloads In ApacheCOn EU, June 2006. [18] RedHat, SPECweb2005 Benchmark using Red Hat Enterprise Linux 5.2 on a HP Proliant DL580 G5, V1.1, February 2009 [19] http://www.spec.org/web2005/. [20] http://blogs.skype.com/en/2010/12/cio_update.html
50
