Peer-to-Peer Networks Protocols, Cooperation and Competition

Transcription

1 Peer-to-Peer Networks Protocols, Cooperaton and Competton Hyunggon Park Sgnal Processng Laboratory (LTS4), Insttute of Electrcal Engneerng, Swss Federal Insttute of Technology (EPFL), Lausanne, Swtzerland Raft Izhak Ratzn Computer Scence Department, Unversty of Calforna, Los Angeles (UCLA), Los Angeles, USA Mhaela van der Schaar Multmeda Communcatons and Systems Laboratory, Electrcal Engneerng Department, Unversty of Calforna, Los Angeles (UCLA), Los Angeles, USA 1. INTRODUCTION Peer-to-peer (P2P) networks connect many end-hosts (also referred to as peers) n an ad-hoc manner. P2P networks have been typcally used for fle sharng applcatons, whch enable peers to share dgtzed content such as general documents, audo, vdeo, electronc books, etc. Recently, more advanced applcatons such as real-tme conferences, onlne gamng, and meda streamng have also been deployed over such networks. Unlke tradtonal clent-server networks, where servers only provde content, and clents only consume content, n P2P networks, each peer s both a clent and a server. It has been observed that P2P fle sharng applcatons domnate Internet traffc usage. In fact, a wde range of measurements, whch were performed n 8 dfferent geographc regons durng the years of , show that P2P networks generated most of the traffc n all montored regons, rangng from 43% n Northern Afrca to 70% n Eastern Europe ( The same study also dentfed that BtTorrent (Cohen, 2003) s the most popular protocol on the Internet, generatng most of the traffc n 7 out of 8 regons rangng from 32% n South Afrca to 57% n Eastern Europe. The detals of the BtTorrent protocol wll be dscussed n Secton 3. Recently, meda delvery and streamng servces over the Internet such as YouTube ( PPLve ( and Internet vdeo broadcastng (e.g., AOL broadcast, MSNBC, CBS, etc.) have emerged. These servces have become very popular, as they can delver vdeo to a large number of recevers smultaneously at any gven tme. In order to reduce nfrastructure, mantenance, and servce costs, and provde more relable servces, the content provders often mplement ther servces usng P2P network.

2 Whle several desgns for P2P systems have been successfully deployed for fle sharng and real-tme meda streamng, key challenges such as the desgn of optmal resource recprocaton strateges among self-nterested peers stll reman largely unaddressed. For example, pull-based technques (Cohen, 2003; Pa et al., 2005; Zhang et al., 2005) are desgned assumng that peers are altrustc and are wllng to provde ther avalable data chunks (peces) whenever requested. However, such assumptons may be undesrable from the perspectve of a self-nterested peer, whch ams to maxmze ts own utlty. Thus, effcent resource recprocaton strateges need to be deployed, whch can also provde ncentves to the peers for ther contrbutons. In BtTorrent systems, ncentve strateges are based on the so-called tt-for-tat (TFT) strategy, where a peer selects some of ts assocated peers (.e., leechers), whch are currently uploadng at the hghest rates, and provdes them ts content for downloadng (Cohen, 2003). Ths smple strategy s currently mplemented n BtTorrent systems, and provdes good performance. However, a key dsadvantage of ths resource recprocaton strategy s that peers decde how to determne ther resource recprocaton based on only the current upload rates that t receves from ts assocated peers, and does not consder how ths recprocaton wll mpact ther upload rates n the future. In other words, the resource recprocaton based on the TFT s myopc. Snce peers n P2P networks are generally nvolved n repeated and long-term nteractons, such myopc resource recprocaton strategy can result n a suboptmal performance for the nvolved peers. More advanced resource recprocaton strateges have been recently proposed n (Park & van der Schaar, 2009), where the resource recprocaton among the nterested peers s modeled as a stochastc game (Fudenberg & Trole, 1991). In ths framework, peers determne ther resource dstrbutons by explctly consderng the probablstc behavors (recprocaton) of ther assocated peers. Unlke exstng resource recprocaton strateges, whch focus on myopc decsons, t formalzes the resource recprocaton game as a Markov Decson Process (MDP) (Bertsekas, 1976) to enable peers to make foresghted decsons on ther resource dstrbuton n a way that maxmzes ther cumulatve utltes,.e., the sum of ther mmedate and future utltes. Thus, ths strategy can mprove the performance of the peers, whch are generally nvolved n long-term and repeated nteractons. When the foresghted strateges are deployed n practce, the peers bounded ratonalty should be consdered, because perfectly ratonal decsons are often nfeasble n practce due to ther memory and computatonal constrants. Peers can only have lmted knowledge of the other players behavor and lmted ablty to analyze ther envronment. Therefore, t s essental to study the mpact of the peers bounded ratonalty on 1) the performance degradaton of the proposed resource recprocaton strategy and 2) ther repeated nteractons (resource recprocaton). Ths chapter s organzed as follows. In Secton 2, we overvew varous P2P network structures and dscuss ther advantages and dsadvantages. In Secton 3, we dscuss the BtTorrent system, whch s one of the most popular fle sharng protocols. We also dscuss the lmtatons of BtTorrent systems. In Secton 4, we overvew exstng P2P-based meda streamng applcatons, and dscuss how several mechansms have been developed to support real-tme meda streamng requrements. In Secton 5, we show the recently proposed foresghted resource recprocaton strateges, whch can mprove the performance of P2P-based applcatons. In Secton 6, we dscuss new drectons for game-theoretc approaches to ncentve desgn n P2P networks. Conclusons of ths chapter are drawn n Secton OVERVIEW OF P2P SYSTEM STRUCTURES

3 P2P systems can be classfed nto two dfferent classes: structured P2P systems and unstructured P2P systems. In structured P2P systems, connectons among peers n the network are fxed, and peers mantan nformaton about the resources (e.g., shared content) that ther neghbor peers possess. Hence, the data queres can be effcently drected to the neghbor peers that have the desred data, even f the data s extremely rare. Structured P2P systems mpose constrants both on node (peer) graph and on data placement to enable effcent dscovery of data. The most common ndexng that s used to structure P2P systems s the Dstrbuted Hash Tables (DHTs) ndexng. Smlar to a hash table, a DHT provdes a lookup servce wth (key, value) pars that are stored n the DHT. Any partcpatng peers can effcently retreve the value assocated wth a gven unque key. However, ths may result n hgher overhead compared to unstructured P2P networks. Dfferent DHT-based systems such as Chord (Stoca et al., 2001), Pastry (Rowstron & Druschel, 2001), Tapestry (Zhao et al., 2004), CAN (Ratnasamy et al., 2001) are dfferent n ther routng strateges and ther organzaton schemes for the data objects and keys. Unlke structured P2P systems, n unstructured P2P systems, connectons among peers n the network are formed arbtrarly n flat or herarchcal manners. In order to fnd as many peers that have the desred content as possble, peers n unstructured P2P systems query data based on several technques such as floodng (e.g., among the super-peers n KaZaA ( random walkng (Gkantsds et al., 2004), and expandng-rng (e.g., Tme-To-Lve counter n Gnutella ( Three dfferent desgns of unstructured P2P systems exst: centralzed unstructured P2P systems, hybrd unstructured P2P systems, and decentralzed (or pure) unstructured P2P systems. In a centralzed unstructured P2P system, a central entty s used for ndexng and bootstrappng the entre system. In contrast to the structured approach, the connecton between peers n the centralzed unstructured approach s not determned by the central entty. A BtTorrent network dscussed n Secton 3 s an example of a centralzed unstructured P2P network. Napster ( the network that poneered the dea of P2P fle sharng, s another example of a centralzed desgn. In Napster, a server (or server farm) s used to provde a central drectory. A peer n the network nforms the drectory server of ts IP address and the names of the contents that t makes avalable for sharng. Thus, the drectory server knows whch objects each peer n the network have, and then, creates a centralzed and dynamc database that maps content name nto a lst of IPs. The man drawback of Napster s desgn s that the drectory server s a sngle pont of falure. Hence, f the drectory server crashes, then the entre network wll also collapse. Moreover, ncreasng the sze of the network may cause a bottleneck n the drectory server, due to the need of respondng to many queres and mantanng a large database for ths meta-data nformaton. The bottleneck can only be resolved by addng more nfrastructure (e.g., more servers), whch may be expensve. The decentralzed (or pure) unstructured P2P network s an overlay network. An overlay network s a logcal network. An edge n ths network exsts between any par of peers that mantan a TCP connecton. The decentralzed unstructured overlay network s flat, meanng that all peers act as equals. There s nether a central server that manages the network, nor are there preferred peers wth a specal nfrastructure functon. The network has a sngle routng layer. Gnutella ( s an example of a decentralzed unstructured P2P network. In order to jon the Gnutella network, a user ntally connects to one of several knownbootstrappng peers. The bootstrapped peers then respond wth the nformaton about one or more exstng peers n the overlay network. Ths nformaton ncludes the IP address and port of each peer. The peers n Gnutella are aware only of ther neghbor peers. Peers that are connected wth

4 each other n the overlay network have a common vrtual edge n the overlay network. In Gnutella, queres are dstrbuted among the peers usng a varaton of a floodng mechansm. A peer that s nterested n specfc content sends a query to ts neghbors n the overlay network. Every neghbor then forwards the query to all of ts neghbor peers. The procedure contnues untl the query reaches a specfc depth of search lmt (counted by Tme-To-Lve counter). Upon recevng a flood query, a peer that has a copy of the desred content sends a query ht response to the peer that orgnated the query, whch s an ndcaton of havng the content. The response s sent on the reverse path of the query, usng pre-exstng TCP connectons. The peer that orgnated the query then selects one peer from the responded peers, and downloads the desred content through a drect TCP connecton from the selected peer. Although Gnutella desgn s smple, hghly decentralzed, and does not requre peers to mantan nformaton related to locaton of contents, t s often crtczed for ts non-scalablty. Ths s because query traffc can grow lnearly wth the total number of queres, whch n turn grows wth the system sze. In addton, another drawback of the protocol s that a peer that orgnated the query may not fnd the desred content especally f the content s rare. A hybrd unstructured P2P network allows the exstence of nfrastructure nodes, often referred to as super-peers (or super-nodes or overlay nodes). Ths creates a herarchcal overlay network that addresses the scalng problems on pure unstructured P2P networks such as Gnutella. A peer n such network can typcally change roles over tme. For example, a regular peer can become a super-peer that takes part n coordnatng the P2P network structure. KaZaA ( whch s based on the FastTrack ( protocol, s an example of a hybrd unstructured P2P network. Ths network uses specally desgnated superpeers wth hgh bandwdth, dsk space and processng power. When a peer jons the network, t s assgned to a super-peer. The peer then nforms ts super-peer about the content that t wll share. The super-peer facltates the search by mantanng a database that maps content to peers, and tracks only the content of ts assgned peers. Smlar to the centralzed desgn, the super-peer plays the role of a drectory server, although only to ts assgned peers. The super-peers together create a structured overlay of super-peers, whch makes search for content more effcent. A query n ths network s routed to a super-peer. Then, as n the decentralzed desgn, the query s flooded n the overlay super-peer network. The super-peer then responds to the peer that orgnated the query wth a lst of peers havng the content. The hybrd networks are no longer dedcated to a sngle server, snce the database s dstrbuted among the super-peers. Moreover, the sze of the database s relatvely small, snce each super-peer tracks only the contents of ts assgned peers. However, the drawback of ths approach s that t s consderably complcated, and requres non-trval mantenance of the overlay network. Moreover, the fact that super-peers may have more responsbltes than ordnary peers can result n a bottleneck. 3. P2P-BASED FILE SHARING: BITTORRENT SYSTEMS BtTorrent s a popular peer-to-peer fle sharng protocol that was created by Cohen (2003). BtTorrent has been shown to scale well wth large number of partcpatng end hosts. Ipoque ( measurements for years show that BtTorrent s the domnant protocol n the Internet, and that t accounted for approxmately 20-57% of all Internet traffc dependng on the geographcal locaton.

5 3.1 System Descrpton BtTorrent s a centralzed unstructured system, whch conssts of two nteractng unts: 1) A control level descrbes control methods such as the requred fle sharng preparaton, whch takes place pror to sharng the actual content, and the coordnaton among end hosts, whch s performed by a central entty durng the downloadng process. 2) A recprocaton level descrbes the actual data exchange among the end hosts. These two desgn levels are descrbed n detal next The BtTorrent System Desgn Control Level The BtTorrent content dstrbuton system conssts of the followng components: Data content An orgnal content provder The metanfo fle The tracker The end hosts or peers or clents A torrent, or swarm, s a collecton of end hosts (or peers) partcpatng n the download of content, where content may refer to one (e.g. the Lnux operatng system) or multple (e.g. several vdeo or audo) fles. The tracker s a server that coordnates and asssts the peers n the swarm. It mantans the lst of peers that are currently n the swarm, as well as statstcs about the peers. The tracker lstens on a BtTorrent TCP port for comng clent requests. Whle the default BtTorrent port s port 6969, several trackers may use dfferent ports. Pror to the content dstrbuton, a content provder dvdes the content nto multple peces, where each pece s typcally 256KB. Each pece s further dvded nto multple subpeces wth a typcal sze of 16KB. The content provder then creates a metanfo fle. The metanfo fle contans nformaton that s necessary for ntatng and mantanng the download process. For example, the metanfo fle contans the URL of the tracker, the name of the data fle (fles), the length of the data fle (fles), and the length of a pece. The metanfo fle may also contan nformaton related to multple data fles, and optonal nformaton such as creaton date, author s comments, name and verson of the.torrent creator, etc. The metanfo fle also contans a specal strng, whch s a concatenaton of 20-byte encoded hash values. Each value s a SHA-1 hash of a pece at the correspondng data content, whch s used for data ntegrty.

6 Data Content Dvde nto peces Upload.torrent Web page lnks to.torrent UPload.torrent.torrent Metanfo fle Creates.torrent fle Orgnal Content Provder Announce Peer lst Tracker End-user Peer Fgure 1: BtTorrent System - Pror to Fle Sharng The metanfo fle s usually uploaded to a webste, thereby makng t accessble to peers that are wllng to download content by jonng the swarm. A peer that s wllng to jon the swarm frst retreves the out-of-band metanfo fle. Then, ths peer contacts the tracker by sendng an announce HTTP GET request. The request n general may nclude necessary nformaton such as the total amount uploaded, the total amount downloaded, the number of bytes the peer stll has to download, an event descrpton such as started f t s the frst request to the tracker, completed f the peer shut down gracefully, stopped f the download completed. Ths nformaton helps the tracker keep overall statstcs about the torrent (e.g., number of seeds, number of leechers, lfe tme of a seed, etc). The tracker responds back wth a "text/plan" document, whch ncludes a randomly selected set of peers that are currently onlne. A typcal sze of a peer set s 50. The random peer set may nclude both seeds and leechers. Seeds are the peers who already have the entre content and are sharng t wth others. Leechers are the peers who are stll n the process of downloadng (.e. they do not possess the entre fle). The new peer can then ntate new connectons wth the peers n the swarm and start to exchange data content peces. The maxmum number of connectons that a peer can open s lmted n BtTorrent to 80 n order to avod performance degradaton due to competton among concurrent TCP flows. In addton, the new peer s also lmted to establsh a fxed number of outgong connectons, typcally 40, n order to ensure that some connecton slots are kept avalable for new peers that wll jon at a later tme. Fgure 1 portrays the prelmnary steps that need to be performed before startng to dstrbute the data content. A peer that has already begun downloadng may contact the tracker and ask for more peers f ts peer set falls below a gven threshold, whch s typcally set to 20 peers. Moreover, usually there s a mnmum nterval between two consecutve peer requests to avod overwhelmng the tracker. In addton, peers contact the tracker perodcally, typcally once every 30 mnutes, to ndcate that they are stll present n the network. If a peer does not contact the tracker for more than 45 mnutes, the tracker assumes that the peer has left the system and wll remove the peer from the torrent lst.

7 3.1.2 The BtTorrent System Desgn Recprocaton Level The connecton between two peers starts wth a handshake message followed by control and data message exchanges. The control messages between peers n the swarm as well as data messages are transferred over the TCP protocol. The range of TCP ports, whch s used by BtTorrent clents s The connecton between peers s symmetrc and the control messages n both drectons have the same format. The data can flow n ether drecton. The messages that are used n a connecton between two peers are: Handshake: the handshake message s a requred message that ensures connectons from both sdes and must be the frst message that s sent by the peer. Btfeld: the btfeld message s an optonal message and may only be sent after the handshakng sequence s completed, and before any other messages are sent. A peer can choose not to send ths message f t has no peces. Usng a sngle bt for every pece, bts that are set ndcate vald and avalable peces, whch can be shared wth other peers, and bts that are cleared ndcate mssng peces, whch must be downloaded from other peers. Interested: an nterested message s a notfcaton that the sender s nterested n some of the recever s data peces. Not-nterested: a not-nterested message s a notfcaton that the sender s not nterested n any of the recever s data peces. Choke: the term choke s commonly used n BtTorrent as a verb that descrbes a temporary refusal to upload. A choke message s a notfcaton that the sender wll not upload data to the recever untl unchokng happens. Unchoke: An unchoke message s a notfcaton that the sender peer wll upload data to the recever f the recever s nterested n some of the sender s data peces. Request: a request message s used to request a subpece. Pece: a pece message s sent n response to a request message, and contans the requested subpece. Have: a have message descrbes the ndex of a pece that has been downloaded and verfed va the SHA-1 hash functon. Keep-alve: Peers may close the TCP connecton f they have not receved any messages for a gven perod of tme, generally 2 mnutes. Thus, the keep-alve message s sent to keep the connecton between two peers alve, f no message has been sent n a gven perod of tme. Cancel: a cancel message s used to cancel subpece requests. It s mostly sent towards the end of the download process (see more detals n Secton 3.3.3). A peer A n the swarm mantans a 2-bts connecton state for every assocated peer B that t s connected to. The frst bt s the chokng/unchokng bt. The second bt s the nterested/notnterested bt. The connecton state s ntalzed to choked and not nterested. Peer B transfers data to peer A only f the state of the connecton wth A s unchoked and nterested. Peer B responds to peer A s request messages wth encapsulated subpeces n pece messages. After peer A fnshes downloadng a pece, t verfes that the pece s uncorrupted. It calculates the SHA-1 value of the downloaded pece and compares ths value wth the encrypted reference value

8 of the pece that s gven n the metanfo fle. Snce the SHA-1 value s assumed to be unque, a corrupted pece s hash would not match the reference hash value. After verfyng that the pece s uncorrupted, peer A announces that t has the pece to all of ts assocated peers usng the have message. Fgure 2 shows an example of a possble message flow among peers that have an actve connecton n a BtTorrent overlay network. In the example, the connecton s establshed after peer A sends a handshake message, and B responses wth one as well. Then, peer B sends a btfeld message but peer A does not. Such a scenaro mght happen f A has no pece ready to be shared. Peer B sends a not nterested message to A, and A sends a choke message to B. Thus, data wll not flow from peer A to peer B untl both messages are replaced. On the other hand, data does flow from peer B to peer A because peer A sends an nterested message to peer B and peer B sends an unchoked message to peer A. Then, peer A requests subpeces of a partcular pece and B responds wth pece messages, uploadng the requested subpeces. Once peer A obtans the entre pece and confrms the valdty of the pece, t sends have messages to all the peers that t s connected to n the BtTorrent overlay network. Handshake Handshake Btfeld Interested Not nterested Peer A Choked Unchoked Request Pece Request PIece... Request Pece Peer B Peer C Have Have... Fgure 2: An llustratve example for a message flow among peers 3.2 Pece Selecton Mechansms In the BtTorrent system, peers download the data content n a random order, unlke other protocols such as http or ftp, where an end host downloads a fle from begnnng to end. In order to facltate such a downloadng process, when a BtTorrent applcaton s actvated n a peer, the peer frst allocates space for the entre content. Then, the peer tracks the peces that each of ts assocated peers possess. A peer s able to dentfy what peces ts assocated peers have by exchangng btfeld messages upon establshng new connectons and by trackng the have messages that ts assocated peers send after downloadng and verfyng peces. In ths way, a peer s able to select a partcular pece to download from a partcular assocated peer. The pece selecton mechansm s fundamental n achevng effcent P2P networks. A poor selecton strategy can lead to an nablty to download, e.g., when a peer s not nterested n any of the peces ts assocated peers have to offer, and vce versa, t can lead to the nablty to upload,

9 e.g., when all assocated peers are not nterested n the peces that a peer has to offer. More generally, t can prevent the peer selecton mechansm from reachng an optmal system capacty (Legout et al., 2006). BtTorrent apples the strct prorty polcy for subpece selecton. Once the frst subpece of a pece s requested, the strct prorty polcy prortzes subpeces that are part of the same pece. Ths ensures that a complete pece s downloaded as quckly as possble. The pece selecton mechansm n BtTorrent s composed of three dfferent algorthms that are appled n dfferent stages of the downloadng process. The three algorthms are Random Pece Frst, Rarest Pece Frst, and End Game Rarest Pece Frst Selecton The rarest pece s the pece that has the least amount of copes n the peer set. For every pece, the peer mantans a counter of the number of copes that exsts n ts peer set. A peer, whch runs the rarest pece frst selecton algorthm, selects the rarest mssng pece as the next pece to download. If there are multple equally-rare mssng peces, then the peer chooses at random to download one of the rarest peces. A leecher that uses the rarest pece frst algorthm wll: 1. Upload peces that many of the assocated peers are nterested n, such that uploadng can be performed when needed. 2. Increase the lkelhood that peers wll offer peces through the entre downloadng process by leavng peces that are more common to a later download. 3. When downloadng from a seed, a leecher downloads new peces frst, where new peces are those peces that no leecher has. Ths s crucal, especally when the system has a sngle seed that may eventually be taken down, snce ths can lead to the rsk that a partcular pece wll no longer be avalable. Ths s also mportant when the seeds n the system are slower than the leechers n the system. In ths case, a redundant download wastes the opportunty of a seed to upload new peces to assocated peers wth faster uploader speeds. In (Legout et al., 2006), the authors studed the effcency of the rarest pece frst selecton algorthm n BtTorrent. More specfcally, they evaluated the effcency of the rarest pece frst selecton strategy by characterzng the entropy of the system, wth peer avalablty. They defned peer avalablty as the rato of tme that a peer s nterested n ts assocated peer. They showed that the rarest pece frst strategy can acheve a close to deal entropy, when each leecher s almost always nterested n all other leechers Random Pece Frst Selecton The download tme of a random pece wll be shorter on average than the download tme of the rarest pece. A pece that s chosen at random s lkely to be more replcated than the rarest pece, and thus, ts download tme wll be shorter on average by downloadng smultaneously from more peers. Despte ths, the download tme of complete pece may not affect the performance of a peer that uses the rarest-frst pece selecton strategy f the peer has other complete peces to share. However at the begnnng of the downloadng process, a leecher has no peces to share, and thus, the leecher should download peces faster than n the rarest-frst pece selecton strategy, as t s mportant for a new peer to obtan some complete peces and to start recprocate peces. Hence, at the begnnng of the process the peer selects a pece to download at random, whle applyng the random pece frst selecton algorthm. Once the peer downloads C

10 peces that are ready to be shared (C s a constant that may vary n dfferent BtTorrent clent mplementatons), the leecher swtches to the rarest pece frst selecton algorthm End Game Pece Selecton The end game pece selecton algorthm s performed after a peer has requested all the subpeces of the content. In ths phase, a peer sends a request to all of ts assocated peers for all of the pendng subpeces (.e., those subpeces that have not been receved yet). Ths step s performed n order to avod potental delays at the end of the content download, whch can occur f a request has been sent to a peer havng a very slow upload rate nstead of a peer havng a fast upload rate. Snce multple requests for the same subpeces are sent out, once a subpece s downloaded n the end game phase, the peer sends cancel messages to ts assocated peers so they do not waste upload bandwdth by sendng redundant data. The end game s performed at the very end of the process, and thus, t may have only a small mpact on the downloadng process. 3.3 Peer Selecton Mechansms In BtTorrent, peers download from whom they can, and upload smultaneously to a constant number of peers. The number of assocated peers, whch a peer uploads to, s lmted n order to avod sendng data over many connectons at once, whch may result n poor TCP congeston control behavor. Thus, peers need to make decsons on whch peers to unchoke. The default number of peers to unchoke (unchoke slots) s four. However, ths number may ncrease unless a peer s upload bandwdth s saturated. A peer ndependently makes the decson regardng whom to unchoke and whom to choke, n every unchoke perod whch s typcally ten seconds. The peer uploads to unchoked peers for the duraton of the unchoke perod. The peer selecton mechansm, whch s also referred to as the chokng mechansm, can affect the performance of the system. A good chokng mechansm should: 1) Motvate peers to contrbute and upload data to the network, 2) Utlze all avalable resources, 3) Be robust aganst free-rdng behavors where peers only download and do not upload. In BtTorrent, the peer selecton (chokng) mechansm s appled dfferently to peers that are leechers and those that are seeds Leecher s Peer Selecton Mechansm The leecher s peer selecton mechansm has two parts: The TFT mechansm and the optmstc unchoke mechansm The TFT Mechansm In the TFT peer selecton mechansm, a leecher decdes to unchoke peers from whch t currently downloads data. It chooses the peers who have the hghest upload rate. The dea of TFT s to have several connectons that actvely transfer data n both drectons at any tme. In order to avod wastng of resources due to rapdly chokng and unchokng peers, the desgner of the protocol sets the rechoke perod to 10 seconds, clamng that Ten seconds s a long enough perod of tme for TCP to ramp up new transfers to ther full capacty (Cohen, 2003) The Optmstc Unchoke Mechansm

11 BtTorrent apples the optmstc unchoke mechansm n parallel wth the TFT mechansm. The goals of the optmstc unchoke mechansm are: 1) to enable a contnuous dscovery of better peers to recprocate wth, 2) to bootstrap new leechers that do not have any content peces to download some data and start recprocate peces wth others. The optmstc unchoke mechansm chooses to unchoke a peer randomly regardless of ts current upload rate. Optmstc unchoke s rotated every optmstc unchoke perod, when an optmstcally unchoked peer s unchoked for the entre optmstc unchoke perod. The desgner of the protocol chose the optmstc unchoke duraton to be 30 seconds, because 30 seconds s enough tme for the upload to get to full capacty, for the download to recprocate, and fnally for the download to get to full capacty. Optmstc unchoke s typcally appled on a sngle unchoke slot whle TFT s appled on the rest of the unchoke slots Ant-snubbng If a peer has receved no data from a partcular peer for a certan perod of tme, typcally 60 seconds, t marks the partcular peer s connecton as snubbed. A peer does not upload to an assocated snubbed peer through the TFT peer selecton mechansm. Ths may result n more than one smultaneous optmstc unchoke, when the peer s choked by many of ts assocated peers. In such a case, the peer may experence poor download rates untl the optmstc unchoke fnds better peers. Thus, ncreasng number of optmstc unchokes n ths scenaro s mportant Seed s Peer Selecton Mechansm Seeds, whch do not need to download any peces, follow a dfferent chokng mechansm than the leechers. The most common mechansm s based on a round-robn mechansm, whch strves to dstrbute data unformly Modelng the Peer Selecton Mechansm Many researchers studed the chokng mechansm n BtTorrent by suggestng mathematcal and game theoretcal models. Qu & Srkant (2004) studed a flud analytcal model of BtTorrent systems. They analytcally studed the chokng mechansm and nvestgated how t affects the peer performance. They showed that the optmstc unchoke mechansm may allow free-rdng. Fan et al. (2006) characterzed the desgn space of BtTorrent-lke protocols capturng the fundamental tradeoff between performance and farness. Other works such as (Izhak-Ratzn, 2009; Izhak-Ratzn et al., 2009; Negla et al., 2007) model the chokng mechansms n BtTorrent as games wth strategc peers. Massoulé & VojnovĆ (2005) ntroduced a probablstc model of coupon replcaton systems, and they argued that performance of fle sharng system such as BtTorrent does not depend crtcally on altrustc behavor or on pece selecton strategy (e.g., the rarest frst algorthm). Levn et al. (2008) presented an aucton based model of the peer selecton mechansm. They clamed that the nsght behnd ther model s that BtTorrent uses an aucton model to decde whch peers to unchoke and not to tt-for-tat as wdely beleved. 3.4 Lmtatons of BtTorrent Systems In addton to the analytcal models of BtTorrent, some measurement studes have been performed (Guo et al, 2005; Izal et al., 2004; Pouwelse et al., 2005; Patek et al., 2007; Patek et al., 2008). Most of these studes were performed on peers that were connected to publc torrents. These studes provde nterestng results about the overall behavor of deployed BtTorrent

12 systems. The studes also pnpont several lmtatons of the BtTorrent protocol. In ths secton, we dscuss two of the lmtatons of BtTorrent protocol that were shown n these studes: 1) The feasblty of free-rdng, 2) The lack of farness Free-Rdng n BtTorrent Systems Free rders are the peers who attempt to crcumvent the protocol mechansm and download data wthout uploadng data to other peers n the network. Researchers have argued that freerdng n BtTorrent s feasble through the optmstc unchoke mechansm and through seeds. The frst to pnpont that effectve free-rdng n BtTorrent s feasble was Shnedman et al. (2004). They brefly descrbed a scenaro n whch peers can attack the tracker whle they explot nvolved leechers by lyng about the peces they have. Jun et al. (2005) also argued that freerdng s feasble n BtTorrent by nvestgatng the ncentves n BtTorrent chokng mechansm. Logkas et al. (2006) showed that free-rdng n BtTorrent s feasble by mplementng three selfsh BtTorrent explots that allow free-rders to acheve hgh download rates and evaluate ther effectveness under specfc crcumstances. Locher et al. (2006) extended these results and presented the BtThef, a free-rdng clent that combnes several attacks. They demonstrated that free-rdng s feasble even n the absence of seeds. More recently, Srvanos et al. (2007) evaluated an explot based on mantanng a larger-than-normal vew of the system, whch affords free-rders a much hgher probablty of recevng data from seeds and optmstc unchokes. They argued that the large vew explot s effectve and has the potental for wde adopton. Wde adopton of free-rdng strategy can result n a tragedy of the commons, where overall performance n the system wll decrease. Several works have attacked the ablty of free-rders to download data from seeds wthout uploadng n return, ntendng to consderably hurt free-rders performance. Locher et al. (2007) proposed a source-codng scheme. Seeds n ths scheme only upload a fxed number of content peces to each leecher they connect to, thereby placng a hard lmt on the data that free-rders can obtan n ths manner. Chow et al. (2008) presented an alternatve modfed seed unchokng algorthm that gves preference to leechers that are ether at the begnnng or the end of ther download. Complementary to these approaches that modfy the seed strategy, other works suggested to replace or lmt the optmstc unchokes. Izhak-Ratzn et al. (2009) suggested a team mechansm that lmts the optmstc unchokes as the collaboraton wth peers havng smlar upload rate ncreases. A foresghted resource recprocaton mechansm was suggested n (Izhak-Ratzn et al., 2009b) to replace the chokng mechansm n BtTorrent. Fnally, reputaton systems such as (Buchegger & Le Boudec, 2004; Xong & Lu, 2004; Yang et al., 2005) that use a peers reputaton hstory to make the chokng decson were also suggested n order to help lmt the ablty to free-rde Lack of Farness n BtTorrent Systems Farness n BtTorrent s commonly defned as receve as much as they gve. Farness among peers partcpatng n content dstrbuton encourages peers to actvely collaborate n dssemnatng content. Thus, farness s an mportant factor, whch can lead to mproved system performance. However, research studes, such as (Guo et al., 2005; Patek et al., 2007; Bharambe et al., 2006; Legout et al., 2007), show that BtTorrent does not provde far resource recprocaton, especally n node populatons wth heterogeneous upload bandwdths. Two of the

13 mechansms that contrbute to the lack of farness are the TFT and optmstc unchoke mechansms, whch are used for peer selecton n BtTorrent. The TFT mechansm s based on a short-term hstory,.e., upload decsons are made based on the most recent observatons of resource recprocaton. Thus, a peer can follow the TFT polcy only f t contnuously uploads peces of a partcular fle and as long as t receves peces of nterest n return. However, ths s not always possble because peers may not have any peces that other peers are nterested n, regardless of ther wllngness to cooperate (Patek et al., 2008). Ths behavor s stll perceved as a lack of cooperaton. The mpact of optmstc unchokes on farness n the BtTorrent system s shown n Fgure 3 [the Fgure s taken from (Izhak-Ratzn, 2009)], whch shows the mpact of optmstc unchokes on the expected download rate as a functon of the peer s upload rate. The peer upload rate dstrbuton s based on observed bandwdth dstrbuton gven n (Patek et al., 2007). It s assumed that one unchoke slot s used by the optmstc unchoke mechansm, and that the regular unchoke mechansm works perfectly n terms of farness,.e., the download rate and the upload rate through TFT unchokes are equal. Clearly, we can see that the sub-lnear behavor of the expected download rate leads to unfarness for hgh capacty leechers that are forced to nteract wth low-capacty peers, and low-capacty leechers that beneft from ths unfarness. Note that n the observed bandwdth dstrbuton, the majorty of the leechers are low-capacty leechers wth 88% of the leechers havng less than 300KB/s upload capacty. Expected download rate (KB/sec) optmal download rate expected download rate Upload capacty (KB/sec) Fgure 3: Upload and download n BtTorrent network Fnally, the number of unchoke slots may also lead to a lack of farness n BtTorrent. The number of unchoke slots that a leecher uses for regular unchoke s a functon of the leecher s ablty to fully utlze ts upload capacty. Ths agan may lead to unfarness, snce typcally, n real torrents, the download capacty of a leecher may be greater than the upload capacty. Thus,

14 hgh capacty leechers may upload n full capacty, but not be able to download as much, due to upload constrants of the downloadng leechers and lmted number of unchoke slots. Farness n BtTorrent systems has been largely dscussed n the lterature. Guo et.al. (2005) performed extensve measurements of real torrents and pnponted several BtTorrent lmtatons ncludng lack of farness. Bharambe et al. (2006) utlzed a dscrete event smulator to evaluate the mpact of BtTorrent s mechansms such as the peer selecton mechansm, and observed that rate-based TFT ncentves cannot guarantee farness. They suggested a block-based TFT polcy to mprove farness. Legout et al. (2007) studed clusterng of peers havng smlar upload bandwdth. They observed that when the seed s underprovsoned, all peers tend to complete ther downloads approxmately at the same tme, regardless of ther upload rates. Moreover, hghcapacty peers assst the seed to dssemnate data to low-capacty peers. Patek et al. (2007), observed through extensve measurement on real torrents the presence of sgnfcant altrusm, where peers make contrbutons that do not drectly mprove ther performance. They proposed the BtTyrant clent, whch adopts a new peer selecton mechansm that reallocates upload bandwdth to maxmze peers download rates. Izhak-Ratzn (2009) dentfed the potental of there beng a sgnfcant dfference between a leecher s upload and download rates and proposed the Buddy protocol that matches peers wth smlar bandwdth. Other researchers acknowledged the mportance of cooperaton ncentves through addtonal reputaton mechansm. Anagnostaks & Greenwald (2004) extended BtTorrent s ncentves to n way exchange among rngs of peers, provdng ncentve to cooperate. Later, Lan et al., (2006) proposed mult-level TFT ncentves as a hybrd between prvate and shared hstory schemes. More recently, Patek et al., (2008) proposed a one-hop reputaton system, n whch peers that are not nterested n the current avalable content perform data exchanges for the assurance of future payback. 4. P2P-BASED MEDIA STREAMING 4.1 Challenges and Requrements for Meda Streamng As dscussed n Secton 3, several protocols and ncentve mechansms have been developed for effcent data dssemnaton over P2P networks. However, they may only provde a lmted performance for meda streamng, because meda streamng needs much more consderaton such as real-tme and hgh bandwdth requrements than general data dssemnaton. Extensve studes on vdeo transmsson over IP multcast have dscussed n the lterature (e.g., Lu et al., 2003; van der Schar & Chou, 2007), and varous P2P based overlay multcast systems have also been recently proposed (e.g., Zhang et al., 2005; Lang et al., 2009; Ln et al., 2009). Unlke proxyasssted overlay multcast systems, where several proxes are coordnated and placed such that an effcent overlay can be constructed (Zhuang et al., 2001; Guo et al., 2004; Hefeeda et al, 2004; Sh & Turner, 2002), the P2P based systems do not need such dedcated nodes and coordnaton. Rather, these systems consst of autonomous and often self-nterested nodes that self-organze nto groups, exchange nformaton, and share ther data. Desgnng effcent protocols and mechansms for the meda streamng applcatons over P2P networks s challengng, because:

15 the real-tme and contnuous delvery of content to a large number of partcpants should be supported n dynamcally changng network condtons and groups of nteractng peers, and a hgher bandwdth s requred n general. Therefore, the meda streamng applcatons requre dfferent desgn rules and approaches that consder such requrements. For example, the objectve of the fle sharng applcatons such as BtTorrent s to completely download the content data as fast as possble. Therefore, the tmely downloadng of data objects s not crtcal. Rather, downloadng data objects that can be rarely found s more mportant. However, meda streamng applcatons should consder strngent realtme constrants. Thus, a mechansm that enables peers to download data objects that meet the playback deadlne s requred, such that meda streamng s unnterrupted. Second, each data object has an equal mportance for fle sharng P2P applcatons, as all the data objects should be completely downloaded. However, for meda streamng applcatons, each data object has dfferent mportance based on the codng structure, playback deadlne, etc. Thus, data objects that have hgher qualty mpact or that have strngent playback deadlne can have hgher prorty. Therefore, packet prortzaton and schedulng mechansms should be developed n the meda streamng applcatons over P2P networks. Fnally, a mechansm that provdes graceful qualty degradaton also needs to be mplemented, whch enables adaptve and flexble meda streamng n dynamc networks where heterogeneous peers havng dfferent bandwdth nteract wth each other. In order to address these challenges, several solutons for meda streamng have been proposed n the lterature (see e.g., Vlavanos et al., 2006; Zhang et al., 2006; Banerjee et al., 2002; Castro et al., 2003; Deshpande et al., 2001; Trans et al., 2004; Heffeeda et al., 2003; Kostc et al., 2003; Pa et al., 2005; Padmanabhan et al., 2003; Tan et al., 2005; Venkataraman et al., 2006; Zhang et al., 2005b). The mplementaton of these solutons vares dependng on ther focuses, whch can be broadly classfed as 1) peer clusterng strateges, 2) overlay constructons and 3) ncentve strateges on resource recprocatons. 4.2 Peer Clusterng Strateges Several approaches for effcent and relable delvery of meda streams over P2P networks have focused on developng peer clusterng strateges. As dscussed, the meda content s drectly shared by peers nteractng wth each other. Hence, t s mportant to select good peers and form clusters (or groups) wth them. For example, Purandare & Guha (2007) proposed that peers can form groups based on allance formaton process, where ths process consders the tme and resource constrants. In (Venkataraman et al., 2006), the partcpatng nodes form a graph, where the degree of the graph s determned proportonally to ts desred transmsson load. In addton, several other strateges such as SpreadIt (Deshpande et al., 2001), NICE (Banerjee et al., 2002), and ZIGZAG (Banerjee et al., 2002) have been proposed, where these algorthms perform herarchcally from clusters such that a mnmzed transmsson delay can be acheved. In order to enhance the effcency and robustness of the meda delvery, varous codng structures and packetzng strateges can also be mplemented n conjuncton wth the abovementoned clusterng strateges. For nstance, Multple Descrpton Codng, or MDC (Goyal, 2001), s an llustratve example of codng structure for P2P based meda delvery, and ts deployment for meda delvery has been studed n e.g., Padmanabhan et al., 2003; Padmanabhan

16 et al., 2002b; Chu et al., 2004; L et al., Alternatvely, network codng technques are also deployed for effcent meda delvery (e.g., Nguyen et al., 2007; Wang & L, 2007; Wang & L, 2007b; Gkantsds & Rodrguez, 2005). 4.3 Overlay Constructons: Tree-based and Data-drven Approaches Tree-based Approach: Descrpton One of desgn approaches of data dssemnaton over P2P networks s based on tree structure. In ths approach, peers are organzed nto tree structure, where each peer s partcpatng n dssemnatng data. In general, peers (or nodes) n the tree are herarchcally organzed (.e., parent chldren node relatonshp) and data s dssemnated by typcally push-based approach, where the data s forwarded from parent nodes to chldren nodes. Because the data s dssemnated n a structured way, t s mportant to 1) desgn optmal tree constructons that provde an effcent performance to each peer, 2) develop approaches for tree constructon that are robust to nodes (unexpected) jonng and leavng trees and provde easy tree repar, and 3) construct non-cyclc trees,.e., trees that have no loops. Note that one of the major concerns n ths approach s the falure of nodes. If a node cannot approprately perform forwardng data due to node crash or node malfuncton, ts chldren nodes n the tree receve no data packets, resultng n sgnfcantly poor performance. Moreover, snce a sgnfcantly large number of nodes are located n the end of the trees, an effcent utlzaton of outgong bandwdth of them s challengng. In order to address these ssues, several approaches have been proposed (e.g., Chu et al., 2000; Deshpande et al., 2001; Padmanabhan & Srpandkulcha, 2002; Padmanabhan et al., 2002b; Padmanabhan et al., 2003; L et al., 2004). In order to successfully mplement the tree-based approaches, the followng mechansms have been proposed Group Management Mechansm To mantan a robust and effcent tree, each peer (or node) may need the nformaton about a set of other nodes and the path from a source. Peers n a tree keep exchangng the nformaton that they have, whch may nclude the group member nformaton, and thus, they can have updated nformaton about the tree. The nformaton exchange can be mplemented based on gossp-lke protocols (e.g., End System Multcast, ESM, (Chu et al., 2000)). Peers already partcpatng n a tree can swtch ther parent nodes f the performance (e.g., download rates) acheved n a current poston s not satsfed. If a peer newly jons the network (.e., a tree), t contacts the server, and obtans the (partal) nformaton about the exstng peers and the correspondng paths. Then, the peer can determne ts parent nodes. Fnally, the records of peers that left the tree are smply removed from the group member lst Parent Selecton Algorthm As dscussed, the way of selectng parents s mportant for both peers n a tree and newly jonng peers. In order to select the parent nodes, a peer can contact a node that s randomly chosen from

17 ts group member lst. Then, t retreves the nformaton that ncludes the currently acheved performance, the number of chldren nodes, etc. from the contacted node, whle estmatng the round-trp tme. The peer evaluates the contacted node only f the contacted node s not ncluded n ts chldren nodes, and the contacted node has not exceeded ts chldren nodes lmt. The evaluaton of the contacted node can nclude the achevable performance and nduced delay. Several crtera can be deployed n order to evaluate the node based on goals of applcatons. For fle sharng applcatons, the performance (.e., bandwdth) can be one of the most mportant crtera. For meda streamng applcatons, however, the delay may be the most mportant crteron for parent selecton. Alternatvely, the obtaned meda qualty can also be a crteron for parent selecton (Park and van der Schaar, 2009d) Data-drven Approach Alternatve approaches for data dssemnaton over P2P networks are based on data-drven structures (Pa et al., 2005; Zhang et al., 2005). Unlke the tree-based structures, where welldesgned trees need to be constructed and contnuously mantaned for effcent data dssemnaton n dynamcally changng networks, data-drven approaches focus on 1) how to effcently exchange nformaton about the data avalablty, 2) how to form groups of peers and share ther data, and 3) how to develop group management algorthms and schedulng algorthms. In data-drven approaches, a newly generated data of a peer can be forwarded to ts randomly selected neghbor nodes, and the neghbor nodes also forward the data to ther neghbor nodes, whch can be contnued. Fnally, the messages can be dstrbuted to all the nodes. Ths approach can be mplemented based on gossp algorthms (Eugster et al., 2004). Whle such random push approaches enable the P2P systems to be robust to the random node falures, whch s one of challenges for tree-based approach, these approaches may result n sgnfcant redundancy for recevng nodes (Gkantsds et al., 2004). In order to reduce the redundancy, pull-based technques are proposed (Cohen, 2003; Pa et al., 2005; Zhang et al., 2005). In pull-based technques, peers self-organze nto groups and each peer requests necessary data packets from other peers n ts group. Thus, each peer can avod recevng redundant packets from ts neghbor peers. The metadata that may nclude nformaton about the peers can be downloaded from a server (e.g., trackers n BtTorrent systems), and then, each peer forms a group (e.g., swarm) wth the other randomly selected peers or jons an exstng group. The groups can be mantaned by perodcally exchangng the nformaton about data avalablty wth the group members. Ths approach has been actually mplemented n BtTorrent (Cohen, 2003), and has shown effcent performance for general fle sharng. In ths example, a source dstrbutes ts content to peer A and peer B, and then, they exchange the content wth ther group members. Note that peer C also has ts own group (whch s not shown n ths example), whch also ncludes peer A. However, ths approach cannot be drectly deployed for meda streamng applcatons that requre explct playback deadlnes, unless approprate schedulng algorthms are mplemented. Thus, for effcent meda streamng over P2P networks based on data-drven approaches, several approaches have been proposed n (Pa et al., 2005; Zhang et al., 2005), where they explctly

18 mplement schedulng algorthms. These mechansms that support the data-drven approaches are dscussed next Group Management Mechansm One of the key mechansms requred for data-drven approaches s the group management mechansm, whch enables peers to mantan ther groups, such that they can contnuously exchange necessary data packets among the peers. For newly jonng peers, they can contact a server to obtan an ntal set of group member canddates (e.g., End System Multcast (Chu et al., 2000), BtTorrent, CoolStreamng (Zhang et al., 2005)). Based on the ntal nformaton, each peer can form a group wth partal set of peers or jon an exstng group. Then, each peer mantans ts group by exchangng the nformaton about the data avalablty. For example, CoolStreamng deploys an exstng gossp membershp protocol for exchangng the nformaton about the data avalablty, whch s referred to as membershp message. The nformaton s generated based on a Buffer Map (BM) that represents actve data segments. More detals about the BM are dscussed next Prortzaton and Schedulng Mechansms Unlke fle sharng applcatons, t s crtcal for meda streamng applcatons to delver data segments tmely and contnuously. Thus, pece selecton mechansm (.e., the rarest frst mechansm) mplemented n BtTorrent systems can only provde lmted performance, as t does not consder the prorty of each data segment when t s downloaded. In order to explctly consder the prorty of data segments, schedulng mechansms can be deployed. For example, n CoolStreamng, a sldng wndow (see Fgure 4), or BM, s used, whch conssts of 120 segments that correspond to 120 seconds of meda data (.e., 1 segment ncludes meda data of 1 second). In ths llustraton shown n Fgure 4, the peer s focusng on downloadng the segment that s not n the wndow (empty segment) wth the hghest prorty at ths playback pont. Meda Segments Playback pont Sldng wndow Fgure 4. Sldng wndow n schedulng mechansms Thus, the schedulng algorthms should be desgned whle takng nto account the playback deadlne (.e., prorty) for each segment, and the avalable upload bandwdth of assocated peers. Ths s because peers n a P2P system may be heterogeneous, havng dfferent upload bandwdth, etc. In CoolStreamng, a smple and heurstc algorthm has been proposed Group Update Mechansm In general P2P systems, peers can leave the systems, and thus, leave ther groups, at any tme, whch changes the groups that the peers have been assocated. Thus, an effcent group update

19 mechansm needs to be deployed, such that peers can easly capture the group changes and effcently respond to the changes. Ths may nclude an effcent reschedulng algorthm for data segment request, and the exchanged nformaton about data avalablty that can be used. For nstance, n CoolStreamng, the groups are perodcally updated by randomly contactng peers n local membershp lst, and the reschedulng algorthms are performed based on exchanged BM nformaton. 4.4 Incentves for Resource Recprocaton Whle several approaches dscussed n the prevous sectons provde effcent solutons to meda streamng over P2P networks, they are desgned based on an mplct assumpton that peers are uncondtonally cooperatve and collaboratve they are wllng to provde correct and true nformaton, exchange and share ther resource actvely, by honestly followng the pre-desgned protocols. However, n realty, ths s not always true. Rather, peers are often self-nterested and are tryng to maxmze ther own benefts (e.g., download rates, meda qualty, etc.) by devatng from the pre-determned rules n the systems. One of the representatve examples for selfnterested behavors of peers s the free-rdng, whch s dscussed n Secton 3. The free-rders may not contrbute ther resources whle downloadng content from the other peers (data-drven approach), or they try to become leaf nodes by ntentonally announcng that ther upload bandwdth s poor. Moreover, t has been observed from several P2P based systems that the majorty of uploadng requests are concentrated on a small set of peers (Al et al., 2006; Adar & Huberman, 2000), whch may prevent potentally cooperatve peers from actvely contrbutng ther resources. One of the reasons why such behavors that can result n sgnfcant degradaton of both the system and ndvdual peers performance are allowed s the lack of well-desgned ncentve mechansms. In order to provde ncentves for each peer s contrbuton, smple ncentve mechansms have been developed based on TFT strategy for a general fle sharng n BtTorrentlke protocols (e.g., Cohen, 2003; Legout et al., 2006; Patek et al., 2007) or for a meda streamng n BToS (Vlavanos et al., 2006). Incentves can also be provded based on each peer s reputatons, whch can be managed n varous ways (e.g., Credence (Walsh & Srer, 2006), DARWIN (Jaramllo & Srkant, 2007), EgenTrust (Kamvar et al., 2003), PeerTrust (Xong & Lu, 2004), DCRC and CORC (Gupta et al., 2003), Despotovc & Aberer, 2005). Fnally, several game theoretc approaches have been adopted for provdng ncentves (see e.g., Chen et al., 2007; Fan et al., 2006; Zhang et al., 2007; Buragohan et al., 2003; Jun & Ahamad, 2005; La et al., 2003; Golle et al., 2001; Feldman et al., 2004; Park & van der Schaar, 2009; Park & van der Schaar, 2009c). Whle smple ncentve mechansms have been developed and deployed n practce (e.g., TFT strategy n practcal BtTorrent systems), t s stll reported that exstng ncentve mechansms do not effcently prevent such self-nterested behavors n P2P systems. In the next secton, we wll dscuss recently proposed game theoretc approaches for ncentve mechansms n detal, whch model the resource recprocaton among self-nterested peers as a stochastc game and fnd an optmal strategy that maxmzes each peer s long term beneft n P2P systems 5. FORESIGHTED RESOURCE RECIPROCATION STRATEGIES

20 5.1 Challenges of Incentve Desgn Cooperaton and Competton As dscussed n Secton 4, one possble soluton for provdng cooperaton ncentves s the TFT strategy, whch has been actually mplemented n practcal fle sharng P2P systems such as BtTorrent. The TFT strategy s deployed n BtTorrent as a chokng algorthm, whch effectvely encourages peers cooperaton and penalzes peers selfsh behavors (see Secton for more detal). Whle t has been shown that ths strategy performs effectvely n varous P2P network scenaros, t may not completely elmnate selfsh behavors such as free-rdng (Logkas et al., 2007; Locher et al., 2006; Srvanos et al., 2007). Moreover, the resource recprocaton based on TFT s myopc, because a peer unchokes some of ts assocated peers (.e., leechers) that are currently uploadng at the hghest rates. Thus, the resource recprocaton decsons based on TFT may not provde optmal solutons that maxmze the long-term rewards. Snce peers n P2P networks are generally nvolved n repeated and long-term nteractons, such myopc decsons on peer selecton and bandwdth allocaton can result n a sub-optmal performance for the nvolved peers. Fnally, the TFT strategy n BtTorrent s based on the equal upload bandwdth dstrbuton (Cohen, 2003; Legout et al., 2007) whch s nether a far nor an optmal resource allocaton for heterogeneous content and dverse peers wth dfferent upload/download requrements (Park & van der Schaar, 2007). To address these challenges, a foresghted resource recprocaton strategy has been recently proposed, whch enables the peers to determne ther resource recprocaton decsons that maxmze a long-term utlty. The nteractons among the peers are modeled as a stochastc game, where they determne ther resource dstrbutons by consderng the probablstcally changng future behavors of ther assocated peers. The resource recprocaton process of a peer s modeled as a Markov Decson Process (MDP), and the foresghted resource recprocaton strategy s obtaned by solvng the MDP. It has been shown that the foresghted strategy provdes mproved performance compared to exstng ncentve mechansms n BtTorrent or heurstc algorthms n several meda streamng approaches (e.g., Lee et al., 2009). 5.2 Formalzaton of Resource Recprocaton as Stochastc Games Group-based Resource Recprocaton Resource recprocaton games n P2P networks are played by the peers nterested n each other's meda content. A resource recprocaton game s played n a group, where a group conssts of a peer and ts assocated peers. The group-based resource recprocaton has been dscussed n the lterature, where a group could be formed of swarms (Cohen, 2003; Legout et al., 2006), partnershps (Zhang et al., 2005), or neghbors (Pa et al., 2005). The group members assocated wth a peer s denoted by C, where a peer k Î C also has ts own group C k whch ncludes peer. Due to the dynamcs ntroduced by peers jonng, leavng, or swtchng P2P networks, the nformaton about groups needs to be regularly (perodcally) updated or t needs to be updated when group dynamcs change (Cohen, 2003; Legout et al., 2006). Ths process s shown n Fgure 5. In ths dagram, the group dynamcs change when group members are changed or ther behavor are changed, etc. Moreover, resource recprocaton n Fgure 5 may nclude several modules for ts actual mplementaton, such as an estmaton of the state transton probablty and a level of accuracy for behavor estmaton. These wll be dscussed n the followng sectons.