2007 IFIP International Conference on Network and Parallel Computing - Workshops

An Improved Kademlia Protocol In a VoIP System Xiao WuCuiyun Fu and Huiyou Chang Department of Computer Science, Zhongshan University, Guangzhou, China emilyfcy@gmail.com Abstract
Kademlia, which has been widely used in file sharing systems such as eMule and Overnet, concerns mainly on the resources and prefer to locate precisely the right peers despite of time consuming. We proposed an improved kademlia protocol to adapt to VoIP systems meeting the need of real-time audio service and establishing a conversation in short delay. Beside, to provide an effective circuit switching we present timely backup channel for each peer to rescue interrupted conversation. Differing from file sharing system, VoIP system provides real-time audio service and concentrates more on establishing a conversation in short delay. Therefore, it is no need to continue searching for k closest peers when the local peer gets the desirable peer. In addition, mostly in file sharing system searchers do not rely on a single peer since they could get the resources on several peers whereas in VoIP caller should locate exactly the one he/she wants to call. In this paper, we propose improved kademlia routing protocol in VoIP system. Section 2 introduces standard Kademlia. Section 3 describes improved Kadmlia and expatiates on the routing process. In section 4 we describe an indispensable backup channel in the VoIP system based on improved Kademlia. Finally, section 5 concludes this paper.

1. Introduction
More and more file sharing systems are implemented in a P2P(Peer-to-peer) overlay network for its conspicuous advantages. P2P is quite different from traditional client/server architecture for its nodes work both as client and as server. P2P network is free from single point of failure and bandwidth bottleneck due to the fact that they do not rely on dedicated servers. Moreover, P2P network has advantages of scalability, reliability, fault-tolerance, self-organizing and resistance to denial of service attack (DOS) to some extent. P2P network is categorized into unstructured and structured network. In unstructured P2P network the placement of content is completely unrelated to the overlay topology while in structured networks the overlay topology is tightly controlled and files are placed at precisely specified locations. File sharing systems such as eMule and Overnet concern mainly on what resources nodes could offer and obtain so they would like to find precisely the right resources at the cost of time consuming. Standard Kademlia[5] is designed for file sharing systems and searching in Kademlia is expected to stop when both the desirable peer and k closest peers return. In a way, Kademlia as one of DHTs performs better than other DHTs such as CAN[1], Chord[2], Pastry[3], Tapestry[4]. System based on Kademlia could be selflearning and self-organizing. When applying to real-time system such as VoIP, standard Kademlia should make some modification.

2. Related Work
Kademlia is a peer-to-peer distributed hash table protocol in P2P network. Each node in Kademlia is assigned a unique 160-bits identifier named node ID before joining the network. The node ID, which indicates logical position in the overlay topology, is given by using hashing algorithms (such as SHA-1) to hash some large data. Whatever algorithms used to calculate the node ID, they have two properties in common: 1) different inputs bring different values; 2) node IDs should be distributed in the overlay topology uniformly. Every peer maintains a routing table and some resources about other peers, that is <key, value> pairs. Key is 160-bit identifier and value is some information such as file name in file sharing system and phone number in VoIP system. Those pairs would be stored in some peers whose node IDs are close to the key. Kademlia uses a novel XOR metric to represent distance between 2 points in the key space. Providing two peers node IDs are x and y, the distance between them can be calculated from the formula as follow:

d ( x, y ) = x y

The routing table is a binary tree whose leaves are k-buckets keeping a list of at most k nodes with some common prefix of their node IDs in terms of <IP

0-7695-2943-7/07 $25.00 2007 IEEE Unrecognized Copyright Information DOI 10.1109/NPC.2007.168

920 918

Address, UDP port, NODE_ID> triples. The prefix is the k-buckets position in the routing table. The nodes in the k-bucket are sorted by least-recently seen, that is least-recently seen nodes at the head, most-recently nodes at the tail. Figure 1 illustrates a routing table with local node ID 00001010, k bucket size 4, in an 8bits address space.

does not choose a circuit randomly, but considering physical positions of peers in the network. It is no need considering NAT traversal since when entering the network the newcomer would know his/her own IP address in public network. The newcomer must have a contact to an already participating node and then it performs a node lookup for its own ID. During this process, he/she could get his own IP address in public network by receiving messages from the known peer. Only the IP address in the public network would be noted in the IP address of quaternion <NodeID, IP address, port, state > in kbuckets.

3.1. Improved Route Table

Fig 1 Structure of the Routing Table with address space 8bits, k bucket size 4. The Kademlia protocol consists of four RPCs (Remote Procedure Control): PING, FIND_NODE, STORE and FIND_VALUE. The PING RPC probes a node to see if it is online. FIND_NODE takes a 160-bit target ID as an argument. It sends asynchronous FIND_NODE to k nodes it knows closest to the target ID from its routing table. The recipient returns k closest nodes it knows to the target ID in the term of <IP Address, UDP port, NODE_ID>. It runs recursively until no more closer node IDs. Finally, FIND_NODE ends by sending FIND_NODE to k closest nodes it have already known. STORE instructs a peer to store a <key, value> pair for later retrieval. FIND_VALUE is similar to FIND_NODE, except that recipients would just return the desired <key, value> pair but not k closest nodes. Besides, peers will republish their <key, value> pairs to keep them alive periodically (for instance 24 hours), otherwise, <key, value> pairs would expire and be deleted. In our system, every peer maintains two tables: routing table and backup channel table. The routing table is a binary tree similar to Kademlia; however, each leaf contains a cache-bucket as well as a k-bucket. (Because the nodes of the binary tree and the nodes in the k-bucket or cache-bucket both have a concept of node, to distinguish them, we use TNodes referred to former and nodes referred to the latter.) Cache-bucket is used as a backup buffer of the k-bucket, storing the nodes discarded when k-bucket is full. When the kbucket is available again (due to the remove of nodes in the k-bucket), some of the nodes will be moved from the cache-bucket to the k-bucket. When a leaf TNode splits (splitting only happens on the leaf TNode but not the internal TNode), every child TNode gets only k/2 nodes on average. In this case we can supply the children TNodes k-buckets with nodes from the parents cache-buckets.

Fig 2 K-bucket and cache-bucket in the routing table. Nodes in k-bucket and cache-bucket are stored as a quaternion <Node ID, IP address, Port, State>, in which Node ID is generated by performing SHA-1 operation on clients phone number, while IP address and Port is the IP address and Port of its route entry. For clients in the private network, we do not record their private IP and port, but use a variable State to indicate it. Given a specific node ID, the algorithm of looking up k nodes closest to the target ID from the routing table is as follow:

3. Improved protocol based by Kademlia

The VoIP system based on improved kademlia is a pure P2P overlay network. When making phone calls, callers use routing algorithm FIND_CALLEDID to search callees IP addresses and UDP ports in the absence of server. We modified the lookup node algorithm in the standard Kademlia and it proves to adjust to the VoIP system. Besides, our system has a backup channel. When two peers can not establish communication directly or connection is suddenly broken, our system will switch to another circuit immediately to ensure the conversation. The system

921 919

the target TNode being split

The routing table is established by continuously inserting or deleting nodes and dynamically splitting or compressing TNodes. At the first beginning, the routing table is composed of a single TNode, which covers the whole 160-bits address space, with only one k-bucket and one cache-bucket. When more than k nodes are being inserted into the k-bucket, the TNode will be split into two and each child will be allocated a k-bucket and a cache-bucket respectively. In this case, nodes in the parent k-bucket and cache-bucket will be moved to the childrens. Those near the local node ID will be put in the right childs k-bucket or cachebucket; in contrast, those far from the local node ID will be moved to the other childs. In the other word, nodes whose node IDs share common prefix of local node ID are put in the right childs. To guarantee the nodes look up algorithm FIND_CALLEEID is convergence, the routing table should try its best to stores nodes near the local node ID and drop some nodes far away appropriately to avoid routing table turgid expansion. According to such a rule, we proposed a definition of splitable, which are used in the splitting and compressing process. We call the TNode which includes the local Node ID node Local TNode, and it must be the most right leaf of the binary tree. For instance, the red node in the figure 4 is a Local TNode. When nodes are being inserted into the full k-bucket of a TNode, system will determine whether the desired TNode is splitable or not. If the TNode is splitable, the desired TNode will be split into two, otherwise nodes will be discarded anyway.

Fig 3 TNode splitting A target TNode is splitable if it is consistent to one of the two following rules: RULE1 It is a Local TNode; RULE2 The right subtree of the minimum subtree, containing the Local TNode and the target TNode, contains less than k nodes. For example, as demonstrated in figure 4, the yellow node is the target TNode being inserted by a coming node. Obviously, the k-bucket of the target TNode is full, and the system should determine whether it can be split into two children or not. The minimum subtree containing the Local TNode and the target TNode is in a red oval. The right subtree of it, which in this case is a single Local Node, contains less than k nodes, hence the target TNode is splitable, and will be split into two Children. The reason why we use such a mechanism to split a TNode is as follow: If a node should be inserted into the Local TNode, it means that it shares the longest common prefix with the local node ID in the routing table and is quite near the local node ID as well; therefore it should be stored anyway. On the other hand, if the right subtree of the minimum subtree, containing the Local TNode and the target TNode, contains at least k nodes, it means that there are at least k nodes nearer than the coming node, then the coming node is of less importance, and can be discarded, hence the target TNode is not splitable. The algorithm of splitting TNode is as follow:

922 920

1
number of nodes in the k-bucket

Minimum subtree containing the Local TNode and the target TNode

0
Local TNode containing local node ID

GetClosestNodes(id, list) 1 distance ComputeDiatance(id, localId) 2 GatherNodes(distance, list) GatherNodes(distance, list) 1 if This is an internal TNode 2 then visit the close child first, and let the child gather nodes 3 if list.size() < K 4 then visit the far away child, and let the child gather nodes 5 else This TNode is a leaf 6 if K list.size() >= kBucket.size() 7 then push all nodes into list from the K bucket 8 else only some of the nodes should be added, sort the nodes in the K bucket and add the closest ones.

k=4

k-bucket cache-bucket

3 move nodes from child TNodes to parent and prefer old nodes, when bucket is full put remaining nodes in replacement cache. 4 Order all nodes in child replacement caches by time last seen and prefer most recently seen nodes endif Fig 4 Compression in the routing table

3.2. Improved Route protocol

Caller sends FIND_CALLEEID, with callee ID as its parameter, to find the IP address in accordance with the ID. Receiver returns k closest peers to some given callee ID. In our model, modified Kademlia employs a recursive algorithm for callee lookup similar with standard Kademlia. Caller picks k nodes from its closest k-bucket and sends parallel and asynchronous FIND_CALLEEID. In the recursion, caller sends the FIND_CALLEEID to peers it has learned about from previous RPCs. It resends the FIND_CALLEEID RPC peers it has not yet queried among k peers it heard of closest to callee. Peers fail to respond quickly are out of consideration. If Caller gets a response containing the callee ID, lookup finishes or else continues to find closer peers to callee. If a round of FIND_CALLEEs fails to return any closer peer, caller resends the FIND_CALLEEID to al of the k closest peers it had not already queried. The searching process terminates when caller has queried and gotten responses from the k closest peers it has seen and informs the caller that search fails. Avoiding no refreshing in a certain distance, every k-bucket without lookup in an hour would refresh themselves by doing a callee lookup for a random ID in the buckets range.

ISSpitable() 1 if This is a Local TNode 2 then return true 3 else if The right subtree of the minimum subtree, containing the Local TNode and the target TNode, contains less than k nodes. 4 then return true 5 else return false Split 1 if ISSpitable() 2 then close Child new TNode 3 far Child new TNode 4 move the nodes in the K Bucket to the corresponding Child K Bucket 5 move the nodes in the Cache Bucket to the Corresponding Child Cache Bucket 6 endif Besides, we propose a compression mechanism of the routing table aimed at improving the system performance and getting rid of unnecessary information. Considering the routing table in figure 5, the subtree in the red oval has more nodes than the Local TNode, which is another subtree sharing common prefix with the former one. All the nodes in the red oval are all farther than the nodes in the Local TNode. Since there are already k nodes in the Local TNode closer than them, the system is unnecessary to keep all of them. Compression can be performed and the result is shown in figure 5. Compression is only performed in a subtree with one parent and two leaves not including the Local TNode. When a coming node is being inserted into a leaf TNode, the algorithm determines whether the binary tree can be compressed is as below: Compacity 1 if This is an TNode that both left and right child TNode is a leave TNode and the binary tree is not splitable. 2 Then Order all nodes in child buckets by time first seen

4. Backup Channel
Once the caller and callee are disconnected, caller should find another channel to continue the conversation. Factors should be concerned as follow: Only peers with public IP address could be considered since connection with private IP address would not be accessible without NAT traversal. Circuit should be physically as short as possible to shorten the delay. Nodes in the backup channel should be active and available so that circuit switching would not last too long. Peers in backup channel should be online and continue to be online for some time.

923 921

In our model, backup channels build up a list which stores n closest peers in IP network in the form of <IP distance, IP address, port, timestamp, next> as shown in figure 6. IP distance is the XOR distance between local IP and other peers IP. IP address should be the public IP address. Timestamp notes when the quaternion expires.

Fig 5 node in the list for backup channel The sorted list stores n peers information with IPs closest to the local IP. Head in the list records the closest peer it knows. Every time when it obtains new information about other peer, local peer counts the XOR IP distance and inserts the new peer into the list appropriately. If it is even larger than the longest IP distance in the list it knows, that is the tails IP distance, otherwise it compares with every IP distance in the quaternion from tail to head until it reaches the quaternion that has shorter IP distance. If the quaternion has already exists in the list, it just resets the timestamp .After new quaternion inserting the list, the list will check if it overflows and delete the tail accordingly. The availability of the quaternion marked by timestamp would be within the average talk time. We assume that the quaternion would become untrusty once it stays longer that average talk time and would be offline at any moment. Such quaternion should be dropped so that the list could be effective to the greatest extent thereafter. During the search for callee IP, caller could obtain many peers information in every recursive step. The caller refreshes the backup channels as well as the routing table. When getting the IP address of the callee, caller establishes a conversation with the callee and caller no longer refreshes its backup channels. It sends heartbeat packets to those peers in the list to ensure every peer could connect to both caller and callee. If peer fails to response, caller supposes the peer is offline and deletes the quaternion from the list. Once the conversation is interrupted, caller sends set-up request to peer which the head points to. After connecting with both sides, this peer comes to be agent of the conversation.

Fig 6 shows the flow of heartbeat packet,1 & 2 ensure caller and agent could connect,3 & 4 ensure callee and agent could connect, after confirming the connections agent will inform caller that this circuit is available. Since the offline peer could be dropped and online peer could retain, heartbeat packets can test the state of each recording peer in the backup channels. Even in the worst condition, when the connection is broken, the probability of that online peer appears to be offline is 1/2 and the failure probability of whole list is 1/2n. The backup channels will stop refreshing when ID searching is over. Thereby the failure probability of backup list is increasing together with the increase of the talk time. When backup channel is really needed, little useful channel could be offered by the list. Method should be suggested to rescue such feeble list and validate the backup channels in a long term in spite of gradually abortive channels. When there are less than quaternions, caller will require all of the remaining peers in the list for more backup channels. Those peers will return closest peers it knows from their own backup channels. and is a system-wide parameter, for example =1, =3. Returning peers would update the current backup channels. In this rate, local peer would get more information to set up a robust backup channel. In addition, closer peers could be found to achieve a shorter circuit when switching is needed. IP distance could be replayed by equation considering more factors to decide the best backup channel, for instance overload, CPU, amount of time online.

5. Conclusion
Kademlia which has been widely used in file sharing system proves to be also compatible to realtime system such as VoIP system when modification has been made. In the improved Kademlia protocol we change the original FIND_NODE in Kademlia to FIND_CALLEEID, which terminates once the caller gets the information about callee so that it could set up

924 922

a session as soon as possible. In addition, backup channel for circuit switching shortens the delay when the connection between caller and callee is broken. In the future, more studies for security and practical measurement of backup channel factors would be made to offer a smooth and safe VoIP.

Reference
[1]. Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, Scott Shenker, A scalable content-addressable network [C]. In: Processing of ACM SIGCOMM, 2001 [2]. Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, Hari Balakrishnan, Chord: A scalable peer-to-peer lookup service for internet applications, in SIGCOMM, USA, 2001 [3]. Antony Rowstron, Peter Druschel, Pastry: Scalable, distributed object location and routing for large-scale peer-topeer systems, in IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, 2001 [4]. B Y Zhao , L Huang , J Stribling , etal Tapestry : A resilient global2scale overlay for service deployment[J] 1 IEEE Journal on Selected Areas in Communications , 2004 [5]. Petar Maymounkov, David Mazires, Kademlia: A Peerto-Peer Information System Based on the XOR Metric, 2002

925 923