A Technical Analysis of SIP and P2P Networks Centralization and Decentralization

Transcription

1 A Technical Analysis of SIP and P2P Networks Centralization and Decentralization Xie Xiaolei Helsinki University of Technology Abstract The session initiation protocol (SIP) is an application layer control protocol intended for creating, modifying and terminating multi-participant sessions such as internet telephony, conferencing, messaging and file transfer. The functionalities of SIP are organized in a centralized manner and heavily rely on dedicated servers. Moreover, in order to accomplish the data transmission in those sessions, SIP must be used in combination with other protocols such as RTP, RTSP, SDP, though it does not depend on such protocols. In contrast, the same functionalities are provided by P2P protocols in a totally decentralized manner. Among them, Skype is characteristic. It works in a decentralized fashion both in session initiation and in the following data transmission. In this paper we evaluate the advantages and disadvantages of these two approaches, from a perspective of centralization and decentralization. The area of the evaluation includes session setup latency, quality of service and protocol openess. KEYWORDS: Peer-to-Peer (P2P), Voice over IP (VoIP), Session Initiation Protocol (SIP) 1 Introduction The session initiation protocol (SIP) is a protocol designed to setup sessions. The typs of such sessions may vary from message sessions in chat systems to multimedia and multiparticipant sessions in internet telephony or conference. Currently the standardized version of SIP, RFC 3261, accomplishes its task by setting up lots of servers to provide registration, proxy, and location services to clients. This centralized architecture is rather traditional and undoubtedly has its advantages, e.g. a low latency in connection establishment, but on the other hand, it also has some critical drawbacks, such as being subject to denial-of-service attacks, the lack of robustness and scalability, etc. P2P protocols such as Skype and emule, while providing the same functionalities of internet telephony, conferencing, etc, do not suffer from those problems. By organizing their overlay networks in a decentralized fashion, P2P protocols become much more robust and scalable than their competitors of the traditional fashion. This is why many efforts have been taken recently to incorporate the P2P technology into SIP. A complete session discussed in the above can be roughly divided into three phases connection establishment, data transmission and session termination. The differences between centralization and decentralization are most remarkably manifested in the first two phases. Thus in this paper we shall focus on the behavior of SIP and P2P networks during these two phases. In the next section we shall take a close look at the process of connection establishment in SIP and in a P2P framework, for the latter of which, Skype is taken as a case study. Then we tend to file transfer in both networks. For SIP, the internet draft published as [9] is carefully studied; for P2P, because the protocol used by Skype is not open to the public, we turn our attention to emule, a popular P2P file sharing application with an open protocol. It is notable that Skype originates from the file sharing application KaZaa [11]. Thus we have a good reason to believe that studies of such an application will reveal to us the mechanisms of P2P data transmission, including those employed by VoIP applications such as Skype. 2 Connection Establishment 2.1 SIP Registration The premise of any dialog in SIP, which involves the inviter and an invitee, is a successful registration of the latter. In other words, a user agent server (UAS) must first register itself to a local registrar server and hence make itself reachable through the local location service before it is able to receive any incoming INVITE request. The registration is done by issuing a REGISTER request to the local registrar server, indicating the domain for which the registration is meant, the user name to be registered and a list of contacts to be bound with the domain and the user name. A contact specified in the list could be of any URI scheme, such as a telephone number with a tel URL, an address with a mailto URL or a more specific SIP/SIPS URI. Some other information is also included in the REGISTER request, but for clarification it is omitted here. Now that a user agent client (UAC) has constructed a REGISTER request, its next task is to locate a registrar server and send the request to the server. There are three alternatives specified in RFC 3261 [1] for the UAC to carry out this task. The first is to follow local configurations. The UAC may be configured with the address of a local registrar server and when needed, send the request there without any

2 extra efforts. Secondly, the UAC may send the request to the host that appears in the SIP address in question. For example, if the SIP address is the UAC may send the request to sip:tkk.fi using the normal SIP server location mechanisms. Finally, the UAC can send the REGISTER request to the well-known "all SIP servers" multicast address "sip.mcast.net", which translates to A UAS listening to this address will receive the request and make bindings accordingly Invite Request Here we take a close look at the process that starts a SIP call session, which literally comprises one or more dialogs. A session is always started by the originator sending INVITE requests to desired participants. Such a request includes in its header fields, among others, the address of the recipient, which can be of any URI scheme as is a contact in the REG- ISTER request, the address of the originator, the ID of the attempted call, and a sequence number of the request. [1] Once the request is generated, the UAC computes the destination by querying DNS for SRV (Service record) and NAPTR (Naming Authority Pointer) records about the domain specified in the targeted SIP address [3] (tkk.fi as in alice@tkk.fi), or by following local policies if any. [1] Then the request is sent. If its receiver is a stateless UAS, which is primarily used to handle unauthenticated requests, a challenge response is most likely to be generated; if the receiver is a redirect server, which has access to some location service, the server would use the service to generate a list of alternative locations and return it in a final response. [1] If, however, the receiver of the INVITE request is a proxy server, the successive operations become more complicated. The proxy server will first validate the request. This procedure includes checking the URI scheme, the Max-Forwards field, the Proxy-Require field, etc. If one of these checks fails, the server will conclude the request by responding with an error code. [1] If the request passes the validation, the proxy server will preprocess the route information contained in the request and then determine the target of the request and finaly forward it. [1] After all these relays by the intermediate servers, the IN- VITE request will eventually arrive at its desired UAS and if it is accepted, the two parties will start data transmission using a transport protocol. 2.2 Skype Registration According to [6], user directories in Skype are maintained in a totally decentralized manner, by utilizing the Global Index (GI) technology. GI constructs a multi-tiered overlay network where every node gains full knowledge of all the available users and resources not by contacting a central server but by participating in the communication between super nodes. This way the central login server, which used to be a vital component in the Skype network, can be removed and with it the bottleneck of the whole network performance. During the first login after installation, a Skype client (SC) sends UDP packets, if UDP is not restricted, to some well-known Skype nodes (bootstrap super nodes, as they are called in [2]) and establishes a TCP connection with those that respond. However, if UDP is restricted by a firewall, the SC will try to establish a TCP connection with one of the bootstrap super nodes. At the end of a login process, an SC tries to advertise its arrival in the Skype network by sending UDP packets to other online nodes. This attempt will be made as long as the SC is not behind a UDP-restricted firewall. After that, according to the received responses, the SC will maintain a table of reachable online nodes and, once its super node [2] goes down, it will resort to these nodes instead. It is notable that the SC maintains in the windows registry a list of possible super nodes. This list is first populated by the bootstrap super nodes during the first-time login, and then, as we conjecture, enriched by election from the table of online nodes User Location In order to start a multimedia session with another user identified by a Skype user ID, an SC must first find out the availability of that user and if the user is available, the address of it, before the session can be initiated. Because the Skype protocol is not open and its messages are encrypted, detailed investigations into this process is impossible. However, according to the experiments in [2], the super node of an SC is responsible for providing candidates of the desired user for the SC to query. The first batch of candidates provided by the super node contains 4 address-port pairs and the next contains 8, and so on. If the desired user is not found in one batch, the SC will contact its super node for the next. It remains unknown how the SC decides to terminate the search if the user is not found. 2.3 An Evaluation Latency is obviously the major concern when we consider connection establshment, hence it should be the main criteria in evaluating the two approaches. The widely deployed servers in the SIP architecture now show their contributions: The redirect servers, which provide location services to each other and proxy servers, are carefully configured with local information and consequently are able to route a request/response more accurately to its destination. Thus after a few hops, the request/response will be eventually delivered. In contrast, P2P protocols may incur many more efforts to do the same. In general, the capability and hence responsibility of a node in a P2P network change from time to time, making the information about it stored by other nodes out of date and leading to incorrect routing. Nevertheless, a node may leave its network abruptly and as a result, the affected part of the network has to be re-structured, causing a high latency or even connection failure. However, when we consider the openness as well as the adaptability of protocol, SIP is definitely more preferable. SIP is intended to be a general mechanism for internet telephony and hence its registration process is highly scalable and can be easily adapted to specific administrative policies.

3 On the opposite, Skype is intended and designed to be a proprietary service. It does not follow any open standard to make possible cooperating with other internet telephony software, nor does it support configuration to a specific local area network (LAN) environment. 3 File Transfer 3.1 File Transfer in SIP MSRP The Message Session Relay Protocol (MSRP) is a protocol intended to transfer a series of messages in a SIP session. However, the capability of MSRP is not restricted to the transmission of plain-text messages. Furthermore, it is able to transfer any content that is compliant with the Multipurpose Internet Mail Extensions (MIME) [12], including audio and vedio clips. [9] The basic idea of file transfer using MSRP in a SIP session is to embed the file in question into the stream of instant messages as a MIME object. Moreover, in order to avoid blocking the interactive message exchange while transferring a large file, the same transport connection is shared between both transmission operations. [9]. In the following sections, we shall take a closer look at MSRP Message Partition Since the same transport connection is shared between the transfer of files and the transfer of instant message streams, a large file must be partitioned, and the transmission of the resulting parts must be regularly interrupted, so that the message stream is allowed some chances to be transferred. MSRP provides such a mechanism that allows a large file to be delivered using several SEND requests (such SEND requests are hereafter referred to as MSRP requests in the rest of this section), each of which carries a single chunck of the file. And in turn, each of these chuncks can be interrupted during its transmission. [9] To make possible the partition mechanism, an MSRP request always starts with a unique identifier, which is also regarded as the terminating symbol of the last request. Also, included at the end of the ending line of an MSRP request is a flag that indicates whether the chunck carried by the current request is the last chunk of the message (which contains the file being transferred). Moreover, in the header field of the MSRP request, there is a byte-range header that indicates the overall position of the current chunck in the complete message. With the help of this header, the message can be reconstructed even if the arrival of the seperate messages are disordered. [9] The following figure depicts the partition mechanism described in the above: + <- (1) <- (2) + <- (3) + <- (4) <- (5)... + <- (6) + <- (7)... <- (8)... $ <- (9) 1. beginning of the file and the 1st chunck; the 1st SEND request 2. 1st interrupt 3. the file is to be continued 4. beginning of the 2nd chunck; 2nd SEND request 5. the 2nd interrupt 6. the file is to be continued 7. beginning of the i-th chunck 8. the n-th interrupt 9. the end of the message (file) A Transaction of File Transfer When an MSRP end-point wishes to send a file to another end-point, it will first look into the type of the other endpoint s URL to determine the type of transport connection that it is supposed to use (TLS, TCP, etc.). Particularly, if the URL scheme of the other end-point is msrp:, then a TLS connection must be used. [9] MSRP advocates reusing transport connections. Whenever a connection is needed, the party in question should first check whether it already has a connection associated with the desired host, port and URL scheme. And if it does, it should reuse the existing connection. [9]Following this rule, embedding files into active message streams will be a common case. This strategy positively reduces the number of connections involved in each session and hence reduces the overall transportation cost. However, due to the fragile nature of end-to-end transportation in networks with a low quality of service, we would still expect the transmission of very large file eg. using MSRP in such networks to be error-prone and consequently not practical. Anyway, MSRP is only intended for casual file transfer in message sessions instead of large-scale resource spreading, which is the designed capability of many popular P2P networks, e.g. emule.

4 3.2 File Transfer in P2P P2P File Transfer in General File transfer (sharing) is one of the best known uses of P2P technology. A node joins the P2P overlay network by connecting to some of the nodes that are already in the network. When a node wishes to download a file, it will contact its neighbors to locate the providers of the file and then request those providers to transfer the file Distributed Hash Table Nowadays most P2P systems use a Distributed Hash Table (DHT) to locate resources. In such a system, every resource is assigned a resouce-id, which is obtained by hashing some keyword of the resource that uniquely identifies the resource. On the other hand, the nodes in the overlay network are also each assigned a node-id, which is in the same hash space as the resource-id s. [13] A node in the overlay network is responsible for storing the resources whose resource-id s are close to the node s node-id. When a node enters/leaves the overlay network, the responsibility area of each node in the network will be recalculated, so that the hash space of the resource-id s is always completely covered. After the re-calculation, the nodes in the overlay network will exchange resources to cover their own responsibility areas. [13] In most P2P architectures, e.g. Skype, emule, a node in the DHT knows about more other nodes in the DHT as the distance of interest decreases. When a user tries to search for a resource, the node in which it resides will contact the node that it knows about and that has the node-id closest to the desired resource-id. If, however, the contacted node does not have the requested resource, it will either suggest the closest node that it knows about, or instead consult that node itself and then returns the answer. [13] In this fashion, a request will eventually reach the node that is responsible for the desired resource; that node will then reply to the requester. [13] Chord Chord is a popular DHT algorithm. It organizes the hash space of DHT in a ring structure. In this structure, the node with hash value 0 will be considered ajacent to the node with hash value 2 n 1 in the DHT, where 2 n 1 is the largest possible value in the hash space. Moreover, each node in the structure keeps a table of n pointers to other nodes. The i- th (0 <= i <= n-1) pointer in this table points to a node that is at least 2 i units away from the node in question. Thus the farthest colleague that a node knows about will be 2 n 1 units away, the longest distance possible in the DHT, and as the considered distance decreases, more and more colleague nodes are within its acquaintance. [13] File search in chord is done by sending requests to the node with the node-id closest to the desired resource-id. That node will know about more nodes in that area of the DHT (or has a better resolution about that area of the DHT, as is said in [13]) and hence, by following the same rule of closest node-id, it will be able to route the request closer to the node that is responsible for storing the desired resource. This process will be repeated recursively until the request eventually arrives at the node of responsibility A case Study of emule In this section we shall look at emule more closely. emule is one of the most popular P2P file sharing applications. Through a careful study of it, we demonstrate the decentralized nature of P2P and the great powers this nature brings. In the first part we go through a transaction of emule file transfer, and look into the collaboration between different nodes; then in the second part we study a file search operation initiated by a human user. A Transaction of File Transfer The emule overlay network comprises several hundreds of dedicated servers and millions of clients. Upon startup, an emule client will try to connect to a single emule server using TCP and if successful, it will be assigned a client ID, which will be valid until the TCP connection is closed. [4] There are two categories of client ID s in the emule network [4]: high ID s and low ID s. High ID s are only given to those clients that are able to accept incoming TCP connections and these ID s are simply the big endian representation of each client s IP address. Clients other than those are given low ID s, which are lower than 0x Being assigned a low ID has several implications. First of all, as the bearer of the ID is unable to accept incoming connections, all its communication has to be done through the emule server. This will result in a higher probability of rejection by the latter when the client makes its startup connecting attempt. Secondly, as emule servers don t support forwarding requests between each other, a low ID client is unable to interact with another low ID client connected to a different server. [4] After successfully establishing a TCP connection with an emule server, a client sends to the server a list of its shared files and following that a list of files that it wishes to download. In response, the server will send the client a list of other clients that share the files desired by the latter. Then the client will contact those in the list to request that it be added to their download queue. In the same request, it will also specify which file parts are desired by it. [4] Usually, a client will request the file parts that are owned by fewest other uploading clients so as to aid the distribution of those file parts. By doing so, the rare parts are more quickly spreaded and hence are less likely to become a bottleneck. However, so far I haven t found out how a client knows which parts of a file an uploading client owns or which uploading clients have which parts among those it needs. [4] Nevertheless, the low ID clients are unable to accept incoming requests, so the requests directed to them have to be relayed by the server to which they are connected. Such requests directed to a low ID client are called callback requests. Upon receiving such a request, the server will send the low ID client a "callback requested" message containing the address and port number of the request s initiator and ask the low ID client to call back. Obviously, these callback re-

5 quests can be initiated only by the high ID clients, which are capable of accepting incoming connections. [4] When a request has reached the top of another client s download queue, its initiator will be informed by a connection request from the uploader. if, however, at this moment the initiator has obtained the previously needed file part, it will reject the request. This is not an unusual case since the same client can be in the download queue of several other clients, requesting the same file parts; yet, when it completes downloading a file part, it does not cancel its requests to other clients, but simply rejects those clients connection initiatives when they are made. Here we should note that keeping the registrations no longer needed is better than canceling them, as the former approach does not require an extra log of download requests. [4] Moreover, how fast a request advances in a download queue is dependent on who has sent it. In the emule network, each client is identified by a unique user ID, which is a concatenation of 14 random and 2 fixed bytes and which is valid across sessions. The user ID s are related to a credit system. The more files a user has uploaded to others, the faster the requests sent by this user will advance. In order to support this credit system, an encryption scheme is integrated into the emule protocol to prevent impersonating. [4] File Search A file search operation is first initiated from the user interface. Then the emule client will send the search request to its server. In response, the server will send back a list containing the sources for each of the requested files. After getting this list, the client will send download request(s) to each source. [4] However, a client can have only one connection with the same source even if it wishes to download more than one file from the latter. So it has to decide which file to request when several are available. Currently this decision is based on the priority specified by the user and if the user doesn t specify any, the files will be requested in alphabetical order. [4] In our opinion, some improvements could be made to the above algorithm so as to achieve higher performance and/or better user satisfaction. For instance, if a client chooses to first download the file that has the smallest uncompleted portion, a better user experience can be expected. 3.3 An Evaluation between the Two Solutions The file transfer mechanism proposed by MSRP is fairly suitable for casual file transfer involved in message sessions. Its advocation of connection reuse helps save the cost of connection establishment, as is undoubtedly a good measure to enhance the overall efficiency of the SIP network. The strategy of file partitioning, on the other hand, gives an effective solution to the potential blocking of interactive message streams, provided that a single connection will be used for both message delivery and file transfer. MSRP serves as a good solution to file transfer in message sessions where human users are actively participating and files in question are relatively small, but it is definitely not a good candidate for file sharing in larger scales, which inherently requires better robustness and scalability. In this realm P2P technologies come to show their great powers. The most fundamental idea of the Peer-to-Peer architecture is that every node of the network has an equal importance in the network and that each node serves others with its resources, e.g. data, bandwidth, and processing capability, while enjoying services provided by others. Although a particular node may be unable to provide certain services and when it is able to, the quality of service may vary from time to time, the overlay network as a whole, in most cases, is able to provide the intended services and furthermore, maintain the quality at a decent level. With the P2P architecture, the robustness and scalability of an overlay network are more easily achievied but, nevertheless, P2P also brings its own problems, such as being subject to denial-of-service attacks, file searches being unable to exploit the entire overlay network, the necessity of re-structuring, etc. Targeting at these problems, a variety of DHT algorithms have been proposed and studied. Hopefully, these efforts will yield a satisfactory solution. 4 Conclusion First of all, what SIP describes is a general mechanism for internet telephone calls, multimedia distribution, and multimedia conferences. Presented by SIP is a flexible and extensible overlay network that consists of sub-networks, independant service providers, end users and so on. Furthermore, these components could be various interest parties, for example, commercial/non-commercial VoIP operators, location service providers, Internet service providers (ISP), etc. In a word, all kinds of participants can be easily involved and differently configured networks can be seamlessly integrated into the SIP network. In contrast, the P2P counterparts of SIP, for example, Skype and emule, do not enjoy such flexibility and extensibility. Their networks are each dedicated to a specific functionality and each have their own user group and are not expected to merge easily. From this point of view, SIP certainly has a big advantage. However, when performance becomes the major concern, P2P networks such as Skype prevails. P2P networks are designed to be scalable yet providing a high-quality service. As we understand, such desirable features originate from the distributed nature of P2P networks and the clever algorithms fully utilizing this nature. On the other hand, SIP heavily relies on servers for location service, request redirection (redirect servers) and delegation (proxy servers) and hence are not as scalable as its P2P counterparts. Moreover, owing to the limited capabilities of the SIP servers as well as to the end-to-end data transmission (using RTP, MSRP, etc), the quality of service offered by SIP, on average, may not be as good as that offered by P2P networks. For these reasons, recent efforts have been taken to incorporate P2P technologies into the SIP framework.

6 References [1] J. Rosenberg, etc. SIP: Session Initiation Protocol. RFC 3261, IETF Network Working Group, June [2] Salman A. Baset and Henning Schulzrinne. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. September 15, [3] J. Rosenberg, H. Schulzrinne. Session Initiation Protocol (SIP): Locating SIP Servers June, [4] Yoram Kulbak and Danny Bickson. The emule Protocol Specification. January 20, [5] H. Schulzrinne, etc. RTP: A Transport Protocol for Real-Time Applications January, [6] Skype Limited. P2P Telephony Explained For Geeks Only [7] D. Milojicic, V.Kalogeraki, R. M. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins, and Z. Xu. Peer-to-Peer computing. technical report HPL , Technical Publications Department, HP Labs Research Library, March, 2002 [8] A. Gupta, B. Liskov, and R. Rodrigues. One hop lookups for peer-to-peer overlays. In HotOS IX: The 9th workshop on hot topics in operating systems, Lihue, Hawaii, USA, May USENIX [9] J. Rosenberg, M. Isomaki, et al A Mechanism to Enable File Transfer with the Session Initiation Protocol (SIP) February 23, [10] B. Campbell, R. Mahy, C. Jennings The Message Session Relay Protocol (MSRP) February 25, [11] Sharman Networks Ltd How Peer-To-Peer (P2P) and Kazaa Software Works February 23, [12] Freed, N. and N. Borenstein Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Bodies, RFC 2045 November [13] D. Bryan, B. Lowekamp, et al A P2P Approach to SIP Registration and Resource Location draft-bryansipping-p2p-02 Internet-Draft March 5,2006