Seminar P2P im Wintersemester 2010

Transkript

1 Seminar P2P im Wintersemester 2010 Teilnehmer des Seminar P2P im Wintersemester Juni 2011 Veranstalter: Fachgebiet Peer-to-Peer Netzwerke und Fachgebiet Telekooperation Fachbereich Informatik TU Darmstadt

2 Inhaltsverzeichnis 1 Exploiting Anonymity in P2P-based Systems von Hristo Chonov 3 2 Replikationsstrategien in Content-Distributionssystemen von Julian Dean 11 3 P2P Service Description Language von Dimitar Goshev 20 4 Cheating Detection in P2P-based Massive Multiplayer Online Games von Georgi Hadshiyski 26 5 P2P-Based Video-on-Demand-Streaming von Pablo Hoch 32 6 Skype - Ein Überblick über die Protokolle, das Overlay-Netzwerk und die Sicherheitsmaÿnahmen von Marius Hornung 40 Übersicht über datenorientierte Netzwerklösungen von Bastian Laur 4 8 Trac Analysis of p2p Applications von The An Binh Nguyen 54 9 Peer-to-Peer-basierte Live-Streaming-Systeme von Thomas Schlosser Harvesting Sensor Networks von Andreas Straninger 0 11 Load Balancing in Peer-to-Peer Netzwerken Survey von Johannes Thomas 5 12 Diaspora und Safebook: Der Stand von Decentralized Online Social Networks von Samuel Vogel P2P-based VoIP von Zoran Zaric 85 2

3 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS 1 Exploiting Anonymity in P2P-based Systems Hristo Chonov Abstract After David Chaum, considered the father of anonymous communications, proposed a system for anonymous in 1981 many new systems has been implemented on the scene aiming to offer better protection than their predecessors. But trying to cover some security holes in the anonymity new protocols can cause other security issues. In this paper I describe some of the peer-to-peer network protocols that employ anonymization techniques and some of the known approaches that can be used to exploit anonymity in overlay networks built on top of those protocols. At the end, I make a conclusion based on a table showing the most widely uncovered and effective types of attacks. I. INTRODUCTION Anonymous overlay networks allow Internet hosts to communicate with each other, while preventing linkability between sender and receiver from the rest of the overlay. This means they conceal who is interacting with whom. Those networks have a very important usage like for online privacy, resisting censorship, evasioning surveillance. At some places in the world there is no freedom of speech and censorship is imposed. There expressioning online could be considered as a crime and thus the authors need to protect their real identities. This kind of networks could also be used to resist blocking circumvention censorship. Of course they could be used for illegal file sharing, what someones are doing, by running BitTorrent on the top of Tor for exchanging illegal content. But actually this is not what these systems are built for, it s just an exploitation of them. Some of the schemes use global list to choose relays from it. An alternative is to organize the nodes of a network overlay in a distributed hash table (DHT), which can form a decentralized and distributed system that maps identifiers to nodes and has a mechanism to determine the responsible node- ID for a given identifier. The problem however with DHTs is that they are proven to have very weak points and thus be very insecure queries in DHTs are easy to observe and manipulate. That s why redundancy mechanisms for securing DHTs are developed and will continue to be developed in the future. In this paper I review both mechanisms for finding relays i.e. overlays based on a global list and overlays based on a DHT. In the most cases the anonymity has a price and that is the speed. The anonymous peer-to-peer network overlays are structured in two areas: The first one is Low-Latency anonymity systems and the second one is High-Latency anonymity systems. The time of message delivery in High-Latency systems like Mixmaster and Mixminion is around 4 hours. This two networks are assuming that the attacker can see the whole network traffic and also can manipulate some of the nodes, who are taking part in the anonymous message transfer. On the other side Low-Latency systems like Tor attempts to reduce the delivery delay to provide normal speeds for internet browsing and file sharing. In the current open peer-to-peer overlay networks every client can participate without the need to prove that it is trust-able. Thus a small fraction of malicious nodes can easily be built, what can lead to incorrect message delivery. That s why closed peer-to-peer overlay networks where the clients connect to the nodes they trust have evolved. In some cases to participate the network a client needs an invitation. The closed peer-to-peer networks are usually very small and increasing the size of the network makes it more insecure. I ll mainly concentrate on open peer-to-peer systems. The main objective of an adversary in an anonymous communication system is to link the initiators of connections with their respective communication partners and vice versa. Outline The rest of the paper is organized as follow: In Section II I give a short background information and in Section III I briefly describe well known look up mechanisms and their weaknesses. Sections IV to XI present different systems for anonymous communication and how the anonymity in those systems can be exploited. At the end I make a conclusion about the most uncovered weak points which could be used to exploit the anonymity in the respective systems. II. BACKGROUND David Chaum, considered the father of anonymous communications, proposed a system for anonymous in 1981 which is count as the the first one of its kind. He introduced the term MIX that is a server between sender and receiver performing cryptographic transformations on the messages and forwarding them to the next destination in such a way that the input address could not be linked with the output address. Most of the existing anonymous routing layers utilize Chaum- MIXes for anonymity. Figure 1. illustrates a path in a MIX system. Other technique built on the idea of Chaum-MIXes is Onion-routing, where the messages are encrypted in layers and sent through several network nodes (onion routers), which remove the upper encryption layer to uncover routing instructions. Fig. 1. Example Path in a MIX system 3

4 2 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS In the following sections I review Tor and Torsk, which are Onion-routing schemes and Tarzan, Cashmere, Salsa and MorphMix, which are Chaum-MIXes based systems. Torsk, Cashmere and Salsa also are based on DHTs for finding relays. They all represent open peer-to-peer networks. III. STRUCTURED PEER-TO-PEER OVERLAY NETWORKS A. Overview In structured P2P networks, peers employ a globally consistent protocol. Thus the nodes in the overlay can route and search for other peers. The most such networks are using distributed hash table DHT. These following are look up mechanisms, which doesn t built a whole system and actually does not employ any anonymization techniques, but they can be used as a base for building a peer-to-peer system that provides anonymity. Some of this look up mechanisms are Pastry, Tapestry, Chord and CAN. Lets just briefly describe them. In Pastry the nodes get assigned an unique IDs and maintain a list of their neighbors called leaf set, which is used for storing replicas. The IDs of the nodes included in the leaf set are numerically close to the current node-id. From a message to be send is built a key, which is used for choosing the node towards which the message will be routed. Beside the list of neighbors a node maintains also a routing table. Two options to route a message are available. First, the message is forwarded to a node-id from the routing table, which shared prefix with the key of the message is at least one bit longer than the shared prefix with the current sender. Otherwise, the message is forwarded to a node-id which shares the same prefix length, but is numerically closer to the key than the current node. Finally, if no node is found to which the message should be forwarded the destination is either the current node or its immediate neighbor. Tapestry is similar to Pastry, but the nodes don t keep a neighbors set. Tapestry also uses a surrogate routing mechanism by trying to forward the message to a node that matches the key s n-th digit. If no such node exists in the routing table, the n-th digit will be incremented till an appropriate node is found. Unlike Pastry Chord uses circular ID space and routes the messages only in clockwise direction. Chord doesn t have a routing table but maintains a so called finger table, which contains up to m pointers to online nodes. A node always is aware of it s predecessor. The more deeper an entry in the table is, the more distant node it ll point to. Chord maintains the replicas by mapping keys to node-ids. CAN is based on d-dimensional Cartesian coordinate space. A hash function is assigned to each dimension. The entire space is partitioned amongst the nodes. Each node has a routing table consisting of O(d) entries, which are the neighbors of the current node. B. Attacks 1) Attacks based on the node-id assignment [1]: The security of structured peer-to-peer overlay networks depends on the assumption that the assignment of node-ids can t be controlled from an attacker. If an attacker succeeds in finding a way to control the distribution of the node-ids she can use a lot of mechanisms to violate the network overlay. An attacker needs to control small fraction of nodes. When, in Chord, the attacker chooses appropriate node- IDs she can accomplish that all the entries in a victim s finger table point to enemy nodes. The access to a target object can also be controlled by choosing node-ids close to the target key and so the attacker can gain full control over the target object by owning all the replicas. So the attacker can delete, modify, corrupt, or deny access to the object. Using both techniques an adversary is able to reveal identities. Sybil attack: If the attacker can gain control over many legitimate nodes she can accomplish 1. and 2. without the need of freely choosing node-ids. This kind of attack is called Sybil attack. 2) Attacks based on the maintenance of the routing table [1]: The first attack works only against routing algorithms which are aiming to improve network efficiency by calculating the delays between nodes. If an attacker controls enough number of nodes she can intercept a delaycalculating request from a correct node to hostile node and get another faulty node closer to the correct node answer to the request. This way an attacker can populate the victim s routing table with bad entries. The second attack is based on the routing updates. It is hard to check their trust in network overlays like Pastry and Tapestry. The attacker can just start populating the overlay with updates pointing to hostile nodes. As result the correct nodes will announce their bad entries in the routing updates. Storage Anonymity means that a request for a particular data doesn t reveal the node storing this data. Chord doesn t provide such anonymity since the answer of such a request is the IP address of the node on which the data is stored. Problem: Pastry and Tapestry employ very weak constraints which node-ids should be granted in the routing table. This gives the opportunity to use the network proximity and thus to improve routing performance. CAN and Chord on the other side employ very strong constraints: only the closest node- IDs should be accepted in the routing tables. This improves the security, but thus the network proximity can t be used. IV. ATTACKS AGAINST GENERAL CHAUM-MIXES BASED AND ONION-ROUTING BASED NETWORK OVERLAYS A. Timing Attacks in Low-Latency MIX Systems A MIX can be defined as a proxy that hides the conversation between its incoming and outgoing connections. Routing through many MIXes provides strong unlinkablity of senders and receivers. Among the systems using MIXes for routing are 4

5 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS 3 Onion-routing, Freedom and Tarzan. Using a timing attack an adversary tries to identify, if two malicious MIXes M first and M last that belongs to him are on the same path. To reveal the Identity of the sender and the receiver one of the MIXes should be the first and and the other one the last in the chain and they must be aware of their position. This way an adversary is able to find a correlation in the timings of both malicious nodes and thus link the initiator with the receiver. The first method to exploit the attack is to compute the difference between the arrival time of packet x n and its successor packet x n+1 at M first and M last. The adversary can compare both differences and for example, if the delay at M first was large and both nodes lie on the same path the delay at M last is more likely to be larger than average. This method is sensitive to dropped packets and some otherwise perfect correlations could be identified as a mismatch. More powerful approach [8] is to use a nonoverlapping and adjacent windows of time. During this periods both malicious nodes will count the packets on every path they are belonging to. Finally the collected counts need to be compared. To make this attack even more powerful M first could drop intentionally packets to enhance the correlation. Onion-routing and the second version fo Freedom do not offer any special mechanisms to prevent timing attacks if an adversary happens to own the first and the last node of a chain. Tarzan and the original version of Freedom employ constantrate cover traffic between pairs of mixes and send traffic between covered links. Freedom however is still vulnerable to timing attacks, because the traffic between the initiator and first node and between the last node and the receiver is not covered. In Tarzan and in Freedom the mixes are able to distinguish between real and covered traffic and the malicious nodes can consider only the first for the timing attack. B. Intersection Attacks in Onion-routing Systems The Onion-routing project has drawn the attention to such kind of attacks and also named them Traffic Confirmation Attacks. This kind of attacks is based on the fact that not all the nodes are active at the same time and that users typically communicate with a small number of parties for example a user queries the same web sites in different sessions. To reveal the identities of the nodes the observer records the active users and intersects the sets. This is possible only if the observer knows all the nodes in the system. When the attacker has reduced the possible set of initiators she can switch to another tactic e.g. Packet Timing to reveal the original initiator. V. TOR SECOND GENERATION ONION-ROUTING A. Overview Tor is a Low-Latency circuit-based anonymous network overlay, thus it s main aim is to hide the identities of the clients. When a client wants to establish a connection to a server, it first obtains a list of Tor nodes from a directory server and then picks up n nodes from the Tor network and afterward builds a circuit. The messages are encrypted n times with encryption keys negotiated separately with the hops in the circuit. The first encryption is done with the key known to the last node called exit node and the last encryption is done with the key known to the first node in the circuit. This represents the so called onion routing and every node in a circuit knows only its predecessor and successor. Multiple TCP streams from one source are put together in one circuit to improve efficiency instead of building many circuits from a single node. This improves the anonymity and it is restricted to put new streams in circuits containing streams older than 10 minutes. Tor protects against non-global adversary that only control fraction of the nodes. Tor doesn t protect against attacks trying to find out, if two parties are communicating with each other by observing them this kind of attack is the already mentioned traffic confirmation attack. Tor only makes it difficult for an adversary with weak suspicions to collect more information. B. Attacks 1) Traditional traffic analysis global passive adversary: One kind of attack is to consider the time of connection initiations. Statistical variant of this attack is also developed. Both attacks could be used to determine if a specific node establishes connections to a set of web sites regularly. Low cost traffic analysis - One corrupt node in the Tor overlay network is required to accomplish this attack. The corrupt node first must establish connections to the nodes in the network to measure and monitor the latencies of those connections for some period of time. The aim of this is to determine the traffic loads of the nodes the attacker has made connection with. Then from this traffic patterns are derived. They can be used to be built a template indicating how a stream based on the reply of a server outside the overlay network will look like inside of it. A comparison of all links is needed to find similarity with the model built from the template and so even the position of a node in the circuit can be found. [6] 2) Traffic analysis non-global passive adversary: Packet Counting Lone Connection Tracking []: This attack is applicable on the 2 nd generation onion routing, Tarzan and MorphMix. The attacker only needs to observe all the links used by a connection. By counting the packets on lone connections the anonymised streams can be followed. The term lone connection means that only this connection is traveling toward a particular link. If the packets number on D->X and X->T is very similar, it can be assumed that X is communicating with T, as it can be observed on Figure 2. There are some restrictions about the measure interval to implement the attack: First, it must be larger than the mix delay. Otherwise the incoming and outgoing packet counts will be made dissimilar. Second, it must be shorter than the mean time new connections are built between the pair of links. A simulation [] in a network with 100 nodes showed that 92 Figure 3. shows a graph of the number of nodes against 5

6 4 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS Fig. 2. Packet Counting Example Fig. 4. Attack Model Against Tor TCP port the client is listening on, 3. peer ID of the client and 4. optionally the IP address of the Alice s NIC device. In return the tracker sends a sub list of peers already joined the torrent. Finally, the client sends a handshake to the peers to establish a connection with them. BitTorrent can also use DHT over UDP to search for a tracker controlling the desirable torrent. BitTorrent can run over Tor network as over proxy. So it is possible to use the Tor network for communication with the tracker and the peers. The client can decide to use Tor for only one of them or both. Fig. 3. Lone Connections Simulation the lone connections when there are 60 connections all running through 2 links. Traffic-analysis of Tor - Tor employs round-robin sending of packets. If a stream has no more cells to be forwarded, it is skipped and the node proceeds with the next waiting connection. Thus the load on a Tor node affects the latency of the connections running through it. This can be used by an attacker. An adversary can route a connection through a Tor node and with another corrupt node measure the latency to learn the traffic load of that node by connecting with it and sending probe traffic. If traffic pattern is already extracted the traffic load can be compared with it and thus an attacker is able to detect the nodes it is relayed through. The following attack is just a more powerful version of the previous one and is based on the assumption that a victim node is trying to access a corrupt server which sends the data in specific traffic pattern. Using this pattern a template can be derived and it can be checked which nodes correspond to it. One such traffic pattern could represent sequences of short bursts of data. Figure 4. shows an example model of this attack. [6] VI. BITTORRENT ON TOP OF TOR A. Overview of BitTorrent When joining a torrent Alice first sends an announce message to the tracker containing 1. unique torrent identifier, 2. B. De-anonymizing IPs in BitTorrent on top of Tor In a study [2] 6 Tor exit nodes have been mounted all over the world for 23 days. 1) Inspection of BitTorrent control messages: The tracker announces can contain the IP address of a client and according to the study 3968 unique public IP addresses were captured, which represents 58 Clients supporting the Extension Protocol may also send additionally their IP addresses. As result 1131 unique public IP addresses were collected 33 2) Hijacking Trackers Responses: The following is typical man-in-the-middle attack and works, if the client is using Tor only for communication with the tracker. The attacker Bob can hijack the tracker s response to an announce message from Alice. Then Bob can just send an altered sub list with peers where the first one is Bob himself. This way Alice will try to establish a direct connection with Bob and thus revealing her public IP address. Comparing this IP address with the public addresses of the Tor s exit nodes can show, if it belongs to Alice or to the exit nodes. Finally, 2240 unique public IP addresses were collected - 3 3) Exploitation of the DHT: As Tor doesn t support UDP the client will connect to the DHT without Tor and Alice will publish it s public IP address in the DHT and despite of the connection to the peers over Tor the IP address of Alice can still be looked up in the DHT. This is possible only when Bob is controlling Alice s exit node and so knowing her BitTorrent port number. Later Bob can search in the peer list for this torrent in the DHT and compare the port numbers. After finding a match it is possible that the published IP address belongs to Alice. This tactic resulted in 6151 unique public IP addresses. 6

7 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS 5 A. Overview VII. TORSK Torsk improves the scalability of Tor and retains the benefits of the client-server architecture claiming it doesn t introduce new attacks. Torsk distributes most of the Tor directory service over a DHT and propose usage of secret buddy nodes and certificates to keep the look up initiator anonymous. The look up mechanism is based on Kademlia DHT and Myrmic. Torsk look-up: Every node maintains a finger table and when it wants to look up data x, it first selects t (usually 3) pointers close to x. Then the querier starts independent look ups at the t pointers and builds a list with the closest nodes from every look up he has learned. Next the node selects again from every list t pointers and start the same way independent look ups. This iterative process terminates when at the end of an iteration the lists with the closest nodes to x stay unchanged. Every node has a certificate from a trusted central authority, that contains all fingers of the node. Finally, the querier can check if the node he has found is responsible for x by verifying it s certificate. During the iterative process every node included in the search learns x and if a hostile node is looked up it can associate the found node with the query initiator. Secret buddy: To remain anonymous the nodes select random buddies in the network and when a node searches for some data it gets the query executed from one of its buddies. The selection of buddies is realized with random walks before starting the look up, what prevents Timing Analysis Attacks. The buddies should be used only one time and not repeatedly. B. Attacks 1) Inherited attacks: As Torsk is just a implementation of Tor that aims to make the overlay network achieve scalability it inherits the weaknesses of the previous system. Thus all the attacks mentioned in the Tor section are applicable also against the Torsk overlay network. 2) Buddy Exhaustion Attack: Since the buddies should be used only one time on the end node of a built circuit, Buddy Exhaustion Attack can be used and thus the attacker can succeed placing malicious entry and exit nodes in many circuits. Then the attacker can apply DoS attack or use timing analysis attack. The attack consists in flooding the node that is looked up with the aim to extend the circuit. Since the random walk for selecting new buddies is restarted every time when an invalid certificate is found, the attacker can just let the malicious nodes expose invalid certificates and with enough large fraction of hostile nodes it is most likely a malicious node to be included in a random walk. Thus the victim node can t recover from the exhaustion attack. The performed study [3] shows that with this attack over 80 A. Overview VIII. SALSA Salsa is a DHT-based layered circuit anonymity scheme. Look up mechanism: The querier selects r random nodes A 1...A r and gets them separately look up for another r nodes Fig. 5. Example Binary Tree In Salsa B 1...B r. Then connections are built from each A 1...A r node to each B 1...B r node. The initiator then asks the B nodes to search for a final node. Next the querier selects a circuit randomly and connects the final node to it. The nodes get mapped trough a hash function of their IP addresses into points in the ID space. This is done for bound checking and so the closest node to a target is selected. If a path exceeds a threshold length, it is discarded. The ID space is partitioned in groups as each node knows all of the participants in its group and also knows some nodes in the other groups to route look up requests in the system. The groups are organized in the form of a binary tree. A node has a global contact for each level in the tree, which is selected at random from the child subtree where the node is not belonging to. A global contact is chosen by hashing the concatenation of the selecting node s IP address and the level height. This is done to ensure that a node cannot select arbitrary global contacts. Figure 5. shows an example for a binary tree in Salsa. B. Attacks 1) Intersection Attack: To accomplish this attack in Salsa an attacker only needs to have at least one node in each group. When 4096 groups exits, an attacker needs hostile nodes to ensure success with probability 0,9998. [4] The other mechanism of gaining overview of the network is by using the look up process. This is a long procedure and new nodes are joining over and over again. 2) Active path compromise attacks: If an attacker gets all the nodes in a particular stage compromised, she can get all the IDs/public keys of the next set of nodes, being looked up, modified. Since a node can not determine the validity of a public key the bound checking algorithm is defeated. The remaining stages of the path building can now be emulated. If the attacker gets the first and the last node in a circuit compromised she can use end-to-end timing analysis to compromise the path. 3) Conventional Continuous Stage Attack: Another way of compromising path is to have at least one malicious node at every stage of the path. Lets take the three attacks nodes A 1,

8 6 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS A 2, A 3, where 1, 2 and 3 stay for the different stages. A 1 looks up A 2, which on his turn looks up A 3. A. Overview IX. CASHMERE Cashmere is a recursive DHT based network overlay on top of Pastry DHT. A node has k-bit signed node-id. The nodes are divided in groups with m-bit IDs, where k is equal or greater than m. The group-id serves as a prefix of the nodes. A node participates in a group if the ID of the group is a prefix of its ID. Every group has assigned public/private keys and the group members receive them. The nodes obtain also the public keys from the other groups. Messages in the overlay are routed using group-ids. The first found node, that has this group-id as a prefix is responsible for forwarding the message to all other members in this group. The forwarding of messages is done through n groups. The sender encrypts separately the path and the message in layers using the public keys of the groups. Thus the same path can be used multiple times. A group in the path decrypts the path message with it s private key and finds out the next group in the path and the symmetric key to decrypt the outer layer of the message. B. Resending captured messages Attack [4] If a observer catches a message m 1 delivered to group G 1 and m 2 to G 2, the attacker can try to send m 1 over a new path, including both groups and built by the attacker. Then depending on that if m 2 is seen on the same place, where the first m 2 was caught it is sure whether G 1 and G 2 were/are neighbors on the original path. This attack is possible, because only public-private key structure is used for encryption. It is not applicable in overlays where only session keys are used for encryption. A. Overview X. TARZAN Tarzan is the first anonymizing communication system that is both self-organizing and fully-decentralized. Every node in the network is a client and a relay. Not both ends of a tunnel need to be in Tarzan for the communication. If a client wants to connect to a server not in Tarzan, the last node in the circuit (the exit node) acts as a NAT-Server. Tarzan is based on the Chaum-MIXes idea and every node in the tunnel adds or removes encryption layer depending on the direction. When joining Tarzan, a node ask k nodes already in the network to share with it mimic traffic. This means they must send him their mimics. The mimics are normal nodes in the network and the joining node builds a bidirectional connections with them. When Alice wants to establish a connection with a server, she picks up the first node n 1 of her mimic list. Then she asks n 1 for its mimic list and picks up the second node from it. This process is repeated until the path reaches length of l hops. The l + 1 node in the path is the NAT-Server and Alice picks up it randomly from her peer database. The initiator first negotiates symmetric session keys with the hops in the circuit. The IP packet that has to be send is first encrypted with the key of the last node in the tunnel and last with the key of the first node. Before forwarding the packet each node first removes the outer encryption layer and then tags the packet with the flow identifier of the next node in the tunnel. The last hop removes the last layer and sends the original IP packet. The response from the server then gets encrypted l times in the tunnel and Alice needs to perform l decryptions. B. Attacks 1) Low Cost Attack: The term low cost attack means that the attacker requires only a partial view of the network. Like the low cost attack against Tor a corrupt node must find the other nodes and establish connections with them to monitor their latencies. When the adversary is ready with the monitoring she can use the latencies information to obtain the traffic load of the nodes, she has built connections with. If the nodes were on a path to a corrupt server there will be similarity between their traffic load and the traffic load of that server. Checking all the nodes can lead to learning the whole path. For this attack to be applicable, the traffic loads of the nodes must be extracted from the latencies, as the described above Tor attack. Second, the corrupt node must be able to discover all nodes. Third, an establishment of direct connections to all of them should be possible. In the testbed of Tarzan during the study [5] a mimic part wasn t available and it wasn t possible to conduct an experiment to obtain, if the mimic mechanism is able to destroy the timing characteristics. So the problem if it is possible to extract the real traffic loads was left open. Tarzan offers the ability to discover all other nodes in the network overlay through a goosip-protocol based mechanism. The last condition is also met. Through the mimics is not possible to be established a direct connections to all nodes, unless the desired nodes are mimics of the corrupt node. But the NAT-Server node can be freely chosen and thus it is possible to be established a one-hop connection to the desired nodes if they are treated as the NAT-Server of that connection. As conclusion the applicability of the attack against Tarzan depends only on the open question if the mimic traffic can destroy the timing characteristics. 2) Intersection Attacks: Since as already mentioned a node is capable of discovering all nodes in the network an Intersection attack is thus applicable here. 3) Packet Counting Lone Connection Tracking []: As I already said in the Tor Section that this attack is applicable also against Tarzan. A. Overview XI. MORPHMIX MorphMix is a peer-to-peer anonymous network based on MIXes. Each node is a client that generates anonymous traffic and at the same time is a mix server that forwards anonymous traffic for other nodes. A node finds other nodes in the system through its neighbors. To defend against attacks based on colluding nodes that redirect to a set of other colluding nodes when a tunnel is built up, MorphMix introduces new collusion 8

9 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS detection mechanism (CDM). Each node has virtual links via TCP to its neighbors. MorphMix uses fixed size messages and layered encryption to defends against traffic analysis and also protect the message content. To build a anonymous tunnel the initiator D firsts select node A from its neighbors and establish a symmetric key with it. If the initiator wants to extend the tunnel he asks A to recommend nodes. Then D selects one of the recommended nodes, B, and gets a witness node C from the already known nodes to establish a symmetric key between D and B. This continues until D stops appending nodes to the tunnel. The witness mechanism is also used for the selection of the first node, thus a node is not aware of its position in the tunnel. CDM To improve security each node maintains a fixed size extended selection list L ES which consists of the suggested selections and the 16-bit IP prefix of the node that recommended them. To detect that a malicious node recommends another malicious nodes MorphMix distinguishes the nodes from each other by their 16-bit IP address prefix, because it is very costly for an attacker to own nodes in many unique /16 subnets. For every recommended selection a comparison in the extended selection list is made. B. Attacks 1) Intelligent Selection Attack if a colluding node knows it is the first one in the tunnel: 1) For every victim we construct a list of selections S, so that there is no overlap in the subnets between the nodes in S. 2) Global pointer p g keeps reference to a node in the list that is to be offered the next time. 3) Every time the pointer is incremented and when it refers to the last node in S the pointer is moved to the first node and the iteration goes so on. 2) Intelligent Selection Attack if a colluding node doesn t knows it is the first one in the tunnel: 1) We reply to a v s request by assigning local pointers p l to the elements referenced by p g and offer v this selection. 2) For every successive request we increment p l and offer the selection it points to. 3) After the tunnel is built up we just measure the length of the tunnel and determine if the initiator was v or some other node. 4) In the case v was the initiator we set p g to point to the elements referenced by p l. The Intelligent Selection Attack is very powerful especially against new nodes, because their extended selection lists are empty. 3) Packet Counting Lone Connection Tracking []: As I already mentioned earlier in the Tor Section that this attack is applicable also against MorphMix. Low cost traffic analysis and Packet counting are also very powerful threats that can be used against plenty of the existing anonymous communication systems. I hope this review of the attacks will motivate the development of a communication system that implements anonymization techniques and doesn t expose weaknesses which can be used to employ the attacks described in this paper and also others not reviewed here. Personally I think that the development of a new system should not follow the approaches of the existing ones and needs to take a whole new way, because analysis of the old schemes has proven that those systems could not be made resistant against all the attacks. The focus of my paper were Low-Latency Open anonymous peer-to-peer systems and I haven t reviewed any closed ones a.k.a. Darknets like Nulsoft s WASTE and Freenet. However I suggest extensions of this paper that include those systems and even more of their kind. REFERENCES [1] Miguel Castro and Peter Druschel and Ayalvadi Ganesh and Antony Rowstron and Dan S. Wallach Secure routing for structured peer-topeer overlay networks. Proceedings of the 5th symposium on Operating systems design and implementation - OSDI 02, III-B1, III-B2 [2] Pere Manils and Abdelberi Chaabane and Stevens Le Blond and Mohamed Ali Kaafar and Claude Castelluccia and Arnaud Legout and Walid Dabbous Compromising Tor Anonymity Exploiting P2P Information Leakage. VI-B [3] Qiyan Wang and Nikita Borisov In Search of an Anonymous and Secure Lookup. ACM CCS, VII-B2 [4] Andrew Tran and Yongdae Kim Hashing it out in public: common failure modes of dht-based anonymity schemes. WPES, VIII-B1, IX-B [5] Rungrat Wiangsripanawan and Willy Susilo and Rei Safavi-naini Design principles for low latency anonymous network systems secure against timing attacks. In Proceedings of the fifth Australian symposium on ACSW frontiers (ACSW 0, 200. X-B1 [6] Steven J. Murdoch and George Danezis Low-Cost Traffic Analysis Of Tor. In Proceedings of the 2005 IEEE Symposium on Security and Privacy. IEEE CS, V-B1, V-B2 [] Andrei Serjantov and Peter Sewell Passive Attack Analysis for Connection-Based Anonymity Systems. In Proceedings of European Symposium on Research in Computer Security (ESORICS, V-B2, V-B2, X-B3, XI-B3 [8] Brian N. Levine and Michael K. Reiter and Chenxi Wang and Matthew Wright Timing attacks in low-latency mix systems (extended abstract. Proceedings of the 8th International Financial Cryptography Conference (FC 2004), Key West, FL, USA, February 2004, volume 3110 of Lecture Notes in Computer Science, IV-A XII. CONCLUSIONS As we can see based on Table 1. that makes a summary of the attacks described here the Intersection Attack approach seems to be serious problem for Onion-routing schemes. 9

10 8 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS TABLE I COMPARISION Attack Protocol Salsa Cashmere TOR Torsk Tarzan MorphMIX Chaum-MIXes systems Onion Routing Time of connection initiations x x x Low Cost traffic analysis x x x x Packet counting x x x x x Traffic Analysis - corrupt Node, corrupt Server x x Intersection Attack x x Active path compromise attacks x Conventional Continuous Stage Attack x Resending catched messages x Intelligent Selection Attack x Timing Attacks x Buddy Exhaustion Attack x 10

11 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN 1 Replikationsstrategien in Content-Distributionssystemen Julian Dean Zusammenfassung Mittels Replikation können Performanz und Verfügbarkeit von Content-Distributionssystemen erhöht werden. Solche Systeme dienen der Verbreitung von Inhalten, etwa Webinhalten oder Streaming-Medien im Internet. Es existieren verschiedene Strategien für die Platzierung, Aktualisierung und Abfrage der Replikate, welche die Performanz und Verfügbarkeit maßgeblich beeinflussen. In diesem Paper wird ein Überblick über existierende Replikationsstrategien in Content-Distributionssystemen gegeben. Sie unterscheiden sich vorallem bezüglich Kommunikation (Client-Server vs. Peer-to- Peer), Informationsfluss (Push vs. Pull) und Konsistenz (stark vs. schwach). I. EINLEITUNG Content-Distributionssysteme sind im Allgemeinen Systeme, mit denen Inhalte an Verbraucher geliefert werden, beispielsweise Webinhalte oder Streaming-Medien im Internet. Solche Systeme reichen von Content-Delivery-Systemen (CDN) bis hin zu Peer-to-Peer-Systemen. Das Ziel des Betreibers ist immer, seine Inhalte möglichst wirtschaftlich einem großen Publikum bereitzustellen. Er will also wie immer in der Wirtschaft seinen Gewinn maximieren und gleichzeitig die Kosten minimieren. Dazu müssen die Daten möglichst nahe an den Verbraucher gebracht werden, damit die Auslieferung nur geringe Kosten verursacht. Dies erreicht der Betreiber für Inhalte, die nicht in Echtzeit übertragen werden müssen, durch Replikation. Das generelle Ziel der Replikation ist es, Performanz und Verfügbarkeit von verteilten Systemen zu erhöhen, etwa den erwähnten Content-Distributionssystemen. Daten und Dienste sollen effizient abrufbar und trotz Knotenausfällen oder Netzwerkpartitionen verfügbar sein. Knotenausfällen kommen beispielsweise durch Abstürze von Servern zustande. Netzwerkpartitionen treten dann auf, wenn Gruppen von Knoten durch den Ausfall von Verbindungen voneinander getrennt werden, jedoch für sich noch funktionsfähig sind. Es wird mit einem Lehrbuchbeispiel gezeigt, dass durch Replikation die beiden Ziele erreicht werden können: Bei n replizierenden Knoten mit unabhängiger Ausfallwahrscheinlichkeit p beträgt die Verfügbarkeit des Gesamtsystems 1 p n, sie kann demnach durch Replikation verbessert werden. Allerdings ist in Folge mehr Fehlertoleranz nötig, etwa muss bei gleichzeitigen Updates in verschiedenen Netzwerkpartitionen eine Synchronisierung durchgeführt werden, nachdem die Partitionierung behoben ist. Lese- und Schreibvorgänge müssen auf vielen Knoten ausgeführt werden. Da all dies aber nicht skaliert, muss häufig die Konsistenzbedingung abgeschwächt werden [CDK05], [Kla06]. Die Arbeit gibt einen Überblick über existierende Ansätze, Replikation in Content-Distributionssystemen zu verwirklichen. Dazu werden zunächst in Kapitel II Faktoren genannt, anhand derer solche Replikationsstrategien klassifiziert werden können. Danach werden konkrete Replikationsstrategien für Verschiedene Architekturen beschrieben: in Kapitel III für Client-Server-Systeme, in Kapitel IV für unstrukturierte P2P- Systeme, in Kapitel V für strukturierte P2P-Systeme und in Kapitel VI für hybride Systeme. Abschließend wird in Kapitel VII eine Taxonomie der Systeme gegeben und in Kapitel VIII ein Fazit und ein Ausblick. II. GRUNDLAGEN Es gibt grundsätzlich zwei verschiedene Arten von Replikation [SKS09]: Replikation ganzer Dateien: hierbei werden n Kopien einer Datei auf verschiedenen Knoten abgelegt. Der Nachteil ist, dass die Replikation ganzer Dateien relativ aufwendig ist. Eine Lösung ist die... Blockweise Replikation: hierbei wird eine Datei in Blöcke zerteilt, die dann auf verschiedenen Knoten abgelegt werden. Der Verlust von Blöcken ist allerdings problematisch. Eine Lösung ist die Verwendung von Auslöschungscodes (engl. erasure code), eine Art von Vorwärtsfehlerkorrektur (engl. forward error correction, FEC), mit denen verlorene Blöcke wiederhergestellt werden können. Dabei können b originale Blöcke von m kodierten Blöcken rekonstruiert werden, wobei m nur wenig größer ist als b. Bei der Konstruktion von Replikationsstrategien für ein verteiltes System sind diverse Faktoren zu beachten, anhand derer auch die späteren Algorithmen klassifiziert werden können [Kla06]: a) Kommunikation: Grundsätzlich sind zwei Arten von Kommunikation denkbar: Bei Client-Server-Systemen werden Daten auf eine bestimmte Anzahl von Knoten kopiert, beispielsweise bei Content-Delivery-Networks (CDN). Ein CDN ist ein Netz von Servern zur Auslieferung von Inhalten. Bei Overlay-Netzwerken kann die logische Struktur des Netzwerks auf der Anwendungsebene genutzt werden, um Replikate zu platzieren. Es kann aber auch anhand von Kriterien wie der Beliebtheit von Daten oder der Verfügbarkeit von Knoten repliziert werden. Zu beachten ist, dass bei gewöhnlichen P2P-Netzwerken, etwa Tauschbörsen, bereits implizit eine Replikation stattfindet, weil Benutzer lokale Kopien von Daten erzeugen. Das Ausmaß der Replikation hängt dort allerdings von der Popularität der Daten ab und ist daher nicht ausreichend, weil auch unpopuläre Daten verfügbar sein müssen. 11

12 2 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN Da insbesondere bei Overlay-Netzwerken eine starke Fluktuation von Knoten bestehen kann, müssen deren Eigenschaften wie Bandweite, Rechenleistung oder Verweildauer beachtet werden, wenn sie Replikate speichern sollen. b) Synchronisierung und resultierende Konsistenz: Bei der Synchronisierung von Replikaten kann der Informationsfluss zwischen den Knoten grundsätzlich in zwei Richtungen stattfinden: Knoten sind passiv und bekommen ihre Updates zugewiesen (Push). Die Aktualisierung von Replikaten kann auf zwei Wege geschehen, wobei das benötigte Maß an Konsistenz ausschlaggebend ist: Bei der eifrigen Replication (engl. eager replication) werden alle Replikate synchron durch eine Transaktion aktualisiert. Sie führt zu starker Konsistenz, ist bei großen Systemen allerdings ungeeignet, weil Deadlocks auftreten können. Ein Deadlock kann etwa auftreten, wenn mehrere Transaktionen gleichzeitig Knoten aktualisieren, jedoch jede Transaktion auf das Commit einer anderen Transaktion warten muss. Bei der trägen Replication (engl. lazy replication) werden Updates asynchron durch Subtransaktionen propagiert. Sie führt zu schwacher Konsistenz und kann nur eingesetzt werden, wenn veraltete Daten hinnehmbar sind. Knoten sind aktiv und erkundigen sich bei anderen Knoten nach Updates (Pull). Die resultierende Konsistenz ist schwach, da Updates nur allmählich propagiert werden. c) Schreiben: Bezüglich des Schreibens auf Knoten gibt es zwei Möglichkeiten: Es kann nur auf einen ausgezeichneten Knoten geschrieben werden. Dieser stellt somit einen Single-Point-of- Failure dar. Es wird in der Regel ein pessimistisches Replikationsprotokoll verwendet, wobei Updatekonflikte gar nicht erst auftreten dürfen. Es entsteht der Eindruck einer einzigen Kopie der Daten. Es kann auf mehrere oder alle Knoten geschrieben werden. Dabei können Inkonsistenzen auftreten, deren Behandlung zu schlechter Skalierbarkeit führt. Daher wird in der Regel ein optimistisches Replikationsprotokoll eingesetzt, wobei Updatekonflikte nur beim Eintreten behandelt werden. III. CLIENT-SERVER-SYSTEME Bei Client-Server Systemen handelt es sich beispielsweise um CDNs, welche Inhalte im gesamten Internet ausliefern. Von besonderer Bedeutung ist es dabei, Inhalte innerhalb der Domänen der Internetdienstanbieter (engl. Internet Service Provider, ISP) bereitzustellen, um den Traffic über den Backbone zu minimieren. Die folgenden Ansätze sind möglich, stellen jedoch keine erschöpfende Aufzählung dar. Es handelt sich um akademische Ansätze, nicht um industrielle. A. Klassisch Die meisten gängigen CDNs verwenden eine DNS-basierte Weiterleitung von Anfragen an Replikate (Lastverteilung). Das Problem ist, dass es sich die zentralisierten Nameserver nicht leisten können, die genauen Standorte der Replikate zu speichern. Die Replikate werden in Rechenzentren gespeichert, um eine gewisse Verfügbarkeit zu erreichen. Allerdings platziert das CDN oft mehr Replikate als nötig, was Speicher und Bandbreite verschwendet [CKK02]. B. Zufällig Die Idee hinter einem auf Zufall basierenden Ansatz rührt daher, dass ein randomisierter Algorithmus für gewöhnlich eine gute durchschnittliche Performanz aufweist. Ein möglicher Algorithmus (Random-Popularity) funktioniert wie folgt: Jedem Objekt wird eine bestimmte Popularität zugeordnet, die der Anzahl der Anfragen nach diesem Objekt entspricht. Der Algorithmus ist iterativ: Die Objekte werden in jeder Iteration absteigend nach ihrer Popularität geordnet und das populärste Objekt auf einen zufälligen CDN-Knoten repliziert. Ist das Replikat in der Nähe des Zugangsnetzes ein oder mehreren ISPs platziert, so wird die Popularität des entsprechenden Objekts mit der Anzahl der Anfragen dieser ISPs gesenkt, da diese Anfragen nun durch das Replikat bedient werden können. Damit auch unpopulärere Objekte verfügbar sind, werden mindestens k Replikate jedes Objekts erzeugt. Sehr populäre Objekte dürfen nur mehr als k-mal repliziert werden, wenn alle anderen Objekte bereits k Replikate besitzen [KMS09]. Blade Runner Popularität Attack of the Clones Replicant Metropolis Abbildung 1. Bei einer zufälligen Platzierung wird in jedem Schritt das populärste Objekt repliziert und entsprechend abgestuft. C. Baum-basiert Die Topologie des Internets kann als Baum aufgefasst werden, mit dem CDN-Knoten, von dem die Inhalte ausgehen, als Wurzel, und den einzelnen ISPs als Blättern. Nun sollen mindestens k Replikate jedes Objekts möglichst auf Pfaden zu Blättern (ISPs) platziert werden, über die viele Zugriffe stattfinden. Eine Möglichkeit (Tree Based Bottom Up) besteht darin, eine Breitensuche (Traversierung) von den Blättern ausgehend zur Wurzel durchzuführen. Dabei werden der Reihe nach auf jeder Ebene des Baums möglichst viele Objekte auf jenen Knoten repliziert, bei denen sie am populärsten sind. Da die Replikate von unten nach oben im Baum platziert werden, 12

13 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN 3 handelt es sich um das Bottom-Up-Prinzip. Die Popularität der Objekte entspricht wieder am Anfang der Anzahl entsprechender Anfragen und wird für jedes Replikat entsprechend der nun bedienbaren Anfragen gesenkt. Allerdings werden nicht mehr als k Replikate erzeugt, sodass möglicherweise nur auf den unteren Ebenen des Baums Replikate existieren. Das Resultat ist, dass sehr populäre Objekte nahe an den Blättern also näher an den Verbrauchern repliziert werden, während unpopulärere weiter oben Replikate besitzen. Daraus resultiert eine Entlastung des Netzwerks, weil gefragte Daten mit weniger Aufwand an den Mann gebracht werden können. [KMS09]. das populärste Objekt auf dem Knoten platziert, für den die durchschnittlichen Zugriffskosten aller ISPs am geringsten sind. Danach wird die Popularität des Objekts gemäß der Anfragen benachbarter ISPs gesenkt. Es wird wieder solange iteriert, bis jedes Objekt k Replikate besitzt. Es handelt sich um einen Greedy-Algorithmus, weil in jedem Schritt auf dem besten Knoten repliziert wird. AOL Telekom AT&T Metropolis 1&1 Replicant Top CDN-Knoten Blade Runner Attack of the Clones Replicant Metropolis DECIX EQUINIX Popularität Telekom Blade Runner 1&1 AOL Attack of the Clones AT&T Abbildung 2. Bei der Baum-basierten Platzierung werden populäre Objekte möglichst an den Blättern (ISPs) platziert, damit der Zugriff ökonomisch ist. D. Greedy Eine weitere Möglichkeit ist der Einsatz eines Greedy- Algorithmus, wobei in jedem Schritt ein Knoten so platziert wird, dass später minimale Kosten entstehen. Die Motivation dafür ist folgende: Wenn Anomalien auftreten, beispielsweise Knotenausfälle, so müssen die Kommunikationskosten zwischen den Replikaten beachtet werden, da bei einem Knotenausfall ein anderes Replikat in der Nähe die Anfragen übernehmen muss. Das gesuchte Verfahren ähnelt dem Facility- Location-Problem, der Platzierung von k Anbietern, sodass die Summe der Abstände jedes Verbrauchers zum nahesten Anbieter minimal ist. Der Abstand zum nahesten Anbieter ist demnach für die meisten Verbraucher relativ klein, er kann aber für einige Verbraucher auch größer ausfallen. Entscheiden ist, das die Summe aller Abstände minimiert wird. Die Anbieter entsprechen hier der Teilmenge von Knoten, die Inhalte bereitstellen, die Verbraucher den restliche Knoten, welche die Inhalte abrufen. Die Replikate (Anbieter) müssen zusätzlich so platziert werden, dass ihr Ausfall zu möglichst geringem Schaden führt. Daher platziert der iterative Algorithmus (Greedy Median) Objekte derart an Knoten (Anbietern), dass der Zugriff für alle ISPs (Verbraucher) minimale Kosten verursacht. Die Popularität eines Objekts wird wieder mit der Anzahl der Anfragen initialisiert. In jeder Iteration werden die Objekte nun absteigend nach Popularität sortiert, und Abbildung 3. Bei einer gierigen Platzierung werden Objekte dorthin repliziert, wo viele ISPs in der Nähe sind. Dadurch können sie ökonomischer abgefragt werden. Eine Optimierung des Algorithmus (Greedy Median Robust) berücksichtigt die Auswirkungen von Knotenausfällen im Worst Case. Der Ablauf ist ähnlich, allerdings werden die jeweils populärsten Objekte nicht nur solange an günstigen Knoten repliziert, bis deren Speicher ausgeschöpft ist, sondern es werden zusätzlich bestehende Replikate gelöscht, deren Verlust die kleinste Verschlechterung bezüglich des Traffics bewirkt. Des Weiteren wird am Ende verbleibender Speicher von Knoten aufgefüllt. Dazu werden Replikate von Objekten identifiziert, deren Ausfall den meisten Traffic verursachen würde. In der Nähe dieser Replikate wird das Objekt dann weiter repliziert, um den Schaden bei Knotenausfällen zu begrenzen [KMS09]. E. Dynamisch Die drei genannten Algorithmen erfordern globales Wissen sowie eine Instanz, die alle Knoten kennt und Replikate zuweist. Sie bringt auch die üblichen Probleme mit sich: Flaschenhals und Single-Point-of-Failure. Daher wird nun ein Algorithmus vorgestellt, bei dem jeder CDN-Knoten lokal entscheidet, ob Replikate weiter geklont oder gelöscht werden sollen [PPV0]. Die Entscheidung basiert auf Anzahl, Inhalt, Art von Abfragen und Last der Replikate, die der Knoten speichert. Jeder Knoten j speichert zwei Mengen benachbarter Knoten: α(j) enthält CDN-Knoten, die höchstens d max entfernt sind. Es sind Knoten, die j versorgen kann. ρ(j) enthält CDN-Knoten, die höchstens d max von Knoten in α(j) entfernt sind. Es sind Knoten, die j bei einem Ausfall vertreten können. 13

14 4 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN Anhand dieser Information kann Knoten j nun überlastete Replikate klonen und unterbelastete Replikate löschen. Der Klonalgorithmus ist rekursiv und funktioniert wie folgt: Knoten j bestimmt zunächst die Last eines einzelnen Replikats, welche der Anzahl der Anfragen entspricht. Wenn die Last einen Schwellwert überschreitet, wird solange repliziert, bis j selbst nicht mehr überlastet ist. Dazu wählt j in jedem Rekursionsschritt einen Knoten aus ρ(j), der die abzugebenden Anfragen am besten bedienen könnte, ohne dabei selbst überlastet zu werden, und repliziert auf diesem das entsprechende Objekt. Der Löschalgorithmus kann ein Replikat nur dann löschen, wenn es keine Anfragen mehr bedient, daher müssen Anfragen zuerst umgeleitet werden. Es besteht die Gefahr, dass kurzzeitig nicht belastete Replikate ständig gelöscht und kurz darauf neu angelegt werden, was dem Seitenflattern (engl. page thrashing) bei der virtuellen Speicherverwaltung ähnelt. Deshalb wird für jedes Replikat eine Zugriffshistorie gespeichert, über die längerfristig der Bedarf nach dem Replikat ermittelt werden kann. Replicant Attack of the Clones Blade Runner Blade Runner Metropolis Abbildung 4. Bei einer dynamischen Platzierung entscheiden die Knoten lokal, welche Objekte sie halten. Hier wird beispielhaft ein sehr populäres Objekt repliziert. F. Ring-basierte CDNs Es gibt CDNs mit Ringstruktur, bei denen Objekte immer über jeden Knoten des Rings gereicht werden. Für Algorithmen zur Platzierung von Replikaten können dabei ähnliche Annahmen wie bei Greedy-Algorithmen getroffen werden. Ein Algorithmus (Survival of the Fittest), der nur die Transferkosten T n,f von Objekten beachtet, die ja immer um den Ring herum gereicht werden, basiert auf dem Überleben der populärsten Objekte. Wenn ein Objekt f über den Knoten n gereicht wird, modifiziert dieser seinen Aufwand A n,f = T n,f entsprechend der Kosten, das Objekt auf sich selbst zu übertragen. Zuerst speichern nun alle Knoten jedes weiterzureichende Objekt bis sie voll sind, danach werden bestehende Objekte durch populärere ausgetauscht. Allerdings sind gespeicherte Objekte nicht unbedingt die lokal populärsten, da durch T n,f (Transferkosten von Objekt f zu Knoten n) auch die Entfernung zum entsprechenden Knoten berücksichtigt wird. Wenn ein nahe gelegener Knoten das Objekt bereits repliziert, sinkt T n,f. Der Algorithmus optimiert nur nach Transferkosten, welche nicht auftreten, falls ein Knoten ein Objekt speichert. Dabei wird nicht beachtet, dass die Speicherung ebenfalls Kosten verursacht. Ein Algorithmus (Storage Renting) der ebenfalls die Speicherungskosten S n,f berücksichtigt, ist dem erstem Algorithmus sehr ähnlich. Der Aufwand berechnet sich zu A n,f = T n,f α S n,f. Dadurch ist ein Kompromiss zwischen Transferkosten und Speicherungskosten über α steuerbar [WCDT + 06]. IV. UNSTRUKTURIERTE P2P-SYSTEME Der Vorteil dezentralisierter, unstrukturierter P2P- Netzwerke liegt darin, dass sie relativ belastbar bezüglich der Fluktuation von Peers sind. Der Nachteil ist, dass sie nicht skalierbar sind, weil Abfragen (engl. Queries) über Flooding oder Walker umgesetzt werden. Beim Flooding werden Abfragen an alle Nachbarn weitergeleitet, das P2P-Netzwerk wird förmlich überflutet. Bei Walkern werden Abfragen jeweils an einen zufälligen Nachbarn weitergeleitet, es sind infolge mehrere Walker nötig, um mit angemessener Wahrscheinlichkeit eine Datei zu finden. Weil beide Verfahren das P2P-Netzwerk stark belasten, ist die Reduzierung des Abfrageaufwands ein wichtiges Ziel der Replikation [LCC + 02]. Um das Problem zu verdeutlichen, nehme man ein vereinfachtes System mit m zu replizierenden Objekten und n Knoten an. Jedes der mit dem Index i durchnummerierten Objekte besitzt die Abfragerate q i (q steht für Query) und den Replikationsfaktor r i, wird also auf r i zufälligen Knoten repliziert. Die gesamte Anzahl von Replikaten ist somit R = m i=1 r i mit 1 < r i n. Die Summe der Abfrageraten wird normiert und ist somit m i=1 q i = 1. Das Problem kann nun wie folgt formuliert werden: Wie muss die Verteilung der R Replikate auf die m Objekte geschehen, damit der Abfrageaufwand möglichst gering ist? Drei idealisierte Verteilungen sind vorstellbar: 1) Die Replikate sind gleichverteilt, somit ist r i = R m. Die Auslastung eines Replikats ist dann proportional zu Abfragerate des replizierten Objekts, der Abfrageaufwand zum Finden eines Objekts hingegen ist für alle Objekte gleich. 2) Die Replikate sind proportional zur Abfragerate verteilt, somit ist r i = Rq i. Es entsteht eine perfekte Lastverteilung, da alle Replikate die gleiche Auslastung haben. Allerdings haben populäre Objekte einen niedrigeren Abfrageaufwand als unpopuläre. 3) Die Replikate sind proportional zur Quadratwurzel der Abfragerate verteilt, r i = λ q i mit λ = R m i=1 qi. Es entsteht eine optimale Verteilung im Hinblick auf den Abfrageaufwand. Es kann gezeigt werden, dass 1 und 2 den gleichen durchschnittlichen Abfrageaufwand verursachen, und dass bei 3 ein optimaler durchschnittlicher Abfrageaufwand besteht. Leider sind diese Erkenntnisse theoretischer Natur, in der Praxis sind sie kaum anwendbar, da kein globales Wissen über die Anzahl bestimmter Replikate existiert. Allerdings gibt es verschiedene 14

15 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN 5 Möglichkeiten, bei Abfragen auch gleich Replikate anzufertigen, um bestimmten Verteilungen nahe zu kommen. Es wird von keinem Flooding ausgegangen, sondern von k-walkern, also k parallelen Walkern zwecks Verkürzung der Suche. Der anfordernde Knoten repliziert das Objekt (owner replication, z.b. bei Gnutella). Es ist die einfachste Art von Replikation. Das Objekt wird entlang des Pfades zwischen anforderndem und lieferndem Knoten repliziert (path replication, z.b. bei Freenet). Dies führt annähernd zu einer Quadratwurzel-Verteilung, hat aber den Nachteil, dass replizierende Knoten immer auf dem selben Pfad liegen, also keine gute Streuung über das Netz stattfindet. Das Objekt wird auf p zufällige Knoten repliziert, die ein k-walker besucht hat, wobei p die Anzahl der Knoten auf dem Pfad zwischen anforderndem und lieferndem Knoten ist (random replication). Die Methode ist deutlich aufwendiger zu implementieren als die Vorige (path replication) und daher eher hypothetisch, sorgt jedoch für eine bessere Streuung der Replikate über das Netz. V. STRUKTURIERTE P2P-SYSTEME Um in strukturierten P2P-Systemen zu replizieren, werden in der Regel verteilte Hashtabellen (enlg. distributed hash table, DHT) wie Chord 1, CAN 2, Pastry 3, Tapestry 4, oder Kademlia 5 als Primitiven benutzt. Dabei kann die logische Struktur dieser Overlay-Netzwerke ausgenutzt werden, um Replikate mehr oder minder geschickt zu über das Netzwerk zu verteilen. Replikate können aber auch zufällig, je nach Bedarf nach Daten (Last) oder gemäß der Verfügbarkeit von Knoten platziert werden. Es werden im Folgenden Verfahren beschrieben, die allgemein auf DHTs anwendbar sind, aber auch solche, die nur mit speziellen DHTs funktionieren. A. Modifizierte Hashfunktion Eine Methode, die bei allen DHTs andwendbar ist, besteht in der Modifizierung der Hashfunktion derart, dass zu einem Schlüssel mehrere Werte (Replikate) gespeichert werden können. Die Platzierung der Replikaten erfolgt auf den Knoten h(index, Schlüssel), wobei jeder Instanz ein Index von 1 r zugeordnet wird (r = Replikationsfaktor) [BHW0]. Die zweiparametrige Hashfunktion h ist beispielsweise h(index, Schlüssel) = H(Index Schlüssel) ( ist die Konkatenation), sie wird also auf eine einparametrige Hashfunktion H zurückgeführt. Beim Nachschlagen spielt es eine Rolle, ob die DHT Lokalität unterstützt, also anhand eines Schlüssels erkennen kann, wie weit der zuständige Knoten entfernt ist. pdf Unterstützt die DHT Lokalität, so kann zunächst das Replikat angefragt werden, das vom nahe liegensten 1 siehe 2 siehe 3 siehe 4 siehe 5 siehe Knoten gespeichert wird. Reagiert er nicht, können weiter entfernte Knoten kontaktiert werden. Unterstützt die DHT keine Lokalität, so bleibt nichts übrig als zufällige Replikate auszuwählen und die entsprechenden Knoten zu kontaktieren bis eine Antwort vorliegt. B. Chord und Co Besitzt die DHT eine Ringstruktur wie beispielsweise Chord, so kann die Platzierung von Replikaten entweder mit Hilfe der Ringstruktur oder der Hashfunktion geschehen [LDH06]. 1) Über Ringstruktur: Die Platzierung anhand der Struktur ist bei einem Ring besonders gut vorstellbar. DHash etwa, ein Speichersystem auf Basis von Chord, repliziert einen Wert auf den r Nachfolgern des Knotens, der für den entsprechenden Schlüssel verantwortlich ist. Zur Wartung der Replikate müssen zwei Maßnahmen regelmäßig durchgeführt werden: Zwecks Instandhaltung von Replikaten sendet jeder Knoten den Schlüsselbereich, für den er zuständig ist, an seine r Nachfolger. Diese synchronisieren daraufhin ihre Daten, sodass Replikate angelegt oder aktualisiert werden. Als Optimierung können Hashbäume (engl. Merkle Tree) verwendet werden. Zwecks Prüfung der Zuständigkeit für Replikate sucht jeder Knoten den Besitzer des entsprechenden Schlüssels auf und prüft anhand dessen Nachfolgerliste, ob er selbst innerhalb von r Hops liegt. Ist das nicht der Fall, etwa weil neue Knoten zwischendrin beigetreten sind, löscht er das Replikat. Problematisch ist, dass der Ort der Replikate nicht bekannt ist. Alle Anfragen müssen über den Knoten geleitet werden, der für einen Schlüssel zuständig ist. Er leitet die Anfragen dann an Replikate weiter. 2) Über Hashfunktion: Es wird, analog zum oben beschriebenen Verfahren, eine Hashfunktion h mit zwei Parametern benutzt, um einen Wert r-mal (r = Replikationsfaktor) auf die Knoten h(index, Schlüssel) zu replizieren, wobei der Index von 1 r reicht. Der Knoten h(1, Schlüssel) ist dabei der Besitzer. Die Methode reduziert zwar die Kosten für das Nachschlagen, allerdings können die Kosten für die Kommunikation zwischen replizierenden Knoten je nach Platzierung der Replikate hoch sein. Außderdem können Allokationskollisionen entstehen, wobei zwei Replikate auf dem selben Knoten gespeichert werden nicht gerade im Sinne der Ausfallsicherheit. Über die Hashfunktion können nun verschiedene Platzierungen realisiert werden: Nachfolger: Replikate werden durch die Nachfolger eines Knotens gespeichert, was einer Nachbildung von DHash entspricht. In Chord ist dies effizient implementierbar, es kann allerings zu Allokationskollisionen kommen. Vorgänger: Replikate werden durch die Vorgänger gespeichert. Dadurch kann das Nachschlagen (engl. Lookup) effizienter bearbeitet werden, da Abfragen über die Vorgänger des Zielknotens geleitet werden, also genau über 15

16 6 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN die replizierenden Knoten, von denen sie dann bearbeitet werden können. Allerdings treten ebenfalls verstärkt Allokationskollisionen auf. Finger: Replikate werden durch die Finger eines Knotens gespeichert. Dies führt zu einer besseren Verteilung der Replikate und zu einem schnelleren Nachschlagen. Blockweise Platzierung: Der Schlüsselraum wird in r gleichgroße Gruppen zerlegt, in denen jeweils alle Daten der Gruppe durch alle Knoten repliziert werden. Dies führt zu einer besseren Verfügbarkeit. Symmetrische Platzierung: Replikate werden in gleichmäßigen Abständen im Ring gespeichert. Dadurch ist die Replikation nicht von einer wechselnden Menge von Knoten abhängig, außerdem besteht eine guten Verfügbarkeit, da Allokationskollisionen unwahrscheinlich sind. C. Tapestry Beim Routing einer Anfrage in Tapestry wird der Suffix des Schlüssels in jedem Schritt um eine Stelle aufgelöst und die Anfrage einen Knoten näher zum Zielknoten geleitet. Daher rührt die Idee, über Tapestry nahe gelegene Knoten für die Replikation zu finden. Für den Aufbau eines Tapestry-Netzes wird von gut erreichbaren Servern in Rechenzentren der ISPs ausgegangen. Sie bilden eine Art Verteilungsbaum für die Verbreitung der Objekte. Aktualisierungen werden über einen Multicast auf der Anwendungsschicht (engl. application-level multicast) verteilt. Die Lebendigkeit des Baums, die Verfügbarkeit von dessen Servern, wird durch Keepalive-Nachrichten von der Wurzel zu den Kindern hin sichergestellt. Schicken diese keine Refresh- Nachricht innerhalb eines Timeouts zurück, werden sie aus dem Baum entfernt. Die mit j durchnummerierten Server haben die Beschränkung l j (Schwellwert) bezüglich der Last, Bandbreite und Speicherkapazität. Die mit i durchnummerierten Clients haben eine Beschränkung d i (Schwellwert) bezüglich der Latenzzeit für den Zugriff auf die Server. Das Problem lässt sich nun formulieren: finde eine kleinste Menge von Servern S, sodass der Abstand zwischen jeglichem Client c i und seinem Eltern- Server s ci S durch d i beschränkt ist. Clients und Server in S organisieren sich dabei in einem Multicastbaum (auf Anwendungsschicht) mit den Clients als Blattern und derartigem Fanout f(s i ) l i der Server in S, sodass sie nicht überlastet werden. Es sind verschiedene Platzierungen von Servern denkbar, um die Daten zu replizieren. Eine naive Platzierung funktioniert folgendermaßen: Schickt ein Client c eine Anfrage über Tapestry an den Server s, so schaut dieser, ob er der Elternknoten von c ist, sprich seine verbleibende Kapazität (engl. remaining capacity) rc s > 0 ist und sein Abstand zum Client dist IP (s, c) d c. Ist das nicht der Fall, versucht er, ein Replikat auf einem Server möglichst nahe an c zu platzieren. Eine geschicktere Platzierung erweitert die Selektion der Elternknoten eines Clients auf die Eltern, Geschwister und Kinder des Servers s. Beide Platzierungen haben das Problem, dass Clients höchstwahrscheinlich keine optimale Anzahl von Replikaten erzeugen, da sie die Netzwerktopologie nicht kennen. Eine Möglichkeit für eine statische Platzierung konvertiert das Problem zu einem kapazitätsbeschränkten Spezialfall des Facility- Location-Problems (engl. Capacitated Facility Location Problem). Es gibt Lokationen i, und die dortige Platzierung eines Anbieters hat die Kosten f i. Ein Anbieter kann höchstens l i Verbraucher versorgen. Jeder Verbraucher j muss einen Anbieter i haben, für ihn entstehen dadurch die Kosten d j c ij, wobei d j die Last auf Knoten j ist und c ij die Entfernung von i nach j. Das Ziel ist nun, Anzahl und Standort von Anbietern zu finden, sodass die Gesamtkosten am geringsten sind. Leider ist das Problem NP-schwer, eine optimale Platzierung von Anbietern kann daher in der Regel nur annähernd bestimmt werden [CKK02]. D. Zeiger auf Replikate Die bisherigen Verfahren verteilen Replikate möglichst so, dass die Verfügbarkeit gewährleistet ist. Allerdings berücksichtigen sie nicht den tatsächlichen Bedarf nach den Daten. Beispielsweise können Hotspots auftreten, wobei auf bestimmte Daten sehr oft zugegriffen wird. Für deren Bedienung die bisherigen Verfahren denkbar schlecht geeignet. Eine Lösung besteht darin, die DHT nur zu benutzen, um die Lokationen von Replikaten verfügbar zu machen. Im Folgenden wird dazu beispielhaft ein Algorithmus für Chord vorgestellt, wobei ein Chord-Ring mit virtuellen Knoten und einer konsistenten Hashfunktion angenommen wird. Benutzer (de-) registrieren Replikate (in Form einer Abbildung: Dateiname Lokationen) bei einem lokalem Katalog, der über Updates verteilt wird. Der Wurzelknoten einer Abbildung, also jener Knoten, der für den Schlüssel SHA- 1(Dateiname) zuständig wäre, speichert stattdessen das Tupel (Dateiname, Katalog). Diese Abbildungen werden wegen möglicher Knotenausfälle auf r Nachfolgern des Wurzelknotens repliziert (r = Replikationsfaktor), vorstellbar wäre aber auch eine andere Strategie. Bei der Fluktuation von Knoten werden Abbildungen an neue Wurzelknoten übertragen, diese aktualisieren wiederum ihre r Nachfolger, sodass die Kataloge von Replikat-Lokationen erhalten bleiben [CCF04]. Das Problem ist, dass die Kataloge von Dateien aktualisiert werden müssen, wenn Replikate hinzukommen oder entfallen. DHTs können aber normalerweise keine Werte verändern, sondern kennen nur Operationen wie Get() oder Set(). Allerdings können Updates über die Set-Operation emuliert werden [CZ05]. Dazu beispielhaft ein modifizierter Lookup-Algorithmus für Kademlia, der bei Lookups auch gleich veraltete Kataloge auf den neusten Stand bringt: Zunächst findet der Initiator eines Lookups alle nahesten Knoten zu einem angefragten Schlüssel über die FIND_NODE-Nachricht, diesen schickt er dann eine FIND_VALUE-Nachricht. Die Knoten antworten mit dem gesuchten Wert oder, falls der Wert nicht bekannt ist, mit dem kompletten Katalog. Der Initiator findet nun die aktuellste Antwort (Wert), und aktualisiert Knoten mit veralteten oder nicht vorhandenen Werten in ihrem Katalog über STORE-Nachrichten. Das Löschen von Einträgen im Katalog entspricht einem Update mit der Länge Null [CZ05]. 16

17 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN Die beiden Algorithmen beschreiben nur, wie die Lokationen vorhandener Replikate verteilt werden können. In einem weiteren Schritt können auch die Replikate selbst in der DHT abgelegt werden. Lookups erfolgen dann in einer zweischrittigen Prozedur; zuerst werden Lokationen ermittelt, dann die eigentlichen Daten. Da die Replikate an keine DHT-Struktur mehr gebunden sind, liegt es auf der Hand, das Angebot strategisch gemäß der Nachfrage zu platzieren. E. Strategische Platzierung Es werden einige Algorithmen vorgestellt, die Standort und Anzahl erzeugter Replikate anhand bestimmter Kriterien bestimmen. 1) Anhand des Zufalls: Ein randomisierter Algorithmus (CDN-Random) wählt neue Knoten für Replikate zufällig aus dem Overlay-Netzwerk aus. Dadurch werden die Replikate im Netzwerk ungefähr gleichverteilt. Der Nachteil ist allerdings, dass Replikate unter Umständen weit weg von überlasteten Knoten platziert werden, sodass keine gute Lastverteilung stattfindet. Außerdem ist der Algorithmus bezüglich der Anzahl angelegter Replikate relativ aggressiv. Dadurch werden mehr Replikate erzeugt als wirklich nötig sind [AWZZ0]. 2) Anhand des Bedarfs nach Daten: Ein möglicher Algorithmus (CDN-QueryStat) platziert Replikate auf oder nahe von Knoten, von denen viele Anfragen herkommen. Dazu ist allerdings eine Datenzugriffshistorie nötig. Replikate werden möglichst entlang der Zugriffspfade von Queries erzeugt. Bezüglich der Anzahl angelegter Replikate ist der Algorithmus moderat. Es werden also nicht übermäßig viele überflüssige Replikate erzeugt. [AWZZ0]. Eine Optimierung des Algorithmus (CDN-PriorityBased) besteht darin, bereits replizierende Knoten möglichst mit anderen Schlüsseln aufzufüllen. Ziel ist dabei, die Anzahl replizierender Knoten und damit auch die Kosten für die Aktualisierungen von Replikaten (Traffic zwischen den Knoten) zu minimieren. Was die Anzahl angelegter Replikate angeht, ist der optimierte Algorithmus konservativ. Unter den drei aufgeführten Algorithmen erzeugt er die beste Anzahl von Replikaten. [AWZZ0]. Ein Algorithmus (Top-K Most Frequently Requested), bei dem Knoten anhand der Last aktiv selbst replizieren, funktioniert wie folgt: jeder Knoten hält eine Tabelle für alle Dateien, für die er Anfragen erhalten hat. Für jede Datei in der Tabelle führt der Knoten eine Schätzung ihrer lokalen Anfragerate. Eine einfache Schätzung wäre beispielsweise die Anzahl Anfragen nach einer Datei geteilt durch die Uptime des Knotens, als Optimierung könnten jüngere Anfragen stärker gewichtet werden als ältere. Jeder Knoten speichert nun zunächst soviele der populärsten Dateien wie möglich. Danach aktualisiert er laufend die Popularität von Dateien, und ersetzen gegebenenfalls gespeicherte Dateien durch populärere [KRT0]. 3) Anhand der Verfügbarkeit von Knoten: Ein möglicher Algorithmus (basiert auf Peer Availability Table) benutzt eine Tabelle, um über längere Zeiträume die Verfügbarkeit von Knoten im Netzwerk aufzuzeichnen. Für jede Datei wird eine FileID vergeben, die länger als die NodeID eines Knotens ist. Die Replikation einer Datei läuft wie folgt ab: zunächst werden Knoten (Kandidaten) ausgewählt, die eine ähnliche NodeID wie der gleichlange Präfix der FileID haben. Für die Auswahl wird eine Funktion und ein Schwellwert benötigt. Die Kandidaten werden anhand der Tabelle bezüglich ihrer Verfügbarkeit sortiert. Nun wird auf gerade soviele der verfügbarsten Knoten repliziert, dass die Gesamtverfügbarkeit der Datei im Netzwerk einen festgelegten Schwellwert übersteigt [SKS09]. VI. HYBRIDE SYSTEME In Overlay-Netzwerken ist die physikalische Lokation von Daten teilweise überhaupt nicht feststellbar. Es ist dann aber nicht möglich, Daten möglichst nahe an allen ISPs zu replizieren. Eine mögliche Lösung ist die Verwendung einer hierarchischen, hybriden, zweistufigen Architektur. Auf der höheren Ebene verhält sie sich wie ein klassisches CDN, Inhalte werden über das Backbone-Netz an Zwischnknoten verteilt, welche strategisch in der Nähe von Internet-Knoten platziert sind. Auf der niedrigeren Ebene verhält sich die Architektur wie ein P2P-Netzwerk, die Inhalte der Zwischenknoten werden über eine Art Zugangsnetz an die Benutzer verteilt [JLLB08]. 1

18 8 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN Replikationsstrategie VII. TAXONOMIE Client-Server Zufällig Baum-basiert die mit Hilfe der logischen Struktur des Netzwerks Replikate platzieren. Ob diese geeignet sind, um Belastungsspitzen zu bedienen, ist allerdings zweifelhaft. Eine Tatsache, die für P2P-Netzwerke spricht, ist, dass Last an die Benutzer übertragen wird. P2P-basierte Content-Distributionssysteme könnten dies verwirklichen, haben aber die üblichen Probleme wie schnelle Fluktuation von Knoten und teilweise keine Information über die physikalische Lokation von Knoten. Die Fluktuation kann eingeschränkt werden, indem Benutzer nicht Teil des P2P-Netzwerks sind, sondern Daten direkt von Knoten beziehen. Dann wird allerdings wieder keine Last auf die Benutzer übertragen. Die Beachtung der physikalischen Lokation von Knoten sollte das Ziel zukünftiger P2P-basierter Content-Distributionssysteme sein. Abbildung 5. P2P Strukturiert P2P Unstrukturiert Greedy Dynamisch Ring-basierte CDNs Über Struktur Über Hashfunktion Strategische Platzierung Taxonomie der verschiedenen P2P-Systeme. VIII. FAZIT UND AUSBLICK Replikation dient generell dazu, Performanz und Verfügbarkeit verteilter Systeme zu erhöhen. Bei der Erfüllung dieser Ziele spielt die Replikationsstrategie eine maßgebliche Rolle. Es existieren Strategien unterschiedlicher Güte sowohl für Client-Server-Systeme als auch P2P-Netzwerke. Bei Client-Server-Systemen wird in der Regel versucht, die Daten möglichst nahe beim Verbraucher zu replizieren. Für P2P-Netzwerke existieren ähnliche Ansätze, aber auch solche, LITERATUR [AWZZ0] ALQARALLEH, Bassam A. ; WANG, Chen ; ZHOU, Bing B. ; ZOMAYA, Albert Y.: Effects of Replica Placement Algorithms on Performance of structured Overlay Networks. In: Parallel and Distributed Processing Symposium, 200. IPDPS 200. IEEE International, 200, S. 1 8 V-E1, V-E2 [BHW0] BAUER, Daniel ; HURLEY, Paul ; WALDVOGEL, Marcel: Replica Placement and Location using Distributed Hash Tables. In: Local Computer Networks, 200. LCN nd IEEE Conference on, 200. ISSN , S V-A [CCF04] CAI, Min ; CHERVENAK, Ann ; FRANK, Martin: A Peer-to- Peer Replica Location Service Based on a Distributed Hash Table. In: Proceedings of the 2004 ACM/IEEE conference on Supercomputing. Washington, DC, USA : IEEE Computer Society, 2004 (SC 04). ISBN , 56 V-D [CDK05] COULOURIS, George ; DOLLIMORE, Jean ; KINDBERG, Tim: Distributed Systems: Concepts and Design. 4th Edition. Addison Wesley, 2005 I [CKK02] CHEN, Yan ; KATZ, Randy H. ; KUBIATOWICZ, John: Dynamic Replica Placement for Scalable Content Delivery. In: Revised Papers from the First International Workshop on Peer-to-Peer Systems. London, UK : Springer-Verlag, 2002 (IPTPS 01). ISBN , III-A, V-C [CZ05] CHAZAPIS, Antony ; ZISSIMOS, Antonis: A Peer-to-Peer Replica Management Service for High-Throughput Grids. In: Proceedings of the 2005 International Conference on Parallel Processing. Washington, DC, USA : IEEE Computer Society, ISBN , V-D [JLLB08] JIANG, Hai ; LI, Jun ; LI, Zhongcheng ; BAI, Xiangyu: Performance Evaluation of Content Distribution in Hybrid CDN-P2P Network. In: Future Generation Communication and Networking, FGCN 08. Second International Conference on Bd. 1, 2008, S VI [Kla06] KLAN, Daniel: Replikation in Peer-to-Peer Systemen. In: Workshop Grundlagen von Datenbanken, 2006, S Witt06.pdf I, II [KMS09] KHAN, Samee U. ; MACIEJEWSKI, Anthony A. ; SIEGEL, Howard J.: Robust CDN replica placement techniques. In: Proceedings of the 2009 IEEE International Symposium on Parallel&Distributed Processing. Washington, DC, USA : IEEE Computer Society, ISBN , 1 8 III-B, III-C, III-D [KRT0] KANGASHARJU, Jussi ; ROSS, Keith W. ; TURNER, David A.: Optimizing File Availability in Peer-to-Peer Content Distribution. In: INFOCOM th IEEE International Conference on Computer Communications. IEEE, 200. ISSN X, S V-E2 [LCC + 02] LV, Qin ; CAO, Pei ; COHEN, Edith ; LI, Kai ; SHENKER, Scott: Search and replication in unstructured peer-to-peer networks. In: Proceedings of the 16th international conference on Supercomputing. New York, NY, USA : ACM, 2002 (ICS 02). ISBN , IV 18

19 REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN 9 [LDH06] LESLIE, Matthew ; DAVIES, Jim ; HUFFMAN, Todd: A Comparison of Replication Strategies for Reliable Decentralised Storage. In: Journal of Networks 1 (2006), Nr. 6, S jnw html V-B [PPV0] PRESTI, Francesco L. ; PETRIOLI, Chiara ; VICARI, Claudio: Distributed Dynamic Replica Placement and Request Redirection in Content Delivery Networks. In: Proceedings of the th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems. Washington, DC, USA : IEEE Computer Society, 200. ISBN , III-E [SKS09] SONG, Gyuwon ; KIM, Suhyun ; SEO, Daeil: Replica Placement Algorithm for Highly Available Peer-to-Peer Storage Systems. In: Advances in P2P Systems, AP2PS 09. First International Conference on, 2009, S II, V-E3 [WCDT + 06] WAUTERS, Tim ; COPPENS, Jan ; DE TURCK, Filip ; DHOEDT, Bart ; DEMEESTER, Piet: Replica placement in ring based content delivery networks. In: Comput. Commun. 29 (2006), October, DOI /j.comcom ISSN III-F 19

20 P2P SERVICE DESCRIPTION LANGUAGE 1 P2P Service Description Language Dimitar Goshev Abstract P2P networks are increasingly used for different kinds of services, which could be generally implemented in a P2P cloud system. Technologies known from the Service Oriented Architecture, such as description languages for services could be a powerful tool in such a P2P service cloud. This paper gives an overview of the Service Oriented Architecture, describes the role of a P2P service description, and introduces the Ontology Web Language for Services as a description language for P2P services. It illustrates that a description language for P2P services could provide substantial value to the P2P computing paradigm and is one of the technologies and machanisms that will allow transition from file-sharing to service- and data-sharing in P2P networks. I. INTRODUCTION In the recent years P2P netowrks are increasingly used for a variety of services. The diversity among the types of P2P services, along with the different kinds of P2P systems, has made it difficult to establish a widely accepted set of standards and protocols, that would facilitate the description of P2P services. Each one of the contemporary P2P networks accommodates its own proprietary set of protocols, which are arbitrarily designed in a way to enable their specific features and properties. They present limited or no capabilities for automated service discovery, selection, composition and invocation. A description of P2P service, which provides sufficient information to enable mechanisms for publishing and discovery of the service in the P2P network and facilitate interaction between the peers, could be one way to address these issues. An interpretaion of such a description must be consistent among all the participants in a service interaction. Therefore a necessity to establish a standartized approach for describing the services arises. In this paper this is addressed by introducing the Ontology Web Language for Service(OWL- S) as a description language for P2P services. Thus enabling description of P2P services, that can be used unambiguously across and between different implementations. OWL-S allows the service description to answer questions, such as What does the service provide?, How is the service used? and How to access the service? in a machine-understandable form. Descriptions in OWL-S are in no way limited to services, which follow the client/server model. In fact the research shows, that by introducing semantics to service description, OWL-S enables mechanisms to discover and locate services in P2P netwrorks and is powerful enough to describe details on how to divide composite services into sections, which can be executed by different execution peers. This paper is organized as follows: In order to present traditional approaches to service description, discovery and invocation, chapter 2 gives an overview of the Service Oriented Architecture(SOA), an architecture designed to support the implementation of services. Chapter 3 provides information about the role of a P2P service description language and the speciffic issues, which a P2P service description will address. Chapter 4 gives a detailed view of OWL-S and how it could be used for P2P service description and chapter 5 presents briefly alternatives, which has been considered during this research. II. SERVICE ORIENTED ARCHITECTURE When we deal with the notions of service and service description, it is inevitable to have a look at the Service Oriented Architecture(SOA), in order to gain knowledge about the traditional approaches to service description, discovery and invocation. SOA is an architecture designed to support the implementation of services. It could be defined as a set of design principles for building large loosely coupled systems, which package functionality as inter-operable services. SOA defines an interaction model between three primary parties - the service provider, the service broker and the service client [Figure 1]. Figure 1. The three primary roles in the service interaction model. The service provider creates the service description and implementation and publishes its interface and access information to the service registry. The service broker manages registries, and supplies information about services to enables clients to discover the service. The service client locates entries in the broker registry and binds to the service provider in order to invoke the given service. A. Overview of techologies in SOA The traditional service solutions use a server-centric approach to manage all components. This limits their deployment to static domains, since a service invocation will fail, if 20

21 2 P2P SERVICE DESCRIPTION LANGUAGE the server component changes its availability or location. The services are typically defined by a set of standards, including Extensible Markup Language(XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery and Integration(UDDI). These technologies are described bellow. 1) SOAP: Commonly an invocation of a service is accomplished through exchange of a series of messages, normally encoded in XML. SOAP, a lightweight protocol for exchange of information in a decentralized, distributed environment, is the most widespread technology for exchanging these messages. The protocol consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data-types, and a convention for representing remote procedure calls and responses[8]. SOAP typically depends on other Application Layer protocols, most notably Remote Procedure Call (RPC) and Hypertext Transfer Protocol (HTTP), for message negotiation and transmission. However the SOAP/TCP[9] and SOAP-over-UDP[5] specifications, present an alternative approach, which eliminates the need of application layer protocol. SOAP also provides mechanism for binary data transfer. That is the SOAP Message Transmission Optimization Mechanism(MTOM) - a W3C recommendation by Microsoft, IBM, EBA and Canon. MTOM makes use of the XML-binary Optimized Packaging(XOP) format for optimizing the transmission of SOAP messages. It combines the composability of Base 64 encoding with the transport efficiency of SOAP with Attachments(SwA). Non-XML data is processed just as it is - the data is simply streamed as binary data in one of the Multipurpose Internet Mail Extensions(MIME) message parts. Solutions for data transfer with MTOM, such as file transfer in chunks, exist and demonstrate the feasibility of using this technology for data transfer in P2P networks. Experiments show that XOP/MTOM, keeps performance of binary data transfers via service interface at a reasonable level[15]. Other alternatives for handling binary data in SOAP messages are also available: SwA and Direct Internet Message Encapsulation(DIME). 2) WSDL: The WSDL definition describes how to access a service and what operations it will perform. The data-types for the information passed between the service consumer and provider are described using WSDL. The services are described as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint[3]. A WSDL document uses the following elements to describe a service: Types - a container for data type definitions using some type system. XML Schema is used (in-line or referenced) for this purpose. Operation - an abstract description of an action supported by the service. Four types of operations exist: a request-response,where the client expects response from the service, a solicit-response,where the service expects a response from the client, one-way operation, representing a call by the client to the service, and a notification, representing a call by the service to the client. Interface - an abstract set of operations supported by one or more endpoints. Binding - a concrete protocol and data format specification for a particular port type. Endpoint - defines the address or connection point to a service. Service - a collection of related endpoints, which has been exposed to the web based protocols. 3) UDDI: The discovery of the services is facilitated by UDDI. It defines a standard method for publishing and discovering the network-based software components of a SOA. The core information model used by the UDDI registries is defined in an XML schema. The UDDI XML schema defines four core types of information: business information, service information, binding information, and information about specifications for services. UDDI provides only a central registry [2]. Figure 2 illustrate a traditional scenario of development and deployment of services. Figure 2. B. P2P and SOA The traditional services development/deployment scenario. From the described technologies above it is clear, that the traditional service solutions, present an approach, where the three main parties of the interaction model are commonly thought of as separate entities. However, it is more useful to consider the client, the provider and the broker as simply different behavioral roles, rather than separate pieces of software. In fact SOA doesn t impose a particular implementation style such as specifically a client/server, request-response model. The alternative approach to service interaction, namely services communicating in a P2P fashion, requires each node to accumulate one, two or all of the roles simultaneously. 21

22 P2P SERVICE DESCRIPTION LANGUAGE 3 In a P2P SOA, each node should be able to act as a provider of a set of services, a consumer of a service, and a broker, which offers information about services presented by the node and other nodes in the network. Of course, the nodes are responsible for their own security, reliability, process, and management capabilities. III. DESCRIPTION OF P2P SERVICES In order to provide a P2P service description language, first we need clear definitions of What is a P2P service? and What is the role of the P2P service description?. A. P2P Service A service is defined as a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description[12]. In [10] is stated that, the term P2P service has emerged as a result of the merging of P2P and service oriented computing paradigms and that the term itself has not yet reached consensus among the P2P community. The definition of a service is not restricted to services following client/server approach. Therefore in this paper the term P2P service is considered equivalent to the term service defineded above, with the additional knowledge, that these services are used in a P2P network. B. P2P Service Description In general the description of a P2P service should present sufficient information to enable mechanisms for publishing and discovery of the service in a P2P network and facilitate interaction between the peers. While, there are certain elements that are likely to be part of any service description, many elements such as function and policy may vary. The specific goals of the description could be summarized as follows: Publication and Discovery - Describe what this service does and how to locate it in the P2P network. Present such a description, that could be used by discovery systems, which perform on distributed registries on ad hoc and managed networks. Specify the set of constraints and policies, under which the service operates. Selection - Provide enough details about the service capabilities and other critical information, that a client needs in order to decide whether or not, the described service is the most appropriate one for the given task. Service invocation - Provide information on how the client can interact with the service and how exactly to access it. This information should be preferably presented in a way understandable not just for developer of a client agent, but for a software agent, to enable automated invocation of P2P services. Composition - Present information on how to combine multiple services in the P2P cloud to achieve the desired goal. The description should contain enough detail on how to divide the described composite service into sections, which can be executed by different execution peers. Verification and Monitoring - Supply information about how to verify the service execution and recognize when errors occur, log and track progress of the execution. Security - Provide information about how to address issues such as authentication, authorization and privacy, evalute security parameters, etc. In the next chapter is illustrated that description of P2P services with OWL-S, accomplishes to supply the necessary information to achieve all of the listed above goals. IV. OWL-S The Ontology Web Language for Services is an ontology for services. It is often referred as a semantic markup language for describing services, due to the fact that it provides a standard vocabulary to create service descriptions, comprehensive enough to support the entire lifecycle of service tasks[4]. It is formerly known as DARPA agent markup language for services(daml-s) and some of the researched materials reffer it as such. OWL-S is based on the Ontology Web Language(OWL), a semantic markup language for publishing and sharig ontologies. In OWL ontologies are primarily exchanged as RDF documents(an RDF/XML serialization). OWL-S presents a semantic markup to describe what is being sent and why, not just how it is being sent. It has been developed as a joint effort between Carnegie Mellon University, Nokia, Stanford University, SRI International and Yale University as an aim to provide ontology, which automates the discovery, invocation, composition, interoperation and monitoring of servicess. It complements existing technologies such as SOAP, WSDL, UDDI, and Web Services Business Process Execution Language (WS-BPEL) by providing rich typing and class information that can be used to describe and constrain the range of service capabilities much more effectively than XML data types[13]. OWL-S supplies an abstract or application level description absent in other description languages such as WSDL. The OWL-S ontology includes three primary subontologies: the service profile, service model, and grounding[ Figure 3 ]. Genrally the service profile provides information about what does the service provide, the service model, also referred as process model gives information on how to use the service, and the service grounding supplies the necessary details about accessing the service. A. Service Profile The service profile is a high-level characterization of the service. It defines explicitly what are the server capabilities and what it provides. Its main purpose is to enable advertising, discovery and selection for services. It contains two type of properties, that describe the service - non-functional and functional properties. 22

23 4 P2P SERVICE DESCRIPTION LANGUAGE Figure 3. Top level of the service ontology. The non-functional properties describe what is achieved by the service, its limitations and boundaries, as well as other information such as location of the service, QoS features describing its characterics, etc. The functional properties consist of inputs, outputs, preconditions and effects. 1) Inputs, Outputs, Preconditions and Results: Inputs represent the the object descriptions that the service works on, i.e. the information that the service will receive. Outputs represent the object descriptions that it produces, i.e. the information that the client will receive. Preconditions define what must be satisfied in order the service to function as expected and effects, also known as results, describe what conditions will be changed after the service completes. Inputs, outputs, preconditions, and effects are used, by all three components of an OWL-S service model. The service profile could contain only the ones that are necessary for the discovery and selection of the service. B. Process Model All services described with OWL-S are represented by an instance of the OWL class service, which properties associate it with a process model. A process model[ Figure 4 ] describes how the service is used, i.e. how it executes its tasks. It contains all of inputs, outputs, preconditions and effects, to describe precisely the behavior of the service. The process model decribes three type of processes: composite, atomic and simple processes. Atomic processes correspond to the actions a service can perform by engaging it in a single interaction. Simple processes, can be used to provide abstracted, non-invocable views of atomic or composite processes. Composite processes are decomposable into other (non-composite or composite) processes[1]. The composition is created through control constructs. The available control constructs are: Sequence - a list of control constructs to be done in order. Split - process components to be executed concurrently. Split + Join - same as Split with additional barrier synchronization. Choice - for execution of a single control construct from a given set. Figure 4. Top level of the process ontology. Any-Order - processes, which have to be executed in some unspecified order but not concurrently. If-Then-Else - conditional control constructs. Iterate, Repeat-While, and Repeat-Until - for iteratation over a given set until a condition becomes false or true The process model could be used to automate the interaction with P2P services. There exist a working solution for automatic automatic invocation of services described in OWL- S, namely the OWL-S VM. C. Grounding The service grounding specifies the details on how to interact with the service. It enables service calls to be translated to messages for use by transport protocol languages. For example the grounding could be used to create mapping to WSDL[ Figure 5 ] or Universal Plug and Play (UPnP) Figure 5. Mapping between OWL-S and WSDL. 23

24 P2P SERVICE DESCRIPTION LANGUAGE 5 D. Other Ontologies Apart from the ontologies described above, OWL-S defines an ontology for the required resources. This ontology covers the description of physical resources, temporal resources and computational resources related to the services. In [23] is described a method for extending the monitoring capabilities of OWL-S through event based monitoring. An additional Event Ontology is introduced to achieve that and enable further capabilities for logging, performance measuring, evaluations of security parameters and execution progress tracking of services. OWL-S also creates a layer of abstraction on top of the various existing security standards, such as XML Signature, WS-Security, etc, as well as abstraction for security notations such as Authentication, Authorization, AccessControl, Confidentiality, Privacy, Anonymity, Negotiation, KeyDistribution, etc. This is achieved through several security related ontologies. These are namely the Credential Ontology, Security Mechanisms Ontology, Service Security Extensions Ontology, Agent Security Extensions Ontology, Privacy Ontology and Cryptographically Annotated Information Object Ontology. E. P2P Service Discovery Solutions for service discovery in a P2P network with semantic descriptions support are described in several papers( [20], [14], [21], [22], [18] and [1]). They all describe capability-based service discovery in systems, which doesn t contain a central registry. The described in [18] and [20] P2P service discovery mechanisms use OWL-S for service description and rely on the Gnutella P2P protocol. An actual implementation of platform independent and highly flexible service discovery system for ubiquitous peer-topeer networks is described in [1]. Again OWL-S is used for service description, WSDL is used for interface descriptions, and SOAP for remote invocation over a JXTA P2P infrastructure. The inference engine JTP (Java Theorem Prover) is used as reasoner for evaluating the service capabilities. The author of this paper concludes, that reasoning using an inference engine and semantic descriptions, allows powerful service discovery. F. Automated Service Invocation OWL-S supplies declarative, computer-interpretable API that includes the semantics of the arguments to be specified when executing service calls, and the semantics of data returned, when the services succeed or fail. Therefore services described in OWL-S could be automatically invocated in contrast to the traditional approach, where an agent is preprogrammed to perform calls to the particular service. An existing solution for automatic invocation is OWL-S VM. This implementation also takes into account privacy and authorization constraints that cryptographic techniques can implement. Peers using services implementing the OWL-S VM are able to maintain secure communication with other peers. SOAP security annotations are used to implement the actual message encryption or signing. [] V. ALTERNATIVES In the course of this research several others alternatives for service description were considered. These are WS-CDL, WSCI, WSMO, WSDL-S, PSDL, to name a few. Here are briefly presented two other languages, which were considered as main alternatives of OWL-S. A. WS-CDL WS-CDL describes P2P collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior, where ordered message exchanges result in accomplishing a common business goal. WS-CDL is targeted for composing interoperable P2P collaborations between any type of Web Service participant regardless of the supporting platform or programming model used by the implementation of the hosting environment[6]. In WS-CDL the collaboration between services takes place within a set of agreements about the ordering and constraint rules, through which messages are exchanged between participants. However it is widely accepted that the language has several drawbacks which makes it impractical. It is lacking separation between meta-model and syntax as well as comprehensive formal grounding[11]. As a further drawback it is difficult to write WS-CDL specifications that can be considered elegant or intuitive and specifications of even smaller interactions become rather lengthy[19]. Few implementations exist s.a. WS-CDL Eclipse and LTSA WS-Enginee but both were last updated in The last specification of the language is from 2005 and the W3C Choreography Working Group was closed in B. WSMO Web Service Modeling Ontology(WSMO) is to some extend similar to OWL-S. It is based on concepts from the Web Service Modeling Framework(WSMF) It defines four components: Ontologies - provide the terminology and formal semantics for describing the other elements in WSMO. Goals - consist of non-functional properties, imported ontologies, mediators used, post-conditions and effects. Web Services - provide a semantic description of Web services, including their functional and non-functional properties. The main descriptions are the capability and the interface. Mediators - represent connectors that resolve heterogeneity problems in order to enable interoperability between heterogeneous parties[16]. In contrast to OWL-S, at the moment software tools and libraries for WSMO are rare. VI. CONCLUSION Contemporary P2P networks accommodate their own proprietary set of protocols and provide limited or no capabilities for automated service discovery, selection, composition and invocation. OWL-S and other service description languages were examined as possible solution to address these issues. 24

25 6 P2P SERVICE DESCRIPTION LANGUAGE The research showed that OWL-S is capble to create description for services, which are comprehensive enough to support the entire lifecycle of service tasks. Moreover it accomplishes to provide descriptions, that enable mechanisms for service discovery on ad hoc and managed networks, as well as automated invocation of services. A varieity of authoring tools, libraries and APIs for the language, give this language another advantage over its competitors. The research showed that a description language of P2P services could provide substantial value to the P2P computing paradigm and is one of the technologies and machanisms that will enable transition from file-sharing to service- and datasharing in P2P networks. REFERENCES [1] OWL-S Release 1.2 :: IV-B [2] UDDI Technical White Paper II-A3 [3] WSDL Specification :: II-A2 [4] OWL-S: Semantic Markup for Web Services W3C Member Submission :: IV [5] SOAP-over-UDP Specification :: II-A1 [6] Web Services Choreography Description Language Version 1.0 W3C Candidate Recommendation :: V-A [] OWL-S Technology for Representing Constraints and Capabilities of Web Services :: IV-F [8] SOAP W3C Recommendation Version 1.2 :: II-A1 [9] SOAP/TCP Version 1.0 Reference :: II-A1 [10] M. Pantazoglou A. Tsalgatidou, G. Athanasopoulos. A P2P Service Description Language Specification: Technical Report. III-A [11] Phillipa Oaks Alistair Barros, Marlon Dumas. A Critical Overview of the Web Services Choreography Description Language (WS-CDL) V-A [12] F. McCabe P. Brown R. Metz C. Matthew MacKenzie, K. Laskey. Reference Model for Service Oriented Architecture 1.0. III-A [13] Drew McDermott Sheila McIlraith Massimo Paolucci Katia Sycara Deborah L. McGuinness Evren Sirin David Martin, Mark Burstein and Naveen Srinivasan. Bringing Semantics to Web Services with OWL-S IV [14] Valeria De Antonellis Devis Bianchini and Michele Melchiori. Servicebased Semantic Search in P2P Systems. IV-E [15] Andrew Wendelborn Donglai Zhang, Paul Coddington. Binary Data Transfer Performance Over High-latency Networks UsingWeb Service Attachments. II-A1 [16] D.Roblek. Decentralized Discovery and Execution for Composite Semantic Web Services. V-B [1] Daniel Elenius. Service Discovery in Peer-to-Peer Networks. IV-E [18] Ching-Chien Chen Farnoush Banaei-Kashani and Cyrus Shahabi. WSPDS Web Services Peer-to-peer Discovery Service. IV-E [19] Lars Ake Fredlund. Implementing WS-CDL. V-A [20] Takuya Nishimura1 Naveen Srinivasan1 Massimo Paolucci1, Katia Sycara1. DAML-S for P2P Discovery. IV-E [21] Jian Yang Mike P. Papazoglou, Bernd J. Krämer. Leveraging webservices and peer-to-peer networks. IV-E [22] Marek Paralič and Gabriel Gécy. Web Services discovery in P2P registry with semantic descriptions support. IV-E [23] Katia Sycara Roman Vaculín. Semantic Web Services Monitoring: An OWL-S based Approach. IV-D 25

26 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES 1 Cheating Detection in P2P-based Massive Multiplayer Online Games Georgi Hadshiyski Abstract In the recent years there has been a lot of development of Massive Multiplayer Online Games (MMOGs), which has shown to be very profitable and is now a billion-dollar industry. However because of the huge number of players, the normal client-server architecture approach doesn t scale well and it becomes increasingly hard to support the traffic and the computational power needed for the servers. A peer-to-peer approach to the game development solves those scalability issues. However this new approach is more cheating-prone because the server loses most of the control over the game state. Cheating in MMOGs is a serious issue because it can lead to player dissatisfactions and losses for the companies providing games. In this paper we review and compare different types of cheating, discuss why cheating is a problem and look into the ways to detect and prevent cheating in MMOGs. I. INTRODUCTION In the recent years there has been an enormous growth in the availability and the speed of the internet connection throughout the globe. This enabled the creation of massive multiplayer games where hundreds, thousands or even millions of people can play together inside a virtual game world. This new genre of computer games has been very successful and profitable. The game called World of Warcraft (WoW) now has more than 12 million subscribers worldwide and the company that created the game (Blizzard Entertainment) collects revenue in the billions each year. Although the development of Massive Multiplayer Online Games (or MMOGs) have shown to be quite profitable, the huge number of people playing simultaneously introduces a completely new set of problems. The main problem is the difficulty to support the game server. On one hand big server farms are needed just for the computation of the game state. This is very expensive and can be error-prone because it introduces a single point of failure. On the other hand the sheer number of people playing at the same time requires a huge amount of traffic going in and out of the server. This can also become expensive with the growth of the number of people simultaneously playing and can lead to game lag if the server can t support that many people. Game lag can be very frustrating to players and thus can lead to players dissatisfaction, resource misuses and profit losses. To tackle the scalability problems, a peer-to-peer approach can be used to decentralize the game. In the normal client-server approach all of the information is transferred between the server and the player and the game state is computed at the server. With the peer-to-peer approach however, most of the game traffic and game state computation goes between the players themselves, thus relieving the huge computational and bandwidth pressure on the server. That way the game can scale well even with million of people playing at the same time. This not only saves money on servers and bandwidth, but also increases the stability of the system. Although this approach solves the scalability issues in MMOGs quite well, it also introduces other problems. With this peer-to-peer decentralization the server loses most of the control it has over the correctness of the game state. With the computation of the next game state happening in the clients themselves, it becomes easy to manipulate and cheat inside the virtual game world. Cheating prevention is very important in the development of any multiplayer game. If there are cheaters in the game, the normal players can easily become frustrated with the gameplay and thus stop playing. This problem is even more serious in MMOGs because most of them operate by requiring a monthly subscription fee from the players. So the reduction of the number of players means direct profit losses. Cheating detection and prevention is extremely important to ensure commercial viability of P2P-based MMOGs. The rest of the paper is organised as follow: In the following Section of the paper we review a typical game architecture in order to better understand the relationships between the different entities both in centralized and decentralized MMOPGs. In Section 3 we discuss the possible implementation types of cheating detection architectures. After that we define and review different categories of cheating. By providing this classification we can better understand the cheating possibilities and then be able to tackle each of those problems separately. The fifth Section makes comparisons with similar work in this area done by other authors and in the end we make conclusions about the plausibility of cheating prevention in this kind of systems and the need for future work. II. GAME ARCHITECTURE A typical server-client oriented MMOG has the architecture shown on Fig.1. First, there is an authentication server which is responsible for account management.(a) Then there is a game server, which is responsible for maintaining the game state(b). All of the clients(c,d,e) are communicating directly with the game server after they have logged in. As seen in Fig.2, in a P2P-oriented MMOG architecture the management of the game state is outsourced to the client. The only centralized server left is the authentication server(a). The computational power and traffic needed for maintaining a login system is not that high and thus decentralization of account management is not needed. In this kind of architecture however there is no longer a need for a game server. Instead, 26

27 2 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES Fig. 1. Client-Server based game architecture server in order to create and maintain different constraints on the clients. Although easily implemented, this approach suffers from the scalability issues that come from the use of a server-client oriented architecture. With an increased number of players, the computational power needed for cheating detection rises and becomes very costly. Another possibility is to outsource the detection system to the client nodes. This approach is better suited for a peer-to-peer based game architecture because it enables good scalability. In this kind of cheating detection architecture the clients themselves are computing and verifying the validity of other players actions. The general idea is that although a single client node can t be trusted, a consensus between few random nodes can be trustworthy enough to provide good cheating prevention. A few not affiliated client nodes are chosen as monitoring nodes and are responsible for cheating detection for a certain number of players. If inconsistencies are detected, a majority vote is taken in order to determine the correct action. [1] discusses the problems stemming from P2P-based cheating detection and proposes a plausible implementation. The third option for cheating detection is a hybrid between previous two proposals. Such approaches try to minimize the cheating risks that stem from a decentralized detection system, while still maintaining low server computational and traffic requirements. Log Auditing[4] is one such proposal. This implementation outsources the game state to the client machines in order to maintain good scalability. However the cheating detection mechanism remains on the server. In order to reduce traffic and computational server requirements, the cheating detection is not computed in real time. Instead, the different game state changes are recorded and analysed at a later time. This reduces the computational power pressure because the server can use periods of time with lower demand in order to check for cheating. Although there is a delay between the cheat and the cheat detection, with good logging the game can easily be rolled back to revert the damage done by the cheater. Fig. 2. P2P-based game architecture a number of game clients (with enough resources) are chosen in order to maintain the game state(b). The game space is divided into subareas and each subarea has a responsible node. Other players(c,d) in this subarea are communicating with their responsible node instead of the server. Thus the local state of a sub-area is held at the responsible node and the whole game state can be seen as the sum of the game states of each of these subareas. III. CHEATING DETECTION ARCHITECTURES There are three possible approaches to implement cheating detection and prevention mechanisms. The first approach is to detect cheating on the server side. In this case the developing company provides a big server (or server farms) that makes sure no cheating is taking place. A possible approach [3] is the symbolic execution on the IV. TYPES OF CHEATING In order to better understand and defend against the different cheating possibilities, a classification of those cheating attempts is needed. In this Section we review the different categories of cheating according to the target of the attack. First we review cheats that are possible in multiplayer games in general. Every multiplayer game needs to deal with those cheating possibilities (or at least part of them) regardless of the types of architecture the game uses. After that we review cheating that stems from the use of a P2P-based architecture. A game client can exploit the fact that the system is decentralized to get an advantage over other player or players. Here we discuss what can be exploited and show examples of different cheating attempts. A. Categories of cheating Almost all multiplayer games suffer from cheating attempts regardless of the number of players and the type of game architecture. Although most games are not played for financial 2

28 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES 3 or other gain, but only for entertainment instead, there are still a lot of people that try to gain an illegal advantage over their fellow players. This can frustrate a lot of people and thus the game can lose its appeal. In this Subsection we are categorizing the types of cheating that can take place in multiplayer games in general, including P2P-Based MMOGs. To better illustrate the problems, there are examples for each of those categories. 1) Authentication Cheating: This is one of the most frequently seen security problems in network applications in general. In almost all multiplayer games the server provides some kind of an authentication system with which the player can identify himself (usually by providing user-name and password or something similar). A cheater can exploit weaknesses in this authentication system in order to gain access to somebody else s account and/or virtual assets. One possibility is to exploit the fact that a lot of players use weak passwords that can easily be cracked with a dictionary attack or in some cases even by a brute force approach. Another possibility is to exploit weaknesses in the implementation of the authentication system itself. For example some games use a regular telnet connection (where the username and the password are transmitted as plain text between the client and the authentication server). A cheater can snoop this connection in order to get access to the login information of another player s account. In some cases (if the server cannot authenticate himself to the client) a hacker can get access to hundreds of accounts by simulating the authentication server. In this case the clients are unwillingly sending their account information to the cheater instead of the real authentication system. Although this kind of cheating can never be completely prevented due to the possibility of human error, most of this kind of cheating attempts can be evaded through good authentication server design. The server needs to authenticate itself to the client to prevent server impersonation and all traffic between the client and the server (especially the password) needs to be encrypted - this way we can prevent account information snooping. In addition the server can require the players to register with a longer and more complicated password (for example containing at least one number and at least one special character). Thus we can prevent password guessing success with high probability. 2) Client Modification Cheating: This cheating possibility arises when too much trust is put into the client. A cheater can modify his game client or machine in order to perform illegal actions or get access to information he is not supposed to. For example there are the so called "wall hacks" in the game "Counter Strike"[cs]. In this case the cheater exploits the fact that his client receives information about the position of all other players regardless of who the player can actually see in the game. With a slight client modification the cheater can see all enemies (through the walls), although he is not supposed to. This problem comes from the fact that the server trusts every client with all player positions instead of only those visible from the player s current position. The cheater can then exploit this knowledge to gain advantage over the other players. There are a few ways to prevent modification cheating. The easiest way is to restrain the trust put on the client. For most online games the actions of the player and the results of those actions can be checked in the server against the current game state to see if they are valid. With peer-to-peer MMOGs however this becomes more complicated because a lot of the game state management is outsourced to the clients themselves - usually through the use of responsible nodes or a similar approach. This problem can be solved by the use of monitoring nodes that make sure all the players are playing fair. Another way to prevent this type of cheating is to introduce additional software that prevents any client modification. Every client needs to install this additional software before playing the game. If a cheater then attempts to modify his game client or use some kind of helping tools, this additional protection software can detect and prevent that. Although this approach has already been implemented and shows promising results, this piece of software is still on the client machine so it is theoretically possible to hack it as well. 3) Outside Information Cheating: One of the biggest problems in multiplayer games is the fact that the server cannot refrain a client from accessing information outside the game architecture. In this type of cheating a player can gain advantage over the other clients by using access to information outside of the game. For example, a chess player can use an advanced computer program to calculate his next move. This way his opponent stands no chance since even the best chess players often lose against those advanced chess programs. That way the cheater gains a huge advantage by using outside information. For another example let s look at a four-person game of poker. If three of the players are talking to each other over the telephone and giving each other information about what cards they have, then the forth person will definitely lose his money sooner or later no matter how skilled he is, or how much luck he has. In this case the three cheaters are exploiting an outside line of communication to gain an advantage over the unsuspecting forth player and thus win the game. There is no plausible way to completely prevent this type of cheating without invading user privacy. The only way to reduce the risk of this type of cheating is to design the game in a way to prevent it. For example, lets consider again the four-person poker game. If the players in a game are chosen randomly then it will be hard for three cheaters to collaborate against the forth, because the odds are that they are all going to play in different games (on different tables). This kind of solution is however game specific and has its limitations both in terms of success and in terms of reduction of game flexibility. 4) Server Attack Cheating: In some rare cases a hacker can gain direct access to the server of a game if it is not well protected. One possibility is a direct attack. Although rare, in some cases it is possible for a cheater to gain access to the server by exploiting a security weakness on the target machine. Another, more common possibility, happens when the cheater has direct physical access to the server - for example 28

29 4 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES if he is working for the company that makes the game. If this happens the cheater can not only gain an advantage, but basically decide everything in the game. In games with a client-server architecture the hacker can directly change the game state to do whatever he wants. Even in very decentralized peer-to-peer games where the current game state is held mostly at the clients, the cheater can still change the game state because the server always has the authoritative say. Server attacks can be prevented through good server security design. If there are no major security flaws in the server then an outside attacker will not be able to gain unrestricted access. Good company policies against inside cheating can prevent server attacks on the internal level as well. With peer-to-peer approaches this problem becomes even less dangerous, because most of the work is outsourced to the clients. The server itself has less functionality and is therefore less bug-prone because of the lower code complexity. 5) Client Attack Cheating: A cheater can directly attack another player s computer in order to gain advantage in the game. Although rare, sometimes a hacker can use vulnerabilities on a target client machine to gain access to it. In most of the cases the hacker uses a trojan horse or a worm in order to control other people s computers. With this access the cheater has complete control over the other player and can easily beat him in the game. Another possibility is to attempt a Denial of Service attack. This is especially dangerous in peer-to-peer oriented architectures. The cheater can flood the enemy player with packets, thus slowing down his connection. This way the cheater gains an advantage because he can stop the enemy player in key moments or at least slow down his reactions because of the slower connection. A special case of client attacking is the use of social engineering methods to obtain certain information about another player. (or to achieve a certain goal). For example the cheater can ask a victim to see one of his items and then after that not return it. Or in some extreme cases even obtain the victim s login and password by sending an pretending to work at the company that created the game. In the normal client-server architecture this is not a big problem, because most clients are secure enough for these types of attacks. The cheater doesn t have direct access to the target computer and unless the target has been somehow infected with malicious software, the chances of attack success are relatively small. This problem however becomes a lot more complicated with peer-to-peer MMOGs. This approach introduces the possibility of responsible and monitoring nodes sending misleading packets to each other, to other clients or to the server. There isn t much to be done about the special case of social engineering cheating attempts. The risk can be reduced by warning all players about that possibility. However in the end human error is always a factor, so a complete prevention of social engineering attacks is not plausible. 6) Game Architecture Exploitation: In some games a cheater can exploit general problems with the implementation of a game. A player can use (known or unknown to the developer) game features to gain an advantage over the rest of the players. For example, if there is a bug in a certain game that allows the player to become immortal in very specific circumstances, then a cheater can exploit that bug and gain unintended by the developers advantage against the other players. Some of those game architecture exploitation cheats are not even bugs, but actually exist because of bad game design. For example the ranking system of some multiplayer games is calculated according to number of victories only. Two cheaters can then collaborate to cheat the system by starting and immediately ending hundreds of games. By taking turns they can both record hundreds of victory points and thus go to the top of the ranking lists without playing a single game. That way the cheater is not exploiting a bug in the program, but is taking an advantage of the badly designed ranking system. This type of cheating can be circumvent by better software quality control. Better project management and more testing can reduce the chances of bugs in the game. Better game design can prevent unintended abuse of the available game features. B. Cheating in P2P based MMOGs It is a lot more complicated to prevent cheating that stems directly from the use of a peer-to-peer game architecture. The main problem is that with this approach the server loses most of the information about the moves of the players. Even if the server makes extensive checking of the validity of a certain move, cheating is still possible because the server trusts the information coming from a certain responsible node. This information can contain a valid move but that doesn t make sure that this was the actual move the player made. In this Subsection of the paper we review detection and prevention strategies and discuss their limitations in terms of success and performance. 1) Timing Cheating: In a MMOGs with a peer-to-peer architecture most of the information transfer happens directly between the players. However there is always a time delay between the actions of the different players. Thus a cheater can try to exploit the delay in order to gain an unfair advantage against the others. The most famous example of timing exploitation is the Look-Ahead cheating. A cheater can try to delay his actions until he knows what his opponents are going to play. Thus the attacker can decide his next move by using this information and thus gain an unfair advantage against the rest of the players. To prevent Look-Ahead cheating the Lock-Step protocol can be implemented. The way this protocol works is to require from all players to send only the hash of the move they are going to make. The responsible node does this as well. In the end of the timeslot the actual moves are sent and the hash-codes are recalculated and compared. That way the responsible node knows only the hashes of the other player s moves when generating its own hash. When the actual moves become known to the responsible node it is too late for it to change its move, because the hash was already generated and 29

30 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES 5 sent. The use of monitoring nodes can prevent the responsible node from completely dropping certain packets. 2) Authority Exploitation: In most peer-to-peer games a certain number of nodes have more responsibility than the others. Those responsible nodes usually take care of a number of child nodes by coordinating them. If a responsible node is a cheater he can try to exploit this authority he has over all child nodes. For example, the cheater can delay or completely drop certain packets received from a child node. On the other hand it is possible to fabricate completely certain information in order to lie to the rest of the nodes about what a certain victim player did. In most cases those responsible nodes need to report to the server about the game state. A cheater can exploit this authority in order to lie to the server about what somebody s actions were. To prevent authority exploitation, we can use a certain number of nodes, which check whether a responsible node is attempting to cheat or not. These nodes (also called monitoring nodes) can either be chosen from the rest of the responsible nodes, or more common directly from the normal players. The player attempting to make a move sends the information both to his responsible node and to the monitoring nodes assigned to it. That way if the responsible node attempts to modify, delay or completely drop certain packets, the rest of the monitoring nodes can detect and prevent that by making a majority vote and executing the action regardless of what the responsible node did. However this approach introduces traffic overhead for all players and especially for the monitoring nodes. Big computation overhead is also possible if the monitoring nodes need to check the validity of the move. 3) Lack of Central Control Exploitation: Even if the cheater is not a responsible node but a regular node instead, he can still attempt to exploit the decentralization of the game state management. For example, the cheater can try making an illegal move. On normal client-server architectures the validity of the move can be calculated on the server. In a peer-to-peer system however the resources on the responsible node are somewhat limited, so a complete calculation of the possibility of each move for every child node becomes implausible. This becomes even more problematic if there are also monitoring nodes involved, because each of them need to calculate the validity as well. To fight against this kind of cheating we need to make sure that the moves attempted by all players are actually valid. This can be done on the server, however by doing that we lose the scalability advantage that a peer-to-peer system offers. A possible way to deal with this problem is to only log all the moves and make those checks later when the load on the server is smaller. If cheating is detected then the server can roll-back to the last secure point of the game. This solution however introduces a delay between the cheating attempt and the checking and thus the rolling back can be frustrating to players that didn t cheat but needed to lose hours of play anyway because of somebody else. A better possibility is to make those checks at the responsible (and the monitoring) nodes. Although this introduces a significant performance overhead for those nodes that make the validity checking, this solution is still a lot more scalable than using a big server. A middle-ground solution is also possible, where only the responsible node calculates the validity of the move. The server then checks a random limited number of the moves to make sure that the responsible node is not lying. Although this solution has limited ability to prevent cheating it is a good trade-off between cheating prevention and performance. 4) Collusion Cheating: A few cheaters can collaborate to exploit a security weakness, which is only possible when the cheater is not acting alone. Most peer-to-peer architectures depend on some kind of monitoring nodes, which make sure that neither the responsible node, nor the player himself is falsifying information. They can then take a vote in order to make sure that cheating attempts are prevented. However if enough monitoring nodes are actually on the cheater side then they can win the majority vote and thus go around the cheating prevention system. Collusion cheating can never be completely prevented without complete checks by the server, which would make the use of peer-to-peer architecture meaningless. However the chances of collusion cheating success can be reduced with good game architecture design. For example if the monitoring nodes are chosen randomly (instead of choosing only people located in the surrounding area) it will be a lot harder for the cheaters to succeed having the majority of the monitoring nodes. Increased number of monitoring nodes makes collusion cheating even less probable, although it introduces considerate overhead both for the monitoring nodes and for the normal players. In addition if the monitoring nodes are changed frequently we can make sure that even if the cheaters have the luck to gain the majority vote, that they will not have the control for a long period of time. Crosschecking between the different groups of monitoring nodes can also detect cheating attempts, though it introduces significant overhead as well. V. RELATED WORK The paper "A Systematic Classification of Cheating in Online Games" by Jeff Yann and Brian Randell offers a classification of the different cheating approaches that bares similarities to the ones presented in this paper. The authors classify all cheating attempts in multiplayer games into fifteen categories and review each of them. Although the paper doesn t concentrate exactly on peer-to-peer architecture approaches, the information presented there is useful to better understand the different types of cheats we see in online games. Takoto Izaiku and his team concentrate more on cheat prevention in peer-to-peer games in the paper "Cheat Detection for MMORPG on P2P Environments" that stem directly from 30

31 6 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES the decentralization of the system. In the paper the authors propose a method for cheat detection and prevention in Massive Online RPG games that uses strategies similar to the ones proposed in this paper. In the paper "Server-side Verification of Client Behavior in Online Games" the author Darrell Bethea and his colleagues propose a method for validity checking in normal server-client frameworks. Although the work doesn t concentrate on the peer-to-peer approach, the paper proposes a good system for validity checking that can be restructured to work with some peer-to-peer MMOGs. VI. CONCLUSION Although the prevention of cheating in the peer-to-peer architecture approach to the development of MMOGs is a lot more complicated than in the normal client-server approaches, it still provides the traffic scalability needed for the huge number of people playing the game simultaneously. As discussed in the paper most of the problems that arise from the decentralization of the system are quite manageable. Although there probably are more undiscovered ways to attack this kind of systems, most of the cheaters don t have the expertise to attempt something that complicated. On the other hand there is also a number of administrators that watch for anomalies in the game state, so a person suddenly gaining enormous amounts of something valuable can easily be spotted and stopped. This, together with the ease with which the game can be rolled-back to a previous stable state, makes the problem manageable. Thus at the moment the advantages of using a peer-to-peer architecture outweigh the potential risks of revenue losses due to cheating. However, this kind of games are becoming more and more popular and the number of people playing is increasing. Thus in the future we will also see an increase in the number of cheating attempts and the complexity of the cheating approaches. The increase of the number of people playing will also make it harder for the administrators to manually detect cheating attempts. However this increase in player numbers will also make the peer-to-peer approaches even more valuable because of the scalability issues with the normal client-server architectures. Because of the importance of cheating prevention more work in this field will be needed in order to ensure the fair gameplay in the future. REFERENCES [1] Takato Izaiku and Shinya Yamamoto and Yoshihiro Murata and Naoki Shibata and Keiichi Yasumoto and Minoru Ito. Cheat detection for MMORPG on P2P Environments. ACM Workshop on Network and System Support for Games, [2] Jeff Yan and Brian Randell A Systematic Classification of Cheating in Online Games. ACM Workshop on Network and System Support for Games, [3] Darrell Bethea and Robert Cochran and Michael Reiter Server-side Verification of Client Behavior in Online Games. University of North Carolina at Chapel Hill, [4] Patric Kabus and Wesley W. Terpstra and Mariano Cilia and Alejandro P. Buchmann Addressing Cheating in Distributed MMOGs. Darmstadt University of Technology, Germany,

32 P2P-BASED VIDEO-ON-DEMAND-STREAMING 1 P2P-Based Video-on-Demand-Streaming Pablo Hoch Zusammenfassung Video-on-Demand-Streaming hat sich zu einem der wichtigsten Angebote im Internet entwickelt. Durch die enorme Popularität von Video-Plattformen wie YouTube und die ständig wachsende Menge an Videos, ergeben sich hohe Server- und Traffic-Kosten für die Betreiber solcher Angebote. Mit dem Einsatz von Peer-to-Peer-Technologien können diese massiv reduziert werden. Dabei sind besondere Anforderungen wie eine Wiedergabe der Videos mit möglichst geringer Wartezeit und ohne Unterbrechungen zu beachten. Dieses Paper gibt einen Überblick über verschiedene Peer-to-Peer-Systeme für Videoon-Demand-Streaming. Dazu werden die Ansätze anhand der Struktur des verwendeten Overlay-Netzwerks in zwei Klassen unterteilt und jeweils mehrere Systeme vorgestellt. I. EINLEITUNG Video-on-Demand, also die Möglichkeit, Videos nach Bedarf und zu beliebigen Zeiten anzuschauen, hat in den letzten Jahren große Popularität erlangt. So verzeichnet beispielsweise alleine die Video-Plattform YouTube 1 täglich zwei Milliarden Videoanfragen sowie hunderttausende neue Videos 2. Klassische Video-on-Demand-Angebote wie YouTube verwenden eine Client-Server-Architektur mit großen Content- Delivery-Networks. Durch die enorme Popularität entsteht dadurch ein hohes Trafficaufkommen für die Betreiber. Dies legt den Einsatz von Peer-to-Peer-Technologie (P2P) nahe, um einen Teil der Last auf die Benutzer zu verlagern und damit die Belastung der Streaming-Server zu verringern sowie die Kosten zu senken. Eine Untersuchung von YouTube [3] ergab, dass für den Betreiber nur bei einem kleinen Teil der Videos durch den Einsatz von P2P-Technologie Einsparungen erzielt werden können. Dies liegt daran, dass ein Großteil der Videos zu selten aufgerufen wird und diese Videos daher nicht von genügend Benutzern über ein P2P-Netzwerk ausgetauscht werden. Insgesamt wird in der Studie jedoch eine mögliche Serverentlastung von 41% berechnet, wenn die Benutzer sich lediglich während der Wiedergabe des Videos in dem P2P-Netzwerk aufhalten, und sogar eine Entlastung von über 98%, wenn Benutzer die Videos einen Tag lang über das P2P-Netzwerk freigeben. Jedoch kann für Video-on-Demand-Streaming nicht einfach übliche P2P-File-Sharing-Technologie wie BitTorrent [5] eingesetzt werden, da Video-Streaming spezielle Anforderungen stellt. So möchte man eine möglichst kurze Startverzögerung erreichen und das Video anschließend möglichst ohne Unterbrechungen anschauen können. Traditionelle File-Sharing- Protokolle sind darauf ausgelegt, die Datei möglichst schnell herunterzuladen. Dazu wird die Datei üblicherweise in kleine Teilstücke unterteilt, die dann in beliebiger Reihenfolge empfangen werden. Dieses Vorgehen ist nicht geeignet, um das Video bereits während des Downloads abzuspielen. Außerdem ist Video-Streaming besonders anfällig gegenüber Churn, also dem Umstand, dass sich Peers immer nur eine gewisse Zeit in dem Netzwerk aufhalten und sich dadurch die Netzwerkstruktur häufig ändert. Hierbei besteht die Gefahr, dass ein Peer nicht mehr ausreichend Daten zum unterbrechungsfreien Abspielen des Videos erhält. Im Vergleich zu Live-Video-Streaming schauen zudem nicht alle Benutzer gleichzeitig die selbe Stelle des Videos, weshalb auch die dafür entwickelten Verfahren nicht direkt übernommen werden können. Außerdem will man oft das Springen zu einer anderen Stelle im Video, insbesondere Vorspulen, ermöglichen. Dieses Paper gibt einen Überblick über verschiedene Systeme, die Peer-to-Peer-Netzwerke für Video-on-Demand- Streaming einsetzen. Der weitere Aufbau ist dabei wie folgt: In Abschnitt II werden einige benötigte Hintergrundbegriffe kurz erklärt, in Abschnitt III wird eine Klassifikation für die verfügbaren Systeme vorgestellt und in Abschnitt IV werden verschiedene Vertreter der jeweiligen Klassen betrachtet. Abschnitt V bietet neben einer Zusammenfassung ebenfalls einen Ausblick in die aktuelle Forschung im Bereich P2P-basierter Video-on-Demand-Systeme. II. HINTERGRUND A. Application Layer Multicast Multicast bezeichnet das Senden einer Nachricht an mehrere Empfänger. Bei der Implementierung auf Anwendungsebene gibt es einen Sender, der die Nachricht an einen Teil der Empfänger sendet. Bei dem Sender handelt es sich dabei um einen Streaming-Server, die Empfänger sind die Peers im P2P-Netzwerk. Diese Peers leiten die Nachricht wiederum an andere Peers weiter usw., bis die Nachricht alle Empfänger erreicht hat. Dadurch entsteht ein Baum wie in Abbildung 1. Man spricht deshalb von Application Layer Multicast Trees (Zugriff am ) Abbildung 1. Beispiel eines Application Layer Multicast Tree 32

33 2 P2P-BASED VIDEO-ON-DEMAND-STREAMING B. BitTorrent Eines der bekanntesten und erfolgreichsten P2P-File- Sharing-Systeme ist BitTorrent [5]. Dateien werden dort in kleine Teile, auch Pieces oder Chunks genannt, aufgeteilt. Für jede Datei, die über BitTorrent verteilt wird, wird ein eigenes Netzwerk aufgebaut. Dazu gibt es zentrale Tracker-Server, die eine Liste von Peers in dem Netzwerk verwalten. Peers verbinden sich mit einem Tracker-Server, um eine Liste von anderen Peers zu bekommen, die ebenfalls die Datei herunterladen oder bereits heruntergeladen haben und diese bereitstellen. Einen großen Anteil an dem Erfolg von BitTorrent haben die verwendeten Auswahl-Algorithmen, die festlegen, in welcher Reihenfolge die Teile heruntergeladen werden und an welche anderen Peers Daten hochgeladen werden. Zur Auswahl der Reihenfolge für den Download der Teile (Piece Selection) wird hauptsächlich die Rarest-First Strategie verwendet. Dabei werden immer diese Teile zuerst angefragt, die die wenigsten der anderen bekannten Peers besitzen. Dies ist zum einen hilfreich, da dann die seltensten Teile bereits heruntergeladen sind, falls andere Peers, die diese Teile anbieten, das Netzwerk verlassen. Andererseits erhöht sich dadurch die Wahrscheinlichkeit, dass andere Peers diese Teile anfragen und dadurch mit diesen Daten ausgetauscht werden können. Um zu entscheiden, an welche anderen Peers Daten hochgeladen werden, verwendet BitTorrent einen sogenannten Unchoking-Algorithmus. Zunächst werden alle Peers choked, d.h. keine Teile an sie gesendet. In bestimmten Intervallen wird dann die Download-Geschwindigkeit des letzten Intervalls von allen Peers überprüft, und die Peers, von denen die besten Downloadraten erreicht wurden, unchoked, d.h. angefragte Teile werden an diese Peers gesendet. Damit wird versucht, Free-Riding, also das Downloaden von Daten ohne auch eine gewisse Menge von Daten an andere Peers hochzuladen, zu verhindern. Zusätzlich wird immer ein zufälliger Peer unchoked, um auch anderen Peers, von denen momentan nichts heruntergeladen wird, eine Chance zu geben. Dies wird als Optimistic Unchoke bezeichnet. III. KLASSIFIKATION Die verschiedenen P2P-basierten Systeme zum Video-on- Demand-Streaming lassen sich anhand des verwendeten Overlays grob in zwei Klassen unterteilen: Systeme, die Application Layer Multicast Trees aufbauen und Mesh-basierte Systeme, die keine explizit festgelegte Topologie besitzen. A. Application Layer Multicast Trees Bei den Systemen, die Application Layer Multicast Trees einsetzen, werden Bäume aufgebaut, bei denen das Video entlang der Kanten von der Wurzel bis zu den Blättern gestreamt wird. Dieser Ansatz wird u.a. auch für das Live- Streaming von Videos verwendet. Im Gegensatz zum Live- Streaming möchte man bei Video-on-Demand jedoch üblicherweise das komplette Video von Anfang an sehen, weshalb zusätzliche Techniken nötig sind, um den Teil des Videos vom Anfang bis zu der Abspielposition, an der sich der Elternknoten gerade befindet, ebenfalls zu erhalten. Dafür gibt es verschiedene Verfahren, die bei den entsprechenden Systemen in Abschnitt IV erklärt werden. Die Wurzel eines solchen Baums bildet jeweils ein Streaming-Server, der das komplette Video verfügbar hat. Diese Systeme verwenden in der Regel push-basierte Kommunikation, d.h. der Video- Stream wird ohne explizite Anfragen nach einzelnen Teilen im Baum weitergeleitet. Zu den speziellen Herausforderungen bei diesen Systemen zählen u.a. die hohe Anfälligkeit gegenüber Churn, da beim Verlassen eines Knotens absichtlich oder durch Ausfall alle seine Nachfolger den Stream nicht mehr erhalten, sowie die Behandlung von großen Unterschieden in der Uploadund Download-Bandbreite der Peers. Als ein möglicher Lösungsansatz des zweiten Problems wird z.b. Scalable Video Coding [15] eingesetzt. Das Video wird dabei in mehrere Streams aufgeteilt der Basisstream enthält eine Version des Videos in niedriger Qualität oder Auflösung, empfängt man zusätzlich die weiteren Streams, ergibt sich eine Version in höherer Qualität. Ähnlich ist Multiple Description Coding [1], [9]. Dort wird das Video ebenfalls in mehrere Substreams, sogenannte Deskriptoren, aufgeteilt. Zum Abspielen genügt hier ein beliebiger Deskriptor und je mehr Deskriptoren man empfängt, desto besser ist die Qualität des Videos. So kann man beispielsweise für jeden Stream einen eigenen Baum aufbauen und Peers können je nach verfügbaren Ressourcen einen oder mehreren der Streams empfangen und weiterleiten. Außerdem ist Multiple Description Coding beim Verlassen des Elternknotens in einem der Bäume hilfreich, da dann zumindest noch eine Version in niedrigerer Qualität verfügbar ist. B. Mesh-basierte Systeme Die zweite große Klasse bilden die Mesh-basierten Systeme. Hier wird beim Betreten des Netzwerks keine feste Struktur erzwungen jeder Peer baut Verbindungen zu anderen Peers auf und tauscht mit diesen Daten aus. Auch wird das Video hier nicht entlang fester Kanten gestreamt, sondern in kleine Teile aufgeteilt, die dann i.d.r. von verschiedenen Peers angefragt werden. Hierbei handelt es sich um pull-basierte Kommunikation, da jedes einzelne Teil des Videos explizit von einem Peer angefordert wird und erst auf Anfrage zurückgesendet wird. Dieser Ansatz ähnelt etwa dem bei BitTorrent verwendeten, weshalb auch viele Mesh-basierte Systeme auf BitTorrent [5] aufbauen und das Protokoll für die speziellen Video-on-Demand-Anforderungen verändern und erweitern. Die Systeme unterscheiden sich hauptsächlich in der Piece Selection, also der Auswahl, in welcher Reihenfolge die Teile des Videos heruntergeladen werden, sowie darin, mit welchen Peers Daten ausgetauscht werden. C. Vergleich der Ansätze In [12] wird die Performance der beiden Ansätze des Treebasierten und Mesh-basierten Streamings verglichen. In beiden Fällen wird dabei Multiple-Description-Coding verwendet. Die Untersuchung kommt zu dem Fazit, dass Mesh-basierte Systeme eine bessere Performance liefern. Die Hauptgründe dafür sind, dass Auswirkungen von Peers mit niedriger oder schwankender Bandbreite bei den Mesh-basierten Systemen 33

34 P2P-BASED VIDEO-ON-DEMAND-STREAMING 3 minimiert werden können, sowie die höhere Anfälligkeit von Tree-basierten Systemen gegenüber Churn. Bei den Treebasierten Systemen ist in solchen Fällen immer ein ganzer Teilbaum betroffen. IV. SYSTEME In diesem Abschnitt werden einige Systeme der beiden Klassen vorgestellt und auf die Besonderheiten der einzelnen Systeme im Vergleich zu den anderen Systemen eingegangen. A. Application Layer Multicast Trees Diese Systeme unterscheiden sich hauptsächlich bei den verwendeten Algorithmen zum Aufbau der Bäume, bei der Vorgehensweise zum Weiterleiten des Video-Anfangs, sowie der Fehlerbehandlung. 1) P2Cast: P2Cast [10] baut einen Application Layer Multicast Tree auf, um das Video zu streamen. Dazu existiert ein zentraler Server, der sowohl für den Aufbau der Topologie als auch für das Streamen des Videos an einige Peers zuständig ist. Die Peers werden dabei entsprechend ihrer Ankunftszeit in Sessions gruppiert. Der erste Peer erzeugt eine neue Session, weitere Peers, die innerhalb eines gewissen Zeitfensters nach dem ersten Peer das Video aufrufen, treten der bestehenden Session bei. Für Peers, die außerhalb des Zeitfensters der letzten Session ankommen, wird wiederum eine neue Session angelegt. Innerhalb einer jeden Session bilden die Peers zusammen mit dem Streaming-Server einen Multicast-Baum. Peers einer Session sind dabei komplett unabhängig von denen anderer Sessions. Der Server streamt das komplette Video jeweils an den ersten Peer jeder Session, die Peers leiten den Stream jeweils an ihre Kinder im Baum weiter. Dabei handelt es sich um den Base-Stream. Zusätzlich müssen Peers, die der Session erst später beigetreten sind, den Anfang des Videos erhalten, da sie über den Base-Stream nur das Video ab der aktuellen Abspielposition ihres Elternknotens im Baum erhalten. Hierzu wählt ein Peer beim Betreten des Netzwerks einen Patch-Server aus. Dabei handelt es sich entweder um den Streaming-Server oder einen Peer aus der gleichen Session. Von diesem Patch-Server erhält der Peer dann zusätzlich einen Patch-Stream, der den Anfang des Videos, den der Peer im Base-Stream verpasst hat, enthält. Nachdem der Peer den Patch-Stream vollständig empfangen hat, wird nur noch der Base-Stream benötigt. Um diesen Patch-Stream anbieten zu können, muss jeder Peer den Anfang des Videos cachen. Ein Beispiel eines P2Cast-Netzwerks mit zwei Sessions zeigt Abbildung 2. Zum Aufbau des Multicast-Trees verwendet P2Cast den Best Fit (BF) Algorithmus. Dieser beruht auf einer Messung der erreichbaren Bandbreite zwischen den Peers. Im Folgenden wird der Fall betrachtet, dass der Peer einer bestehenden Session beitritt. Andernfalls wird eine neue Session angelegt, die nur aus dem Server und dem neuen Peer besteht. So kontaktiert ein neuer Peer zunächst den Server. Dieser misst dann die Bandbreite zum Peer und fordert gleichzeitig seine Kinder auf, ebenfalls deren Bandbreite zu dem neuen Peer zu messen. Wenn ein Kindknoten die schnellste Anbindung zu dem neuen Peer hat, wird er an diesen weitergeleitet und der Prozess dort Abbildung 2. Beispiel eines P2Cast-Baums mit 2 Sessions zum Zeitpunkt 18. In den Kreisen ist jeweils die Ankunftzeit des Peers angegeben. Alle Peers in Session 1 haben den Patch-Stream bereits vollständig empfangen und benötigen nur noch den Base-Stream. In der 2. Session empfangen noch 3 Peers einen Patch-Stream. rekursiv fortgesetzt. Wenn der aktuell angefragte Knoten zu Beginn also der Server die schnellste Verbindung zu dem Peer hat, betritt der neue Peer an dieser Stelle als Kind dieses Knotens den Baum. Der gleiche Algorithmus wird sowohl zur Auswahl eines Elternknotens für den Base- als auch für den Patch-Stream verwendet. In dem Standardalgorithmus wird bei mehreren Peers mit gleicher Bandbreite zufällig einer ausgewählt. Zusätzlich werden Varianten vorgeschlagen, die in diesem Fall den Peer mit der niedrigsten Latenz auswählen (BF-delay), sowie einen Algorithmus, der keine aufwändigen Bandbreitenmessungen durchführt, sondern lediglich beachtet, ob ein Peer noch genügend Uploadkapazität für einen weiteren Stream zur Verfügung hat und dann ebenfalls nach Latenz einen Peer auswählt (BF-delay-approx). Dieser letzte Algorithmus hat somit einen deutlich niedrigeren Overhead als BF. In allen Fällen kann es vorkommen, dass weder der Server, noch einer der Peers genügend freie Bandbreite für einen weiteren Peer zur Verfügung haben und der Peer deshalb abgelehnt wird. Sobald ein Peer dem Netzwerk beigetreten ist, muss sichergestellt werden, dass dieser den Base-Stream und, falls nötig, den Patch-Stream mit einer ausreichenden Downloadrate erhält. Dies wird von den Peers ständig überwacht. Sollte die Geschwindigkeit nicht mehr ausreichen, oder die Verbindung abbrechen, wird ein Recovery-Prozess gestartet. Dieser wird immer von dem Wurzelknoten des betroffenen Teilbaums durchgeführt. Dazu versucht der Peer, dem Netzwerk neu beizutreten. Hierfür wird der gleiche Algorithmus wie beim ursprünglichen Betreten des Netzwerks verwendet. Zu beachten ist, dass nur solche Peers als Patch-Server in Frage kommen, die der Session vor dem anfragenden Peer beigetreten sind. Sofern dies gelingt, ist der gesamte Teilbaum wieder ein Teil des Netzwerks. Sollte der Wurzelknoten des abgetrennten Teilbaums dem Netzwerk nicht wieder beitreten können, versuchen dies anschließend dessen Kinder. 2) P2VoD: P2VoD [] benutzt ebenfalls Application Layer Multicast Trees zum Streamen des Videos, unterscheidet sich 34

35 4 P2P-BASED VIDEO-ON-DEMAND-STREAMING aber in einigen wesentlichen Punkten von P2Cast. So wird bei P2VoD kein Patch-Stream für später ankommende Peers benötigt. Um ohne diesen zusätzlichen Stream auszukommen, cachen die Peers nicht den Anfang des Videos, sondern jeweils die zuletzt empfangenen Daten. Somit kann ein Peer das komplette Video in einem Stream an einen später ankommenden Peer weiterleiten, solange er zum Beitrittszeitpunkt des neuen Peers noch den Beginn des Videos im Cache hat. Das Video wird dazu in durchnummerierte Blöcke, sogenannte R-Blocks für retrieval blocks, unterteilt. Jeder Peer hat einen Cache, der maximal eine bestimmte Anzahl Blöcke aufnehmen kann. Um das Caching zu vereinfachen, enhält ein R-Block immer die Videodaten für eine Zeiteinheit, z.b. für eine Sekunde. Auch bei P2VoD gibt es Sessions: Wenn ein Peer dem System beitreten will und keine sogenannte offene Session, d.h. eine Session in der es Peers gibt, die noch den ersten Block des Videos im Cache haben, mehr existiert, muss eine neue Session erstellt werden. Neu ist die Gruppierung der Peers innerhalb einer Session in Generationen. Dabei werden die Peers anhand des R-Blocks mit der niedrigsten Nummer in deren Cache in Generationen unterteilt. Zu beachten ist, dass die Größe des Caches zwischen den Peers variiert. Der erste Peer einer Generation benutzt immer die maximale Cachegröße, der Cache später ankommender Peers der gleichen Generation ist jedoch kleiner, entsprechend der Differenz in deren Ankunftszeiten. erste Generation der Session. Da Peer C 3 dem Netzwerk erst zum Zeitpunkt 2 beigetreten ist, der erste Peer in der gleichen Generation (C 1 ) jedoch zum Zeitpunkt 0, ist der Cache von C 3 um 2 R-Blöcke kleiner als der von C 1. Somit ist sichergestellt, dass alle Peers einer Generation den gleichen ersten R-Block im Cache haben. Würde zum Zeitpunkt 20 ein neuer Peer dem System beitreten, würde eine neue Session angelegt, da in der Session 1 kein Peer mehr den ersten Block des Videos im Cache hat. Falls beim Betreten des Systems durch einen neuen Peer keine offene Session existiert, wird eine neue angelegt und das Video direkt vom Server gestreamt. Andernfalls kontaktiert der neue Peer einen Peer der jüngsten Generation einer offenen Session. Von diesem bekommt er eine Liste von Peers der nächstälteren Generation und wählt einen dieser Peers als Elternknoten aus, falls möglich, d.h. falls dieser noch den Anfang des Videos gecached hat. Andernfalls wird eine neue Generation angelegt und einer der Peers aus der bis dahin jüngsten Generation als Vater gewählt. Der Server streamt das Video jeweils an die Peers der ersten Generation, diese leiten es an die der zweiten Generation weiter usw. Der Hauptgrund für die Verwendung von Generationen liegt in der Fehlerbehandlung, die bei P2VoD im Gegensatz zu P2Cast in der Regel ohne den zentralen Server durchgeführt werden kann. Dazu werden bereits im Vorfeld zwischen den Peers einer Generation Nachrichten ausgetauscht, um eine Liste von anderen Peers in der gleichen Generation zu bekommen. Diese wird außerdem an die Kinder in der nächsten Generation weitergeleitet. Im Falle dass der Stream zu einem Peer abbricht, besitzt dieser dann eine Liste von anderen Peers in der nächstälteren Generation. Wie bei P2Cast führt hier auch wieder nur der Wurzelknoten des abgeschnittenen Teilbaums die Recovery-Prozedur durch. Er kann jedoch nun direkt die Peers aus der ihm bekannten Liste kontaktieren und versuchen, dort dem System wieder beizutreten. Nur falls dies fehlschlägt, muss der Server kontaktiert werden. Abbildung 3. Beispiel einer P2VoD-Session zum Zeitpunkt 20. In den Peers (Kreise) ist deren Ankunftszeit angegeben. Ein R-Block entspricht dabei einer Zeiteinheit, d.h. Peer C 3 ist z.b. dem Netzwerk beigetreten, als Peer C 1 bereits zwei Blöcke empfangen hatte. Unter den Peers sind jeweils die Blöcke angegeben, die sich zu diesem Zeitpunkt im Cache des Peers befinden. In Abbildung 3 ist ein P2VoD-Netzwerk zum Zeitpunkt 20 gezeigt. Dort bilden die Peers C 1, C 2, C 3 und C 4 die B. Mesh-basierte Systeme 1) BASS (BitTorrent Assisted Streaming): Bei BASS [6] handelt es sich um ein sehr einfaches System, das ein Client- Server-System zum Streamen des Videos durch einen parallelen Download von Teilen des Videos über BitTorrent ergänzt. Wie bei BitTorrent üblich, wird das Video hierbei in kleine Teile zerlegt. Die Clients verbinden sich mit einem Streaming- Server, der dem Client zunächst die Teile des Videos von Beginn an in Abspielreihenfolge sendet. Gleichzeitig wird über einen Tracker-Server eine Verbindung zum BitTorrent- Netzwerk aufgebaut und hierüber Teile des Videos ausgetauscht. BASS achtet dabei darauf, dass keine Teile doppelt, also vom Streaming-Server und zusätzlich über BitTorrent, heruntergeladen werden. Insbesondere werden von dem Streaming-Server die Teile in Abspielreihenfolge heruntergeladen und dabei Teile, die bereits über BitTorrent empfangen wurden, übersprungen. Weitere Veränderungen an BitTorrent werden nicht vorgenommen. Es werden also die üblichen Rarest-First-Piece-Selection sowie der Standard Unchoking- Algorithmus verwendet. 35

36 P2P-BASED VIDEO-ON-DEMAND-STREAMING 5 2) BiToS (BitTorrent Streaming): BiToS [16] ist ein weiteres BitTorrent-basiertes System. Im Gegensatz zu BASS ist hierbei jedoch kein seperater Streaming-Server nötig. Stattdessen konzentriert sich BiToS auf eine Anpassung des Piece- Selection-Algorithmus, um sowohl das Abspielen des Videos während des Downloads zu ermöglichen, als auch gleichzeitig immer noch eine gute Verteilung der einzelnen Teile des Videos zu gewährleisten. Die Grundidee hinter BiToS ist, Teile des Videos, die als nächstes abgespielt werden sollen, bevorzugt herunterzuladen. Dazu werden die Pieces, die noch heruntergeladen werden müssen, in zwei Mengen aufgeteilt: Das High-Priority-Set beinhaltet eine bestimmte Menge von Teilen, die direkt auf die aktuelle Abspielposition folgen, aber noch nicht heruntergeladen wurden. Alle anderen, noch nicht empfangenen Teile befinden sich im Remaining-Pieces-Set. Dabei gibt es zwei veränderbare Parameter: die Größe des High-Priority- Sets, sowie eine Wahrscheinlichkeit p, die bei der Piece- Selection entscheidet, aus welcher Menge als nächstes ein Teil heruntergeladen wird. Mit Wahrscheinlichkeit p wird ein Teil aus dem High-Priority-Set heruntergeladen, mit Wahrscheinlichkeit 1 p ein Teil aus dem Remaining-Pieces-Set. Bei Simulationen hat sich ein Wert von p = 0.8 als gut erwiesen [16]. Innerhalb des Sets wird dann ein Teil nach dem Rarest-First-Prinzip ausgewählt nur wenn es mehrere gleich seltene Teile gibt, wird das mit der näheren Abspielposition ausgewählt. Während die Größe des High-Priority-Sets bei BiToS konstant ist (die Autoren haben durch Simulation einen Wert von etwa 8% des Videos als optimal ermittelt), kann die Wahrscheinlichkeit p auch zur Laufzeit angepasst werden. Dies kann beispielsweise durchgeführt werden, wenn ein Teil, der abgespielt werden soll, noch nicht heruntergeladen wurde. Falls zu diesem Zeitpunkt bereits viele andere noch nicht abgespielte Teile bereits heruntergeladen wurden, wird die Wahrscheinlichkeit erhöht, um bevorzugt Teile aus dem High- Priority-Set anzufragen. Sind hingegen keine weiteren solche Teile vorhanden, wird die Wahrscheinlichkeit heruntergesetzt, um mehr zufällige Teile zu erhalten und somit attraktiver für andere Peers zu werden. 3) Toward Efficient On-Demand Streaming with BitTorrent: In [2] wird ebenfalls eine Erweiterung des BitTorrent- Protokolls für Video-on-Demand-Streaming vorgeschlagen. Ähnlich wie bei BiToS wird der Piece-Selection-Algorithmus ausgetauscht und die noch fehlenden Teile des Videos in zwei Mengen aufgeteilt. Neu ist, dass hierbei die Größe des Fensters (entspricht dem High-Priority-Set bei BiToS) zur Laufzeit angepasst wird. So wird das Fenster vergrößert, wenn bereits viele der als nächstes abzuspielenden Teile heruntergeladen wurden, und verkleinert, wenn davon nur sehr wenige vorhanden sind. Dadurch, dass die Menge vergrößert wird, erhöht sich die Verteilung der Pieces (Piece Diversity). Durch das Verkleinern wird sichergestellt, dass die in Kürze benötigten Teile möglichst schnell heruntergeladen werden. Als weitere Verbesserung wird innerhalb des Fensters nicht Rarest-First als Piece Selection verwendet, sondern eine sogenannte Portion-Policy, bei der mit einer gewissen Wahrscheinlichkeit Rarest-First und ansonsten In-Order Selection, d.h. Download der Teile in Abspielreihenfolge, verwendet wird. Untersucht wurde hier auch der Einfluss von Peers, deren Uploadrate geringer als die Abspielrate des Videos ist. Dabei ergeben sich für die Peers mit ausreichender Uploadrate kaum Nachteile, selbst wenn 30% der Peers keine ausreichende Uploadbandbreite zur Verfügung stellen nur etwa 2-3% der Daten sind nicht rechtzeitig zum Abspielzeitpunkt angekommen. Außerdem wurden Peers, die keinerlei Daten hochladen, simuliert. Wie erwartet, erreichen diese nur geringe Downloadraten, während die sich normal verhaltenden Peers kaum beeinträchtigt werden. 4) Tribler: Bei Tribler [14] handelt es sich um ein P2P- File-Sharing-System, das auf BitTorrent aufbaut und dieses um diverse Funktionen erweitert. Der Fokus liegt dabei auf dem Aufbau eines sozialen Netzwerks, was sowohl das Finden von Dateien vereinfachen, als auch die Downloadraten erhöhen soll. Im Gegensatz zu vielen der anderen Systeme, die davon ausgehen, dass ein Benutzer nur während der Wiedergabe des Videos ein Teil des P2P-Netzwerks ist, ist Tribler mehr darauf ausgelegt, dass Teilnehmer über einen längeren Zeitraum online sind. Die Peers werden anhand ihrer Interessen in Gruppen eingeteilt, daraus ergeben sich die sogenannten Taste-Buddies. Für das Streaming von Videos bietet Tribler zwei wesentliche Neuerungen: Zum einen Collaborative-Downloading mit dem 2Fast-Protokoll, bei dem befreundete Peers bei dem Download von Dateien helfen, und das Give-to-Get-Protokoll, welches durch Überwachung der Peers versucht, Free-Riding zu verhindern und außerdem einige speziell auf Video-Streaming zugeschnittene Anpassungen enthält. Diese beiden Neuerungen werden in den folgenden Abschnitten beschrieben. 5) 2Fast: Die Idee hinter 2Fast [8] ist, dass ein Peer, Collector genannt, von befreundeten Peers, Helpers genannt, Unterstützung beim Download einer Datei anfordert. Die Helpers laden dann ebenfalls Teile der Datei herunter und senden diese an den Collector. Sowohl der Collector als auch die Helper laden die Datei normal über BitTorrent herunter. Bevor jedoch ein Helper einen Teil der Datei herunterlädt, fragt er beim Collector nach, ob dieser Teil noch benötigt wird, d.h. noch nicht heruntergeladen wurde und kein anderer Helper diesen Teil gerade herunterlädt. Anschließend sendet der Helper den heruntergeladenen Teil an den Collector, ohne eine Gegenleistung zu erwarten. Mit 2Fast kann die Downloadgeschwindigkeit von Peers mit asymmetrischen Internetanbindungen, d.h. solchen, bei denen die verfügbare Upload-Bandbreite geringer als die Download- Bandbreite ist, gesteigert werden. In einem Test mit verschiedenen ADSL-Anschlüssen konnte damit eine Steigerung der Downloadgeschwindigkeit um bis zu Faktor 2-6 erreicht werden. 6) Give-to-Get: In Tribler wird außerdem Give-to-Get [13] verwendet, um Free-Riding zu minimieren. Die Grundidee dabei ist, dass Teile des Videos bevorzugt an solche Peers hochgeladen werden, die diese Teile wiederum an andere Peers weiterleiten. Free-Rider, also solche Peers, die keine oder nur sehr wenige Daten an andere Peers senden, bekommen dadurch nur dann eine akzeptable Downloadrate, wenn genügend Uploadkapazität im Netzwerk vorhanden ist. Der Vorteil bezüglich Video-Streaming gegenüber dem standardmäßigen BitTorrent-Unchoking-Algorithmus ist, dass nun Teile nicht 36

37 6 P2P-BASED VIDEO-ON-DEMAND-STREAMING mehr nur an Peers hochgeladen werden, von denen auch Teile heruntergeladen werden können. Da beim Video-Streaming bevorzugt Teile in der Nähe der eigenen Abspielposition angefragt werden, eignet sich der Standardalgorithmus hauptsächlich für Peers mit ähnlicher Abspielposition, weil diese viele Teile untereinander austauschen können. Wenn sich aber ein Peer erst am Anfang des Videos befindet, ist dieser zwar an den Teilen eines anderen Peers, der bereits fast das gesamte Video heruntergeladen hat, interessiert, aber nicht umgekehrt. Deshalb ist ein Unchoking-Algorithmus, der auf der Anzahl der weitergeleiteten Teile basiert, für Video-Streaming besser geeignet. Der Unchoking-Algorithmus wird so modifiziert, dass immer die drei besten Forwarder unchoked werden. Wie bei BitTorrent wird auch immer ein zufälliger Peer unchoked (Optimistic Unchoke). Die Bewertung eines Peers q durch einen Peer p geschieht dabei nach der Anzahl der Pieces, die q innerhalb des letzten Intervalls an andere Peers hochgeladen hat. Dabei werden zunächst nur solche Teile berücksichtigt, die q von p erhalten hat. Sollten mehrere Peers die gleiche Anzahl an Teilen weitergeleitet haben, werden alle von diesen hochgeladenen Teile berücksichtigt. Um an diese Zahlen zu kommen, sendet q an p eine Liste der Peers, an die er Teile hochlädt. Peer p fragt dann bei diesen Peers nach. Dadurch soll verhindert werden, dass Peers falsche Angaben über die Anzahl der hochgeladenen Pieces senden. Dieses Szenario ist in Abbildung 4 dargestellt. Peer p lädt zu q Daten hoch, dieser leitet sie an die Peers x und y weiter. Der Peer p fragt dann x und y nach den von q weitergeleiteten Teilen. dem Low-Priority-Set. Innerhalb des Mid- und Low-Priority- Sets werden die Pieces wie bei BiToS nach dem Rarest-First Prinzip ausgewählt, in dem High-Priority Set jedoch In-Order. Eine Ausnahme davon ist die Prebuffering-Zeit: Bevor mit dem Abspielen des Videos begonnen wird, werden zunächst alle Pieces in dem anfänglichen High-Priority-Set in Rarest- First Reihenfolge heruntergeladen. Anhand der bisherigen Downloadgeschwindigkeit wird dann die voraussichtlich verbleibende Downloadzeit ausgerechnet und mit der Wiedergabe begonnen, sobald diese unter der Dauer des Videos liegt. ) RINDY: Bei RINDY [4] liegt der Fokus auf effizienter Unterstützung von Änderungen der Abspielposition durch Springen innerhalb des Videos. Hierzu besitzt jeder Peer eine Liste von Peers mit weiter entfernter Abspielposition. Für den Beitritt zum Netzwerk gibt es einen Tracker-Server, der jedem Peer neben einer Liste von anderen Peers ebenfalls einen von mehreren Streaming-Servern zuweist. Die Peers speichern die zuletzt abgespielten Teile des Videos und tauschen diese untereinander aus. Um die Startup-Verzögerung zu minimieren, speichert jeder Peer ebenfalls den Anfang des Videos. Die Nachbarn eines Peers werden anhand der Differenz der Abspielposition auf Ringe aufgeteilt. Der innerste Ring, Gossip-Ring genannt, beinhaltet andere Peers mit ähnlicher Abspielposition und überlappendem Buffer. Die äußeren Ringe, Skip-Ringe genannt, beinhalten Peers, deren aktuelle Abspielposition weiter entfernt ist. Abbildung 4. Beispiel eines Give-to-Get Netzwerks. Peer p lädt Teile an Peer q hoch, der diese wiederum an x und y hochlädt. Peer p erhält durch Nachfrage bei x und y die Informationen darüber, wieviele Teile q an andere Peers weitergeleitet hat. Neben dem neuen Unchoking-Algorithmus kommt bei Give-to-Get ebenfalls ein neuer, auf Video on Demand zugeschnittener, Piece-Selection-Algorithmus zum Einsatz. Ähnlich wie bei BiToS werden die Teile in verschiedene Mengen eingeteilt. Give-to-Get verwendet hier jedoch drei Mengen: Ein High-Priority-Set für die als nächstes abzuspielenden Teile, ein anschließendes Mid-Priority-Set und ein Low-Priority- Set für alle restlichen Teile am Ende des Videos. Die Mengen haben hier eine feste Größe und beginnen immer direkt an der aktuellen Abspielposition, können also auch bereits heruntergeladene Teile enthalten. Bei der Piece-Selection werden immer zuerst alle Teile aus dem High-Priority-Set heruntergeladen, dann aus dem Mid-Priority-Set und erst anschließend aus Abbildung 5. Beispielausschnitt aus einem RINDY-Netzwerk. Gezeigt ist ein Peer p sowie andere Peers, die in Ringe um p aufgeteilt sind. Bei dem inneren Ring handelt es sich um den Gossip-Ring, bei den äußeren Ringen um Skip-Ringe. Jeder Peer verwaltet eine Liste mit einer gewissen Anzahl von Peers aus dem Gossip-Ring, sogenannte Near-Neighbors, sowie aus jedem Skip-Ring, sogenannte Far-Neighbors. Für jeden Skip-Ring wird außerdem eine Liste mit Backup-Peers verwaltet, um Ersatz für Far-Neighbors zu haben, die das Netzwerk verlassen. Die Ringe eines Peers p und dessen Verbindungen zu anderen Peers sind in Abbildung 5 dargestellt. Innerhalb des Gossip-Rings tauschen die Peers regelmäßig Nachrichten mit ihren Abspielposition und Buffer-Zustand 3

38 P2P-BASED VIDEO-ON-DEMAND-STREAMING (vorhandene Pieces etc.) mit ihren Nachbarn aus. Diese Nachrichten werden auch an andere Peers in dem Ring weitergeleitet, um neue Nachbarn zu finden. Wenn ein Peer seine Abspielposition durch Springen innerhalb des Videos verändert, benötigt er neue Nachbarn in der Nähe der neuen Position. Hierzu wird eine Lookup-Operation über die Ringstruktur gestartet. Befindet sich die neue Position außerhalb des Gossip-Rings, wird eine Anfrage an den bekannten Peer gesendet, der am nächsten an der neuen Position liegt. Wenn sich die gewünschte Position in dessen Gossip- Ring befindet, wird eine Nachricht an den suchenden Peer mit einer Liste von Peers aus dem entsprechenden Gossip-Ring gesendet. Andernfalls wird das Verfahren rekursiv fortgesetzt, bis die Anfrage einen Peer aus dem gesuchten Ring erreicht. V. ZUSAMMENFASSUNG UND AUSBLICK Durch den Einsatz von P2P-Technologie bei Video-on- Demand-Streaming können Serverlast und Trafficaufkommen für die Betreiber von Video-Angeboten deutlich gesenkt werden. Dazu gibt es verschiedene Ansätze, die sich in zwei grundsätzliche Klassen einteilen lassen. Eine Klasse von P2P-basierten Video-Streaming-Systemen sind die Application-Layer-Multicast-Systeme, bei denen Clients, die das Video in einem gewissen Zeitfenster anfragen, zusammen mit einem Streaming-Server einen Multicast-Baum zum Streamen des Videos bilden. Hier gibt es verschiedene Techniken um das Streaming trotz unterschiedlicher Ankunftszeiten und somit anderer Abspielpositionen zu ermöglichen. P2Cast verwendet dazu einen Patch-Stream, über den Clients beim Betreten des Systems den verpassten Anfang des Videos erhalten, bei P2VoD cachen die Peers hingegen immer die zuletzt empfangenen Teile des Videos und leiten neuen Clients einen kontinuierlichen Stream ab Beginn des Videos weiter. Daneben gibt es Systeme, die keine explizite Netzwerk- Topologie aufbauen, sondern das Video in kleine Teilstücke unterteilen und diese Teilstücke untereinander austauschen. Viele dieser Systeme basieren auf dem für File-Sharing bewährten BitTorrent-System, verändern jedoch Komponenten davon, um die Wiedergabe des Videos zu ermöglichen, bevor es vollständig heruntergeladen ist. Hierfür gibt es verschiedene Ansätze, die versuchen, eine Balance zwischen dem Download der Teile in der Abspielreihenfolge und einer möglichst guten Verteilung der Teile über die Peers zu erreichen. Auch Funktionen wie das Springen zu bestimmten Stellen in einem Video ist mit P2P-Systemen realisierbar. Systeme wie RINDY bauen entsprechende Verbindungen auf, um solche Operationen möglichst effizient zu unterstützen. Ein weiterer interessanter Aspekt ist der Einsatz von P2Pbasierten Video-Streaming-Systemen für die Verteilung von kommerziellen Videos. Mit den besondern Anforderungen für solche Anwendungsszenarien beschäftigt sich u.a. P2P-Next [11], ein von der EU unterstütztes Projekt, dessen Ziel die Entwicklung einer P2P Content Delivery Plattform ist. In [11] werden dabei insbesondere die folgenden Anforderungen aufgeführt: Zum einen möchte der Produzent einschränken, wer das Video sehen kann. Neben der Beschränkung auf Kunden, die für die Inhalte bezahlt haben, ist beispielsweise auch eine Einschränkung auf Kunden aus bestimmten Ländern denkbar. Außerdem soll es einen seperaten Payment-Provider geben, so dass die Zahlungsinformationen nur diesem und nicht dem Video-Produzenten oder gar anderen Benutzern des Netzwerks bekannt sind. Ein weiteres bei P2P-Next betrachtetes Problem ist, dass P2P-Netzwerke in der Regel keine Kenntnis der unterliegenden Netzwerk-Topologie haben. Hier wäre es insbesondere wünschenswert, in ISP Caches ausgetauschte Daten zu speichern und somit den Traffic zu reduzieren. Als Lösungsansatz für diese Probleme setzt P2P-Next auf ein verteiltes System, das neben dem P2P-Netzwerk zum Übertragen des Contents zwei zusätzliche Komponenten enthält: Ein Payment-System, bei dem Benutzer für Content bezahlen können und ein entsprechendes Token enthalten, sowie ein Access-Control-System, das den Benutzern gegen Vorzeigen des Tokens nach Überprüfung beim Payment-System einen Schlüssel zum Dekodieren des Contents zur Verfügung stellt. Der Content wird dabei, ähnlich wie beim Satellitenfernsehen, mit einem Schlüssel für alle Benutzer verschlüsselt, so dass die verschlüsselten Daten frei verteilt und in Caches zwischengespeichert werden können. Um die Daten jedoch zu benutzen, ist ein entsprechender Schlüssel nötig, den nur authorisierte Benutzer erhalten. Dadurch, dass die Verschlüsselung bei P2P-Next optional ist, können auch andere Geschäftsmodelle realisiert werden. So kann das Video beispielsweise unverschlüsselt übertragen werden, und Benutzer können nach dem Anschauen freiwillig spenden. Auch eine Einschränkung anhand geografischer Position der Benutzer ist implementierbar, indem nur das Access- Control-System ohne Payment-System verwendet wird. LITERATUR [1] E. Akyol, A.M. Tekalp, and M.R. Civanlar. A flexible multiple description coding framework for adaptive peer-to-peer video streaming. IEEE Journal of Selected Topics in Signal Processing, 1(2): , 200. III-A [2] Y. Borghol, S. Ardon, N. Carlsson, and A. Mahanti. Toward Efficient On-Demand Streaming with BitTorrent. NETWORKING 2010, pages 53 66, IV-B3 [3] M. Cha, H. Kwak, P. Rodriguez, Y.Y. Ahn, and S. Moon. I tube, you tube, everybody tubes: analyzing the world s largest user generated content video system. In Proceedings of the th ACM SIGCOMM conference on Internet measurement, pages ACM, 200. I [4] B. Cheng, H. Jin, and X. Liao. RINDY: a ring based overlay network for peer-to-peer on-demand streaming. Ubiquitous Intelligence and Computing, pages , IV-B [5] B. Cohen. Incentives build robustness in BitTorrent. In Workshop on Economics of Peer-to-Peer systems, volume 6, pages Citeseer, I, II-B, III-B [6] C. Dana, D. Li, D. Harrison, and C.N. Chuah. Bass: Bittorrent assisted streaming system for video-on-demand. In Multimedia Signal Processing, 2005 IEEE th Workshop on, pages 1 4. IEEE, IV-B1 [] T.T. Do, K.A. Hua, and M.A. Tantaoui. P2VoD: Providing fault tolerant video-on-demand streaming in peer-to-peer environment. In Communications, 2004 IEEE International Conference on, volume 3, pages IEEE, IV-A2 [8] P. Garbacki, A. Iosup, D. Epema, and M. van Steen. 2fast: Collaborative downloads in p2p networks. In Peer-to-Peer Computing, P2P Sixth IEEE International Conference on, pages IEEE, IV-B5 [9] V.K. Goyal. Multiple description coding: Compression meets the network. Signal Processing Magazine, IEEE, 18(5):4 93, III-A [10] Y. Guo, K. Suh, J. Kurose, and D. Towsley. P2Cast: peer-to-peer patching scheme for VoD service. In Proceedings of the 12th international conference on World Wide Web, pages ACM, IV-A1 38

39 8 P2P-BASED VIDEO-ON-DEMAND-STREAMING [11] R. Jimenez, L.E. Eriksson, and B. Knutsson. P2P-Next: technical and legal challenges. Research funded by Seventh Framework Programme, V [12] N. Magharei, R. Rejaie, and Y. Guo. Mesh or multiple-tree: A comparative study of live p2p streaming approaches. In INFOCOM th IEEE International Conference on Computer Communications. IEEE, pages Ieee, 200. III-C [13] JJD Mol, JA Pouwelse, M. Meulpolder, DHJ Epema, and HJ Sips. Give-to-get: Free-riding-resilient video-on-demand in p2p systems. Proceeding of the 15th SPIE/ACM Multimedia Computing and Networking (MMCN 08), IV-B6 [14] J.A. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup, D.H.J. Epema, M. Reinders, MR Van Steen, and H.J. Sips. Tribler: A social-based peer-to-peer system. Concurrency and Computation: Practice and Experience, 20(2):12 138, IV-B4 [15] H. Schwarz, D. Marpe, and T. Wiegand. Overview of the scalable video coding extension of the H. 264/AVC standard. IEEE Transactions on Circuits and Systems for Video Technology, 1(9): , 200. III-A [16] A. Vlavianos, M. Iliofotou, and M. Faloutsos. BiToS: Enhancing BitTorrent for supporting streaming applications. In INFOCOM th IEEE International Conference on Computer Communications. Proceedings, pages 1 6. IEEE, 200. IV-B2 39

40 SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN Skype - Ein Überblick über die Protokolle, das Overlay-Netzwerk und die Sicherheitsmaßnahmen Marius Hornung Zusammenfassung Skype ist eine Voice-over IP Software basierend auf einem Peer-to-Peer Netzwerk. Es ist die erfolgreichste Software seiner Art, bietet kostenlose und auch kostenpflichtige Dienste, ist aber proprietär und damit Closed-Source. Forscher haben ein grosses Interesse daran herauszufinden, wie Skype funktioniert, um die Ergebnisse für die eigene Forschung zu nutzen. Dabei werden sie vor viele Probleme gestellt, die Skype absichtlich mit sich bringt, um das eigene Know-how zu schützen. Die vorliegende Arbeit stellt diese Probleme vor, fasst die bisher erfahrenen Resultate von Forschern zusammen und gibt einen Überblick bezüglich des verwendeten Overlay-Netzwerks. Weiterhin werden dem Endbenutzer verborgene Details, wie das Umgehen und Durchdringen von Firewalls und NATs, sowie die Maßnahmen zum Schutz der Privatspähre von Skype-Nutzern, beschrieben. Auf Grund der Closed-Source-Taktik, die Skype nutzt, sind die Ergebnisse vage. I. EINFÜHRUNG Skype ist eine Voice over Internet Protokoll (VoIP)- Software, die in 2003 erstmals veröffentlicht und von ehemaligen Mitarbeitern von Kazaa [6] entwickelt wurde. Es handelt sich um die weitverbreitetste und erfolgreichste Software dieser Art mit 519 Millionen registrierten Benutzern (2009) [5]. Im November 2010 waren erstmals 25 Millionen Benutzer gleichzeitig online [15]. Die Software bietet kostenlose Features, wie Sprach- und Videotelefonie, Instant- Messaging, Datei-Transfer und Screensharing. Darüber hinaus werden kostenpflichtige Dienste angeboten zu welchen Anrufe aus und in traditionelle Telefonnetze (SkypeIn, SkypeOut), Skype To Go-Nummern und Videokonferenzen gehören. Die zentralen Fragen, welche sich Forscher, Sicherheitsadministratoren und Konkurrenten von Skype stellen, beziehen sich auf die Gründe des großen Erfolgs, die verwendeten Technologien und beschäftigen sich mit Sicherheitsfragen. Allerdings liegt die Motivation dieser Interessengruppen in verschiedenen Bereichen: Während Forscher gerne die Erfahrung von Skype bei der Unterhaltung von großen Peer-to-Peer (P2P)-Netzen öffentlich zugänglich hätten, um sie für Ihre eigene Forschung nutzen zu können, liegt der Interessenschwerpunkt von Konkurrenten direkt auf den verwendeten Technologien, um ihre eigenen Produkte zu verbessern. Sicherheitsadministratoren können nicht nachprüfen, ob die Angaben, die Skype zum Schutz der Privatsphäre der Nutzer macht, stimmen oder ob vielleicht im Skype-Client (SC) ein Trojaner/eine Backdoor eingebaut ist. Trotz des hohen Interesses ist noch sehr viel über Skype im Dunklen. Die Gründe lassen sich in der Tatsache finden, dass Skype versucht das eigene Knowhow, so weit wie möglich, vor dem Zugriff Dritter zu schützen, um die eigene Marktposition zu stärken. Informationen zur Architektur des Overlay-Netzwerks, den Sicherheitsmechanismen und des Nutzerverhaltens werden bewusst zurückgehalten und effektiv verschleiert. Diese Arbeit fasst die Resultate von Forschern und Forschungsgruppen, die Interesse an Skypes Protokollen und dem Overlay-Netzwerk haben, zusammen und versucht so diese zentralen Fragen zu beantworten. Dabei wird ihr Vorgehen und ihre Analyseansätze vorgestellt und die Probleme, welchen sie sich stellen mussten, beschrieben. Danach werden allgemeine Begriffe, die zum weiteren Verständnis notwendig sind, eingeführt. Es folgt eine Zusammenfassung der Ergebnisse, die zu einem Überblick über die Struktur des Overlay-Netzwerks und die darin involvierten Entitäten führt. Weiterhin werden wichtige Begriffe, die zur korrekten Funktionalität eines SC essentiell sind, erläutert. Am Beispiel der Funktionen Login und Sprachtelefonie werden Methoden zur Umgehung von Firewalls und Network Address Translators (NAT), sowie Sicherheitsmaßnahmen zum Schutz der Privatsphäre, exemplarisch gezeigt. Das Paper schließt ab mit einer Zusammenfassung. II. AUFDECKEN DER PROTOKOLLE Dieses Kapitel fasst die Ansätze von verschiedenen Forschern, die herausfinden möchten wie Skype im Detail funktioniert, zusammen. Prinzipiell lassen sich diese in zwei Gruppen einteilen: Der erste Ansatz sammelt von Skype generierten Netzwerk- Traffic in großen Mengen unter verschiedenen Netzwerkbedingungen, variiert in Testszenarien hinsichtlich öffentlicher IP-Adresse, Firewalls und NATs. Diese gesammelten Pakete werden dann einzeln und/oder in Bezug auf eine bestimmte Skype-Funktion (zum Beispiel Login, Benutzersuche,...) als Message-Flows betrachtet und ausgewertet. Während Guha, Daswani und Jain in [10] und Baset und Schulzrinne in [14] so versucht haben die einzelnen Funktionen von Skype zu analysieren, um ein tieferes Verständnis der Protokolle und des Overlay-Netzwerkes zu erlangen, haben Ehlert und Petgang in [11], Bonfiglio et al. in [6] und Branch et al. in [8] ihr Augenmerk auf das Detektieren von Skype generierten Netzwerk-Traffic gelegt. Der zweite Ansatz, genutzt von Biondi und Desclaux in [3] geht einen anderen Weg. Sie beschäftigen sich mit der Analyse des Quellcodes des Skype-Binarys 1 und stellen die Ergebnisse in Bezug zu Netzwerkpaketen und Funktionen von Skype, um an Einblicke zu gelangen. Nebenresultat dieses Ansatzes ist die Identifikation der Schutzmechanismen von Skype gegen Reverse-Engineering-Angriffe. Bei diesen Angriffen wird durch die genaue Untersuchung der Strukturen, Zustände und 1 Binary: Ausführbare Datei in Maschinensprache oder Bytecode 40

41 SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN Verhaltensweisen eines fertigen Systems versucht die Konstruktionselemente und details zu extrahieren. III. SCHUTZMECHANISMEN SEITENS SKYPE Im letzten Abschnitt wurden Schutzmechanismen angedeutet, die verhindern, dass man Skypes Funktionsweise schnell erfassen kann und weswegen noch viele Details im Dunklen liegen. Im Folgenden werden diese beschrieben und somit begründet, warum die Ergebnisse der Arbeiten sehr vage sind. Die Mechanismen werden nur kurz angedeutet, aber nicht in der Tiefe erläutert. A. Binary Packing Einige Teile des Skype-Binarys sind mit einem festkodierten Schlüssel per XOR verknüpft. Erst zur Laufzeit werden diese Teile des Codes entschlüsselt. Um das Dumping des Codes aus dem Speicher zu verhindern löscht Skype den Anfang des eigenen Codes und überschreibt teilweise die original Import-Table mit einer eigenen Import-Table. Weiterhin finden Imports von Bibliotheken dynamisch während der Laufzeit statt [3]. B. Integritätschecks des Codes zur Laufzeit Um Veränderungen im Binary, wie zum Beispiel das Ersetzen eines bestimmten Code-Bereiches um fremde Code- Fragmente, zu erkennen wird der Code von Skype zur Laufzeit ständigen Integritätschecks unterzogen. Unter normalen Umständen werden diese Integritätschecks zur Identifikation von Schadcode verwendet. In [3] haben die Autoren 300 solcher Tests gefunden, was stark darauf hinweist, dass Skype diese Tests nur durchführt, um das Reverse-Engineering zu erschweren. Zu diesen vielen kleineren Integritätschecks fügt sich noch ein finale Überprüfung durch einen RSA-Integritätscheck an. C. Anti-Debugging Techniken Skype verhindert effektiv das Nutzen eines Kerneldebuggers durch generische und konkrete Tests. Da das Setzten von Breakpoints das Binary verändert, schlagen die Integritätschecks fehl. Konkret testest Skype auf den Debugger Softice, in dem es versucht dessen Treiber zu laden. Erkennt Skype das Mitlaufen eines Debuggers werden Zufallssprünge im Code gemacht und Register randomisiert, was das Erkennen von Strukturen im Code unmöglich macht [3]. D. Quelltextverschleierung Quelltextverschleierung (Code Obfuscation), soll das Entwenden und Studieren des Codes so schwer wie möglich machen. Skype erreicht dies durch dynamisches Aufrufen von Funktionen und gewollte Sprünge im Quellcode, die nicht der Funktionalität dienen, sondern nur zur Verschleierung getätigt werden. [3]. E. Verschlüsselung der Netzwerkpakete Der Payload von Netzwerkpaketen, die Skype erzeugt, wird RC4 2 verschlüsselt. Der RC4-Schlüssel wird durch die Zielund Quell-IP, der Skype Packet-ID und einem nicht weiter bekannten Initialisierungsvektor erzeugt. Anzumerken ist, dass diese RC4-Verschlüsselung einzig der Verschleierung des Inhalts der Netzwerkpakete dient. Der Schutz der Privatsphäre wird durch andere Methoden, siehe Abschnitt VII, sichergestellt [3]. IV. GRUNDLEGENDES Dieser Abschnitt erläutert grundlegende Begriffe, die für das Verständnis des weiteren Verlaufs des Papers notwendig sind, sich aber nicht direkt auf Skype beziehen. Dazu gehören die beiden Protokolle UDP und TCP, sowie durch Firewalls und NATs auftretende Probleme. A. TCP und UDP TCP und UDP sind zwei auf der Transportschicht [2], [12] des ISO/OSI-Referenzmodels angesiedelte Protokolle zur Übertragung von Daten im Internet. TCP ist ein zuverlässiges, verbindungsorientiertes und paketvermitteltes Transportprotokoll. Nachrichten werden in kleinere Pakete aufgespalten und über eine vorher hergestellte Verbindung mit der Gegenseite ausgetauscht. Die Übertragung aller Pakete wird durch das Protokoll sichergestellt. Im Gegensatz dazu ist UDP verbindungslos und unzuverlässig, dass heißt die Übertragung der Daten wird nicht sichergestellt. Da UDP keinerlei Fehlerkorrekturen vornimmt, ist es im Vergleich zu TCP schneller und ressourcenschonender. Dadurch reduzieren sich Bandbreitenverbrauch und Latenzzeiten maßgeblich [4]. Aus diesem Grund wird für Internettelefonie bevorzugt auf UDP zurückgegriffen, da kleinere Ungenauigkeiten im Sprachund Videostream vom Menschen nicht wahrgenommen werden können. B. NAT und Firewall NAT erlaubt es private Netzwerke an öffentliche Netze, wie zum Beispiel das Internet, anzubinden. Der Grund liegt in der Knappheit der IPv4-Adressen. Dabei teilen sich mehrere Hosts in einem privaten Adressraum eine öffentliche IP- Adresse. NAT-Router, die an der Grenze zwischen privaten und öffentlichen Netzen liegen, ersetzen automatisiert Adressinformationen in Datenpaketen, um beide Netze miteinander zu verbinden. Dabei unterhält der NAT-Router eine Tabelle zur Zuordnung von Verbindungen zu privaten Hosts. Verbindungen, die nicht von der privaten Seite aufgebaut oder explizit von einem Administrator in der Tabelle vermerkt werden, können von dem NAT-Router keinem Host in dem privaten Netz zugeordnet werden. Somit ist ein Host in einem privaten Netz faktisch nicht von außen zu erreichen. Ein ähnliches Problem stellt sich für Firewalls dar: Es werden explizit von außen und innen kommende Verbindungen blockiert, um Sicherheit zu gewährleisten. Dies führt, wie in [] beschrieben, zu einigen Problemen bezüglich der Erreichbarkeit von Skype- Knoten in privaten Netzen. 2 RC4 oder ARC4 ist eine Stromverschlüsselung 41

42 SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN C. STUN und TURN Session Traversal Utilities for NAT (STUN) [9] ist ein Protokoll, welches das Vorhandensein und die Art von Firewalls und NATs, hinter welchen sich ein Host eventuell befindet, erkennt und durchdringen kann. Dabei werden nach bestimmten vorher definierten Abläufen Pakete zwischen dem Host und einem STUN-Server verschickt. Je nach Erfolg oder Misserfolg des Sendens bzw. veränderter Adressinformationen in den Paketen lassen sich Rückschlüsse auf eine Firewall oder das verwendete NAT ziehen. Traversal Using Relay NAT (TURN) [13] ist ein Protokoll, welches einen Host hinter einer Firewall oder einem NAT erlaubt Daten über eingehende TCP- oder UDP-Verbindungen zu empfangen. Die Hauptmethodik, welcher sich TURN bedient, basiert auf einer dritten Partei, dem TURN-Server, der als Proxy zwischen zwei kommunizierenden Hosts dient. Mit Hilfe von STUN und TURN lassen sich NATs und Firewalls erkennen und dadurch auftretende Probleme umgehen. Allerdings benötigt man dazu eine dritte Partei mit einer öffentlichen IP-Adresse. V. DAS OVERLAY Im folgenden Abschnitt werden die teilnehmenden Entitäten im Skype-Netzwerk, Ordinary Nodes (ON), Super Nodes (SN), Bootstrap Super Nodes (BSN) und der Login-Server, sowie der für die Funktionalität von Skype wichtige Host Cache (HC), erläutert. Ordinary Node Super Node Login-Server A. Skype Client Ein Skype-Client (SC) ist ein im Skype-Netz teilnehmender Knoten. Er bietet die grundlegenden Funktionen, wie Eintreten in das Netz, Instant-Messaging, Annahme und Initierung von Sprach- und/oder Videoanrufen, Abmelden aus dem Netz, Datentransfer und Benutzersuche. Ein SC kann, abhängig von bestimmten Umständen, entweder ein ON oder ein SN sein [14]. B. Ordinary Node Ein Ordinary Node ist ein SC und bietet keine weiteren oder besonderen Funktionen. Zum erfolgreichen Eintritt in das Skype-Netz ist jedoch eine TCP-Verbindung zu einem SN notwendig [14]. C. Super Node SNs bilden untereinander ein Overlay-Netzwerk (Abbildung 1). Mehrere ONs verknüpfen sich mit einem SN. SNs bieten, im Gegensatz zu ONs, weitere Funktionen, die dem Endbenutzer aber nicht direkt zur Verfügung stehen. Diesen sind ihm aber von Nutzen, falls er sich hinter einer Firewall und/oder einem NAT befindet und deshalb nicht von aussen kontaktiert werden kann. ONs, die nicht direkt mit dem Internet über eine öffentliche IP-Adresse verbunden sind, nutzen SNs, um ihre Erreichbarkeit zu sichern [14], [11]. Eine genauere Erläuterung findet im nächsten Abschnitt statt. Jeder in das Netz eintretende SC ist, wie schon erwähnt, potentiell ein SN. Auf Grund der eben vorgestellten Methodik Firewalls und NATs zu Abbildung 1. Das Skype-Overlay-Netzwerk. ONs verbinden sich mit SNs, die untereinander ein Overlay bilden. SNs und ONs verbinden sich zum Login mit dem LS, der einzigen zentralen Komponente im Netzwerk. umgehen ist das Hauptkriterium, um zu einem SN zu werden, eine öffentliche IP-Adresse. Nebenkriterien sind ausreichender RAM, CPU und Bandbreite. Es existieren mehr ONs als SNs und SNs sind mit ONs im Verhältnis 1 zu n assoziiert. Abbildung 2 lässt Vermuten, dass es im Durchschnitt weniger als 3 sind. Dass ein oberes Limit existiert erkennt man daran, dass mit steigender Zahl an ONs auch die Anzahl der SNs steigt. D. Skype Login-Server Der Skype Login Server (LS) ist die einzige zentrale Entität im Skype-Netzwerk [14], [11] ist dabei aber nicht am Overlay- Netzwerk selbst beteiligt. Der LS speichert die Buddy-Liste, Benutzernamen und deren zugehörigen Passwörter und ist für die Authentifizierung von Benutzern während des Netzeintritts verantwortlich. Des Weiteren sorgt der LS dafür, dass Benutzernamen im Skype-Namensraum Unikate sind. E. Host Cache Jeder SC verwaltet eine Liste mit höchstwahrscheinlich erreichbaren anderen SCs, den Host Cache (HC) [14]. Der HC beinhaltet Paare von IP-Adressen und Ports von SNs. Der Eintritt in das Overlay-Netzwerk ist ein kritischser Punkt 42

43 SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN Start UDP-Pakete zu BSNs Anwtort in 6 Sekunden Ja Nein TCP Verbindungsversuche zu BSNs Abbildung 2. Anteil der SNs auf die Gesamtzahl der SCs. Der Bereich x- Achse bis blaue Linie gibt den Anteil der SNs an. Von der blauen Linie aus nach oben gehend zur roten Linie zeigt den Anteil der ONs. Abbildung von [10]. Verbunden Ja Erfolg Nein und mindestens ein Knoten im HC muss erreichbar sein, um erfolgreich in das Netz einzutreten. In [14] wird angegeben, dass ein HC nach zwei Tagen etwa 200 Einträge vorzuweisen hat. Diese Anzahl steigt bei weiterer Beobachtung nicht mehr. 6 Sekunden warten F. Bootstrap Supernodes Nach der Installation von Skype ist der HC leer. Da der SC in diesem Fall keinen SN zum Eintreten in das Netz kennt, existieren im Quellcode fest codierte Bootstrap Super Nodes (BSN). Diese Knoten werden bei leerem HC als Bootstrapnode, bei Unerreichbarkeit der Knoten als Backup genutzt.. S. A. Baset und H. G. Schulzrinne vermuten in [14], dass es 8 solcher BSN gibt und diese fest in den Skype-Client eincodiert sind. VI. KOMMUNIKATIONSPARADIGMEN Der folgende Abschnitt erläutert exemplarisch am Login- Prozess und der Sprachtelefonie in welcher Form SCs untereinander kommunizieren und welche Rolle dabei STUN und TURN spielen. Im zweiten Teil werden die Transferraten beleuchtet. A. Kommunikation zwischen zwei Knoten In Skype erfolgt die Kommunikation zwischen zwei Knoten ausschließlich über UDP oder TCP, wobei Kontrollinformationen immer über TCP und Sprachpakete, wenn möglich, immer über UDP transportiert werden. In besonderen Fällen kann aber auch Sprache via TCP übertragen werden. Im Gegensatz zu anderen VoIP-Lösungen, wie zum Beispiel Google Talk 3, schafft es Skype augenscheinlich 3 Abbildung 3. Der Loginalgorithmus beim ersten Start eines SCs (HC ist leer) vor dem Authentifizieren am LS. problemlos und für den Nutzer verborgen NATs und Firewalls zu umgehen. Skype verwendet dazu wahrscheinlich STUN und TURN ähnliche Protokolle [14]. Hinweise darauf lassen sich im Loginprozess finden (Abbildung 3). Dieser stellt eine kritische Funktion in Skype dar, weil der SC mindestens einen SN erreichen und sich gegenüber dem LS authentifizieren muss. Nach dem Start schickt der SC UDP-Pakete an die BSN und versucht danach erst, unabhängig ob diese erfolgreich versendet wurden oder nicht, die notwendige TCP-Verbindung zu einem BSN aufzubauen. Der Sinn dahinter lässt sich in STUN finden. Wahrscheinlich versucht der SC das Vorhandensein und die Art eines NATs und/oder einer Firewall, hinter welcher er sich ggf. befindet, festzulegen, bevor er einen Verbindungsversuch startet. Im folgenden Abschnitt werden drei Netzwerkszenarien betrachtet, um die Verwendung von einem TURN ähnlichen Protokoll und den Rückfall auf TCP-Kommunikation, sollte UDP nicht möglich sein, zu zeigen. a) Anrufer und Angerufener haben öffentliche IP- Adresse: Gesetz dem Fall, dass Anrufer und Angerufener eine öffentliche IP-Adresse haben und deshalb beide 43

44 SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN 1 noch die Ports 80 (HTTP) und 443 (HTTPS), um Firewalls zu durchdringen [14]. Des Weiteren legt Skype einen zufällig gewählten Port während der Installation fest, auf welchem es auf TCP- und UDP-Verbindungen lauscht. Dieser Port kann vom Benutzer beliebig geändert werden [14]. Zwei SCs erkennen, falls sie sich hinter demselben NAT befinden. Dann wird die Sprachkommunikation komplett in dem privaten Netz realisiert [14]. Die Nutzersuche, die es ermöglicht andere Teilnehmer zu finden, ist dezentral organisiert und erfolgt über das Peer-2-Peer-Netz. Skype gibt an eine Peer-to-Peer Technologie der dritten Generation ( 3G P2P oder GI für Global Index ) entwickelt zu haben, die jeden Benutzer findet, sollte er sich innerhalb der letzten 2 Stunden im SkypeNetzwerk angemeldet haben [1]. Auch bei der Nutzersuche werden die schon bei Anrufen vorgestellten Techniken zur Überwindung von NATs und Firewalls genutzt. Suchen SCs hinter einer Firewall oder einem NAT einen Benutzer, dann führt der mit diesem Knoten assoziierte SN die Suche durch [14]. Des Weiteren lassen sich Hinweise auf ein Caching von Suchergebnissen finden [14]. Internet Public IP Anrufer 2 Public IP Angerufener Public IP SN NAT Public IP Private IP Anrufer Internet Public IP Angerufener TCP - Steuerinformationen UDP - Sprachtelefonie 3 Public IP SN Internet NAT / Firewall Public IP Private IP Anrufer NAT / Firewall Public IP ~ Public IP Angerufener TCP - Steuerinformationen & Sprachtelefonie Abbildung 4. Die Kommunikation zwischen SCs unter verschiedenen Netzwerkszenarien. In 1 erfolgt eine normale Kommunikation direkt zwischen beiden Parteien. In 2 und 3 dient ein dritter SCs als Proxy. In 3 fällt Skype komplett auf die Kommunikation via TCP zurück. B. Transferraten Haben beide SCs eine öffentliche IP-Adresse fließen Sprach- und Videodaten zwischen ihnen direkt über UDP. Die Größe eines UDP-Sprachpakets variiert dabei zwischen 40 und 110 Bytes. Folglich beträgt die gesamte Uplink- und Downlinkbandbreite für Sprachdaten ca. 5 kilobytes/s [14] (Fall 1 in 4). Befinden sich entweder Anrufer oder Angerufener hinter einem port-restricted NAT (Fall 2 in 4), tauschen beide Teilnehmer Sprachdaten direkt miteinander aus. Die Paketgröße von Sprachpaketen variiert zwischen 40 und 110 Bytes. Die benutzte Bandbreite beträgt in etwa 5 kilobytes/s [14]. Sind beide SCs, Anrufer und Angerufener, hinter einem portrestricted NAT und einer UDP-restricted Firewall tauschen beide Daten via TCP über einen dritten SC aus. Die Paketgröße von Sprachdaten variiert zwischen 30 und 90 Byte. Die totale Uplink- und Downlinkbandbreite, die dabei genutzt wird, beläuft sich in etwa auf 5,5 kilobytes/s. uneingeschränkt von außen über TCP und UDP erreichbar sind (Abbildung 4 Punkt 1), erfolgt die Kommunikation für Steuersignale über TCP und für Sprache über UDP. b) Anrufer hinter port-restricted NAT und angerufener hat öffentliche IP-Adresse: Besitzt nur der Angerufene eine öffentliche IP-Adresse und der Anrufer befindet sich hinter einem port-restricted NAT4 (Abbildung 4 Punkt 2) wird die Kommunikation für Steuerinformationen über einen dritten Knoten (einem SN) geleitet. Die Sprachkommunikation wird weiterhin via UDP übertragen. c) Beide Benutzer hinter port-restricted NAT und UDP-restricted Firewall: Sind beide Benutzer, Anrufer und Angerufener, hinter einem port-restricted NAT und einer UPD-restricted Firewall5 (Abbildung 4 Punkt 2) wird ein dritter Knoten für die komplette Kommunikation, Sprachund Steuerdaten, herangezogen. Es kommt nur noch TCP zum Einsatz. VII. S ICHERHEIT Skype nutzt Authentifizierungs und Verschlüsselungstechniken, um die Privatsphäre seiner Nutzer zu schützen [16]. In diesem Abschnitt wird die von Skype verwendete Security Policy und die eingesetzte Kryptografie bei der Registrierung eines neuen Benutzers, sowie zwischen 2 Knoten, erläutert. Während in A die Kommunikation standardmäßig verläuft, zeigen sich in B und C Hinweise auf ein TURN ähnliches Protokoll, welches durch die Nutzung eines dritten Knotens als Proxy den Datenverkehr zwischen beiden vermittelt. Neben den eben vorgestellten Techniken nutzt Skype auch A. Security Policy Eine Security Policy definiert, was Sicherheit bezogen auf ein konkretes System, in diesem Fall Skype, bedeutet. Nach einer Security Evaluation bei Skype gibt Tom Berson in [1] die Skype Security Policy wie folgt an: Skype Benutzernamen sind Unikate. Benutzer oder Applikationen müssen einen Skype Benutzernamen und dessen assoziierte Authentifizierungsdaten vorweisen, bevor sie die zum Benutzernamen gehörende Identität oder deren Rechte annehmen dürfen. Jeder Peer liefert 4 Port-restricted NAT: Möchten A und B kommunizieren und A befindet sich hinter einem port-restricted NAT, so ist A nur von außen erreichbar, falls A vorher eine Verbindung nach außen aufgebaut hat und dies auch nur über den Port, von welchem aus die Verbindung aufgebaut wurde. 5 UDP-restricted Firewall: Möchten A und B kommunizieren und befindet sich B hinter einer UDP-restricted Firewall, blockt diese alle ein- und ausgehenden UDP-Verbindungen. Verbindungen via UDP sind in diesem Fall komplett ausgeschlossen. 44

45 SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN SC von A A, H(PA), VA Identity Certificat Login-Server 1 Public IP Anrufer Internet Public IP Angerufener Abbildung 5. Der Registeriungsprozess. einem anderen Peer einen Nachweis seines Benutzernamens und seiner Rechte, immer wenn eine Skype-Session hergestellt wird. Beide Peers verifizieren diesen Nachweis, bevor der Session gestattet wird Nachrichten auszutauschen. Nachrichten, die während einer Skype-Session übertragen werden, sind von einem SC zum anderen SC verschlüsselt. Keine zwischengeschalteten Knoten haben Zugriff auf diese Nachrichten. Die eben genannte Security Policy wird wie folgt umgesetzt: B. Registrierung Mit Hilfe der Hashfunktion H wird der zum von Benutzer A gewählten Passwort P A korrespondierende Hashwert berechnet Während der erstmaligen Registrierung eines Benutzers A am LS erstellt dieser für A ein Identity Certificate (IC), welches zur Authentifizierung zwischen SCs dient: Mit Hilfe der Hashfunktion H wird der zum von Benutzer A gewählten Passwort P A korrespondierende Hashwert berechnet und auf dem Client als H(P A ) gesichert. Dann erstellt der SC ein RSA- Key-Paar S A und V 3 A. Danach stellt der SC eine mit 256-bit- AES-Verschlüsselung gesicherte Verbindung zu dem LS her und verifiziert diesen. Im nächsten Schritt sendet der SC A, H(P A ) und V A an den LS. Daraus generiet der LS ein IC und sendet es zurück an den SC [1]. Abbildung 5 visualisiert diesen Ablauf in zusammengefasster Form. C. Peer-to-Peer Key Agreement Um den Austausch von Daten zwischen 2 Knoten zu verschlüsseln, wird zu Beginn einer neuen Session zwischen zwei SCs, A und B, ein 256-bit Session-Key, SK AB, ausgehandelt. Dabei folgen beide einem nicht weiter bekannten Key-Agreement-Protokoll, im Zuge dessen die Identität von A und B verifiziert und SK AB festgelegt wird. Dieser SK AB existiert solange, wie Daten zwischen A und B ausgetauscht werden und noch kurze Zeit danach. Beim Schliessen eines SCs wird der Session-Key gelöscht. D. Verschlüsselung einer Session Der komplette Verkehr einer Session ist verschlüsselt. Der Klartext wird mit einem Geheimtextblock per XOR verknpüft, der aus einem 256-bit-AES-Schlüssel generiert wird. Als Schlüssel wird hier der vorher ausgehandelte Session-Key SK AB benutzt. Wie in Abbildung 6 zu erkennen ist wird auch die Kommunikation über einen dritten SC, der als Proxy dient, Ende-zu-Ende verschlüsselt. Der Proxy-Knoten kann die Datenpakete nicht lesen, da er nicht im Besitz des zwischen A und B ausgehandelten Session-Key SK AB ist. 3 S repräsentiert hier den privaten Schlüssel und V den öffentlichen Schlüssel 2 SC A SN Internet Ende-zu-Ende verschlüsselt SC B Abbildung 6. Ende-zu-Ende Verschlüsselung auch über einen dritten Knoten mittels Session-Key SK AB. VIII. CONCLUSION Für den großen Erfolg von Skype sind viele Dinge verantwortlich. Hier ist vor allem die Peer-to-Peer-Struktur hervorzuheben, die wenige zentrale Instanzen benötigt und so dem Benutzer kostenlose Dienste ermöglicht. Andere Punkte sind die einfache Bedienung, da durch Firewalls und NATs auftretende Probleme fast unsichtbar für den Benutzer umgangen werden, aber auch die kostenpflichtigen Angebote, die in Unternehmen Mehrwert schaffen, wie zum Beispiel Videokonferenzen. Anderseits aber auch Kritikpunkte, wie den Fakt, dass Skype Closed-Source ist. Zwar garantiert Skype die Sicherheit seiner Software, aber wirklich nachprüfen lässt sich das nicht. Fragen, wie zum Beispiel, ob die verwendeten Verschlüsselungsund Authentifizierungsverfahren korrekt implementiert sind und ob sich nicht vielleicht in der Software eine Backdoor oder ein Trojaner befindet, können nicht zufriedenstellend beantwortet werden. Für Wissenschaftler aber ist der größte Negativpunkt, dass sie nicht auf die Erfahrungswerte von Skype im Umgang mit sehr großen Peer-to-Peer-Netzwerken für ihre eigene Forschung zugreifen können. Hinsichtlich zukünftiger Forschungsarbeiten ist einiges zu tun: Die in diesem Paper zusammengefassten Ergebnisse wurden mit alten Versionen von Skype gesammelt und sind nicht mehr aktuell. Diese gilt es aufzufrischen, aber auch neue Aspekte, wie zum Beispiel ob Zentralität im Skype-Netzwerk eine immer größere Rolle spielt, sollten geklärt werden. Hinweise darauf gibt es, da sich ein Benutzer an mehreren SCs gleichzeitig anmelden kann, aber alle Anrufe und Messages an jedem angemeldeten SC erhält. Die Technik, welche zur Replikation eines Ereignisses auf mehreren SCs genutzt wird, ist völlig unbekannt. Natürlich ist es zu verstehen, dass ein Unternehmen sein Know-How schützen möchte. Es wäre jedoch sehr wünschenswert, wenn Skype sich gegenüber den Benutzern und vor allem gegenüber den Forschern auf dem Gebiet Peer-to-Peer- Systeme offener zeigen würde. Auch Skype könnte von diesem Prozess profitieren, da sich das Vertrauen in die Software steigern würde und auch Skype selbst von Forschungsergebnissen anderer Wissenschaftler, basierend auf den eigenen Erfahrungen und Ergebnissen, Mehrwert schaffen könnte. 45

46 SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN LITERATUR [1] Tom Berson. Skype security evaluation, [2] Marina del Rey. Transmission control protocol. Technical report, Information Sciences Institute, University of Southern California, [3] Biondi; Desclaux. Skype fingerprint. BlackHat Europe, March 2006, [4] Prof. Dr. Evren Eren Dr. Kai-Oliver Detken. Voip-security - standards, evaluierung und konzeptbeispiele anhand von asterisk, 200. [5] Ebay. Q3 09 financial highlights. Website, doc/ /ebay-q309earningsslides-final; Seite 15; besucht am [6] Bonfiglio; Mellia; emeo; Rossi; Tofanelli. Revealing skype traffic: When random. SIGCOMM 0, August 200, 200. [] Robert Fehrmann. Your are skyping - but how does it work? Seminararbeit - FU Berlin, [8] Branch; Heyde; Grenville. Rapid identification of skype traffic flows. International Workshop on Network and Operating System Support for Digital Audio and Video, [9] R. Mahy J. Rosenberg et al. Stun - session traversal utilities for nat. Technical report, Network Working Group, [10] Guha; Daswani; Jain. An experimental study of the skype peer-to-peer voip system. Proc. of IPTPS, [11] Ehlert; Petgang. Analysis and signature of skype voip session traffic. CIIT 2006: 4th IASTED International Conference on Communications, Internet, and Information Technology, 200. [12] J. Postel. User datagram protocol. Technical report, ISI, [13] J. Rosenberg R. Mahy, P. Matthews. Traversal using relays around nat (turn). Technical report, Internet Engineering Task Force (IETF), [14] Baset; Schulzrinne. An analysis of the skype peer-to-peer internet telephony protocol. Proceedings IEEE INFOCOM TH IEEE International Conference on Computer Communications, [15] Skype. Skype Blog: millionen_gleich.html, besucht am [16] Skype. available at detailed-security/; visited on February 1st [1] Skype. P2p telephony explained for geeks only. Website, http: // besucht am

47 ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN 1 Übersicht über datenorientierte Netzwerklösungen Bastian Laur Zusammenfassung Heutzutage wird das Internet hauptsächlich genutzt um Daten wie Websites, Musik und Filme zu beziehen. Dafür war es jedoch bei seiner Entstehung nicht gedacht. Das Ergebnis sind zahlreiche Ad-hoc-Protokolle und -Architekturen. Diese aus der Not entstandenen Lösungen haben viele Wissenschaftler motiviert Forschungen anzustellen und Ansätze zu entwickeln, die das Internet den aktuellen Bedürfnissen der Benutzer anpasst. In diesem Text wird eine Übersicht der aktuell populärsten Lösungsansätze vorgestellt. I. EINLEITUNG Das Internet stellt zurzeit wohl das wichtigste Kommunikationsmittel der modernen Gesellschaft dar. Sowohl Firmen als auch Privathaushalte benutzen es um untereinander zu kommunizieren und sich zu informieren. Dabei ist das Datenvolumen in den vergangen Jahren drastisch gestiegen. Wurden vor einigen Jahren lediglich Texte über das Internet verschickt, handelt es sich heutzutage bereits um ganze Filme. Und die Zukunft lässt noch größere Inhalte wie 3D-Filme, virtuelle Arbeitsplätze und Onlinespiele mit High-End Grafik vermuten. Dabei ist es für Benutzer meist uninteressant von welcher Quelle sie ihre Daten beziehen, so lange sie sich sicher sein können, dass die Verbindung sicher und die Daten sowohl verifiziert als auch authentifiziert sind. Der Benutzer legt also primär Wert auf die Daten an sich und nicht deren Herkunft. Das Internet dagegen wurde für Client-Server Verbindungen mit festgelegten Endpunkten entworfen. Es wird also primär auf die Herkunft der Daten und nicht auf deren Inhalt geachtet. Diese Diskrepanz hat viele Wissenschaftler motiviert, datenorientierte Netzwerklösungen für ein modernes, angepasstes Internet zu entwickeln. Die Lösungsansätze Content-Centric Networking (CCN) [9], A Data-Oriented (and Beyond) Network Architecture (DONA) [8], An Architecture for Content Routing Support in the Internet (CR) [], Freenet: A Distributed Anonymous Information Storage and Retrieval System (Freenet) [6] und The Publish/Subscribe Internet Routing Paradigm (PSIRP) [12] werden in diesem Text vorgestellt. Dabei werden die einzelnen Lösungsansätze und ihre Funktionsweise zunächst im zweiten Kapitel vorgestellt. Anschließend werden sie in den Kapiteln 3-5 jeweils auf einen speziellen Aspekt hin untersucht. Das dritte Kapitel beschäftigt sich damit, wie Benutzer Daten im Internet finden. Das vierte Kapitel beschäftigt sich damit, wie die Daten anschließend vom Host zum Client transferiert werden. Das fünfte Kapitel beschäftigt sich damit, wie neue Daten in das Netz eingespeist und publiziert werden. Abschließend werden die Ergebnisse des Vergleichs zusammengefasst präsentiert. II. ÜBERBLICK ÜBER DIE ARCHITEKTUREN In diesem Kapitel geht es darum, einen Einblick in die jeweiligen Ideen und Strukturen der einzelnen Architekturen zu geben. Die Architekturen werden der Reihe nach vorgestellt, wobei jeweils zuerst die Idee und anschließend die Struktur beschrieben wird. Es wird unbedingt empfohlen dieses Kapitel vor den Folgenden zu lesen, da hier Basiswissen vermittelt wird, das für die Kapitel 3 bis 5 benötigt wird. Andernfalls kann es zu Verständnisproblemen kommen. A. CCN CCN ist eine Netzwerkarchitektur bei der Daten und nicht Hosts adressiert werden. Um das zu realisieren, werden sogenannte CCN-Knoten, Interest- und Data-Pakete eingeführt. Ein Interest-Paket spiegelt eine Datenanfrage wider. Will ein Client also Daten beziehen, sendet er ein Interest-Paket, dass den Namen der Datei und eventuelle Filter enthält. Ein Data-Paket ist die Antwort auf ein Interest-Paket. Es enthält ebenfalls den Namen der Datei, dazugehörige Signaturen und natürlich den Inhalt. Abbildung 1. Data- und Interest-Paket [9] Ein CCN-Knoten ist ähnlich wie ein IP-Router und verfügt über eine Forwarding Information Base (FIB), einen Content Store und eine Pending Interest Table (PIT). Die FIB wird genutzt um Interest-Pakete an potentielle Datenquellen weiterzuleiten. Sie funktioniert ähnlich wie eine IP FIB, allerdings können hier mehrere Datenquellen pro Name gespeichert werden. Der Content Store ist äquivalent zum Puffer Speicher eines IP-Routers, bedient sich allerdings einer anderen Ersetzungsstrategie. Während IP-Router eine MRU Ersetzungsstragie verfolgen, 4

48 2 ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN orientiert sich der Content Store am LRU oder LFU Algorithmus. MRU wäre nicht sinvoll, da der CCN-Knoten immer über möglichst aktuelle Daten verfügen soll. In der PIT wird gespeichert, welche Interest-Pakete an welche Adressen weitergeleitet wurden. Will ein Benutzer heutzutage eine Datei beziehen, kennt er von ihr in der Regel lediglich die URL. Diese wird dann an den nächsten Root-Nameserver gesendet, um die Adresse des zuständigen DNS-Servers zu erhalten, z.b. microsoft.com. An Diesen wird anschließend wieder eine Anfrage gesendet, um die Adresse eines nahe gelegenen Servers zu erhalten, der die benötigten Daten enthält. Nun können die Daten angefragt werden. Abbildung 3 veranschaulicht das Vorgehen nocheinmal. Abbildung 2. CCN-Knoten [9] Abbildung 3. CCN-Knoten [] B. DONA DONA schlägt eine komplett neue Namensgebung innerhalb des Internets vor. Dazu führt es sogenannte DONA-Namen ein. Sie sind flach, selbstzertifizierend und jede Datei, jeder Service, Host, jede Domain usw. verfügt über einen. Jeder Name hat einen Namensvorsteher, der für jede seiner Dateien einen öffentlichen und einen privaten Schlüssel besitzt. DONA-Namen haben die Form P:L, wobei P der Hashwert des Namenvorstehers ist und L der Name der Datei. Beispiel: SHA-1(Bastian Laur):p2pReferat.txt. Um die globale Einzigartigkeit des Namens muss sich der Namensvorsteher kümmern. Ebenso bestimmt er die Granularität der Namen und welche Server seine Daten anbieten dürfen. Granularität meint hier, dass der Vorsteher bei einer Webpräsenz z.b. lediglich der kompletten Website einen Namen gibt. Er könnte aber auch jede Unterseite einzeln benennen. Welche Server die Daten des Vorstehers anbieten dürfen, bestimmt dieser, indem er sie dazu explizit mittels eines REGISTER Befehls autorisiert (siehe Abschnitt V.B). Des Weiteren gibt es einen FIND Befehl, mit dem Benutzer Daten anfordern können (siehe Abschnitt IV.B). Treffen anschließend die Daten ein, handelt es sich dabei immer um Tripel der Form <Inhalt, Öffentlicher Schlüssel des Vorstehers, Signatur des Vorstehers>. Statt auf DNS-Servern beruht DONA auf einer neuen Art von Knotenpunkten. Den sogenannten Resolution Handlers (RHs). Diese sind für die Verarbeitung der FIND und REGIS- TER Befehle zuständig. C. Content Routing Die Content Routing Architektur adressiert speziell das Problem des Routings. Beim Content Routing dagegen gibt es sogenannte Content Router (CR). Diese können als normale IP-Router benutzt werden, haben aber darüber hinaus noch eine Routing Tabelle in der Name-To-Next-Hop Einträge gespeichert sind. So kann ein Client eine URL direkt an den nächsten CR senden. Dieser extrahiert aus der URL die Serverkomponente und sucht in seiner Routing Tabelle den besten benachbarten CR um die Anfrage effizient weiter zu leiten. Durch diese Konstruktion entfällt das initiale Auflösen einer URL komplett. Des Weiteren können die CRs selbstständig entscheiden, von wo die Daten am Effizientesten bezogen werden. Will ein Client z.b. ein Video von youtube.com beziehen, können zwischenliegende CRs entscheiden, ob sie die Anfrage an youtube1.com, youtube2.com oder youtube3.com weiterleiten. D. Freenet Bei Freenet handelt es sich um die Idee eines verteilten Informationsspeichers, bei dessen Design besonderen Wert auf die Privatsphäre der Benutzer und die Verfügbarkeit von Daten gelegt wurde. Um genau zu sein hat Freenet fünf große Ziele: Anonymität sowohl für die Ersteller als auch Konsumenten der Daten soll gewährleistet werden Die Quelle einer Datei soll bei Bedarf unerkannt bleiben können Dritten soll es nicht möglich sein den Zugang zu Daten zu blockieren 48

49 ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN 3 Das Speichern und Routen von Daten soll dynamisch und effizient sein Alle Netzwerkfunktionen sollen dezentral sein. Freenet ist als ein adaptives Peer-To-Peer Netzwerk aufgebaut, das aus Knoten besteht, die untereinander Nachrichten versenden um Daten zu erhalten oder zu speichern. Jeder Knoten verfügt über einen lokalen Datenspeicher und eine dynamische Routing Tabelle, in der gespeichert ist, welche Knoten über welche Daten verfügen. Daten werden über Schlüssel identifiziert. Um den Schlüssel einer Datei zu bestimmen gibt es drei Möglichkeiten. 1) Keyword-Signed Key (KSK) Der Name der Datei wird gehasht. Das Ergebnis bildet den Schlüssel der Datei. 2) Signed-Subspace Key (SSK) Da die Methode aus 1) schnell zu Kollisionen führen kann, hat jeder Bereitsteller von Daten die Möglichkeit einen eigenen Namensraum zu definieren, unter dem er seine Daten veröffentlicht. Bei Bedarf können auch mehrere Namensräume definiert und so Ordnerstrukturen abgebildet werden. Um den Schlüssel einer Datei zu ermitteln hasht man zunächst den Bezeichner des Namenraums und den Bezeichner der Datei. Die beiden Hashwerte werden anschließend mit einer weiteren Hashfunktion vereinigt. Das Ergebnis dieser letzten Berechnung bildet den Schlüssel der Datei. 3) Content-Hash Key (CHK) Wie der Name schon sagt, wird hier nicht der Bezeichner, sondern der Inhalt einer Datei gehasht. Das Ergebnis bildet den Schlüssel der Datei. Zum Hashen wird z.zt. ein 160 Bit SHA-1 Algorithmus verwendet. E. PSIRP Bei PSIRP handelt es sich um eine schichtenlose Architektur. Hinter ihr steht die Idee, dass eines der größten Probleme des derzeitigen Internets das zu große Vertrauen in den Sender von Informationen ist. Das Netzwerk leitet alles weiter, was der Sender sendet. So kommt es zu Problemen wie Spam Mails und Distributed Denial of Service Attacken. Deshalb verfolgt PSIRP ein Publish/Subscribe Paradigma, bei dem Sender Daten lediglich publizieren und nicht senden können. Empfänger können diese Daten abonnieren (z.b. bei Programmupdates). Zur besseren Strukturierung der Daten soll das Internet in Bereiche unterteilt werden, die zur Einteilung von Daten dienen und Zugriffsbeschränkungen ermöglichen. Zum Beispiel könnte ein Server einen Bereich Familie und einen Bereich Arbeit einrichten. Diese enthalten dann entsprechend nur familienrelevante Daten (z.b. Familienfotos) bzw. arbeitsrelevante Daten (z.b. Sitzungsprotokolle) und sind nur Familienmitgliedern bzw. Arbeitskollegen zugänglich. Jeder Bereich ist mit einer Datei assoziiert, in der gespeichert ist, welche Daten in ihm verfügbar sind und in welchem Unterbereich diese liegen. Das Internet kann bei PSIRP als azyklischer Graph von in Beziehung stehenden Daten betrachtet werden. Jede davon wird durch verschiedene Bezeichner identifiziert und einem Bereich zugeordnet. Die Bezeichner bestimmen die Beziehung der Daten zueinander auf den verschiedenen Ebenen (z.b. Anwendungsebene und Netzwerkebene). Die Bezeichner sind: Application Identifiers (AID): Wird direkt von Autor und Abonnent genutzt und ist der Bezeichner einer Anwendung. Rendezvous Identifiers (RID): Wird genutzt um Bezeichner der höheren Ebenen mit den Bezeichnern von niedrigeren Ebenen zu verbinden. Kann auch als Bezeichner einer Datei auf der Netzwerkebene angesehen werden. Scope Identifiers (SID): Der Bezeichner eines Bereichs. Er wird genutzt um die Erreichbarkeit von Daten zu begrenzen. Forwarding Identifiers (FID): Der Bezeichner eines oder mehrerer Knotenpunkte. Er wird genutzt um den Pfad von Daten zu bestimmen. Es kann sich lediglich um den nächsten Knotenpunkt oder um ganze Bäume für Multicasts handeln. Jede Datei verfügt typischerweise über mindestens einen AID und mindestens einen SID. Eine Anwendung löst zunächst den AID in einen RID auf. Dieser RID wird anschließend dem Netzwerk übergeben. Da eine Datei immer in einem Bereich liegen muss, ist ein RID auch immer mit einem SID assoziiert. Aus diesem lässt sich dann ein FID ermitteln. In diesem kann die Adresse des nächsten Routers oder auch ein ganzer Pfad gespeichert sein. Somit wird zum Anfordern von Daten nicht mehr die IP Adresse des Endpunktes benötigt. Sämtliche Kommunikation erfolgt direkt über den Dateinamen bzw. den RID. Auf diesem Paradigma soll die komplette Komunikation des Internets aufbauen. III. AUFFINDEN VON DATEN In diesem Kapitel geht es darum, wie die einzelnen Architekturen mit der Anfrage eines Clients nach einer oder mehreren Dateien umgehen. Dabei wird davon ausgegangen, dass ein Client den Bezeichner der Datei kennt, unabhängig davon, ob es sich dabei um eine URL, einen Hashwert, einen eindeutigen Namen oder sonstiges handelt. Mit Hilfe dieses Bezeichners, wird eine architekturspezifische Anfrage gesendet. Um den anschließenden Algorithmus zu erläutern, reicht es meistens aus den Ablauf im nächsten Knotenpunkt zu erläutern. Der Ablauf in den anderen Knotenpunkten verläuft dann äquivalent oder eventuell auch rekursiv. Ist die Anfrage beim entsprechenden Server angelangt und die Daten sind bereit zum Übertragen, gilt dieses Kapitel als abgeschlossen. Wie die Daten anschließend vom Host zum Client übertragen werden, wird im nächsten Kapitel behandelt. 49

50 4 ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN A. CCN Will ein Client Daten finden, muss er per Broadcast ein Interest-Paket verschicken. In diesem ist unter anderem der Name der gesuchten Daten enthalten. Da jeder CCN-Knoten über einen lokalen Speicher verfügt, in dem er Daten zwischenspeichern kann, überprüft er, sobald er ein Interest-Paket empfängt, ob sich die angeforderten Daten bereits in seinem lokalen Speicher befinden. Wenn ja, sind die Daten gefunden und können an den Client zurück gesendet werden. Das Interest-Paket wird anschließend verworfen. Liegen keine entsprechenden Daten im Speicher des CCN- Knotens vor, geht er seine Pending Interest Table (PIT) durch, in der alle weitergeleiteten Interest-Pakete gespeichert sind. Findet er in der Liste einen Client, der bereits die gleichen Daten angefragt hat, verwirft er die Anfrage und erstellt dafür einen weiteren Eintrag in der PIT. Da zwei Clients die gleiche Datei angefragt haben, wäre es eine Ressourcenverschwendung beide Anfragen weiterzuleiten. Stattdessen leitet der Knoten nur die erste Anfrage weiter und speichert die zweite Anfrage. So kann er bei einer Antwort diese vervielfältigen und an alle Interessierten weiterleiten. Liegt auch in der PIT kein entsprechender Eintrag vor, leitet der CCN-Knoten das Paket an den entsprechenden Eintrag der Forwarding Information Base (FIB) weiter. Ist kein entsprechender Eintrag vorhanden leitet er das Paket an alle seine Nachbarn, ausgenommen den Client selbst weiter und erstellt einen entsprechenden Eintrag in der PIT. Sollte nach dem Ablauf einer gewissen Zeitspanne keine Antwort kommen, wird der Eintrag wieder aus der PIT entfernt. B. DONA Will ein Client Daten finden, benötigt er dafür den entsprechenden DONA-Namen. Diesen sendet er verbunden mit einer FIND-Anfrage an den nächsten Resolution Handler (RH). Erhält der RH die Anfrage, prüft er in seiner Registration- Table, wie weit es von ihm aus bis zu der angeforderten Datei ist und den nächsten RH. Um die Entfernung anzugeben gibt es verschiedene Möglichkeiten, wie die Anzahl der zwischen liegenden Hops, die RTT (Round-Trip-Time) oder auch die physische Entfernung. Anschließend wird die Anfrage an den nächsten RH weitergeleitet. Liegen mehrere Einträge mit identischer Entfernung vor, ist es dem RH überlassen, welchen er zur Weiterleitung wählt. Liegt kein entsprechender Tabelleneintrag für den DONA- Namen vor, leitet der RH die Anfrage an seinen Parent, sprich den in der AS-Hierarchie übergeordneten RH (z.b. der Provider) weiter. Die FIND-Anfrage des Clients enthält neben der angefragten Datei auch dessen Domain-Namen. Gelangt die Anfrage zu einem RH oder Server, fügen diese ihre eigenen Domain- Namen an den des Clients an. C. Content Routing Benötigt ein Client Daten, sendet er eine Anfrage an den nächsten Content Router (CR). Wie die RHs von DONA Abbildung 4. Möglicher Weg einer FIND-Anfrage [8] hat jeder CR eine Menge von Name-To-Next-Hop Einträgen. Dieses geht der CR durch und bestimmt so, an welchen Hop er die Anfrage weiterleiten muss. Abbildung 5. Routing [] Erreicht die Anfrage einen CR der direkt mit dem Zielserver verbunden ist, antwortet dieser mit der Adresse des Zielservers. Dabei geht die Antwort den gleichen Weg wieder zurück. Kommt nach einer gewissen Zeitspanne keine Antwort von dem CR oder Server an den die Anfrage weitergeleitet wurde, geht der CR von einem Fehler aus und die Verbindung wird dann als nicht mehr gültig betrachtet. Die Anfrage kann anschließend zu einem alternativen CR oder Server weitergeleitet werden. Da immer nur zu Servern und nicht zu deren Inhalt geroutet wird müssen dadurch eventuell Ordnerstrukturen in die Server URL eingebunden werden. Aus wird somit D. Freenet Benötigt ein Client Daten, benötigt er zuerst deren Keys. Diese Keys bzw. diesen Key sendet er, verbunden mit einem Hopsto-live Limit an den nächsten Router, der zunächst prüft, ob die Datei bereits in seinem lokalen Speicher vorhanden ist. Ist die Prüfung erfolgreich, antwortet er mit der Datei. Andernfalls leitet er die Anfrage an den Router weiter, der am nächsten an der angeforderten Datei liegt. Dazu sucht er in seiner Routing Tabelle den Key, der dem angeforderten am nächsten kommt und leitet die Anfrage an den zugehörigen Router weiter. Antwortet der Router an den die Anfrage weitergeleitet wurde 50

51 ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN 5 nicht, oder mit einem Fehler, wird die Anfrage an einen alternativen Router weitergeleitet. Das gleiche passiert, wenn durch das Weiterleiten die Anfrage wieder zum Sender gelangt, also eine Schleife entsteht. Haben alle Kandidaten zu einem Fehler oder einer Schleife geführt, gibt der Router einen Fehler zurück. Abbildung. Zusammenarbeit der PSIRP-Komponenten [12] IV. BEZIEHEN VON DATEN In diesem Kapitel geht es um alles, was auf das Auffinden von Daten folgt. Der Schwerpunkt liegt dabei, wie die Antwort des Servers den Weg zurück zum Client findet. Also wie die Knotenpunkte mit der Antwort auf die Anfrage umgehen, die sie soeben weitergeleitet haben. Abbildung 6. Routing [6] Ist die Datei gefunden, wird sie über den gleichen Weg zurück geleitet. Dabei kopieren sich alle Router, die auf dem Weg liegen die Datei in ihren lokalen Speicher und tragen einen entsprechenden Eintrag in ihre Routing Tabelle ein. E. PSIRP Benötigt ein Client Daten, braucht er dazu deren Rendezvous Identifiers (RIDs). Diese kann er über Freunde, Suchmaschinen, Webseiten, usw. erhalten. Die RID wird an den Router gesendet, der für den Bereich des Clients zuständig ist. Aus der RID kann man den Bereich bestimmen, in dem die Datei liegt. Für diesen Bereich bestimmt der Router dann einen Forwarding Identifier (FID), mit dem er die Anfrage weiterleitet. In dem FID könnte lediglich der nächste Hop aber auch der komplette Pfad zur Datei enthalten sein. A. CCN Erhält ein CCN-Knoten ein Interest-Paket und kann die Anfrage befriedigen, verwirft er das Interest-Paket und antwortet dem Absender mit einem entsprechenden Data-Paket. Handelt es sich bei dem Absender um den Client ist der Vorgang beendet. Handelt es sich bei dem Absender um einen weiteren CCN-Knoten, prüft dieser anhand seiner PIT-Tabelle an wen das Data-Paket weitergeleitet werden muss. Haben mehrere Clients bei ihm die gleichen Daten angefragt, vervielfältigt der Knoten das Paket und leitet dieses an alle wartenden Clients bzw. CCN-Knoten weiter (Multicast). Der bzw. die betreffenden PIT Einträge werden anschließend gelöscht. Der Hinweg des Interest-Pakets ist also der Rückweg des Data- Pakets. B. DONA Erhält ein Server eine FIND-Anfrage, ist in dieser nicht nur der Name der gesuchten Datei, sondern auch der akkumulierte Pfad den die Anfrage gegangen ist, enthalten. Diesen dreht der Server um und gibt ihn seiner Antwort mit. Bekommt ein RH so eine Antwort, bestimmt er die Position seines Domain-Namens in dem Pfad und kann daraufhin den nächsten RH identifizieren. Der Pfad bleibt dabei vollständig erhalten. Denn diesen kann der Client wiederum umdrehen und für seine Antwort an den Server verwenden. C. Content Routing Stellt ein Client eine Datenanfrage an seinen nächsten CR, erhält er als Antwort die Adresse der Daten. Diese kann er anschließend beliebig verwenden, um auf die Daten z.b. mittels HTTP- oder FTP-Verbindung zuzugreifen. 51

52 6 ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN D. Freenet Erhält ein Router/Server eine Datenanfrage, die er befriedigen kann, Antwortet er mit der gewünschten Datei. Die Antwort geht dabei den gleichen Pfad zurück, den die Anfrage gekommen ist. Sämtliche Router, die auf dieser Strecke liegen, kopieren sich die Antwort, also die Datei, in ihren lokalen Speicher. So können sie bei einer erneuten Anfrage direkt mit der Datei antworten. Gegebenenfalls wird auch die Routing-Tabelle aktualisiert, falls zunächst erfolglos probiert wurde, die Datei von anderen Routern zu beziehen. E. PSIRP Stellt ein Client eine Datenanfrage, hinterlässt diese eine Brotkrumenspur bei den Routern, die die Anfrage weitergeleitet haben. Über diese Spur wird die Antwort wieder zurück geleitet. A. CCN V. HINZUFÜGEN VON DATEN Erhält ein Server bzw. CCN-Knoten neue Daten, bleibt diese Information der restlichen Welt zunächst unbekannt. Dadurch können Server beliebig viele neue Daten aufnehmen, ohne dass das Netzwerk unnötig belastet wird, wenn keine Clients an den Daten interessiert sind. Sind die Daten jedoch für die restliche Welt von Interesse, wird es nicht lange dauern bis verschiedene Clients diese anfragen. Sobald ein Client die neuen Daten anfragt, werden diese per Broadcast gefunden und wie unter IV.A beschrieben, übermittelt. Beim Übermitteln des Data-Pakets trägt sich jeder CCN- Knoten, der auf dem Pfad liegt in seine FIB-Tabelle ein, von wo er eine Antwort auf die Anfrage bekommen hat. So kann der Knoten eine erneute Anfrage gezielt weiterleiten. B. DONA Hat ein Server ein Upate oder eine neue Datei erhalten, die veröffentlicht werden soll, schickt er einen REGISTER-Befehl an seinen lokalen RH. Vorausgesetzt der REGISTER-Befehl weist auf eine neue Datei oder einen kürzeren Weg zu einer bereits bekannten Datei hin, aktualisiert der RH seine Registration-Table und leitet den Befehl an seinen Parent und alle seine Peers weiter, was ein rekursives Update der einzelnen RHs zur Folge hat. Sollte eine Weiterleitung an den Parent oder bestimmte Peers nicht erwünscht sein, kann dies im REGISTER-Befehl vermerkt werden. Ist die Datei, die registriert werden soll bzw. ein kürzerer Weg zu ihr dem RH bereits bekannt, wird der Befehl verworfen. C. Content Routing In der zugehörigen Quelle finden sich hierzu keine speziellen Angaben. Allerdings lässt die Architektur darauf schließen, dass ein Server wie gewohnt Daten seinem lokalen Speicher hinzufügen kann. Die Adresse kann dann über Suchmaschinen, Links, Foren, Social Networks, usw. bekannt gemacht werden. Da die Adresse des Servers bereits in den Routern gespeichert ist, sind hier keine weiteren Modifikationen nötig. D. Freenet Will ein Benutzer neue Daten veröffentlichen, muss er zunächst einen zugehörigen binären Schlüssel, wie in II.D beschrieben, erstellen. Anschließend sendet er eine Pre-Insert Nachricht, die den Schlüssel und einen Hops-to-live Wert enthält, an den nächsten Router. Der Hops-to-live Wert gibt hier an, bis zu welcher Tiefe der Router die Datei verteilen soll. Erhält der Router die Nachricht, behandelt er sie ähnlich wie eine normale Suchanfrage. Zunächst prüft er, ob der Schlüssel bereits in seiner Storage Table vorhanden ist. Wenn vorhanden, sendet er die Datei als Antwort. So weiss der Benutzer, dass eine Kollision aufgetreten ist und er einen neuen Key wählen muss. Ist der Key nicht im Storage-Table vorhanden wird die Nachricht wie eine Suchanfrage an andere Router weitergeleitet, die ebenfalls mit der Datei antworten, wenn eine Kollision auftritt. Ist das Hops-to-live Limit erreicht und es wurde keine Kollision entdeckt, bekommt der Benutzer eine all clear Nachricht. Das bedeutet für ihn, dass sein gewählter Schlüssel noch nicht vergeben ist und er beginnen kann die Daten hinzuzufügen. Dazu sendet er wieder den Schlüssel und Hops-to-live Wert. Diesmal als Insert Nachricht. Die Insert Nachricht geht die gleichen Wege, wie die Pre-Insert Nachricht. Nun betrachten die auf dem Weg liegenden Router die Nachricht jedoch nicht als Anfrage, sondern als Antwort. Demzufolge speichern sie die Datei in ihrem lokalen Speicher und aktualisieren ihre Routing Tabellen. Damit gilt die Datei als hinzugefügt. E. PSIRP In der zugehörigen Quelle finden sich hierzu keine speziellen Angaben. Allerdings lässt die Architektur darauf schließen, dass ein Server wie gewohnt Daten seinem lokalen Speicher hinzufügen kann. Die Adresse kann dann über Suchmaschinen, Links, Foren, Social Networks, usw. bekannt gemacht werden. Da der zugehörige Bereich des Servers bereits den Routern bekannt ist, sind hier keine weiteren Modifikationen nötig. VI. FAZIT Der Vergleich der verschiedenen Architekturen zeigt, dass es bereits einige vielversprechende Ansätze gibt, um einige der derzeitigen Probleme des Internets zu lösen. Dabei haben verschiedene Architekturen verschiedene Schwerpunkte. Bei CCN fällt auf, dass man eine Datei von mehreren Quellen gleichzeitig beziehen kann, DONA will das Namenssystem des Internets revolutionieren, Freenet bemüht sich stark um die Privatsphäre der Nutzer, Content Routing sieht die Latenz beim Umwandeln einer URL in eine IP Adresse und die damit verbundene Anfrage bei einem DNS Server als eines der größten Probleme an. 52

53 ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN Doch trotz der unterschiedlichen Ansätze fiel beim Vergleich auf, dass zwei grundsätzliche Ideen immer wieder aufgegriffen wurden. Zum einen der Gedanke, dass die zwischen Client und Host liegenden Entitäten Daten zwischenspeichern können, um bei einer erneuten Anfrage direkt mit den geforderten Daten antworten zu können und so das restlichen Netz zu entlasten. Und zum andern die Idee, Daten global eindeutige Bezeichner zu geben, die aber nur vom Inhalt und nicht vom Ort der Datei abhängig sind, was beim momentanen System mit URLs nicht gegeben ist. Gerade der zweite Gedanke liegt nahe, wenn man Daten auf mehrere Server verteilen aber trotzdem serverunabhängig darauf zugreifen will. Abschließend lässt sich feststellen, dass keiner der Ansätze den Anspruch erhebt eine vollständige, implementationsfähige und realistische Lösung zu sein. Die hohe Anzahl von Publikationen in den letzten Jahren lässt jedoch vermuten, dass die Forschungen weiter gehen und die Lösungsansätze immer präziser und umsetzungsfähiger werden. LITERATUR [1] M. Alduán, F. Álvarez, Th. Zahariadis, N. Nikolakis, F. Chatzipapadopoulos, D. Jiménez, and J. Manuel Menéndez. Architectures for future media internet. In 2nd International Conference on User Centric Media, Palma de Mallorca, September [2] Future Internet Assembly. Why do we need a Content-Centric Future Internet? European Future Internet Portal, [3] Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Michael Walfish. A Layered Naming Architecture for the Internet. In ACM SIGCOMM 2004, Portland, OR, September [4] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I. Stoica, and S. Shenker. Rofl: Routing on flat labels. In ACM SIGCOMM 2006, Pisa, Italy, [5] D. Cheriton and M. Gritter. Triad: A new next-generation internet architecture. In 3rd USENIX Symposium on Internet Technologies and Systems, San Francisco, California, USA, March [6] Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore W. Hong. Freenet: A distributed anonymous information storage and retrieval system. Lecture Notes in Computer Science, 2009:46+, I, 6 [] Mark Gritter. An architecture for content routing support in the internet. In 3rd USENIX Symposium on Internet Technologies and Systems, San Francisco, California, USA, March I, 3, 5 [8] T. Koponen (ICSI/HIIT), A. Ermolinskiy M. Chawla, B.-G. Chun, K. H. Kim (UCB), S. Shenker (ICSI/UCB), and I. Stoica (UCB). A data-oriented (and beyond) network architecture. In ACM SIGCOMM 200, Kyoto, Japan, August 200. I, 4 [9] V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs, and R. Braynard (Palo Alto Research Center). Networking named content. In CoNEXT 2009, Rome, Italy, December I, 1, 2 [10] John Kubiatowicz, David Bindel, Yan Chen, Steven Czerwinski, Patrick Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westley Weimer, Chris Wells, and Ben Zhao. Oceanstore: An architecture for global-scale persistent storage. In ASPLOS-IX Proceedings of the 9th International Conference on Architectural Support for Programming Languages and Operating Systems, Cambridge, MA, USA, November [11] U. Lee, I. Rimac, and New Jesey U.S.A. V. Hilt (Bell Labs, Alcatel- Lucent. Greening the internet with content-centric networking. In e- Energy 2010, 1st International Conference on Energy-Efficient Computing and Networking, University of Passau, Germany, April [12] Kari Visala Sasu Tarkoma, Mark Ain. The Publish/Subscribe Internet Routing Paradigm (PSIRP): Designing the Future Internet Architecture, pages IOS Press, I, [13] T. Zahariadis, P. Daras, J. Bouwen, N. Niebert, D. Griffin, F. Alvarez, and G.Camarillo. Towards a Content-Centric Internet. IOS Press, April

54 TRAFFIC ANALYSIS OF P2P APPLICATIONS 1 Traffic Analysis of p2p Applications The An Binh Nguyen Abstract The popularity of P2P applications is continued to grow. Parallel to this growth, P2P protocols are getting more complex. Nowadays the problem of Quality of Service is often in question of P2P research field. A peer node has to store data, receives queries from other peer nodes, and distributes its content for other peers. Such processing peer node can generate bulky traffic to the network. Also for each node we have to reserve enough resources for this peer node to function. P2P is not only used in many legal applications, but also finds its place for illegal doing e.g., DDoS attack. The need of P2P application analysis and traffic monitoring therefore have become mandatory. P2P traffic needs to be analyzed in order to optimize load of P2P traffic. When P2P node consumes too much resources, we need to monitor P2P traffic and detect this problem in runtime, in order to perform load balancing in right time and prevent corruption of P2P networks. Monitoring P2P traffic also helps prevent malicious attempt, for instance DDoS attack based on P2P. There have been many works for P2P traffic analysis. This paper considers some of them, describes their approaches and tries to address advantages and disadvantages of each method. We analyzed the approaches and believe that each approach can be useful for a particular interest. Also machine learning would be more important in the future for P2P traffic analysis. Monitoring P2P traffic is still a challenge due to dynamic properties of P2P networks, a great number of new P2P applications and the big scale of the network. Monitoring of P2P is often decentralized. We tend to believe hybrid approach (combination of both centralized and decentralized) would be a good solution for P2P monitoring, which compromise advantages of both centralized and distributed monitoring scheme. I. INTRODUCTION P2P is a network architecture, where a group of computer users can communicate with each other and directly access files from other s hard drive in a decentralized manner. P2P introduces some advantages compared to other classic architectures such as decentralized organizing systems, high scalability. Therefore P2P has been widely used in many applications for file sharing, content distribution (BitTorrent, EMule etc.), chat, Voice over Internet protocol (VoIP) e.g. Skype and also for malicious attempts, for instance malware distribution (botnet) or DDoS. The growth of P2P implies a lot of consequences. Basher et al. [4] analyzed network traffic, which were generated from classic web applications and from P2P applications. They found out that compared to web traffic, P2P traffic contributes many large-sized and many small-sized packets. P2P flows also last longer, inter-arrival time between two P2P flows is longer than web traffic, packet size of P2P is often larger [1]. These findings indicate, that a large amount of network traffic is contributed by P2P traffic. This result is confirmed in [2], [8], [10], [14], [18]. Due to decentralized manner, P2P might be deployed not only to share illegal file contents, but also to attempt DDoS attacks [], [22]. Because of its complexity and widely used, it has become mandatory to analyze P2P traffic. Torres et al. [19] discussed three reasons based on domain knowledge, why it is necessary for P2P traffic analysis. First of all for network operators, a large distributed amount of traffic from P2P may reduce the performance of the whole network, which is why network operators want to analyze and monitor behaviors of such applications, in order to adjust network under different circumstances.. Second of all, for P2P application designers, it s important for them to evaluate their implementation and do improvements, so comes the role of P2P traffic analysis. For end users it might be interesting to control incoming and outgoing traffic of their systems, to be able to detect suspicious attempts of P2P applications and also be able to balance load in their local machine. In summary the quality of service, load balancing, P2P based attack prevention and detection encourage the need of P2P analysis and monitoring. In the early day, monitoring was often done in centralized manner, where a centralized monitoring entity exists to monitor the network. The scale of monitoring has now become larger. For a big scale P2P network, a centralized scheme is inefficient. Usually a decentralized or hybrid monitoring scheme is preferred in P2P applications. Some approaches were introduced in [12] [20] [1]. To detect particular behaviors of P2P networks, particular metrics should be considered. Some of metrics can be named such as: flow size, flow inter-arrival time, duration, number of destination ports, traffic volume etc. In this paper we will see, how these metrics are used in research works. There have been many contributions in analyzing P2P traffic. In this paper some methods will be considered and reviewed to see the developments of P2P traffic analysis methods and their future. In order to analyze P2P traffic the first thing needs to be done is distinguish P2P traffic from the other traffic. The first generation of P2P applications was not so complex, they often used default ports and default protocols, thus it was able to look into payload to determine P2P traffic. This so-called payload based technique was mentioned in [18] [13] [14] [2]. Through time P2P application got more complex. They can even disguise themselves as usual traffic by randomizing port or use default ports of other traffic. P2P applications can also encrypt their transmitted content, so a fully payload-based technique is not always possible. Using payload-based technique we can detect known P2P traffic, but to discover unknown P2P traffic and overcome many disadvantages of payload-based non-payload-based techniques are necessary. Non-payload techniques or heuristic based techniques are based on common behavior patterns to identify P2P traffic due to nature of P2P. Common characteristics of P2P traffic are, for instance the use of both TCP/UDP, same number of distinct ports and destinations connect to host [13], [14], peer node acts in both roles as client and server [6]. Other approach based on machine learning to learn the behavior of P2P traffic is applied in [8], but it is still in development and in 54

55 2 TRAFFIC ANALYSIS OF P2P APPLICATIONS some cases inefficient. But use of machine learning to extract traffic patterns of P2P can be further improved and would get more efficient in the future. The rest of the paper is structured as follows. The second section will summarize analysis methods. This section contains of three main parts, how P2P traffic can be identified, how can we monitor P2P traffic and how P2P traffic were analyzed in research papers. The third section will discuss the summaries from this paper. The last section is the conclusion. A. P2P Traffic Identification II. ANALYSIS METHODS Although P2P applications are heterogeneous in term of specification of their protocols, they still have many things in common. The nature of P2P is equality among peers. In file sharing P2P applications, each peer gets a part of wanted data from other peers, and offers a part of this data for other peers as well. It implies the roles of server and client. A peer must therefore satisfy the function of both roles. This nature indicates some common characteristics of P2P applications. These characteristics can be made used for identifying P2P traffic, especially when it comes to unknown P2P protocols. Some of the most used characteristics of P2P traffic can be listed as followed: C1: Nowadays P2P applications use both TCP/UDP to exchange control message and data. UDP is often used for queries, control messages or responses, while TCP is often used for transmission. Because of that IP pairs which use both TCP/UDP should be the first candidate of P2P traffic network. This characteristic is widely used in almost every heuristic based P2P identifying methods. C2: In many P2P applications the number of distinct ports is equal to the number of distinct destinations, since peer node often choses an arbitrary port to connect to other nodes, which implies another heuristic for identifying P2P flows. C3: Many P2P applications can disguise their used ports as default ports from other web traffic. Still the difference is web traffic tends to open many parallel connections to host. On the contrary P2P data transmission consists of many consecutive connections, there is at most one connection at one time. Based on this heuristic it is able to separate disguised P2P from web traffic C4: P2P is in major used for file sharing, P2P traffic often contains many large sized flow or long duration flow. C5: In P2P file sharing, the file is divided in many smaller chunks. Therefore if source and destination peers use fixed ports for data transfer, it should exist many identical flows with similar flow identities <SourceIp, SourcePort, DestIp, DestPort, protocol, etc.> C6: A set of classic P2P applications often use fixed ports to transfer data. This heuristic is despite of its simplicity quite useful to identify the well-known P2P traffic in the first step. Besides the use of P2P for file sharing, chat, P2P is also used for streaming data. The characteristics of these kinds are quite different to P2P file sharing applications, especially for overlay characteristics. These kinds are for the time being outside scope of this paper, and should be considered in future papers. For an overview of overlay characteristics of P2P streaming applications refer in [21]. In order to identify P2P traffic, two main approaches are possible. The paper will introduce 6 methods which will be called MI1, MI1, MI2 to MI5 (stand for Method for Identification). Methods can be categorized as payload-based, non-payload-based (or heuristic-based) and machine learning technique. Payload-based technique is applied to identify traffic, where it is possible to look into the content of network traffic. Non-payload-based technique or heuristic-based technique makes use of common characteristic to identify P2P traffic. A classification of introduced methods and their category can be found in Figure 1. MI1 and MI1 are payload-based technique. MI2 to MI4 are heuristic-based technique. The last introduced method MI5 is machine learning technique. For further details of each method, refer in next coming text. MI1: Karagiannis and Broido [13] proposed a payloadbased method to identify P2P traffic, using C6. The method consists of three steps. The first step is to compare source port and destination port of a flow to a table of well-known P2P applications. This step is quite common since it is quite simple to perform this step, and these well-known P2P applications are often well-documented. With this all known P2P applications with fixed ports are identified. The second step is to look into the payload of each packet in a flow and compare these strings against a table of known protocols. In case of a match we can identify the flow to the corresponding known P2P applications. The third step considers the host IPs which were identified as P2P flows from step two, and classifies all flows that contains one of these identified IP addresses as possible P2P. In this step all known services such as , DNS, FTP are excluded to reduce the false positive rate. MI1 is simple but exposes many drawbacks. MI1 can only identify well-know P2P applications, unknown P2P traffic are still not to be identified. Payload matching is still difficult since the limit size of capturing packets doesn t allow to fully look into payload. In case applications encrypt the payload, it will be impossible to look into the true content. Another problem of this approach is privacy issue. There is privacy law, which often forbids researcher to look into real content of network traffic. MI1 : Technique of MI1 was improved in [14]. MI1 holds the first two steps as in MI1 with two additional steps to improve step three. In MI1 step three will consider UDP flows and step four will consider TCP flows. As in MI1, in step three all source and destination IPs of UDP flow will be hashed in a table, and all the flows, which contain IP address from this table will be considered as possible. Step four does the same thing as in step three for all TCP flows, to retrieve the second IP address tables. For these two steps the exclusion of web traffic as in MI1 still remains to reduce the false rate. As for advantage MI1 uses not only C6 but also 55

56 TRAFFIC ANALYSIS OF P2P APPLICATIONS 3 Fig. 1. Classification of P2P Identification Methods C1. Step three and step four help to partially overcome limit packet size problem and a better upper bound for identified P2P traffic. Still for general the upper bound of these payload-based technique is still too great, and fully overcome the problem of encryption is still far from possible. MI2: As seen from these two payload-based techniques, there are still many drawbacks with such techniques. Fully looking into a packet is due to privacy issue usually forbidden, and the need of identifying new P2P traffic became greater. Therefore the creation of non-payloadbased techniques was necessary. In [13] the authors, besides payload-based approach, also contributed a nonpayload based technique (MI2) of identifying P2P traffic, using heuristics based on characteristics C1 and C2. Based on C1 all IP sources and destinations which concurrently use both TCP/UPD during a time t will be considered as P2P. All well-known other services like NETBIOS, IRC, DNS, which have similar behaviors will be excluded. For C2 all flows which have the difference of numbers of distinct connected IPs and distinct used ports larger than a threshold (in this paper 10) will considered P2P flows. This technique compared to MI1 and MI1 provides a new way to efficiently identify new kind of P2P traffic. But still the false positive problem is an opened question. The first heuristic of this method depends on viewed time t, the ratio of UPD and TCP in a P2P application may vary. For the second heuristic if threshold is chosen too big or too small, it can affect the result, thus it may still generate false determination of non-p2p traffic. MI3: Constantinous and Mavrommatis [6] used the same idea as MI2, which is based mainly on C1 and C2 to discover new P2P traffic ports. Their implementation is a little different to MI2. MI3 introduced term diameter. Diameter is used to measure the interaction rate between peers. Each host is assigned a level, the level means the time when host receives first connection from another, or first time to be touched. A host is assigned one level greater than its parents. For the classification, the number of hosts that acts in both roles server and client at a port should exceed a threshold thus satisfies C1, network diameter should greater than two, and number of host, which are present in network should also exceed a threshold. Advantages and disadvantages of MI3 is similar to MI2, since it uses the same characteristics and quite the same idea. MI4: Perenyi et al. [18] used all mentioned characteristics to identify P2P traffic. In preparation MI4 tries to exclude all web traffic that have the same behaviors with TCP/UPD based on their default ports. The first step is identify flow with characteristic C1. The second step tries to refine separation from web traffic and P2P traffic which disguise as web traffic using C3. Some of flows can be identified using default ports(c6). C5 is then applied to identify identical flows which might belong to P2P applications. The next step is empirical experience of the authors. They found out, that if an IP uses TCP/UPD port more than 5 times in a period time, this IP,port indicate P2P traffic. The last step chooses flow where flow size is larger than 1MB or flow duration is longer than 10 minutes. Advantage of this technique, like other heuristicbased technique is to be able to discover unknown traffic, but also introduces less accurate results, however because of its consistencies, it is still suitable for P2P traffic analysis. MI5: Another approach should be mentioned is machine learning based technique. An example of such approach 56

57 4 TRAFFIC ANALYSIS OF P2P APPLICATIONS TABLE I CHARACTERISTICS VERSUS P2P IDENTIFICATION METHODS Method Identification MI1/MI1 MI2 x x MI3 x x Characteristics C1 C2 C3 C4 C5 C6 x MI4 x x x x x x MI5 x can be found in [8]. MI5 uses clustering technique, defines cluster with interesting metrics, such as flow size etc. MI5 only needs statistic of unidirectional flow. With the help of training data, which were achieved from both payload-based and non-payload-based techniques. For each flow it can determine to which class (P2P, or other web traffic) the flow should belong. MI5 is also useful to learn the new behaviors of P2P traffic, as well as classify them. MI5 is still in development, since MI5 concentrated mainly on TCP and lets UDP out of concern. Through empirical experiments MI5 works better for better for server-to-client statistic. The result from server-toclient direction often has higher accuracy. In the future work, the authors intended to extend their technique, so that it will be able to classify UDP traffic and also work better with client-to-server direction. For the end of this section, a table for an overview which characteristics were used by which methods, is provided in Table I. For recall MI1 and MI1 are payload-based technique. They used the port-based characteristic and content of the traffic to identify P2P traffic. C1 and C2 are the most common used characteristics in heuristic-based methods. The machine learning based method MI5 often uses the statistic of large flow size to identify P2P. B. P2P Traffic Monitoring Monitoring is an important task not only for P2P traffic analysis, but also for administration purpose. Monitoring scheme in general can be classified in three categories, centralized scheme, decentralized scheme (distributed scheme) and hybrid scheme [16]. Normally for monitoring purpose, monitoring agent is needed. The centralized monitoring scheme results accurate information. But centralized scheme is often not scalable, since a central entity has to take responsible to monitor the whole network. Decentralized or distributed scheme can overcome the problem of scalability, but introduces other problems. In such scheme peers are responsible for monitoring each other. This can be a problem, if one peer provides false information, it can affects the global conclusion for the state of the network. Also a peer can attempt malicious doing, such as injecting malicious code etc. A better solution for monitoring problem would be a hybrid scheme, where we should use centralized scheme if possible, and decentralized if not. The combination of two major monitoring schemes might overcome disadvantages of each of them. The current state of P2P monitoring is still not perfect. The risk of false positives is still high. Use of arbitrary address in P2P applications makes it difficult to identify peer and cause misidentification, especially in case P2P is behind NAT. In case P2P applications use tracker like BitTorrent, the behaviors of monitoring agent (crawl and monitor all) is likely to be identified as attempt of denial of service attack and would be blocked. The risk of exposing P2P agent is therefore high, which implies task for designing such monitoring agents, is to assign these agents multiple IP addresses. The monitoring scheme in [5] can be classified as a hybrid scheme. The authors proposed monitoring approach for chord based protocols. In this approach the overlay of P2P network is divided in many subparts. Each subpart is monitored and measured as desire. Data are sent back to a central collecting point. One distributed monitoring scheme was P2PML, which can be deployed not only in P2P monitoring, but also in monitoring web services as well. This idea of distributed monitoring was introduced in [1]. The monitor system itself is a P2P network that coexists with monitored P2P network. Each peer can be member of monitoring and monitored network. The system uses a declaration subscription language, P2PML to describe monitoring tasks. Monitoring tasks are described using P2PML, a description language based on XML. Thus is easy to implement and adapt, since XML is a widely-used standard. Peers in monitored P2P system observe activities, publish information stream. A peer may host alerter, which intercepts inbound and outbound and detects changes, stream processor which does operation on streams, publisher which publishes stream generated from stream operation. When a user is interested in a specific monitoring task, he can subscribe to a channel, which will publish the stream. The filter bases on Atomic Event Set Algorithm and YFilter Algorithm to match pattern. By defining condition the desired information can be filtered. A subscriber, who is interested in a part of network can subscribe to a channel, which was published by monitoring peers. Although this idea is interesting for monitoring task not only for P2P systems, but also for web services call, it still has drawbacks. Alerters have to be implemented for each type of monitored system. Furthermore for analysis purpose the use of another P2P system as monitoring system may introduce confusion. As stated in introduction for P2P monitoring task, distributed and hybrid schemes are often applied. Other distributed monitoring scheme can be found in [9], [11], [15] For the end of this section, a list of common used metrics are provided. In section of traffic analysis we will see, how these metrics are differently considered in each different work. Traffic volume or throughput (traff_vol): The whole P2P traffic volume, which was captured. flow size (flow_size): Size of P2P flow flow duration (flow_duration): Time begins when one P2P flow started, until this flow ends. flow inter-arrival time (flow_inter_arr_time): Time between each arrival of two consecutive P2P flows. packet size (pkt_size): size of a packet, which belongs to P2P traffic. Live connection or number of TCP connections from a host (live_conn): Number of TCP connections, which belong to P2P traffic in a period of time Geographical distribution of peer (geo_distr): how peers 5

58 TRAFFIC ANALYSIS OF P2P APPLICATIONS 5 are geographically distributed. Bit rate (bit_rate) P2P population or number of peers (peers_popu): Number of P2P peers. Popularity distribution (how traffic is distributed among IP address) (poplr_distr): the number of distinct IP addresses among peers. C. P2P Traffic Analysis Traffic analysis generally consists of identification, choice of interesting metrics (filter of them from the identified traffic) and the analysis result based on the metrics. In the following the methods will be called as MA (method of analysis) MA1: Karagiannis et al. [14] used MI1 to identify P2P traffics and collect P2P traffic traces. The traces were collected by monitoring traffic of two commercial backbone links San Jose - Seattle in US. The authors collected the traces and learned P2P traffic characteristics, by measuring the following metrics: bitrate of P2P traffic, population of P2P traffic (number of distinct IP mapped to Autonomous systems), traffic volumes of P2P traffic relative to all traffic columns. With their results the authors also concluded that P2P trend changed but never died. Since MI1 is payload-based technique, as described above, it can not identify all P2P traffic, but the identifiable P2P protocols were in time the most traffic contributed. This means for the purpose of the paper, the method was sufficient. MA2: Louis et al. [1] contributed an early analysis work in field of P2P traffic analysis. MA2 used only characteristic C6, compared flow ports with famous applications default ports, to identify P2P traffic. Although it was restricted only to some famous P2P applications, but these application in time contributed most P2P traffic to the Internet. Furthermore MA2 only wanted to analyze the most famous protocols. MA2 captures all TCP packets between BAS 1 and the IP Backbone. MA2 analyzed and also compared some famous P2P protocols such as edonkey, BitTorrent, FastTrack, WinMX. These protocols are compared with regards to the following metrics: traffic volumes, connection duration, geographical distribution of peers, termination of connections, whether the connection ended normally, connectivity of peers (number of local peers and non-local peers) and from this result described the different behaviors of each application type. MA1 still had many restrictions, w.r.t. P2P identification. With the growth of P2P network nowadays, MA2 is not really efficient anymore. Nevertheless MA2 gave us many interesting behaviors of P2P traffic in early time, which is also contribution for P2P traffic analysis. MA3: Baset et al. analyzed the most famous P2P VOIP Skype in [3]. Since Skype is not open-sourced, its protocol is not clear. Skype s used port can be altered, so it is impossible to use approach like in MA1 or in MA2. Instead of monitoring to capture traffic of skype, 1 Broadband Access Server MA3 uses shared library and system call redirection technique to overload shared library functions. With the overloaded share functions, when Skype client calls a function from shared library (this is applied for Linux OS) the called function can redirect the input parameter to output. Thus it is able to get interesting information from Client behaviors, targeted modify calls and then analyze interesting results/behaviors from called parameters. In this work the authors are interested in protocol aspect of Skype client. One common viewed metric is also analyzed here, namely geographical distribution. MA3 is an efficient approach if using Linux as OS for analysis purpose, since the manipulation of called share library is nature part of Linux OS. But with approach like MA3, other measurements like flow size, flow duration etc. will not be considered. Only behaviors of peer client is analyzed. The characteristic of overlay network in this case is missed. MA4: In [18] data for analysis were collected from two Cisco routers at one large Internet provider in Hungary. MA4 used NetFlow to collect traffic flow information and also some packet-level information. The method MI4 was applied to identify P2P traffic. MA4 focused on comparison between P2P and non-p2p traffics. Therefore following metrics were considered: P2P traffic volume compared to total traffic, number of P2P users/total active users, and in order to reduce error MA4 associated an individual IP address to a user, flow size and flow duration, packet size, thus to analyze the properties of P2P traffic in data transmission and the differences between P2P protocols, and popularity distribution. MA4 used MI4 which is easy to implement, like other heuristicbased techniques, MI4 might introduce false positives. The author proposed a solution by assigning individual IP address to a user, which might reduce accuracy. But for interest of Internet Provider, and the whole purpose for comparison P2P and non-p2p traffic, this less-accuracy can be tolerated. MA5: Basher et al. [4] dedicated their work to compare P2P traffic and network traffic. The traces were collected by using lindump, which monitors ports and captures all TCP/IP packets from the commercial Internet link of the university Calgary. For identification of P2P flows/applications MA5 uses port-based and payload signature-based technique. MA5 considered flow size, flow duration, flow inter-arrival time, maximum number of TCP flows from a single host, transfer volume and geographic distribution. As other methods the less-accuracy problem of signature-based technique is not a non-tolerated problem. The traces in MA5 were not collected continuously, thus might not cover all abnormal behaviors of traffics, but either way the most common characteristics of P2P are already covered. MA6: Torres et al. [19] focused on analyzing and finding undesirable behavior from P2P traffic. All TCP and UDP traces were collected by using Tstat at a MiniPoP router, where all traffics go into Internet backbone. Tstat is a 58

59 6 TRAFFIC ANALYSIS OF P2P APPLICATIONS TABLE II COMMON USED METRICS VERSUS ANALYSIS METHODS MA1 MA2 MA3 MA4 MA5 MA6 traff_vol x x x x x flow_size x x flow_duration x x x flow_inter_arr_time x x pkt_size x x live_conn x x geo_distr x x bit_rate x x peers_popu x poplr_distr x x tool, which can capture flows and perform Deep Packet Inspection, thus enables users to identify known P2P traffics based on payload. MA6 focused on EMule, Kad, and KadU (a modified version of Kad). These 3 application contribute the most traffic to the monitored network. Signatures of these application were already mentioned in other works, therefore classification of these three were not a problem. MA6 applied a machine learning approach, density based algorithm to divide the data set in subsets (clusters), in which the data have similarity. Normally noise region, which was generated after the last step would be considered interesting. However in this case the authors of MA6 chose to select interesting regions based on domain knowledge of network operator, P2P developer and P2P users. MA6 considered metrics as dependent from flow initiator and independent from flow initiator. Metrics dependent from flow initiator are flow average duration, number of active flows, ratio of outside connections to total numbers, bit rate, average packet size, ratio of byte sent and byte received. Metrics dependent of flow initiator are total connection attempts, ratio of flows to the number of distinct destinations, number of peers, number of destination ports, also number of destination ports which are under 1024 was considered. Using signature-based technique for identification, MA6 limited it s work only with three P2P protocols. MA6 analyzed traffic based on domain knowledge, which is better for classification of behaviors at host level, and the way MA6 chose interesting region can be applied in other works as well. Table II is a summary of corresponding metrics in each analysis methods. We can recognize from the table, that the use of each metric differentiates in each work. The reason is, each work has it s own focus on a particular direction. Of all metrics, the metric traffic volume of P2P was the most considered one. It is also a sign, that P2P traffic is getting larger over time and this naturally raises concern of P2P network administrator and researcher. III. DISCUSSION As we have already seen, the common template of P2P traffic analyzing is identify P2P traffic from other traffics, filter them, chose the appropriate metrics, which should be interesting with regard to each particular work, evaluate the worked results from the collected data. There have been many works for P2P traffic identification, they can be general categorized as payload-based, non-payload based and machine learning based methods. Non-payload based has advantage, that it might be able to discover new P2P traffic, which is also a concerned question for analysis. But non-payload based techniques introduce false-positives. In fact four from six described methods chose payload-based techniques, because they only concerned about particular well-know protocols. Payload-based can not discover new P2P traffics, but it can guarantee the correctness of those identified. Therefore the choice of identification method must primarily base on purpose of each research. In this case payload-based is better, but in other case the use of non-payload based it recommended. Early works in P2P analysis focused on comparison between P2P traffic and web traffic, in order to determine the trend of P2P. Especially the traffic volume at the beginning was concerned, as for Internet Provider it would be critical to keep their network at good performance. Then the concentration moved to learn the characteristic and behavior patterns of P2P traffic. From this point on P2P protocols get more complex, as for the trend of network analysis this paper found the idea based on domain knowledge a good approach for future work. For network operator, it is mandatory to be able to monitor P2P traffics, to optimize P2P networks and prevent P2P networks from corruption. Monitor of P2P network is still a big challenge due to large scale of network and dynamic properties of P2P protocols. We have seen some solutions for this problem, but it still has to be developed. A general monitoring approach for all P2P traffic is still a big challenge. Hybrid monitoring scheme would be the solution for monitoring P2P networks. To learn the complex behaviors of P2P traffic machine learning is a good approach. The quality of machine learning process is dependent from the quality of the samples, i.e. a sample set from payload-based identified traffic can be fed in order to learn the behaviors pattern of these particular protocols, or sample set of both payload- and non-payloadtechniques can be fed to learning process. The training data can be used to detect and learn behaviors. By using machine learning process it is also able to learn about undesired behaviors of P2P traffic by choosing suspicious cluster. With this notice we tend to believe that further works in P2P analysis should use machine learning more, as P2P is getting more complex. IV. CONCLUSION This paper considered the problem of P2P traffic analysis and summarized some methods. For a better understanding, the methods were viewed as for identification, monitor/filter and analysis tasks. We reviewed the identification methods in two major approaches, payload-based and heuristic-based methods. Furthermore one approach for identification based on machine learning was reviewed. We stated the classification of monitoring scheme, named the problems and difficulties of P2P monitoring. Afterwards we listed the most common concerned metrics, which can be used for monitoring tasks as well as analysis purposes. We also summarized how these metrics were used in analysis researches. We showed that for 59

60 TRAFFIC ANALYSIS OF P2P APPLICATIONS each particular analysis purpose, appropriate metrics should be chosen. The paper also discussed possible advantages and disadvantages for each approach. As result, each approach despite of its drawbacks, can find its own usefulness depends on purpose of each work. For last word we also believed that machine learning would become more and more important in this study field. [21] Long Vu, Indranil Gupta, Klara Nahrstedt, and Jin Liang. Understanding Overlay Characteristics of a Large-scale Peer-to-Peer IPTV System. Computer, V, II-A [22] Ping Wang, S. Sparks, and C.C. Zou. An advanced hybrid peer-topeer botnet. IEEE Transactions on Dependable and Secure Computing, (3):235 12, April I REFERENCES [1] Serge Abiteboul. Distributed monitoring of peer to peer systems. Proceedings of the 9th annual ACM, pages 41 48, 200. I, II-B [2] Genevieve Bartlett, John Heidemann, and Christos Papadopoulos. Estimating p2p traffic volume at USC. ISI-TR-645, USC/Inform., (June), 200. I [3] Salman A. Baset and Henning G. Schulzrinne. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. Proceedings IEEE INFOCOM TH IEEE International Conference on Computer Communications, pages 1 11, April II-C [4] Naimul Basher, Aniket Mahanti, Anirban Mahanti, Carey Williamson, and Martin Arlitt. A comparative analysis of web and peer-to-peer traffic. Proceeding of the 1th international conference on World Wide Web - WWW 08, page 28, I, II-C [5] Andreas Binzenhöfer, Gerald Kunzmann, Robert Henjes, Andreas Binzenhbfer, and Am Hubland. A Scalable Algorithm to Monitor Chordbased P2P Systems at Runtime Institute of Computer Science Institute of Communication Networks. Processing, II-B [6] Fivos Constantinou and Panayiotis Mavrommatis. Identifying known and unknown peer-to-peer traffic. In Network Computing and Applications, NCA Fifth IEEE International Symposium on, pages IEEE, I, II-A [] Karim El Defrawy, Minas Gjoka, and Athina Markopoulou. BotTorrent : Misusing BitTorrent to Launch DDoS Attacks. Analysis, pages 1 6. I [8] Jeffrey Erman, A Mahanti, and Martin Arlitt. Identifying and discriminating between web and peer-to-peer traffic in the network core. on World Wide Web, pages , 200. I, II-A [9] B. Gedik. PeerCQ: a decentralized and self-configuring peer-to-peer information monitoring system. 23rd International Conference on Distributed Computing Systems, Proceedings., pages II-B [10] Takeo Hamada, Kaoru Chujo, Xiang Ying Yang, and Takafumi Chujo. Peer-to-peer traffic in metro networks: analysis, modeling, and policies. Network Operations and, I [11] R. Hofmann, R. Klar, B. Mohr, a. Quick, and M. Siegle. Distributed performance monitoring: methods, tools, and applications. IEEE Transactions on Parallel and Distributed Systems, 5(6): , June II-B [12] Shay Horovitz. Collabrium: Active Traffic Pattern Prediction for Boosting P2P Collaboration. Technologies: Infrastructures for Collaborative, I [13] Thomas Karagiannis and Andre Broido. Transport layer identification of P2P traffic. Proceedings of the 4th ACM, pages , I, II-A [14] Thomas Karagiannis, Andre Broido, and Nevil Brownlee. Is p2p dying or just hiding? Global, I, II-A, II-C [15] M. Karakaya, I. Korpeoglu, and O. Ulusoy. A distributed and measurement-based framework against free riding in peer-to-peer networks. Proceedings. Fourth International Conference on Peer-to-Peer Computing, Proceedings., pages II-B [16] B. Landfeldt, P. Sookavatana, and a. Seneviratne. The case for a hybrid passive/active network monitoring scheme in the wireless Internet. Proceedings IEEE International Conference on Networks 2000 (ICON 2000). Networking Trends and Challenges in the New Millennium, pages II-B [1] Plissonneau Louis, Lauren Costeux Jean, and Brown Patrick. Analysis of Peer-to-Peer Traffic on ADSL. France Telecom R&D. I, II-C [18] Marcell Perényi, Trang Dinh Dang, András Gefferth, and Sándor Molnár. Identification and Analysis of Peer-to-Peer Traffic. Journal of Communications, 1():36 46, December I, II-A, II-C [19] Ruben D. Torres, Mohammad Y. Hajjat, Sanjay G. Rao, Marco Mellia, and Maurizio M. Munafo. Inferring undesirable behavior from P2P traffic analysis. Proceedings of the, pages 25 36, I, II-C [20] S Tzur-David and Danny Dolev. MULAN: Multi-Level Adaptive Network Filter. Security and Privacy in Communication, I 60

61 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME 1 Peer-to-Peer-basierte Live-Streaming-Systeme Thomas Schlosser Zusammenfassung Live-Streaming-Anwendungen finden im Internet zunehmend größere Verbreitung. Durch die steigende Anzahl an Nutzern einer solchen Anwendung wird es immer kostenaufwendiger, ein solches System Client-Server-basiert zu betreiben. Eine kostengünstige, skalierbare Lösung stellen Peerto-Peer-basierte Live-Streaming-Systeme dar. Dieses Paper stellt einige bekannte Klassifikationen und Eigenschaften solcher Systeme vor. Es bietet zudem einen umfassenden Überblick über die verschiedensten existierenden Peer-to-Peer-Live-Streaming- Systeme. Diese werden jeweils kurz vorgestellt und bezüglich ihrer Eigenschaften, Gemeinsamkeiten und Unterschiede betrachtet. Somit hilft dieses Paper bei der Wahl eines Peer-to- Peer-basierten Systems für verschiedenste Einsatzgebiete, Umgebungen und Ziele. I. EINLEITUNG Eine immer größere Anzahl an Internetnutzern verwendet Dienste, die Videos live über das Internet ausstrahlen. Sowohl bei Konferenzen und Großveranstaltungen als auch für gewöhnliche TV-Übertragungen werden solche Dienste angeboten. Die einfachste Art und Weise solche Live-Streams zu verbreiten stellt das Client-Server Modell dar. Mit diesem Modell stoßen die Systeme aber schnell an die Grenze der Skalierbarkeit beziehungsweise auf immens hohe Betriebskosten, denn die Leistung der Server muss proportional zur Nutzeranzahl wachsen. Eine effiziente Lösung des Problems stellt IP-Multicast [9] dar, bei dem die IP-Pakete des Senders an eine Gruppe von Empfängern übertragen wird. Da die Datenpakete erst an Verzweigungen im Netzwerk dupliziert werden, muss jedes Paket lediglich ein einziges Mal über ein und dieselbe Verbindung gesendet werden. Aufgrund der speziellen Anforderungen an die Infrastruktur und den erforderlichen Zustand innerhalb der Router ist IP-Multicast meist kein praktikabler Mechanismus zur Übertragung von Live-Streams. Ein Ansatz namens Peer-to-Peer (P2P), der keinerlei Unterstützung des zugrundeliegenden Netzwerks benötigt, verbreitete sich als Alternativansatz. Dieser abstrahiert von der Netzwerkebene und arbeitet ausschließlich auf der Anwendungsebene. In P2P-Systemen teilen die Teilnehmer die sogenannten Peers ihre Hardwareressourcen untereinander, um als Einheit den Service des Netzwerks allen Peers anbieten zu können. Die Peers kommunizieren direkt untereinander und agieren dabei sowohl in der Rolle des Anbieters als auch in der des Anfragenden [31]. Im Bereich der Live-Streaming-Systeme lassen sich somit kostengünstige und hochskalierbare Systeme entwickeln. Dieses Paper stellt einige bekannte Klassifikationen und Eigenschaften der P2P-Live-Streaming-Systeme vor und gibt eine umfassende Übersicht über existierende Systeme. Die betrachteten Systeme werden ferner hinsichtlich ihrer Gemeinsamkeiten und Unterschiede betrachtet. Zunächst führt Abschnitt II in die Grundlagen der P2P- Live-Streaming-Systeme ein. Dabei werden besonders Begrifflichkeiten, die für das weitere Verständnis in diesem Paper relevant sind, beschrieben. Abschnitt III gibt eine Übersicht über existierende Klassifikationen solcher Live- Streaming-Systeme. Basierend auf den in den Klassifikationen verwendeten Eigenschaften werden diese und weitere in Abschnitt IV zusammengetragen und in ihren Ausprägungen unterschieden. Im anschließenden Abschnitt V werden eine Vielzahl von Systemen anhand dieser Eigenschaften untersucht und beschrieben. Ihre Gemeinsamkeiten und Unterschiede werden hervorgehoben, wodurch die Auswahl eines Systems beziehungsweise Ansatzes für verschiedene Einsatzszenarien vereinfacht wird. Abschließend wird in Abschnitt VI ein Fazit über die in diesem Paper zusammengetragen Systeme und Klassifikationsmöglichkeiten gezogen. II. GRUNDLAGEN Dieser Abschnitt führt in die Grundlagen P2P-basierter Live-Streaming-Systeme ein. Dabei werden besonders die für dieses Paper relevanten Aspekte hervorgehoben. P2P-basierte Live-Streaming-Systeme unterscheiden sich von anderen P2P-Systemen vor allem hinsichtlich ihres Bandbreitenkonsums. Sie gehören der Klasse der fixed-rate- Systeme an [2]. In diesen Systemen wird der zu verteilende Inhalt mit einer konstanten Rate auf einer Teilmenge der Peers generiert. Aufgrund der hohen zeitlichen Anforderungen an Live-Streaming-Systeme muss dieser Inhalt unter Verwendung von kleinen Puffern schnellstmöglichst verteilt werden. Damit ein fortlaufendes Abspielen eines Streams gewährleistet werden kann, muss die Downloadrate der Empfänger im Durchschnitt immer der Generierungsrate entsprechen. Diese Anforderung immer die entsprechenden Daten für den aktuellen Abspielzeitpunkt verfügbar zu haben unterscheidet sich von den Anforderungen anderer P2P-basierter Systeme. Entsprechend der Generierungsrate müssen die Daten an jedem Peer bis zu einer bestimmten Frist vorhanden sein. Somit werden für gewöhnlich Daten, die nahe am Abspielzeitpunkt liegen, höher priorisiert als weiter entfernte Daten. Alle Daten, die hinter dem Abspielzeitpunkt liegen, sind von keinem Interesse und können verworfen werden. Weitere Aspekte, die bei solchen Systemen beachtet werden sollten, sind die Heterogenität der Peers, die Asymmetrie zwischen Download- und Uploadrate und die Gewährleistung eines zusammenhängenden Netzwerks zwischen den Peers. A. Overlay-Topologien Das zwischen den Peers auf der Anwendungsebene aufgebaute Netzwerk wird als Overlay bezeichnet. Der Prozess, diesem Overlay beizutreten, heißt Joinen. Der beim Joinen 61

62 2 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME Server Server Stream 1 Stream 2 Peer 0 Peer 1 P0 P1 Baum 1 Baum 2 P2 P3 P4 P5 P1 P2 P2 P0 P6 P P8 P9 Abbildung 2. Overlaystruktur eines Multi-Tree-basierten Systems Abbildung 1. Overlaystruktur eines Single-Tree-basierten Systems verwendete Mechansimus, zum Kennenlernen eines oder mehrerer initialer Teilnehmer des Overlays, ist das sogenannte Bootstrapping. Die Menge aller Peers, mit denen ein Peer verbunden ist, bildet dessen Nachbarschaft. Die Topologie eines solchen Overlays entspricht bei P2P-Live-Streaming- Systemen einer der folgenden oder Mischformen der folgenden Topologien: 1) Tree-basiert: Ähnlich dem Baum, der bei der Verteilung über IP-Multicast entsteht, werden die Peers in Tree-basierten Systemen miteinander verknüpft. Von der Quelle des Videostreams ausgehend entsteht somit eine zusammenhängende und azyklische Struktur zwischen allen Peers. Diese Topologie lässt sich feiner in Single-Tree und Multi-Tree unterteilen [20]. Ein Single-Tree zeichnet sich dadurch aus, dass alle Peers in einem Baum verwaltet werden. Der Stream wird jeweils vom Eltern-Peer an seine Kinder gesendet. Jeder Peer außer der Wurzel besitzt genau einen Eltern-Peer. Die wichtigsten Merkmale eines solchen Baums sind dessen Tiefe und der Ausgangsgrad der Knoten 1. Offensichtlich ist auch, dass die Peers auf einer tieferen Ebene die Daten zu einem späteren Zeitpunkt erhalten. Somit wäre ein möglichst flacher Baum das Wünschenswerteste. Dies ist wiederum durch die begrenzte Upload-Kapazität der Peers nicht beliebig umsetzbar. Ein weiterer wichtiger Aspekt eines solchen Baums ist dessen Verwaltung. Sobald ein Peer ausfällt, sind alle seine Nachfahren von der Quelle abgeschnitten. Darum ist es wichtig, dass der Baum möglichst schnell repariert werden kann. Diese Verwaltung kann entweder durch einen zentralen Server oder über einen verteilten Algorithmus durch die Peers erfolgen. Ein weiterer Nachteil dieser Topologie ist, dass Blätter keinen Ressourcen-Beitrag leisten können. Abbildung 1 zeigt ein Beispieloverlay eines Single-Treebasierten Systems. Auf Ebene 1 befinden sich zwei Peers, die direkt vom Server versorgt werden. Peer 0 wiederum ist Eltern-Peer von drei anderen Peers. Da Peer 6 auf Ebene 3 den Stream von Peer 3 von Ebene 2 erhält, ist offensichtlich, dass dieser den Stream erst später erhält. Um das Problem mit dem fehlenden Ressourcen-Beitrag der Blätter zu lösen, wurden die sogenannten Multi-Treebasierten Ansätze entwickelt. Dabei wird der Originalstream in 1 Die Begriffe Knoten und Peer werden austauschbar verwendet. mehrere Teilstreams aufgeteilt und jeweils über einen eigenen Baum verteilt. Jeder Peer ist in jedem Teilbaum meist an unterschiedlichen Positionen enthalten. Über die Positionierung kann die Ausnutzung der Bandbreiten verbessert werden. In einem vollständig balancierten Baum ist jeder Peer nur in einem Teilbaum ein innerer Knoten. Durch die vielen Teilstreams und Bäume entsteht ein größerer Overhead. Andererseits führt das Verteilen der Daten über verschiedene Pfade bei Verwendung einer redundanzbehafteten Kodierung zu einer deutlich größeren Ausfallsicherheit. Abbildung 2 zeigt ein Overlay eines Multi-Tree-basierten Systems. Der Stream wird vom Server in zwei Teilstreams aufgeteilt und in den Teilbäumen Baum 1 und Baum 2 verteilt. Peer 0 und Peer 1 tauchen als Blätter und als innere Knoten auf. Lediglich Peer 2 kann seine Upload-Kapazität nicht zur Verfügung stellen, da er immer als Blatt angehängt ist. 2) Mesh-basiert: In einem Mesh-basierten System gibt es keine statische Topologie. Beziehungen zwischen den Peers werden dynamisch auf- und abgebaut. Jeder Peer kann gleichzeitig verschiedene Daten zu mehreren Peers hochladen und von mehreren Peers herunterladen. Eine hohe Anzahl an Verbindungen zwischen den Peers macht eine solche Topologie sehr robust. Bei Ausfällen einzelner Peers können die Daten weiterhin von anderen Peers empfangen werden [20]. B. Kommunikationsparadigmen Der Austausch der Daten in einem P2P-System kann auf zwei verschiedene Art und Weisen Pull-basiert oder Pushbasiert vonstatten gehen. In einigen neueren Systemen wird eine Mischform verwendet, in der die eine oder andere Art je nach Kommunikationszweck gewählt wird. 1) Push: Die Push-basierte Kommunikation zeichnet sich dadurch aus, dass der Sender die Daten ohne explizite Anforderung an den Empfänger sendet. Dieses Paradigma ist das Standard-Paradigma in Tree-basierten Systemen. 2) Pull: Bei einer Pull-basierten Kommunikation werden die Daten vom Empfänger beim Sender angefordert. Dazu tauschen die Peers für gewöhnlich die Verfügbarkeit der Daten untereinander aus. Dadurch lassen sich redundante Übertragungen wie sie durch Push-basierte Kommunikationen entstehen würden vermeiden. Diesem Paradigma wird standardmäßig bei Mesh-basierten Systemen gefolgt. 62

63 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME 3 III. KLASSIFIKATIONEN Dieser Abschnitt gibt eine Übersicht über existierende Klassifikationen für P2P-Live-Streaming-Systeme. In [34] klassifizieren Silverston und Fourmaux P2P-Live- Streaming-Protokolle anhand ihrer Verwaltung des Overlays. Sie unterscheiden die Kategorien Source-Driven, Receiver- Driven und Data-Driven. In Source-Driven Systemen werden die Daten von einer Wurzel ausgehend über eine Baumstruktur an die Empfänger verteilt. Werden die Daten hingegen über einen Baum verteilt, dessen Wurzel der Empfänger ist, so handelt es sich um einen Receiver-Driven Ansatz. Dabei organisiert der Empfänger die Ressourcen das heißt die anderen Peers, um an den gewünschten Stream zu gelangen. In Data-Driven Systemen tauschen die Peers Nachrichten über die Datenverfügbarkeit aus. Anhand dieser Datenverfügbarkeiten suchen sich die Peers selbstständig ihre Nachbarn zum Datenaustausch aus. In ihren Untersuchungen kommen sie zu dem Ergebnis, dass der Data-Driven Ansatz der beste Ansatz für Live-Streaming zu sein scheint. Aufgrund der Ähnlichkeit von unstrukturierten Overlays zu Zufallsnetzen, erweisen sich solche Systeme gegenüber Angriffen und Ausfällen als resistenter. Eine weitere Möglichkeit zur Klassifizierung wird von Liu, Guo und Liang in [20] beschrieben. Sie unterscheiden Live- Streaming-Systeme anhand der Struktur des Overlays. Dabei verwenden sie die Klassen so, wie sie in Abschnitt II-A vorgestellt wurden. Sie unterscheiden somit zwischen Single- Tree, Multi-Tree und Mesh-basierten Systemen. Durch die kontinuierliche Neuentwicklung von P2P-Live- Streaming-Systemen entstanden in der Vergangenheit eine Reihe von hybriden Systemen, wie beispielsweise Climber (siehe Abschnitt V), die sich nicht mehr eindeutig einzelnen Klassen dieser Klassifikationen zuordnen lassen. Zudem entstanden auch neue Systeme, die weitere Komponenten wie die Gruppierung von Peers in Cluster in die Topologie integrierten und weiter vermischten. Das Aufstellen einer neuen Klassifikation, die alle wichtigen Aspekte dieser Systeme berücksichtigt, ist somit nicht befriedigend umsetzbar. IV. EIGENSCHAFTEN VON P2P-LIVE-STREAMING-SYSTEMEN Da sich, wie in Abschnitt III beschrieben, keine eindeutige Klassifikation für P2P-Live-Streaming-Systeme erstellen lässt, werden die Systeme im weiteren Verlauf dieses Papers hinsichtlich ihrer Eigenschaften betrachten. Die wichtigsten Eigenschaften, die ein solches System ausmachen können, werden in diesem Abschnitt zusammengetragen. A. Overlay-Struktur Eine der wichtigsten Eigenschaften eines P2P-Overlays ist dessen Struktur. Ein Overlay kann über einen strukturierten Ansatz erstellt werden, bei dem die Peers zusammen eine spezielle Topologie bilden. Eine solche Struktur kann zum Beispiel einem Ring [35], Hypercube [29] oder Plaxton Mesh [30, 39] entsprechen. Hierbei ist es wichtig, dass beim Joinen, aber auch beim Ausfall von Peers die Struktur weiter Bestand hält. Im Gegensatz zum strukturierten Ansatz kann auch ein unstrukturiertes Overlay erzeugt werden, das sich dadurch auszeichnet, dass die Peers in keiner speziellen Topologie miteinander verknüpft sind. Mesh-basierte Systeme besitzen genau dieses Merkmal und können somit synonym verwendet werden. Tree-basierte Systeme können sowohl die eine als auch die andere Ausprägung dieser Eigenschaft besitzen. Dies ist davon abhängig, ob der Baum bei der Konstruktion des Overlays entsteht oder ob der Baum erst jeweils bei der Datenverteilung seine Form erhält. In letzterem Fall handelt es sich um ein unstrukturiertes Overlay [11]. Weiterhin können sich die Systeme in ihrer Struktur dahingehend unterscheiden, dass ein System ein oder mehrere eventuell verschiedene Overlays für die Verteilung der Daten verwendet. Auch die Struktur der Overlays zur Verwaltung der Peers kann von denen zur Datenverteilung abweichen [11]. B. Cluster Einige Systeme gruppieren ihre Peers in sogenannte Cluster, um robustere Netzwerke aufbauen zu können. Meist wird innerhalb eines Clusters eine andere Struktur als zwischen den Clustern verwendet. Aussagen über die Overlay-Struktur lassen sich jedoch sowohl auf Peer- als auch auf Clusterebene in gleichem Maße treffen. C. Koordinierung der Peers Zur Koordinierung in einem P2P-System zählt sowohl der Aufbau desselben als auch die Verteilung der Daten in ihm. Wird die Koordinierung der Peers von einem einzelnen Knoten übernommen, so wird das System als zentrales bezeichnet. In einem solchen System stellt dieser zentrale Punkt einen Flaschenhals dar. Er steht für gewöhnlich unter einer großen Last und im Falle seines Ausfalls kann das System nicht mehr betrieben werden. Dezentrale Ansätze, bei denen die Peers gemeinsam die Koordination übernehmen, verhindern das Auftreten dieses Problems. Im Gegensatz zu dem zentralen Ansatz, bei dem der dedizierte Knoten über ein globales Wissen des Systems verfügen muss, wird beim dezentralen Ansatz an jedem Peer meist lediglich ein lokales Wissen benötigt. Durch das globale Wissen können in zentral verwalteten Systemen Optimierungen vorgenommen werden, die sich mit Hilfe reines lokalen Wissens nicht realisieren lassen. Mischformen, die den Aufbau durch eine zentrale Instanz koordinieren und die Verteilung der Daten dezentralisiert ablaufen lassen, versuchen die Vorteile beider Koordinierungsarten zu vereinen. D. Kommunikationsparadigma Entsprechend der Erläuterung in Abschnitt II-B existieren zwei verschiedene Kommunikationsparadigmen: Push und Pull. Push-basierte Kommunikation hat den Vorteil einer geringeren Aufbauzeit, da der Sender ohne explizite Anfrage die Daten versenden kann. Bei Pull-basierter Kommunikation teilt der Sender für gewöhnlich zunächst die Verfügbarkeit der Daten mit, woraufhin der Empfänger die gewünschten Daten anfragt und erst im Folgenden zugesendet bekommt. Allerdings werden im Pull-basierten Ansatz redundante Übertragungen vermieden. Auch bei den Kommunikationsparadigmen werden Mischformen für verschiedene Aspekte der Systeme verwendet, um die Vorteile beider Varianten zu nutzen. 63

64 4 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME E. Fairness In P2P-basierten Systemen werden die Systemressourcen durch die Summe der von den Peers zur Verfügung gestellten Ressourcen bestimmt. Um die Bereitschaft zur Ressourcenbereitstellung der Peers zu erhöhen, verwenden einige Systeme sogenannte Anreiz-basierte Ansätze. Ein Peer, der dem System mehr seiner Ressourcen das heißt Upload-Kapazität zur Verfügung stellt, erhält Vorzüge gegenüber anderen Peers. Dies kann sich zum Beispiel in der Qualität des Videos, aber auch in der Abspielkontinuität widerspiegeln. F. Kodierung des Streams Das Teilen des Videostreams in mehrere Teilstreams und das Versenden über verschiedene Wege führt zu einer höheren Ausfallsicherheit und einer besseren Möglichkeit die Lasten im Netzwerk zu verteilen. Dies lässt sich im einfachen Fall durch das sogenannte Stream Splitting realisieren. Dabei wird der Hauptstream in mehrere gleich große Pakete zerlegt und auf die gewünschte Anzahl an Streams verteilt. Eine Variante, mit der sowohl Redundanzen hinzugefügt als auch Fairness leichter unterstützt werden können, stellt das Network Coding dar. Bei dieser Variante reicht dem Empfänger eine Teilmenge der Pakete aus, um den Stream abspielen zu können. Je mehr Streams das heißt Pakete er zur Verfügung hat, desto besser wird die Qualität des Videos. Ein Beispiel solch einer Kodierung stellt die H.264/AVC-Erweiterung Scalable Video Coding (SVC) [33] dar. G. Berücksichtigung der Lokalität Im Rahmen der Übertragungszeit-Optimierung zwischen den Peers verwenden einige Systeme die physikalische Lokalität der Peers, um das Overlay-Netzwerk zu optimieren. Diese kann sowohl einer geographischen als auch topologischen Lokalität entsprechen. Für die Optimierung der Übertragungszeit ist in erster Linie die topologische Lokalität im zugrundeliegenden Netzwerk entscheidend. Einige Systeme verwenden dazu die IP-Adressen der Peers, andere wiederum approximieren die Entfernungen anhand der Übertragungszeiten oder Bandbreiten zwischen den Peers. Der zusätzliche Aufwand beim Konstruieren und Verwalten des Overlays wird wegen der Verringerung der Übertragungszeit und damit der Gewährleistung eines stabileren Streams in Kauf genommen. V. P2P-LIVE-STREAMING-SYSTEME Dieser Abschnitt gibt einen Überblick über existierende Forschungssysteme und kommerzielle P2P-Live-Streaming- Systeme. Die Systeme werden kurz bezüglich ihrer Funktionsweise erläutert und hinsichtlich der Eigenschaften aus Abschnitt IV untersucht und unterschieden. Zunächst werden Vorgehensweisen, die in allen Systemen gleichartig verwendet werden, separat aufgeführt. Auf spezifische Abweichungen wird in den speziellen Beschreibung der entsprechenden Systeme eingegangen. Eine weit verbreitete Vorgehensweise ist der einheitliche Umgang mit austretenden Peers. Beim Verlassen des Overlays sendet ein Peer eine Nachricht an alle Peers, die ihn kennen. Der Empfänger dieser Nachricht kann diese direkt vom Peer oder über Weiterleitungen anderer Peers erhalten. Verlässt er ungewollt das Netzwerk, so nehmen die anderen Peers nach einer gewissen Zeitspanne, in der sie nichts von ihm mitbekommen haben, sein Verschwinden an. In Folge des einen oder anderen Falles werden die Informationen zum austretenden Peer entfernt. Narada In [16] stellen Chu et al. mit Narada ein Mesh-basiertes P2P- System vor. Die Peers dieses Systems organisieren sich selbst über einen vollständig dezentralen Ansatz und benötigen dafür globales Wissen über alle Peers. Dazu tauschen sie periodisch untereinander Nachrichten aus, die Informationen über die bereits bekannten Peers enthalten. Beim Joinen benötigt der neue Peer über einen beliebigen Bootstrap-Mechanismus eine Liste bereits existierender Peers über die er mit dem Netzwerk verbunden wird. Im weiteren Verlauf wird das Overlay durch das Entfernen und Aufbauen von Verbindungen optimiert. Die dafür verwendeten Bewertungsfunktionen messen als Aufbaukriterium den Performance-Gewinn und als Abbaukriterium die Anzahl der Pfade über diese Verbindung. Mit Hilfe eines kürzeste Wege-Algorithmus wird ein Baum in dem aufgespannten Mesh erzeugt, über den die Daten von der Quelle die als Wurzel dient Push-basiert an die Peers verteilt werden. Befinden sich mehrere Quellen im System, so werden mehrere Bäume im Mesh erzeugt. In beiden Varianten werden in Narada keine speziellen Kodierungen für den Stream verwendet. CoolStreaming/DONet Mit DONet [38] entwickelten Zhang et al. ein Data-Driven Pull-basiertes Mesh-Overlay-Netzwerk zur Übertragung von Live-Streams. Eine skalierbare Internet-basierte Implementierung namens Coolstreaming [3] wurde auf Basis DONet s entwickelt. Ähnlich zu Narada besitzt jeder Peer eine Liste aller aktiver Knoten, die durch einen periodischen Nachrichtenaustausch auf dem aktuellsten Stand gehalten wird. Der Source-Knoten ist in DONet allseits bekannt und wird beim Joinen kontaktiert. Von ihm erhält der neue Peer einen zufällig gewählten existierenden aktiven Peer, von dem er eine Liste von Peers erhält. Zu jedem dieser Peers versucht der neue Peer eine Nachbarschaftsbeziehung aufzubauen. Für den Datenaustausch des in Segmente zerteilten Streams werden durchgehend Informationen über deren Verfügbarkeit mit Hilfe sogenannter BufferMaps ausgetauscht. In einer BufferMap ist entsprechend dem Sliding Window-Verfahren ein Bit zu jedem Segment in der Nähe des aktuellen Abspielsegments enthalten. Dieses gibt an, ob das Segment an einem Peer verfügbar ist oder nicht. Jeder Peer kann dann über ein Bitmuster gewünschte Segmente entsprechend seines Schedulings (zeitlichen Ablaufplans) anfragen. Dabei werden die selteneren und schneller herunterladbaren Segmente priorisiert. Um die Qualität des Streams zu erhöhen und eine stabile Anzahl an Partnern zu gewährleisten, werden periodisch neue Nachbarschaftsbeziehungen mit einem zufällig gewählten aktiven Knoten aufgebaut. Dabei wird wenn nötig der Partner, von 64

65 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME 5 dem im Durchschnitt am wenigsten Segmente pro Zeiteinheit erhalten wurden, entfernt. MeshTV MeshTV [3, 8] ist ein Pull- und Mesh-basiertes P2P-Live- Streaming-System, dessen Ansatz dem Data-Driven Ansatz entspricht. Im Wesentlichen deckt sich die Funktionsweise mit der von DONet. Im Gegensatz zu DONet beschränkt MeshTV die Anzahl der Nachbarn eines Peers nicht. Dadurch kann in MeshTV eine bessere Ausnutzung der Upload-Kapazität von hochkapazitiven Knoten erreicht werden. Eine weitere Besonderheit dieses Systems liegt in der lokalen Optimierung des Overlays hinsichtlich der Latenzzeit zwischen den Peers. Diese meist auch physikalisch kurzen Verbindungen werden dann auch für die Datenübertragung verwendet. Des Weiteren stellt MeshTV sicher, dass alle Peers die benötigte Datenrate über eine konstante Anzahl an Sendern empfangen können. Außerdem wird die Anzahl der Nachbarn eines Peers in Korrelation zur Bandbreite des Peers gehalten, um ungenutzte Kapazitäten zu vermeiden. PRIME Magharei und Rejaie entwickelten mit PRIME [23] ein Mesh-basiertes Live-Streaming-System. Das zufällig verbundene Netz entsteht dadurch, dass Peers einen Bootstrapping- Knoten nach Versorger-Peers fragen und sich mit diesen verbinden. Jeder Peer versucht die Anzahl der Versorger-Peers in Korrelation zu seiner Eingangsbandbreite zu halten. Die Datenverteilung des in Teilstreams zerlegten Streams erfolgt in zwei Phasen und in Intervallen. In der ersten Phase der Diffusion-Phase werden die Daten über einen impliziten Verteilungsbaum Pull-basiert von der Quelle ausgehend verteilt. Jedes Kind der Quelle und somit jeder Peer innerhalb des entsprechenden Teilbaums erhält dabei nur Daten eines Teilstreams. In der zweiten Phase der Swarming-Phase versucht jeder Peer Pull-basiert an die fehlenden, aber bereits verteilten, Daten der anderen Teilstreams zu gelangen. Dieses Vorgehen hilft dem Flaschenhals durch zu wenig Bandbreite oder durch zu wenig Daten an den Nachbarn vorzubeugen. STREAMCOMPLETE Covino und Mecella entwickelten mit STREAMCOMPLE- TE [6, ] ein Mesh-basiertes P2P-Live-Streaming-System, in dem sich die Peers mit Hilfe verteilter Algorithmen selbst verwalten. Kernelement dieses Systems ist der State of health-parameter, der abhängig von den aktuell zur Verfügung stehenden Ressourcen und Verbindungen zu anderen Peers berechnet wird. Um die Gesamtperformance zu erhöhen wird die sogenannte Fast-Top Prozedur verwendet. Abhängig von dem Wert des State of health-parameters tauschen Anbieter und Abnehmer ihre Positionen im Overlay. Peers mit geringem State of health werden somit am Rande des aufgebauten Meshs und Peers mit besserem State of health näher an der Quelle positioniert. Dadurch wird die Last dynamisch im System verteilt. Um ein stabiles Overlay aufrecht erhalten zu können, tauschen die Peers ihre lokalen Sichten untereinander aus und aktualisieren die eigene Sicht mit Hilfe dieser Informationen. Im Rahmen dieser lokalen Sicht verwendet das System einen Algorithmus um Schleifen zu erkennen und zu entfernen. Abhängig von der Eingangsbandbreite werden Verbindungen zu verschiedenen Anbietern aufgebaut. Ein Peer kann somit auch über mehrere Anbieter und Abnehmer verfügen. Der Stream selbst wird ohne weitere Kodierung mit Hilfe des Realtime Transport Protokolls (RTP) [32] von den Anbietern an die Abnehmer Push-basiert übertragen. Live-Streaming über BitTorrent Cai, Xiaolu Zhang und Xuejie Zhang stellen in [4] ein auf BitTorrent [5] basierendes Live-Streaming-System vor. Um den Bedingungen eines Live-Streaming-Systems gerecht zu werden, passten sie ein paar der BitTorrent-Mechanismen an. So werden anstatt der seltenen Stücke die Stücke nahe des Abspielzeitpunkts höher priorisiert. Auch das Verhalten des Source-Knotens wurde angepasst. Er wird im sogenannten Super Seeding Mode betrieben, in dem er sich als Leecher Peer ohne vollständige Datenverfügbarkeit ausgibt. Dabei stellt er einem Nachbarn erst dann weitere Daten zur Verfügung, wenn dieser die bereits erhaltenen Daten an andere weitergegeben hat. Der Source-Knoten bekommt dies über die periodischen Datenverfügbarkeitsnachrichten der anderen Peers mitgeteilt. Wenn der Source-Knoten weiß, dass gewisse Daten an einem Peer noch nicht verfügbar sein können, dann kann er diese Daten zu ihm pushen. Der restliche Datenaustausch im aufgebauten Mesh läuft wie in BitTorrent üblich über Pull-basierte Kommunikation ab. Sobald alle Daten eines Streaming-Intervalls mindestens einmal verteilt wurden, wechselt der Source-Knoten in den normalen Modus. Um einen langsamen Start zu vermeiden, werden die aktiven Nachbarn periodisch bestimmt und deren Anzahl auf einem bestimmten Level gehalten. Chainsaw Das von Pai et al. in [24] vorgestellte Chainsaw ist ein Mesh-basiertes Live-Streaming-System, das sowohl in der Art des Aufbauprozesses als auch der Datenverteilung dem im letzten Abschnitt beschriebenen Live-Streaming-System über BitTorrent entspricht. Lediglich der Super Seeding Mode des anderen Systems wird nicht verwendet und die Wahl der Pullbasiert zu holenden Daten wird nur per Zufall getroffen. Da dadurch viele Daten nicht rechtzeitig an den Peers zur Verfügung stehen würden, führten Pai et al. den Request Overriding- Algorithmus ein. Dazu verwaltet der Source-Knoten eine Liste mit allen noch nie versendeten Datenpaketen. Ist die Liste nicht leer, so sendet der Source-Knoten das älteste Paket der Liste an den anfragenden Peer, sofern dieser ein nicht auf der Liste enthaltenes Datenpaket angefragt hat. Dadurch wird gewährleistet, dass jedes Datenpaket im Overlay verteilt ist. PALMS PALMS [14], ein zu DONet und BitTorrent ähnliches Mesh-basiertes Live-Streaming-System, wurde von Hoong und Matsuo entwickelt. Sowohl der Aufbau und die Verwaltung 65

66 6 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME des Netzes geschehen analog zum DONet-Ansatz. In ihrer Grundform verläuft die Datenverteilung ebenfalls ähnlich der Verteilung in DONet und BitTorrent. Um jedoch die Verzögerung, die durch Verwendung des Pull-Mechanismus entsteht, zu verringern, wird zudem auch ein Push-basierter Ansatz verwendet. Dabei subskribieren sich Peers bei ihren Nachbarn, um deren neu erhaltene Pakete automatisch zugesendet zu bekommen. Wird das Fehlen eines Paketes anhand der Sequenznummer festgestellt, so kann dieses Paket über eine NACK-Nachricht erneut angefragt werden. Um dem Heterogenitätsproblem der Peers entgegenzuwirken, wird der Originalstream mit Hilfe von Network Coding in Teilstreams zerlegt. Je mehr Streams an einem Peer vorliegen, desto höher ist die Qualität des Videos an diesem Peer. Um die Bereitstellung von Ressourcen zu erhöhen und das Aufkommen von Freeridern Peers die sich nicht beteiligen zu verringern, werden die Peers für ihren Einsatz Punkte-basiert belohnt. Entsprechend ihrer zentral hinterlegten Wertung dürfen sie nur Daten von Peers laden, deren Wertung kleiner oder gleich der eigenen Wertung ist. Je mehr sie sich beteiligen, desto flexibler dürfen sie also ihre Peers auswählen. LSONet Bei LSONet [12, 13] handelt es sich um ein Mesh-basiertes P2P-Live-Streaming-System, das eine Layer-Kodierung verwendet. Am Source-Knoten wird der Stream über Network Coding auf mehrere Teilstreams (Layer) verteilt. Für jeden dieser Layer wird ein eigenes Mesh aufgebaut. Ein Peer kann gleichzeitig mehrere Layer von mehreren Sendern empfangen und auch zu mehreren Empfängern schicken. Die Verfügbarkeit von Layern wird im Gegensatz zu den anderen Systemen nur auf explizite Anfrage verschickt. Ein durch den Pull-Mechanismus erhaltener Anbieter bleibt prinzipiell durchgehend in dieser Rolle, bis er fehlschlägt oder das Overlay verlässt. Beim Joinen wendet sich der neue Knoten an einen der vielen Bootstrapping-Knoten und erhält von ihm eine eindeutige ID. Ein Peer nimmt den neuen Knoten mit einer gewissen Wahrscheinlichkeit als Empfänger an oder leitet ihn an einen anderen weiter. Bei der Verwaltung des Overlays werden Strategien wie LTM (location-aware topology matching) [21] verwendet, um das Overlay an die physikalische Topologie anzupassen. Dazu gehört ebenfalls die periodische Eliminierung langsamer Partner. Über einen Algorithmus wird versucht, jedem Peer die maximale Anzahl an Layern zur Verfügung zu stellen. Der Basis-Layer der alleine ausreicht, um das Video abzuspielen erhält bei der Auswahl eine höhere Priorität. Die über diesen Mechanismus realisierbare Fairness wird in LSONet nicht betrachtet. Jedoch wird durch diese Daten- und Pfadredundanz eine höhere Stabilität erreicht. Climber Climber [25, 26], ein hybrides Tree- und Mesh-basiertes P2P-Live-Streaming-System, verwendet einen Anreizbasierten Ansatz, um die Beteiligung der Peers zu erhöhen. Das Overlay wird durch einen Baum gebildet, der um redundate Verbundenheit herzustellen mit weiteren zufälligen Kanten versehen wird. Analog zu LSONet nimmt ein Peer einen joinenden Peer mit einer gewissen Wahrscheinlichkeit als Kind an oder gibt ihn weiter. Die zufälligen Kanten werden nach dem Erhalt von Datenpaketen eingefügt. Der Stream wird am Source-Knoten in gleich große, mit einer Sequenznummer durchnummerierte Pakete zerlegt und über den Verteilungsbaum zu allen Peers gepusht. Sobald ein Peer durch eine Zufallskante einen Knoten findet, von dem Pakete mit höherer Sequenznummer ankommen, verwendet er diesen als neuen Eltern-Peer. Bei Ausfällen von Peers wird der Baum ebenfalls mit Hilfe dieser Zufallskanten repariert. Ist dies nicht möglich, so müssen die entsprechenden Peers einen Rejoin durchführen. Um Rejoins zu vermeiden, wird die Anzahl der Zufallskanten proportional zur Anzahl der durchgeführten Rejoins gewählt. Der zu Beginn des Abschnitts angesprochene Anreiz liegt darin, dass ein Peer, der sich stärker an der Datenverteilung beteiligt, mehr Zufallskanten aufbauen darf. Dadurch erfährt er weniger Unterbrechungen und besitzt einen deutlichen Vorteil gegenüber unkooperativer Peers. Als Maß für die Beteiligung wird die Anzahl der Kinder eines Peers verwendet. Overcast Overcast [18] ist ein Tree-basiertes P2P-System, das Live- Streaming unterstützt. Beim Joinen initialisiert sich der Peer selbst und registriert sich in einem zentralen Register. Von diesem erhält er eine Liste von Overcast-Netzwerken, in denen jeweils unterschiedliche Streams verteilt werden. Möchte ein Peer einem konkreten Overlay beitreten, so beginnt der Eltern-Auswahlprozess an der Wurzel, die dem Source-Knoten entspricht. Als Eltern-Knoten wählt der neue Knoten den am weitesten entfernten Knoten, bei dem er maximal 10% Verlust hinsichtlich der Datenrate gegenüber der Wurzel hinnehmen muss. Zudem entscheidet er sich auf jeder Ebene für den Knoten der innerhalb der 10% liegt zu dem die Anzahl an Hops am geringsten ist. Periodisch prüft jeder Peer ob alle seine Kinder, an die er den Single Stream pusht, noch vorhanden sind. Dazu, und um ein schnelleres Joinen zu ermöglichen, verwaltet jeder Knoten eine Liste aller seiner Kinder und deren Zustand. Diese Informationen werden bis zur Wurzel nach oben propagiert. Peers können sich in Overcast durch die Wahl eines neuen Eltern-Knotens an Änderungen im zugrundeliegenden Netzwerk zum Beispiel durch Fehler oder Datenstau anpassen. Dennoch garantiert Overcast mit seinen Algorithmen keine optimale Topologie. CTree CTree [40] ist ein geclustertes, Tree-basiertes P2P-Live- Streaming-System. Die Peers werden dabei von einem zentralen Tracker, der für die Verwaltung des ganzen Systems zuständig ist, in Cluster verteilt. Wie in Abbildung 3 zu sehen, bilden diese Cluster einen Verteilungsbaum, dessen Wurzel das Cluster mit dem Source-Knoten ist. Ein Elterncluster versorgt push-basiert seine Kindercluster, wobei Peers eines Clusters entweder von Peers aus dem Elterncluster oder aus dem lokalen Cluster versorgt werden können. In CTree gibt es zwei Arten von Peers, die über die Upload-Bandbreite unterschieden werden. Peers mit einer hohen Upload-Bandbreite 66

67 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME Cluster 3 Cluster 1 Source Cluster 4 Cluster 0 Cluster 2 Cluster 5 Cluster Power Peer (p-peer) Normal Peer (n-peer) Push des Gesamtstreams von p-peer in Eltern- zu p-peer in Kindcluster Push eines Teilstreams von n-peer in Eltern- zu n-peer in Kindcluster Verbindung zwischen Peers eines Clusters; Teilstreams werden gepullt Abbildung 3. Overlaystruktur von CTree (adaptiert aus [40]) werden p-peer (Power Peer) genannt und werden beim Joinen vom Tracker in ein neues Cluster gesetzt. Als Elterncluster wird das Cluster verwendet, in den der p-peer zunächst gejoint wurde. Peers mit einer geringeren Upload-Bandbreite werden als n-peers (Normal Peers) bezeichnet und beim Joinen einem existierenden Cluster hinzugefügt. Dabei priorisiert der Tracker die Cluster in der Nähe der Wurzel und Cluster mit wenigen Peers. Jeder Peer bekommt beim Joinen einen Peer des entsprechenden Clusters vom Tracker übermittelt und lernt im Folgenden seine lokalen Peers und die des Elternclusters kennen. Nach dem erfolgreichen Joinen eines Peers, aber auch in fixen Abständen, aktualisieren alle Peers des lokalen Clusters und der Kindercluster ihre Clusterinformationen. Der Tracker hält Informationen zu allen Clustern und wird kontinuierlich aktualisiert. Dabei muss er nicht alle Peers kennen eine Teilmenge aus jedem Cluster reicht aus. Die Daten, die der Source-Knoten streamt, werden von ihm in gleich große Blöcke zerlegt und durchnummeriert. Der Gesamtstream wird mit Hilfe der Blöcke auf unkodierte Substreams verteilt. Jeder Peer hält nur zu einer Teilmenge der bekannten Peers eine aktive Verbindung. Die n-peers wählen zufällig einige Peers aus dem lokalen Cluster und dem Elterncluster um Substreams zu erhalten. Die p-peers hingegen wählen wenn möglich den p-peer des Elternclusters, um von ihm den Gesamtstream übermittel zu bekommen. Sollte dies nicht möglich sein, so verhält sich der p-peer wie ein n-peer. Im Gegensatz zu den Daten aus dem Elterncluster, werden Daten innerhalb eines Clusters nur auf explizite Anfrage das heißt pull-basiert versendet. BEAM BEAM [2, 28] ist ein von Purandare und Guha entwickeltes geclustertes, Mesh-basiertes P2P-Live-Streaming-System. Ähnlich zu CTree verwendet BEAM einen zentralen Tracker, der den Zustand des Systems verwaltet. Beim Joinen eines Peers bekommt dieser vom Tracker eine Liste mit 40 Peers, deren Bandbreite ähnlich zu der des neuen Knotens ist. Diesen Knoten sendet er eine Cluster-Join-Nachricht, die diese annehmen sofern sie noch nicht in genügend Clustern enthalten sind. In BEAM kann ein Knoten in mehreren Clustern enthalten sein. Cluster können auch zu späteren Zeitpunkten über eine ähnliche Nachricht neue Mitglieder für ihr Mesh gewinnen. Knoten, die sich nicht an der Verteilung der Daten beteiligen, werden aus dem Cluster ausgeschlossen. Die Verteilung des in gleich große Teile zerlegten Streams durch den Source-Knoten erfolgt Push-basiert an die sogenannten Power Nodes. Diese entsprechen den Knoten mit der höchsten Beteiligung. Die Beteiligung der Peers wird periodisch über eine spezielle Formel berechnet und über den Tracker an den Source-Knoten weitergegeben. Zu Beginn wählt er die Knoten mit dem größten Upload. Sobald ein Peer im Cluster Daten erhält informiert er die anderen Peers, so dass diese die Daten pullen und selbst verteilen können. Dieses Vorgehen stellt zugleich einen Fairness-Mechanismus dar. Ein Peer, der sich rege beteiligt, hat den Vorteil den Stream unmittelbar und direkt vom Server zu erhalten. Zudem wird die Gesamtperformance des Systems erhöht, da Peers mit einem höheren Upload näher an dem Source-Knoten platziert sind. AnySee/Anysee2 Liao et al. stellen in [19] mit AnySee ein Mesh-basiertes P2P-Live-Streaming-System vor, das sich auf Inter-Overlay- Optimierung, das heißt auf die Optimierung zwischen verschiedenen Overlays, konzentriert. Dazu wird zunächst mit Hilfe eines Bootstrapping-Knotens ein Mesh aufgebaut. Ähnlich zu LSONet wird das Overlay durch Strategien wie LTM [21] an die physikalische Topologie angepasst. Über periodische Nachrichtenfluten wird die Overlay-Struktur durchgehend optimiert. Für die Optimierung des Datenflusses verwaltet jeder Peer jeweils eine Liste mit aktiven Pfaden und mit Backup-Pfaden. Zunächst werden die Pfade innerhalb des eigenen Overlays anhand der kürzesten Verzögerungszeiten bestimmt. Fällt die Anzahl der Backup-Pfade unter einen Schwellwert, so werden Overlay-übergreifende Pfade bestimmt. Diese werden über eine umgekehrte Suche vom Peer zum Source-Knoten ebenfalls anhand der Verzögerungszeit ausgewählt. Der Datenaustausch des Single Streams mit Knoten der aktiven Pfade erfolgt analog zu DONet über einen Pull-Mechanismus. Anysee2 [1] stellt eine Weiterentwicklung von AnySee dar. Im Unterschied zu AnySee werden für den Austausch der Kontroll- und Datennachrichten zwei unterschiedliche Strukturen verwendet. Die Ebenen des Baums, der für die Kontrollnachrichten aufgebaut wird, korrelieren mit Räumlichkeiten, die sich über die IP-Adresse bestimmen lassen. Die erste Ebene unterscheidet die verschiedenen Internet Service Provider (ISPs), die zweite diese anhand der Städte und so weiter. Für den Datenaustausch wird ein Mesh zwischen den Nachbarn des Kontrollbaums erzeugt. Die Anzahl der Kontrollnachrichten konnte durch die Vermeidung der Nachrichtenfluten gegenüber AnySee deutlich reduziert werden. PPLive und SOPCast Neben den bisher beschrieben Systemen existieren auch kommerzielle Systeme wie PPLive 2 und SOPCast 3. Da es sich bei diesen Systemen um proprietäre Systeme handelt, können 2 PPLive. 3 SOPCast. 6

68 8 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME Name Referenz Struktur Cluster Koordinierung Kommunikationsparadigma Unterstützung von Fairness Kodierung Lokalität (Aspekt) Narada [16] Mesh & Tree - dezentral Push - SSt - CoolStreaming/DONet [3, 38] Mesh - de- & zentral Pull - SSt - MeshTV [3, 8] Mesh - dezentral Pull - SSt Latenzzeit PRIME [23] Mesh & Tree - de- & zentral Pull möglich NC - STREAMCOMPLETE [6, ] Mesh - dezentral Push - SSt - Live-Streaming über BitTorrent [4] Mesh - de- & zentral Pull & Push - SSt - Chainsaw [24] Mesh - dezentral Pull möglich durch Kodierung SSt - PALMS [14] Mesh - de- & zentral Pull & Push Peer-Auswahl NC - LSONet [12, 13] Mesh - dezentral Pull möglich durch Kodierung LC Latenzzeit Climber [25, 26] Tree & Mesh - dezentral Push # Kanten SSt - Overcast [18] Single-Tree - dezentral Push - SSt # Hops CTree [40] Tree Mesh de- & zentral Push & Pull - StS - BEAM [2, 28] Mesh Mesh de- & zentral Push & Pull Platzierung SSt - AnySee [19] Mesh - de- & zentral Pull - SSt Latenzzeit Anysee2 [1] Mesh & Tree - de- & zentral Pull - SSt IP-Adresse PPLive & SOPCast [1, 10, 15, 22, 36] Mesh - de- & zentral Pull - SSt - Tabelle I ÜBERSICHT DER SYSTEME UND IHRER EIGENSCHAFTEN Informationen über sie ausschließlich aus Messungen des Netzwerkverkehrs gewonnen werden. Eine Reihe von Untersuchungen stellte bei beiden Systemen ein ähnliches Verhalten fest [1]. Beide Systeme erzeugen mit Hilfe eines zentralen Servers ein Mesh [22, 36]. Dieser Bootstrapping-Knoten liefert beim Joinen eine Liste von potenziellen Nachbarn. Durch den periodischen Austausch der Nachbarlisten können neue Nachbarn gewonnen werden. Im Gegensatz zu PPLive senkt SOPCast die Rate, mit der die Nachbarlisten ausgetauscht werden, mit der Zeit [15]. Für die Datenverteilung wird der Stream ähnlich zu DONet in Segmente zerlegt und durch die Verwendung von BufferMaps Pull-basiert verteilt [10]. Fairness-Mechanismen sind in keinem der beiden beiden Systeme enthalten. So können Peers keine oder um die Kinder besitzen und werden dabei gleichberechtigt behandelt. Bei der Optimierung des Overlays werden die Anbieter nur anhand deren Performance ausgewählt. Die Lokalität der Peers wird dabei vollständig außer Acht gelassen [1]. VI. FAZIT Durch den rapiden Anstieg der Live-Streaming-Nutzer und der immer weiter wachsenden Bandbreite der Internetanschlüsse, stellen P2P-basierte Systeme eine kostengünstige und skalierbare Alternative zum Client-Server Modell dar. Die Belastung des Streamservers wird deutlich reduziert und im Gegensatz zu IP-Multicast werden keine besonderen Anforderungen an das zugrundeliegende Netzwerk gestellt. Bei der Betrachtung existierender Klassifikationen solcher Systeme wurde festgestellt, dass keine umfassende Klassifikation möglich ist. Um dennoch kein System auszuschließen, wurden die in der Übersicht vorgestellten Systeme hinsichtlich ihrer Eigenschaften untersucht. Neben den grundlegenden Eigenschaften wie der Struktur des Overlays, der Art der Koordinierung und dem verwendeten Kommunikationsparadigma, bieten einige Systeme weitere Eigenschaften wie die Umsetzung von Fairness, Clustern, einer speziellen Kodierung und auch die Berücksichtigung der Lokalität der Peers. Eine zusammenfassende Übersicht über die vorgestellten Systeme befindet sich in Tabelle I. Zu jedem System sind dort die Eigenschaften aus Abschnitt IV angegeben. Nutzt ein System Cluster, so ist die Topologie innerhalb des Clusters in der Spalte Cluster hinterlegt. In der Spalte Unterstützung von Fairness ist angegeben, in wie weit ein Fairness-Mechanismus unterstützt wird. Ist ein solcher Mechanismus enthalten, so ist das Gebiet angegeben, in dem sich ein beteiligender Peer einen Vorteil verschaffen kann. Die Kodierungen in der vorletzten Spalte sind wie folgt abgekürzt: SSt = Single Stream StS = Stream Splitting NC = Network Coding LC = Layer-Kodierung In der Spalte Lokalität sind alle Aspekte, die zur Betrachtung der Lokalität verwendet werden, aufgelistet. Wie in der Tabelle zu sehen ist, werden meist Mesh-basierte Systeme mit Single Stream verwendet. Diese werden alle durch dezentrale Ansätze verwaltet. Nur wenige benötigen zusätzlich eine zentrale Instanz. Ebenfalls wird deutlich, dass sich die meisten Systeme auf spezielle Aspekte spezialisiert haben und kein System existiert, das versucht, in allen Eigenschaften nahe ans Optimum zu gelangen. Somit müssen bei der Auswahl eines Systems weiterhin alle Eigenschaften gegeneinander abgewogen werden. Neben den neuen Ausprägungen und der Weiterentwicklung der beschriebenen Eigenschaften muss in Zukunft viel Forschung im Bereich der gesamtoptimierten P2P-Live- Streaming-Systeme betrieben werden. Dadurch könnte die Auswahl relevanter Systeme allein durch den Einsatzzweck getroffen werden, ohne dabei alle Eigenschaften gegeneinander abwägen zu müssen. 68

69 PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME 9 LITERATUR [1] Shahzad Ali, Anket Mathur, and Hui Zhang. Measurement of Commercial Peer-to-Peer Live Video Streaming [2] Farid Benbadis, Fabien Mathieu, Nidhi Hegde, and Diego Perino. Playing with the bandwidth conservation law. In Peer-to-Peer Computing, P2P 08. Eighth International Conference on, pages , [3] Bartosz Biskupski, Raymond Cunningham, and Rene Meier. Improving throughput and node proximity of p2p live video streaming through overlay adaptation. In Multimedia, 200. ISM 200. Ninth IEEE International Symposium on, pages , 200. [4] Qingchao Cai, Xiaolu Zhang, and Xuejie Zhang. Streaming live media over bittorrent. In Communications and Mobile Computing, CMC 09. WRI International Conference on, volume 3, pages 44 49, [5] Bram Cohen. Incentives build robustness in BitTorrent. In Workshop on Economics of Peer-to-Peer systems, volume 6, pages 68 2, [6] Federico Covino and Massimo Mecella. Design and evaluation of a system for mesh-based p2p live video streaming. In Proceedings of the 6th International Conference on Advances in Mobile Computing and Multimedia, MoMM 08, pages , New York, NY, USA, ACM. [] Federico Covino and Massimo Mecella. Streamcomplete: an architecture for mesh-based peer-to-peer live video streaming. In Proceedings of the 6th IEEE Conference on Consumer Communications and Networking Conference, CCNC 09, pages , Piscataway, NJ, USA, IEEE Press. [8] Raymond Cunningham, Bartosz Biskupski, and René Meier. Managing peer-to-peer live streaming applications. In Proceedings of the 8th IFIP WG 6.1 international conference on Distributed applications and interoperable systems, DAIS 08, pages , Berlin, Heidelberg, Springer-Verlag. [9] Stephen E. Deering and David R. Cheriton. Multicast routing in datagram internetworks and extended lans. ACM Trans. Comput. Syst., 8:85 110, May [10] Benny Fallica, Yue Lu, Fernando Kuipers, Rob Kooij, and Piet Van Mieghem. On the quality of experience of sopcast. In Next Generation Mobile Applications, Services and Technologies, NGMAST 08. The Second International Conference on, pages , [11] Mário Rui Vazão Vasco Ferreira. Live streaming in overlay networks, october Master Thesis, Instituto Superior Técnico. [12] Hui Guo, Kowk-Tung Lo, and Chi-Tsun Cheng. Overlay networks construction for multilayered live media streaming. In Multimedia, ISM 06. Eighth IEEE International Symposium on, pages , [13] Hui Guo, Kwok-Tung Lo, and Jiang Li. Lsonet: A case of layerencoded video transmission in overlay networks. In Tat-Jen Cham, Jianfei Cai, Chitra Dorai, Deepu Rajan, Tat-Seng Chua, and Liang- Tien Chia, editors, Advances in Multimedia Modeling, volume 4351 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [14] Poo Kuan Hoong and Hiroshi Matsuo. Push-pull incentive-based p2p live media streaming system. WTOC, :33 42, February [15] Akos Horvath, Miklos Telek, Dario Rossi, Paolo Veglia, Delia Ciullo, Maria Antonieta Garcia, Emilio Leonardi, and Marco Mellia. Dissecting PPLive, SopCast, TVAnts. submitted to ACM Conext, [16] Yang hua Chu, Sanjay G. Rao, Srinivasan Seshan, and Hui Zhang. A case for end system multicast. Selected Areas in Communications, IEEE Journal on, 20(8): , October [1] Qi Huang, Hai Jin, and Xiaofei Liao. P2p live streaming with tree-mesh based hybrid overlay. In Parallel Processing Workshops, 200. ICPPW 200. International Conference on, pages 55 55, 200. [18] John Jannotti, David K. Gifford, Kirk L. Johnson, M. Frans Kaashoek, and James W. O Toole, Jr. Overcast: reliable multicasting with on overlay network. In Proceedings of the 4th conference on Symposium on Operating System Design & Implementation - Volume 4, OSDI 00, pages 14 14, Berkeley, CA, USA, USENIX Association. [19] Xiaofei Liao, Hai Jin, Yunhao Liu, Lionel M. Ni, and Dafu Deng. Anysee: Peer-to-peer live streaming. In INFOCOM th IEEE International Conference on Computer Communications. Proceedings, pages 1 10, [20] Yong Liu, Yang Guo, and Chao Liang. A survey on peer-to-peer video streaming systems. Peer-to-peer Networking and Applications, 1(1):18 28, [21] Yunhao Liu, Li Xiao, Xiaomei Liu, Lionel M. Ni, and Xiaodong Zhang. Location awareness in unstructured peer-to-peer systems. Parallel and Distributed Systems, IEEE Transactions on, 16(2):163 14, [22] Yue Lu, Benny Fallica, Fernando A. Kuipers, Robert E. Kooij, and Piet Van Mieghem. Assessing the quality of experience of sopcast. Int. J. Internet Protoc. Technol., 4:11 23, March [23] Nazanin Magharei and Reza Rejaie. Prime: peer-to-peer receiver-driven mesh-based streaming. IEEE/ACM Trans. Netw., 1: , August [24] Vinay Pai, Kapil Kumar, Karthik Tamilmani, Vinay Sambamurthy, and Alexander E. Mohr. Chainsaw: Eliminating trees from overlay multicast. Peer-to-peer systems IV, pages , [25] Kunwoo Park, Sangheon Pack, and Taekyoung Kwon. Climber: an incentive-based resilient peer-to-peer system for live streaming services. In Proceedings of the th international conference on Peer-to-peer systems, IPTPS 08, pages 10 10, Berkeley, CA, USA, USENIX Association. [26] Kunwoo Park, Sangheon Pack, and Ted Taekyoung Kwon. An adaptive peer-to-peer live streaming system with incentives for resilience. Comput. Netw., 54: , June [2] Darshan Purandare and Ratan Guha. An alliance based peering scheme for peer-to-peer live media streaming. In Proceedings of the 200 workshop on Peer-to-peer streaming and IP-TV, P2P-TV 0, pages , New York, NY, USA, 200. ACM. [28] Darshan Purandare and Ratan Guha. BEAM: A Peer-to-Peer Framework for Live Media Streaming. Technical report, University of Central Florida, Orlando, 200. [29] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Shenker. A scalable content-addressable network. In Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, SIGCOMM 01, pages , New York, NY, USA, ACM. [30] Antony Rowstron and Peter Druschel. Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. In Rachid Guerraoui, editor, Middleware 2001, volume 2218 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [31] Rüdiger Schollmeier. A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications. In Peer-to- Peer Computing, Proceedings. First International Conference on, pages , August [32] Henning Schulzrinne, Stephen L. Casner, Ron Frederick, and Van Jacobson. RTP: A transport protocol for real-time applications. IETF Request for Comments: RFC 3550, july [33] Heiko Schwarz, Detlev Marpe, and Thomas Wiegand. Overview of the scalable video coding extension of the h.264/avc standard. Circuits and Systems for Video Technology, IEEE Transactions on, 1(9): , 200. [34] Thomas Silverston and Olivier Fourmaux. Source vs data-driven approach for live p2p streaming. In Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, ICN/ICONS/MCL International Conference on, pages 99 99, [35] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, SIGCOMM 01, pages , New York, NY, USA, ACM. [36] Long Vu, Indranil Gupta, Jin Liang, and Klara Nahrstedt. Measurement and modeling of a large-scale overlay for multimedia streaming. In The Fourth International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness & Workshops, QSHINE 0, pages 3:1 3:, New York, NY, USA, 200. ACM. [3] Susu Xie, Bo Li, Gabriel Y. Keung, and Xinyan Zhang. Coolstreaming: Design, theory, and practice. Multimedia, IEEE Transactions on, 9(8): , 200. [38] Xinyan Zhang, Jiangchuan Liu, Bo Li, and Tak-Shing Peter Yum. Coolstreaming/donet: a data-driven overlay network for peer-to-peer live media streaming. In INFOCOM th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE, volume 3, pages vol. 3, [39] Ben Y. Zhao, John D. Kubiatowicz, and Anthony D. Joseph. Tapestry: An infrastructure for fault-tolerant wide-area location and. Technical report, Berkeley, CA, USA, [40] Qinglin Zhu, Rui Wang, Depei Qian, and Feng Xiao. Re-exploring the potential of using tree structure in p2p live streaming networks. In Network and Parallel Computing, NPC 09. Sixth IFIP International Conference on, pages ,

70 HARVESTING SENSOR NETWORKS 1 Harvesting Sensor Networks Andreas Straninger Abstract Battery powered Wireless Sensor Networks only have a limited lifetime and have to be replaced if the battery drops to zero. Using renewable energy sources to recharge batteries allows sensor nodes theoretically to attain indefinite lifetime. Thus, the focus moves from maximizing the lifetime to maximizing the usage of harvestable energy. This affects the sensors energy saving strategies, rate adaption, the establishment of routes, compression and the use of error correcting codes. This Seminar work aims to give an overview on algorithms, which maximize the efficiency of harvesting sensor nodes. I. INTRODUCTION Sensors are widely used for gathering information about the environment. One task for a sensor network is field monitoring, where sensors are deployed at an area and information is routed to one or more base stations (see e.g. [2]). Sensors regularly collect information, e.g. temparature or humidity, at a constant rate. The maximum sensing rate for each sensor would be of interest. Another task, which could be performed by sensor nodes deployed over a field is event monitoring. In constrast to field monitoring, only a selected set of events is transmitted, e.g. detected smoke by a fire sensor. Currently, most sensors are supplied by a battery and have to be exchanged, when the sensor node gets out of energy. Algorithms for maximizing the lifetime in sensor networks with batteries are used. Recent works propose the usage of renewable energy sources for sensors in combination with rechargable batteries. If the battery is low, a sensor can shut down components to reduce energy consumption and reload the battery, when energy is available and can be harvested. A harvesting sensor can theoretically work forever. Energy sources, which can be used in harvesting sensor networks (e.g. [6]) are solar, mechanical and thermal energy. Solar energy can be harvested outdoors from the sun or indoors from artificial lights with solar panels. Mechanical energy occurs as vibrational or kinetic energy. Vibrations are harvested by using a piezoelectric capacitator, kinetic energies can be harvested with generators. Thermal energy in terms of temperature differences can also be harvested. The transmission range of sensors usually is limited. Each Sensor collects informations, initiates the transmission of collected informations and routes information to the sink. Compared to a peer to peer network, connections cannot be established arbitrarily. Only connections to locally near sensor nodes are possible. Sensors buffer the information collected and send it to neighbour nodes. In harvestin sensor networks, optimal routes do not necessarily follow the shortest paths with the least possible number of hops. Instead, a routing algorithm would prefer nodes with the highest possible harvesting opportunities. Maximization of energy usage from the environment is one of the task which emerges from the usage of harvesting sensor nodes. The paper is structured as follows. Section II explains the properties of harvesting sensor nodes and introduces the terminology used. In Section III, algorithms for optimizing the energy available for a node are explained. Section IV introduces algorithms, which address sensor network specific problems. Harvesting specific algorithms for rate adaption, routing and compression are depicted. Finally in Section V, a conclusion is drawn and ideas for future research are given. II. BASICS The authors in [2] suggest 3 kinds of energy storage, harvesting systems with no energy storage, harvesting systems with ideal energy buffer and harvesting systems with non-ideal energy buffer. In harvesting systems with no energy storage, for each point in time only the energy harvested can be used. A harvesting systems with ideal energy buffer is able to store and restore all the energy harvested without any losses. Harvesting systems with non-ideal energy buffers have a limited storage capacity, a charging efficiency < 100% and also have a leakage, i.e. a loss of energy over time. In the following it is assumed if not explicitly mentioned, that sensors use batteries as a non-ideal energy buffer. In practice, ultra capacitators and rechargable batteries are used as energy buffers. Ultra capacitators have a high charging efficiency but also a high leakage and a low energy density, i.e. storage capacity per volume. They can be used if high power is available over small time intervals of about a second or less. Rechargable batteries usually have a higher energy density and are suitable for energy that is available for longer periods of time. Sensor nodes use algorithms to control the energy consumption and adjust the duty cycle. The duty cycle is the fraction of time, where the sensor is busy. Sensors are either in active mode or consume a small amout of energy in sleep mode. Empty batteries should be avoided because sensors regularly have to switch to active mode to sense information. A sensor which harvests the same amount energy which it consumes over the time it is deployed, without getting out of battery energy, works at energy neutral operation. If a sensor consumes more energy than harvested before, the battery level may drop to zero and the sensor may be interrupted. On the other hand, if a sensor consumes less energy than possible, the battery may be fully loaded and thus not able to store surplus energy harvested. Hence, an algorithm that optimizes the duty cycle has to estimate the future harvesting opportunities, so that energy neutral operation is possible, and no energy is wasted. Sensors usually provide a sleep mode, where a minimum amount of energy is consumed. In active mode, a sensor 0

71 2 HARVESTING SENSOR NETWORKS may reduce the energy consumption by switching off parts of the hardware e.g. the sensing module or the communication module. Besides, a sensor needs energy for each transmission of data. Thus, an optimized sensing rate and optimal routes for a minimized amout of energy needed for transmission is searched. To measure the current energy produced in an interval, [2] recommend to monitor the energy production of the harvesting source rather than monitoring the battery level because there is only a small change in change of voltage at the battery, compared to the change of voltage in the harvesting module. Algorithms operate either on global knowledge or on local knowledge. Algorithms with global knowledge have information about the state of each deployed sensor node. They can run on a node with high computation power. However, the collection of sensor node states leads to additional transmission overhead and delays. The transmission overhead will be to high to be neglected and delays can cause nodes to make necessary adjustments too late and operate with suboptimal parameters. Algorithms which directly operate on a sensor node with local knowledge only have information about the state of the sensor node and can determine the state of neighboring nodes. Since computation power of sensor nodes is limited, low complexity solutions are required. With the ability to adapt the duty cycle, the energy wastage can be minimized. The following section addresses the issue of optimizing the duty cycle with the use of the state of the sensor node and its sourrounding. III. ENERGY PREDICTION AND USAGE In this section, algorithms for energy prediction and energy usage are presented. The algorithms either schedule the duty cycles on the basis of energy observations or learn how to optimally adapt the duty cycle on the basis of the current sensor state. In the following, one scheduling algorithm and two algorithm that work on current sensor states are presented. A. Scheduling duty cycles The authors in [2] present an algorithm that maximizes the duty cycle over the time, where the sensor is deployed. The algorithm is designed for solar harvesting sensors, therefore it is postulated, that energy patterns reoccure periodically. The period, a day for solar harvesting sensors, is divided into N W time slots. For each time slot i, the power harvested P s (i), the power consumed P c (i) and the duty cycle D(i) are considered to be constant. The maximization of duty cycles is expressed as max N W i=1 D(i) An optimization problem is formulated that takes the power harvested, the power consumed, the battery level and properties of the battery into account. The problem can be solved with high computational power and knowledge about future harvesting opportunities. Since the optimization problem is too complex to be solved on sensor nodes, the authors propose a local low complexity solution. Furthermore, future harvesting opportunities are not known in advance. The algorithm proposed makes predictions about future harvesting opportunities in a first step and then in a second step determines the optimal duty cycle. The duty cycle is readjusted in a third step, if the energy harvested deviates from the energy predicted. In the first step, the algorithm predicts the energy available with an Exponentially Weightetd Moving-Average. The predicted value x(i) at time i is: x(i) = αx(i 1) + (1 α)x(i) where x(i) is the energy harvested at time i. Several values for α have been tested and a value of α = 0.5 is suggested. In experiments, an initial training for 2 hours has been performed before the usage of the sensor nodes. Predictions for each slot x(i) are refreshed after the energy energy yield at slot i has been determined. A window size of 24 hours is chosen, consisting of N W time slots x W. In experiments, N W = 48 time slots have been chosen with a size of 30 minutes each. The algorithm distinguishes sun duty cyles S = {i P s (i) P c 0} where more energy is harvested than consumed and dark duty cycles D = {i P s (i) P c 0} where more energy is consumed than harvested. The optimization problem is reformulated as: N W i=1 P s (i) = i D D(i)[ P c η + P s(i)(1 1 η )] + P c D(i) i S In the second step, the minimum admissible duty cycle is assigned for time slots, where more energy is consumed than harvested and the maximum admissible duty cycle is assigned for time slots, where less energy is consumed than harvested. Then two cases may occure, either there is still energy available or too much energy is assigned to the duty cycles. In the first case, the maximum duty cycle is assigned to additional slots in D, dependent on their harvesting opportunities. Otherwise, the duty cycle of all slots in S is reduced uniformly by a modifier δ. After each time slot, the algorithm corrects in the third step the duty cycle assigned. If less energy is harvested than predicted, the duty cycle of some future time slots is reduced to the minimum duty cycle. Otherwise duty cycles with the lowest duty cycles are increased. In evaluation the authors compared their low complexity algorithm with local knowledge to an optimal solution, which is calculated with global knowledge. They used the same energy prediction method for both algorithms and achieved a good result for the low complexity variant. A drawback of the algorithm is that harvesting predictions are only usable after 2 hours. Thus, the sensor would have to work initially on a reduced duty cycle. B. Learning adaption rules The Idea of the algorithm introduced by Vigorito [] is to minimize the usage of the battery. This is done on the one hand to minimize the losses which occure when charging or discharging batteries. Then, if the battery is full, energy which 1

72 HARVESTING SENSOR NETWORKS 3 cannot be used is wasted and if the batterie is empty, the node gets out of energy. Finally, most types of batteries like NiMH and Li-Ion Batteries have a longer lifetime if they are not completely discharged. The algorithm aims to minimize the quadratic deviation of the battery level B t from the desired level B. In other words, the algorithm tries to minimize the equation lim N t=1 N (B t B ). To achieve this, the algorithm makes use of control theory. The Battery Level at time B t + 1 can be expressed as B t+1 = ab t + bu t + cw t + w t+1 where u t is the utility of the sensor, and w t is some noise. a, b and c are unknown constants. It is mentioned in [], that the optimal control law for u t is u t = B (a + c)b t + cb b The constants a, b, c are calculated via fixpoint iteration. Thus, θ = (a + c, b, c) T and φ t = (B t, u t, B ) T are defined with φ T t θ = y. θ is calculated with fixpoint-iteration. Using fixpoint iteration has the advantage, that a, b and c do not necessarily have to be constant but may change over time. Update rule is given by ˆθ t+1 = ˆθ t + µ φ T t φ t φ t (B t+1 φ T t ˆθ t ) The authors also provide a way to reduce the variance of the duty cycle. Therefore, u t is not used directly, instead, the smoothened duty parameter p t is calculated: u t + 1 = ū t + α(u ū) It is an exponentially weighted utility with old values of u with α < 1. Then, p t+1 = βu t + (1 β)ū t with 0 β 1 is calculated. Experimental results have been made with µ = and different values for α and β. Best results could be achieved with α = 10 4 and β = 0.25 with time steps of 1 minute. The authors compared their solution to the algorithm proposed in [2] and claim to achieve better results with their algorithm. At evaluation, a higher uptime, lower variance of the battery level, and a higher duty cycle was measured. The evaluation was done as a simulation, where measured data of sensors have been used. C. Probabilistic duty cycle adaption Duty cycle adaption algorithms specify the fraction of time, where the sensor is in the wake state or in the sleep state. If a sensor is set to a specific duty cycle, it is not clear, at which parts of the sensors are active and at which intervals they are active. A probabilistic approach for adapting the energy usage of sensor nodes is presented in [4]. Only two states for sensor nodes are assumed, an active mode and a sleep mode. Transations between the states are determined by strategies which are based on properties of the sensor, the battery state or the queue for outgoing messages, or properties of the sourrounding, the channel quality or the solar radiation. Hybrid strategies which use more than one properties are also mentioned. For example, a strategy which is based only on the message queue of size 10 containing x messages and can be formulated in the following way: P active sleep (x) = 0.8 x 4 P active sleep (x) = 0.3 x > 4 P sleep active (x) = 0.3 x 3 P sleep active (x) = 0. x > 3 The authors analyzed the influence of different strategies on the package drop rate respectively the package blocking rate. This was done by modeling the arrival of packages at a node as a batch markovian arrival process, where states are defined for each of the properties and for the state of the sensor node S wake, sleep. A. Maximum flow IV. ROUTING AND NETWORK [2] suggest an approach for maximizing the throughput and determining a constant sensing rate which is equally assigned at all sensor nodes. The energy consumption of a node is given by P (i, j) = r[α 1 + α 2 d(i, j) 2 ] where d(i, j) is the distance between nodes i and j, r is the data rate and α 1 and α 2 are radio [frequency] dependent constants. Given the duty cycle for node i at time t, problem can be formulated as a maximal flow problem where the duty cycle determines the maximal flow through a sensor node and the power P (i, j) determines the actual costs for sending a message from node i to node j. After assigning the flow, the maximum sensing rate can be computed. The algorithm still does not allow the adjustment of sensing rates based on local knowledge. Besides, the approach does not allow sensing rates to be readjusted if the energy harvested varies. B. Rate adaption An approach, which calculates the throughput for a network with fixed routes is presented in [1]. The optimal throughput can be calculated centrally by solving a liniear programming problem. This is done by formulating the necessary constraints for energy consumption of the sensor node, energy needed for routing, and properties of energy neutral operation dependent on the sensing rate. A local solution for the problem is constructed in two steps. First, the maximum sensing rate is calculated for each sensor node. If the battery would drop to zero after a time interval, the 2

73 4 HARVESTING SENSOR NETWORKS sensing rate is adapted. In a second step, each node initiates a request for the sensing rate. The desired rate initially is set to the maximum rate. If a node between the initiator and the sink is not capable of assigning the requested rate for the initiator, all existing assignments are adapted in a fair way and updates are sent. The authors collected harvesting profiles and sensing rates on from a sensor environment and evaluated the algorithm in a simulator. A high running time of the algorithm occured due to frequent rate adaptions. The authors also mention, that higher rates could be assigned more homogeneously among sensor nodes if alternate routes would be possible. C. Greedy Routing A quite simple routing approach is presented in [8]. The algorithm selects the most promising node for next hops dependent on the euclidean distance between the current node and the receiver node, the link state quality, as well as the battery level and the energy production and consumption rates. Informations can be sent between any two sensor nodes in the network. This approach balances the load so that overload situations of nodes are prevented. However, the energy aware greedy routing approach is not the best choice for the monitoring tasks of sensors. Firstly, each sensor node usually only routes its information to one sink. Arbitrary routes are not required and may lead to unneccessary computational overhead. Secondly, no routing tables are used, and thus greedy routing may not be able to find a route in some cases. D. Harvesting aware Routing Tables Routing tables can be used to determine routes between two sensor nodes. For event monitoring and field monitoring, each sensor node has to be able to establish a route only to a collecting node, but not between each other. In a sensor network, where each sensor node has enough energy, a node would keep track about the minimum number of hops to reach a collecting node. Routes would be established to minimize the number of hops. Hence, in harvesting sensor networks, the throughput is limited by the amount of energy harvestable. Thus a higher node availability and thus a higher throughput is expected, if nodes with higher harvesting opportunities are preferred. In [3], five algorithms for harvesting sensor networks are presented and evaluated in a simulation environment. For each sensor node, the average harvesting capabilities are known. The minimum path ( MP ) algorithm selects the shortest path based on the minimum number of hops. For the other four algorithms, nodes randomly make a selection of their next hops. In the randomized weighted minimum path (R-WMP) algorithm, the probability for selecting a node for the next hop is inversely proportional to the package energy, and to minimum number of hops from the next hop node to the sink. The package energy is the energy necessary to transmit the message from the current node to the next hop node. Fig. 1. Comparison of routes calculated with MP, MF and R-MPRT. Dark areas correspond to low harvesting opportunities, bright areas correspond to high harvesting oppor. Source: [3] The randomized minimum path energy (R-MPE) algorithm, computes the minimum path energy, i.e. the energy, which is necessary to route a package from the current node to the sink over a selected next hop neighbor. The probability for choosing a node as the next hop neighbor is inversely proportional to the minimum path energy. The randomized minimum path recovery time (R-MPRT) algorithm is similar to R-MPE. Instead of the link energy, the path recovery time is used, i.e. the time needed to harvest the link energy at the sender node. Finally, with the randomized maxflow (R-MF) algorithm, the optimal flow for each node is centrally calculated. The propability for selecting a node for the next hop are proportional to its optimal flow. Since the algorithm cannot operate on local knowledge, but also uses random node selection, it is only introduced for comparison purposes. The authors showed, that the energy aware algorithms, R- WMP, R-MPE and R-MPRT, perform better than the MP algorithm. Though, compared to the optimal flow, R-MPE and R-MPRT have a performance of about 10% to 40%. In evaluation, the routes were chosen individually for each message. Nevertheless, establishing static routes and reestablishing them regularly is possible to use the rate adaption algorithm presented in this section. Variations of the algorithm R-MPRT can be of use. Firstly, the duty cycle can be used for creating the routing tables instead of the minimum path energy. Then, the authors only address route selection for field monitoring. If routes for event monitoring are required, the maximum delay can be used instead of the minimum path energy. E. Compression Properties about static routes are also discussed in [5]. The authors propose to aggregate and compress data and in this way save energy and reduce the number of messages sent. The authors state, that individual routes, which are established for each message arouse data collisions. Additionally, sensor nodes can aggregate and compress data with the same destination to reduce the amount of transferred data and thus save energy. The method presented divides the area, where sensor nodes are deployed into regions. For each region, a node is chosen which is denoted border node. A border node in harvesting sensor networks should be close to the sink and have high 3