Chapter 2 Related Work
2.2 Feature comparison between various P2P SIP systems
The features comparison between the proposed system and other approaches is shown in Table 1. SOSIMPLE [9] used SIP and Chord [5] to build a decentralized and standards-based system for SIP communications. However, SOSIMPLE did not consider node heterogeneity and churn handling. DChord [10] considered node heterogeneity and location information of nodes to build a full distributed and open P2P-SIP system. Yet, node churn still burdens the
system with extra maintenance messages. UP2P SIP [11] proposed an unstructured P2P SIP with regard to mobility churn and friend relationships. This approach outperforms the conventional Chord-based P2P SIP approach in terms of call setup latency and maintenance cost. However in an unstructured environment, it still involves unnecessary flooding messages when calling for non-buddy nodes and initiating the network. Furthermore, UP2P SIP did not consider node heterogeneity and advanced services such as off-line messages. In addition, UP2P SIP needs an extra host server to build an unstructured P2P network for non-buddies. Table 2 shows the comparison of search overhead and search time between different P2P SIP systems. The search overhead refers to the number of hops that involve in one search. For Chord-based systems, such as SOSIMEPLE [9] and DChord [10], the search overhead and search time are both O(logN). For DChord, because its unstructured nature, the flooding message will involve O(N) hops, and its non-buddies network can guarantee O(logN) search time. As to our proposed SP2P SIP (Social P2P SIP) system, the search overhead and search time are same as those of Chord-based approaches when making calls to non-buddies.
However, for calls to buddies, our approach can achieve O(1) for both metrics.
Table 1. Features comparison between different P2P SIP systems.
Approach
Feature
SOSIMPLE [9] DChord [10] UP2P SIP [11] SP2P SIP (Proposed)
Zero configuration Yes Yes Yes Yes
Efficient lookup Yes Yes No Yes
Interoperability Yes Yes Yes Yes
Node heterogeneity No Yes No Yes
Advanced services Yes Yes No Yes
Churn handling No No Yes Yes
Table 2. Comparison of search overhead and search time between different P2P SIP systems.
Approach Search overhead Search time
Chord-based[9][10] O(logN) O(logN)
UP2P SIP [11] O(N) O(logN)
SP2P SIP with non-buddies (proposed) O(logN) O(logN)
SP2P SIP with buddies (proposed) O(1) O(1)
Chapter 3
System Design
In this chapter, we present our system architecture as well as design considerations behind the proposed SP2P SIP (Social P2P SIP) system.
3.1 System overview
In our system, the overlay network, as shown in Fig. 2, is constructed in a hybrid (structured/unstructured) fashion. Considering node heterogeneity, nodes are categorized as super nodes (SNs) or ordinary nodes (ONs) according to their capability. SNs form a structured overlay, called main net, which is based on Chord. Each SN manages a group of ONs that form an unstructured overlay, called sub net. Each SN maintains a finger table, a sub node table as well as a resource table to support resource publishing and location. A finger table is designed for Chord algorithm to speed up the lookup procedure. A sub node table is used for managing ONs, and a resource table is used for managing resource publishing data.
In addition, as shown in Table 3, each node maintains a contact table, which comprises buddies and contact’s IP address, to achieve better lookup efficiency when calling buddies.
The reason for choosing such a hybrid overlay is that structured P2P networks (DHTs) are much suitable for IP telephony due to its better ability to locate rare files than unstructured P2P networks [13][14]. Besides, unstructured P2P networks are more resilient to cope with node churn [12].
The node social relationship of our system is illustrated in Fig. 3. For a specific ON N, if node N wants to call a friend, it can ask their common friend, called a contact, to get the
conta
Fig. 3. Node N ’s social relationship with other nodes.
3.2 Contacts initiation
A node sends queries to all buddies by contacting a pre-configured bootstrap node or a previously contacted node to build a contact table when the node first starts up. The contact table is shown in Table 3. Each entry is a mapping of a buddy and the IP address of a contact.
A contact is the super node of the buddy. If a buddy is a super node, its contact will be itself.
We assume that a node can get a buddy list. In practice, user information, such as a buddy list and preferences, can be managed by a centralized authentication server or stored as an encrypted file within the overlay [9].
3.3 Super node selection
When a node M wants to join the overlay, it has to select a super node among contacts.
The first priority is the one who was last connected. If the last contact is not available, a super node should be the one who includes the most number of buddies of M. For example, in Table
3, the super node should be the IP name pair 140.113.90.88/Alice. By this rule, one can build a minimal number of contacts.
Table 3. Contact table for speeding up the lookup procedure.
Buddy Contact Alice 140.113.90.88/Alice
Bob 140.113.90.88/Alice Carl 140.113.90.88/Alice David 140.113.100.200/Fred
Eric 140.113.100.200/Fred
3.4 Node startup, node registration and user registration
The node startup procedure is shown in Fig. 4. Once a user enters his/her SIP URI, such as alice@p2psip.com, a user identifier, Resource-ID, will be calculated first by hashing the SIP URI. The default hashing algorithm in Chord is SHA-1 [26], which can produce consistent hashing results. Second, the user performs the super node selection. If there are no contacts to select, contacts initiation will proceed. When there are no buddies in the overlay, contacts initiation will fail. Then, node registration will be executed.
Fig. 4. Node startup procedure for the proposed SP2P SIP system.
Node registration refers to a node that joins the main net and acts as a super node. The new node uses Resource-ID as its Node-ID. Next, it uses SIP REGISTER and “302 Moved Temporarily” messages to locate the closest successor, which is responsible for accepting the joining node. It is an iterative routing fashion. However, in practice, our main net DHT overlay is much stable so that using recursive routing style is another good way to improve routing efficiency. Fig. 5 illustrates the difference between them. In iterative routing, as shown in Fig. 5(a), the joining node with Node-ID 80 first sends a REGISTER message to the bootstrap node, which has Node-ID 44 (step 1). For a specific Resource-ID k in Chord, the first node with Node-ID equal to or greater (mod the size of the namespace) than k is the
responsible node for k. The bootstrap node is not currently responsible for the joining node so it returns a “302 Moved Temporarily” message, which includes information about the node that might be responsible for the joining node, in this case, node A (step 2). Then, the joining node repeats this procedure to send a REGISTER message to node A. Also, node A is not responsible for it (steps 3-4). Finally, the correct node, node B, is indicated, and it response a
“200 OK message” to the joining node, and then the node registration is finished (steps 5-6).
Node B is also the location where offline messages for the joining node should be placed. On the other hand, in recursive routing as shown in Fig. 5(b), the bootstrap node and node A acts as SIP Proxy Servers to relay the REGISTER message to node B. After the node registration, the joining node becomes a super node, and Node Startup is done. The differences between recursive and iterative routing are described as follows. First, iterative routing can easily keep track of the lookup route and can react to routing problems rapidly. Second, when a node on the routing path fails, iterative routing can skip all previous hops and continue the lookup somewhere next to the absent node. Third, wrong finger table entries are the main problem with recursive routing. However, in an error-free environment, recursive lookups require only 60% of the lookup time compared to iterative routing [19].
When a node gets a super node in Super Node Selection, it will become an ordinary node, and proceeds User Registration. User Registration refers to a node publishing its location information (the mapping of Resource-ID and IP address) so that other nodes can locate it.
There are two places where the location information should be registered to. One is the node’s SN, the other is the node that is responsible for it in the main net. The iterative fashion is shown in Fig. 6(a). The joining node first registers itself to its SN, node A. Node A then adds the joining node to its sub node table, and response “200 OK” message (steps 1-2). Next, the message is relayed to node C, which is responsible for the joining node (steps 3-5). Finally, node C puts the location information to its resource table, and returns a “200 OK” message to
node
3.5 Session setup and user location
When a node wishes to establish a session, the target node must be located. This process is called User Location. For example, if Alice wishes to locate Bob, she first calculates Bob’s Resource-ID by hashing Bob’s SIP URI. There are two cases of User Location. One case is that if Bob is one of Alice’s buddies, Alice can refer to Bob’s contact to locate Bob’s IP address, as shown in Fig. 7. Alice first sends SIP MESSAGE or INVITE message to Bob’
contact for an instant message or a multimedia call, respectively (step 1). Then, the contact responds 302 Moved Temporarily message to indicate Bob’s IP address (step 2) so that Alice can send INVITE to Bob, and Session Setup is completed. The other case is shown in Fig. 8.
If Bob is a non-buddy node, Alice first finds the node that is responsible for Bob to get Bob’s location (steps 1-4). This process is same as User Registration. Once Bob is located, the session is initiated (step 5).
F
Fig. 6. Difference betwe
(a
(b)
een iterative
a) Iterative
) Recursiv
e and recurs registrat
e routing
ve routing
sive routing tion
g when a node proceedss to user
F
Fig
Fig. 7. Sess
g. 8. Sessio
sion setup w
n setup with
with a buddy
h a non-bud y node.
ddy node.
Chapter 4 Simulation
4.1 Simulation setup
In this chapter, the performance of our proposed system is evaluated and discussed. Most of P2P SIP systems were implemented with Chord, and Chord is a DHT-based algorithm which was defined in IETF Internet drafts [21][22]. The Chord-based approach is a representative approach so that we chose it for comparison. We used Overlay Weaver [15] as an overlay generator to construct a standard Chord-based P2P SIP system and the proposed system. By the default setting of Overlay Weaver, the namespace of Chord used in both systems is 2160 and the routing style is an iterative fashion. Besides, in order to closely relate to real people’s social relationship, we developed a crawler to extract the buddy relation from [16]. There are two assumptions in our simulation. First, in most situations, the proposed system is not the first launch. Second, SNs are very stable in the overlay so that a node can be connected to the previous SN most of the time. Based on the two assumptions, the overhead of contacts initiation will not be included.
4.2 Simulation results
The call setup latency is a critical property for telephony system. In DHT-based P2P SIP systems, the call setup latency consists of lookup latency and INVITE transaction latency.
Lookup latency takes up about 80% of call setup latency [20], so we simply measure call setup latency in terms of lookup latency. In general, most of our friends are in the same country, so we assume connections between a specific node and its contacts are in domestic
networks. Besides, we assume routing in DHT overlay is through the global Internet because physical positions of those nodes on the routing path are unpredictable. In addition, according to realistic statistics [20], we set average hop latency in the domestic network and the Internet to 90 ms and 400 ms, respectively. Fig. 9 shows the call setup latency against the number of nodes in the system with different percentages of calls to buddies. It is obvious that the more calls to buddies the lower call setup latency on average. Our approach outperforms the standard Chord-based system in all scenarios. For example, in 10,000 nodes overlay, the proposed SP2P SIP system improves 86% of call setup latency compared to the standard Chord-based system while making 30% of calls to buddies.
Fig. 9. Comparison of call setup latency under various number of nodes.
We also evaluate the maintenance cost of two schemes by measuring number of control messages which is needed to build a DHT overlay, as shown in Fig. 10. The messages of our approach increase gently as the number of nodes increases because our approach can reduce the number of nodes in the DHT overlay. For example, in a 10,000 nodes overlay, our system requires only 37% of maintenance cost compared to the Chord-based system.
0
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
Call setup latency (s)
Fig. 10. Comparison of maintenance cost under various number of nodes.
To evaluate the effect of node mobility, we first established a network of 1,000 nodes.
We churned nodes with various churn rates in a period of 1 minute, which meant nodes continually join/leave overlay with various time intervals, maintaining the total overlay size at 1000. Fig. 11 shows the effect of various churn rates on call setup latency. Higher churn rate will increase call setup latency in the traditional Chord-based P2P SIP system. However, the churn rate affects our system slightly. That is because most nodes in our system are ONs and ONs join/leave the system would not affect the structure of the main net. Thus, the main net can remain stable and is more resilient to cope with node churn.
0
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
Number of messages
Number of Nodes
Chord‐based SP2P SIP (proposed) x 103
Fig. 11. Comparison of call setup latency under various churn rates. (Churn rate increases to the left)
0 1 2 3 4 5 6 7
100 500 1000 2000 3000 4000 5000
Call setup latency (s)
Node join/leave interval (ms) Chord‐based
SP2P SIP with no buddies (proposed) SP2P SIP with 30% of buddies ( " ) SP2P SIP with 60% of buddies ( " ) SP2P SIP with 90% of buddies ( " )
Chapter 5
Conclusions and Future Work
5.1 Conclusions
In this thesis, we have presented a hierarchical social network-based P2P SIP system.
The idea behind the system is that people’s friend relationships are closely associated so we can ask a known friend to get more information about other friends. In addition, friends are close geographically so that we can speed up the lookup procedure. Simulation results have demonstrated that the proposed P2P SIP system improves 32% of call setup latency with non-buddies and reduce 63% of maintenance cost in comparison with the conventional Chord-based approach. We also improve lookup efficiency from O(logN) to O(1) when making calls with buddies, where N is the number of nodes in a DHT-based network. As to mobile environments, the proposed hybrid (structured/unstructured) overlay is more resilient to cope with node churn.
5.2 Future work
Since the numbers of buddies among super nodes are not uniform, the load balancing of super nodes is an issue. In addition, there is a security issue when using P2P SIP architectures for real-time communication [27]. Both of the issues deserve for further study.
Bibliography
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M.
Handley and E. Schooler, “SIP: session initiation protocol,” RFC3261, IETF, June 2002 [2] “Skype Technologies,” [Online]. Available: http://www.skype.org/.
[3] N. Leibowitz and M. Ripeanu and A. Wierzbicki, “Deconstructing the Kazaa network,”
in Proc. of the 3rd IEEE Workshop on Internet Applications (WIAPP), pp. 112-120, June 2003.
[4] M. Ripeanu, “Peer-to-peer architecture case study: Gnutella network,” in Proc. of the 1st IEEE International Conference on Peer-to-Peer Computing, pp. 99-100, August 2001.
[5] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup service for internet applications,” in Proc. of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, pp. 149-160, August, 2001.
[6] S. Ratnasamy, M. Handley, R. Karp and S. Shenker, ”Application-level multicast using content-addressable networks,” Lecture Notes in Computer Science, Vol. 2233, January 2001.
[7] A.Rowstron and P.Druschel, “Pastry: scalable, distributed object location and routing for large-scale peer-to-peer systems,” in Proc. of 18th IFIP/ACM International Conference on Distributed Systems Platforms, pp. 329-350, November 2001.
[8] K. Singh and H. Schulzrinne, “Peer-to-peer Internet telephony using SIP,” in Proc. of the International Workshop on Network and Operating Systems Support for Digital Audio and Video Tech, pp. 63-68, June 2005.
[9] D. A. Bryan, B. B. Lowekamp and C. Jennings, “SOSIMPLE: A serverless,
standards-based, P2P SIP communication system,” in Proc. of International Workshop on Advanced Architectures and Algorithms for Internet Delivery and Applications, pp.
42-49, June 2005.
[10] H. Ma, B. Xu, H. Wan and C. Li, “A hierarchical P2P architecture for SIP communication,” in Proc. of International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST), pp. 130-135, September 2007.
[11] C.-M. Cheng, S.-L. Tsao, and J.-C. Chou, “Unstructured peer-to-peer session initiation protocol for mobile environment,” in Proc. of the 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), pp. 1-5, September 2007.
[12] S. Rhea, D. Geels, T. Roscoe, and J. Kubiatowicz, “Handling churn in a DHT,” in Proc.
of the Annual Conference on USENIX Annual Technical Conference, pp. 10-10, June 2004.
[13] K. Singh, “Structured vs. unstructured P2P or why we chose DHT for P2P-SIP?”
[Online]. Available:
http://p2p-sip.blogspot.com/2006/06/structured-vs-unstructured-p2p-or-why.html.
[14] B. T. Loo, R. Huebsch, I. Stoica, and J. Hellerstein, "The case for a hybrid P2P search infrastructure," In Proc. of International Workshop on Peer-To-Peer Systems (IPTPS), pp. 141-150, February 2004.
[15] “Overlay Weaver: An overlay construction toolkit,” [Online]. Available:
http://overlayweaver.sourceforge.net/.
[16] “Plurk,” [Online]. Available: http://www.plurk.com/.
[17] R. Schollmeier,” A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications,” in Proc. of the 1st International Conference on Peer-to-Peer Computing (P2P), pp. 101-102, August 2001.
[18] L. Le and G-S Kuo, “Hierarchical and breathing peer-to-peer SIP system,” in Proc. of IEEE International Conference on Communications (ICC), pp. 1887-1892, June 2007.
[19] G. Kunzmann, “Recursive or iterative routing? hybrid!,” [Online]. Available:
http://subs.emis.de/LNI/Proceedings/Proceedings61/GI-Proceedings.61-27.pdf.
[20] C. Zhang, J. Shi, L. Li, W. Lin, Y. Wang, L. Gu, Y. Ji and Z. Feng, “Signaling latency analysis of peer-to-peer SIP systems,” in Proc. of the 5th IEEE Conference on Consumer Communications and Networking (CCNC), pp. 505-509, January 2008.
[21] C. Jennings, B. Lowekamp, E. Rescorla, S. Baset and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) base protocol,” [Online]. Available:
http://tools.ietf.org/html/draft-ietf-p2psip-base-02, March 2009.
[22] M. Zangrilli and D. Bryan, “A Chord-based DHT for resource lookup in P2PSIP,”
[Online]. Available: http://tools.ietf.org/html/draft-zangrilli-p2psip-dsip-dhtchord-00, February 2007.
[23] Y. ZHu, X. Yang and Y. Hu, “Making search efficient on Gnutella-like P2P systems,” in Proc of the 19th IEEE Conference on Parallel and Distributed Processing Symposium, pp. 56a-56a, April 2005.
[24] Y. Chawathe, S. Ratnasamy, L. Breslau, N. Lanham and S. Shenker, “Making Gnutella-like P2P systems scalable,” in Proc. of ACM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, pp. 407-418, August 2003.
[25] PlanetLab,” [Online]. Available: http://www.planet-lab.org/.
[26] National Institute of Standards and Technology (NIST), “SHA- 1 standard,” [Online].
Available: http://www.techheap.com/cryptography/hash/fip180-1.pdf.
[27] D. Chopra, H. Schulzrinne, E. Marocco, and E. Ivov, “Peer-to-peer overlays for real-time communication: security issues and solutions,” IEEE Journal on Communications Surveys & Tutorials, Vol. 11, pp. 4-12, March 2009.