Network Working Group L. Chen Internet-Draft Peking University & Yale Intended status: Informational University Expires: September 1, 2010 H. Song Huawei February 28, 2010 A Survey of Resource Control in P2P Systems draft-chen-decade-resource-control-survey-00 Abstract This document describes the resource control mechanisms utilized by existing P2P applications. The intent of this document is to generate discussion in the community about resource control and provide guidance for DECADE requirements. For example, some of these resource control functions could be supported DECADE to enable better usability of in-network storage for a wide range of P2P applications. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Chen & Song Expires September 1, 2010 [Page 1] Internet-Draft Resource Control in P2P Systems February 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Survey Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 4 2.2. Resource Control Components . . . . . . . . . . . . . . . 5 2.2.1. Total Upload/Download Bandwidth Control . . . . . . . 5 2.2.2. Upload/Download Bandwidth Control of A Single Task . . 5 2.2.3. Remote/Local Connection Control . . . . . . . . . . . 5 2.2.4. Parallel Connection Control of A Single Task . . . . . 6 2.2.5. Connection Port Assignment . . . . . . . . . . . . . . 6 2.2.6. Cache Size Control . . . . . . . . . . . . . . . . . . 6 2.2.7. Access Control . . . . . . . . . . . . . . . . . . . . 6 2.2.8. Priority Mechanism . . . . . . . . . . . . . . . . . . 6 3. BitComet . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Total Upload/Download Bandwidth Control . . . . . . . . . 7 3.2. Upload/Download Bandwidth Control of A Single Task . . . . 7 3.3. Remote/Local Connection Control . . . . . . . . . . . . . 7 3.4. Parallel Connection Control of A Single Task . . . . . . . 7 3.5. Connection Port Assignment . . . . . . . . . . . . . . . . 7 3.6. Cache Size Control . . . . . . . . . . . . . . . . . . . . 7 3.7. Access Control . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Priority Mechanism . . . . . . . . . . . . . . . . . . . . 8 4. eMule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Total Upload/Download Bandwidth Control . . . . . . . . . 8 4.2. Upload/Download Bandwidth Control of A Single Task . . . . 8 4.3. Remote/Local Connection Control . . . . . . . . . . . . . 8 4.4. Parallel Connection Control of A Single Task . . . . . . . 9 4.5. Connection Port Assignment . . . . . . . . . . . . . . . . 9 4.6. Cache Size Control . . . . . . . . . . . . . . . . . . . . 9 4.7. Access Control . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Priority Mechanism . . . . . . . . . . . . . . . . . . . . 9 5. EMS (End System Multicast) . . . . . . . . . . . . . . . . . . 9 5.1. Total Upload/Download Bandwidth Control . . . . . . . . . 9 5.2. Upload/Download Bandwidth Control of A Single Task . . . . 10 5.3. Remote/Local Connection Control . . . . . . . . . . . . . 10 5.4. Parallel Connection Control of A Single Task . . . . . . . 10 Chen & Song Expires September 1, 2010 [Page 2] Internet-Draft Resource Control in P2P Systems February 2010 5.5. Connection Port Assignment . . . . . . . . . . . . . . . . 10 5.6. Cache Size Control . . . . . . . . . . . . . . . . . . . . 10 5.7. Access Control . . . . . . . . . . . . . . . . . . . . . . 10 5.8. Priority Mechanism . . . . . . . . . . . . . . . . . . . . 10 6. CoolStreaming . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Total Upload/Download Bandwidth Control . . . . . . . . . 10 6.2. Upload/Download Bandwidth Control of A Single Task . . . . 11 6.3. Remote/Local Connection Control . . . . . . . . . . . . . 11 6.4. Parallel Connection Control of A Single Task . . . . . . . 11 6.5. Connection Port Assignment . . . . . . . . . . . . . . . . 11 6.6. Cache Size Control . . . . . . . . . . . . . . . . . . . . 11 6.7. Access Control . . . . . . . . . . . . . . . . . . . . . . 11 6.8. Priority Mechanism . . . . . . . . . . . . . . . . . . . . 11 7. SplitStream . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Total Upload/Download Bandwidth Control . . . . . . . . . 12 7.2. Upload/Download Bandwidth Control of A Single Task . . . . 12 7.3. Remote/Local Connection Control . . . . . . . . . . . . . 12 7.4. Parallel Connection Control of A Single Task . . . . . . . 12 7.5. Connection Port Assignment . . . . . . . . . . . . . . . . 12 7.6. Cache Size Control . . . . . . . . . . . . . . . . . . . . 12 7.7. Access Control . . . . . . . . . . . . . . . . . . . . . . 12 7.8. Priority Mechanism . . . . . . . . . . . . . . . . . . . . 12 8. PPLive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Total Upload/Download Bandwidth Control . . . . . . . . . 13 8.2. Upload/Download Bandwidth Control of A Single Task . . . . 13 8.3. Remote/Local Connection Control . . . . . . . . . . . . . 13 8.4. Parallel Connection Control of A Single Task . . . . . . . 13 8.5. Connection Port Assignment . . . . . . . . . . . . . . . . 13 8.6. Cache Size Control . . . . . . . . . . . . . . . . . . . . 13 8.7. Access Control . . . . . . . . . . . . . . . . . . . . . . 13 8.8. Priority Mechanism . . . . . . . . . . . . . . . . . . . . 14 9. Donnybrook . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Total Upload/Download Bandwidth Control . . . . . . . . . 14 9.2. Upload/Download Bandwidth Control of A Single Task . . . . 14 9.3. Remote/Local Connection Control . . . . . . . . . . . . . 14 9.4. Parallel Connection Control of A Single Task . . . . . . . 14 9.5. Connection Port Assignment . . . . . . . . . . . . . . . . 14 9.6. Cache Size Control . . . . . . . . . . . . . . . . . . . . 15 9.7. Access Control . . . . . . . . . . . . . . . . . . . . . . 15 9.8. Priority Mechanism . . . . . . . . . . . . . . . . . . . . 15 10. Recommendations and Conclusions . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 14.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Chen & Song Expires September 1, 2010 [Page 3] Internet-Draft Resource Control in P2P Systems February 2010 1. Introduction DECADE (DECoupled Application Data Enroute) is an architecture that provides applications with access to in-network storage. Though DECADE may be useful in many contexts, a primary target is P2P applications. P2P applications can have their own application goals and requirements with respect to sharing data. As a simple example, BitTorrent clients share upload bandwidth with a fixed number of peers to achieve a "tit-for-tat" policy. Other applications may have different requirements related to access control or the resources used to distribute data. Put another way, this document intends to identify the set of "knobs" that P2P applications utilize to achieve their policies/requirements. If DECADE is able to support the same types of resource control, then these applications can better integrate with DECADE. If certain types of resource control are not supported, it should be a conscious decision (e.g., due to implementation complexity or scalability). This document will be updated to provide recommendations for the design of DECADE. This document will give an overview of the common resource control mechanisms first in Section 2.2, and then survey the mechanisms used by several well-known P2P applications in the following sections. These P2P applications span use cases from file-sharing, to streaming and gaming. Finally, recommandations and conclusions are in Section 10. There are also some control operations to tasks, such as PAUSE, STOP and RESTART, which should also be supported between P2P client and a media source, but that is beyond the scope of this document and DECADE. 2. Survey Overview 2.1. Terminology and Concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses terms defined in [I-D.song-decade-problem-statement]. This document also uses the following terminologyies that are widely used by various P2P applications: Chen & Song Expires September 1, 2010 [Page 4] Internet-Draft Resource Control in P2P Systems February 2010 Task: A unit of work done by a P2P application, such as downloading a file or a stream. Resource: Resource is taken in this document to mean system resources (e.g., sockets, disk space, memory, etc) and network resources (e.g., bandwidth, etc) available to a user. 2.2. Resource Control Components Before surveying individual technologies, we describe the basic resource control components of P2P systems. This set of components strives to describe the complete set of resource control "knobs" used by existing P2P systems. 2.2.1. Total Upload/Download Bandwidth Control Each user has a limited uplink bandwidth and downlink bandwidth. Bandwidth is an important resource of a peer in content distribution P2P systems and can significantly affect peer performance. In this survey, we focus on the bandwidth control of a peer (client), especially the upload bandwidth control. Upload bandwidth control is more commonly used by P2P applications but download bandwidth control also benefits a user by allowing some bandwidth to be reserved (e.g., for web surfing or when downloading several files at the same time). 2.2.2. Upload/Download Bandwidth Control of A Single Task P2P applications may control the uploading or downloading speed of a single task, because if one task consumes too much bandwidth, other tasks may have less. For example, user may prioritize downloading of a video that he or she wishes to watch sooner. And one user may also share more upload bandwidth to a remote peer which contributes more data. 2.2.3. Remote/Local Connection Control P2P applications control the total number of remote and local connections. Controlling this parameter is important due to the total bandwidth constraint and the overhead of maintaining these connections. We refer to the connections which are connected within a local area network as "local connections"; other connections are referred to as "remote connections." The total amount of the connections has an impact on how many tasks should be running parallel and how many connections per task should have. In this survey, we focus on the control of the number of connections in a peer (client). Chen & Song Expires September 1, 2010 [Page 5] Internet-Draft Resource Control in P2P Systems February 2010 2.2.4. Parallel Connection Control of A Single Task The download/upload speed may be faster if a single task has more parallel connections. However, the amount of parallel connections of a single task has an impact on the performance of other tasks on the same peer. They may compete for bandwidth resources if there are too many parallel connections. 2.2.5. Connection Port Assignment Some P2P systems may provide the capability to assign a particular or random port for incoming TCP/UDP connections. 2.2.6. Cache Size Control A temporal storage is used to cache data that has been downloaded or data waiting to be uploaded. This temporal storage can be in memory, disk, or both. The size of the cache may differ across P2P applications depending on requirements. In this survey, we focus on the cache size of a peer (client). The memory cache can avoid frequent read/write to the hard disk. However, some P2P applications, e.g. PPStream, use disk cache to share large streaming files between clients. 2.2.7. Access Control A user is able to authorize individual users to retrieve certain locally-stored content. For example, a peer can set its sharing strategy for sharing only to friends or sharing to the public, etc. 2.2.8. Priority Mechanism Some P2P systems have mechanisms to control the priorities of the peers or files in the uploading or downloading phase. For example, to decide which peer should download first or which chunk of the file should be uploaded to the neighbors, etc. 3. BitComet BitComet is a BitTorrent-like Peer-to-Peer file sharing application. It supports multiple protocols, including Bitorrent, HTTP and FTP. The new version of BitComet provides a flexible configuration interface for users to control the resource usage. This survey of BitComet is intended to be represent resource control in a typical BitTorrent application. Chen & Song Expires September 1, 2010 [Page 6] Internet-Draft Resource Control in P2P Systems February 2010 3.1. Total Upload/Download Bandwidth Control BitComet has an upper limit of total uploading bandwidth, as well as an upper limit of total downloading bandwidth, which are shared by all uploading or downloading connections in a peer. 3.2. Upload/Download Bandwidth Control of A Single Task BitComet controls the upper limit of uploading speed, as well as the upper/lower limit of downloading speed of a single task. Since it implements BitTorrent, the policy for its uploading bandwidth control is "Tit-for-tat", which is a simple strategy that a client only uploads data to the top peers who contribute data back to the client. Allowing data to be uploaded to a peer is called "unchoking" the peer, while disabling upload to a peer is called "choking" the peer. A mechanism called "optimistic unchoking" allows for exploration of new peers and allows new peers to download even if they have no data to contribute. 3.3. Remote/Local Connection Control BitComet has an upper limit of the total number of remote and local connections, including connections established by BitTorrent Protocol, HTTP and FTP. 3.4. Parallel Connection Control of A Single Task BitComet maintains a fixed upper bound of parallel connections of a single task. Note that BitTorrent's tit-for-tat policy causes only certain connections to be used for uploading at a particular point in time. 3.5. Connection Port Assignment BitComet provides the capability for users to assign a particular port for incoming connections. Outgoing connections use a OS- assigned port number. 3.6. Cache Size Control BitComet allocates a default "disk cache" as 50 MB. This "disk cache" is used to keep frequently accessed data in memory to reduce the reads and writes to the hard disk. The user is able to modify the size of the disk cache. Chen & Song Expires September 1, 2010 [Page 7] Internet-Draft Resource Control in P2P Systems February 2010 3.7. Access Control BitComet does not have any access control. All the files in BitComet are shared to public. Although BitComet does not provide initial access control, but the resource provider has the privilege to manually disconnect any remote user within a limited period(5min, 1h, or 24h) from the connected user list. In that case, the subsequent request from the same IP address will be denied. 3.8. Priority Mechanism BitComet has an optional priority mechanism. It provides the capability for users to set the priority of each task. The priority of the task can be set among low, normal and high. 4. eMule eMule is a free peer-to-peer file sharing application for Microsoft Windows. eMule can connect to both the eDonkey network and the Kad network. The distinguishing features of EMule are the direct exchange of sources between client nodes, fast recovery of corrupted downloads, and the use of a credit system to reward frequent uploaders. [EmuleWikipedia] 4.1. Total Upload/Download Bandwidth Control eMule has an upper limit of total uploading bandwidth, as well as an upper limit of total downloading bandwidth. Which are shared by all uploading or downloading connections in a peer. 4.2. Upload/Download Bandwidth Control of A Single Task EMule controls the upper limit of uploading speed, as well as the upper limit of downloading speed of a single task. The Policy for its uploading bandwidth control is different from BitTorrent's "Tit- for-tat" and instead uses long-term credit to judge which neighbor should be served first. In particular, for every file, EMule only uploads it to one peer a time, according to the priority of the peers in its credit logs. EMule's divides files into larger units than BitTorrent; files are divided into 9.28MB parts, which are each divided into 180KB blocks. It also uses the "Rarest-Piece-First" policy to select peer for downloading the rarest portion of a file. 4.3. Remote/Local Connection Control EMule has an upper limit of the total number of remote and local connections. Especilly the number of concurrent TCP connections, Chen & Song Expires September 1, 2010 [Page 8] Internet-Draft Resource Control in P2P Systems February 2010 which will incur maintaining overhead. 4.4. Parallel Connection Control of A Single Task EMule provides the flexibility to set a fixed number as the upper limit of the number of parallel connections of a single task. 4.5. Connection Port Assignment EMule assigns particular ports for different functional connections, such as port for TCP, UDP, Web serve and MobileMule. 4.6. Cache Size Control EMule allocates a fixed size for cache used to stored the data downloaded from neighbors or to be uploaded to neighbors. 4.7. Access Control EMule has access control. Users can decide to share their files to their friends only or share to the public. 4.8. Priority Mechanism EMule has a priority mechanism according to the uploading/downloading credit logs recorded in each peer itself. Credits are not global, they are exchanged between two specific clients. The credit system is used to reward users contributing to the network. The more a user uploads to a client the higher credit it gets, subsequently, the faster he advances in this client's queue of downloading a file. A user may also locally adjust the priority between tasks. 5. EMS (End System Multicast) End System Multicast (ESM) is a research project at Carnegie Mellon University. It is a peercasting system for streaming live, high- quality video and audio to large audiences. It is a push based and single tree based system. 5.1. Total Upload/Download Bandwidth Control EMS has an upper limit of total uploading bandwidth, as well as an upper limit of total downloading bandwidth. As a single tree structure, each only downloads live stream from its parent with full playback rate, and uploads to a fixed number of children with full playback rate, too. Chen & Song Expires September 1, 2010 [Page 9] Internet-Draft Resource Control in P2P Systems February 2010 5.2. Upload/Download Bandwidth Control of A Single Task Peers in EMS can not watch more than one live streaming channel concurrently, thus the control is exactly as Section 5.1. 5.3. Remote/Local Connection Control EMS has only one downloading connection which is from its parent, and a fixed number of uploading connections to its children. 5.4. Parallel Connection Control of A Single Task Since only one channel exists, the control is exactly as Section 5.3. 5.5. Connection Port Assignment Not user configurable. 5.6. Cache Size Control EMS allocates a fixed size buffer for caching the stream in playback window, which will be uploaded to children. 5.7. Access Control EMS does not have any access control. It only delivers its buffer to its children. 5.8. Priority Mechanism EMS does not have any priority mechanism. It treats its children equally. 6. CoolStreaming CoolStreaming is a P2PTV (peer-to-peer television) technology that enables users to share television content with each other over the Internet. The technology behind CoolStreaming is similar to that of BitTorrent. The viewers upload content at the same time the programs are downloaded and viewed. CoolStreaming is a pull based and mesh based system. 6.1. Total Upload/Download Bandwidth Control CoolStreaming has an upper limit of total uploading bandwidth, as well as an upper limit of total downloading bandwidth. Which are shared by all uploading or downloading connections in a peer. A Chen & Song Expires September 1, 2010 [Page 10] Internet-Draft Resource Control in P2P Systems February 2010 CoolStreaming client always tries its best to download all the chunks it needs, but only uploads to the neighbors who served it most, as a "Tit-for-tat" strategy. 6.2. Upload/Download Bandwidth Control of A Single Task Peers in CoolStreaming join one channel per time, thus the control is exactly as Section 6.1. 6.3. Remote/Local Connection Control CoolStreaming has an upper limit of the number of uploading and downloading connections. It fixes the number of both connections and periodically adjusts its connections to disconnect unqualified neighbors. 6.4. Parallel Connection Control of A Single Task Since only one channel can a peer join at a time, the control is exactly as Section 6.3. 6.5. Connection Port Assignment CoolStreaming assign a particular port for the connections. 6.6. Cache Size Control CoolStreaming allocates a fixed size buffer for caching the stream in playback window, which also serves as a source for data uploaded to neighbors. 6.7. Access Control CoolStreaming does not have any access control. 6.8. Priority Mechanism CoolStreaming does not have any priority mechanism. 7. SplitStream SplitStream is a tree-based application-level peer-to-peer multicast system. In this system, it stripes the content across a forest of interior-node-disjoint multicast trees that distributes the forwarding load among all participating peers. Chen & Song Expires September 1, 2010 [Page 11] Internet-Draft Resource Control in P2P Systems February 2010 7.1. Total Upload/Download Bandwidth Control SplitStream has an upper limit of total uploading bandwidth, as well as an upper limit of total downloading bandwidth, which are shared by all uploading or downloading connections in a peer. A SplitStream client tries its best to download all the chunks it need and contributes only as much bandwidth as it received to upload to its children. 7.2. Upload/Download Bandwidth Control of A Single Task Peers in SplitStream join one channel per time, thus the control is exactly as Section 7.1. 7.3. Remote/Local Connection Control SplitStream has an upper limit of the number of uploading connections. It only serves as an internal node in one tree and sends data to a fixed number of children. On the other hand, it can join as a leaf in many trees to download data. 7.4. Parallel Connection Control of A Single Task Since a peer can join only one channel at a time, the control is exactly as Section 7.3. 7.5. Connection Port Assignment SplitStream assign a particular port for the connections. 7.6. Cache Size Control SplitStream allocates a fixed size buffer for caching the stream in playback window, which also serves as a source for data uploaded to neighbors. 7.7. Access Control SplitStream does not have access control. 7.8. Priority Mechanism SplitStream does not have any priority mechanism. 8. PPLive PPLive is a peer-to-peer streaming video network created in Huazhong Chen & Song Expires September 1, 2010 [Page 12] Internet-Draft Resource Control in P2P Systems February 2010 University of Science and Technology, China. It is part of a new generation of P2P applications, that combine P2P and Internet TV. It is a pull based and mesh based P2P live streaming and video-on-demand system. 8.1. Total Upload/Download Bandwidth Control PPLive has an upper limit of total uploading bandwidth, as well as an upper limit of total downloading bandwidth, which can be set by users. The bandwidth is shared by all uploading or downloading connections in a peer. A PPlive client always tries its best to download all the chunks it needs and uses all its uploading bandwidth to upload to its neighbors. 8.2. Upload/Download Bandwidth Control of A Single Task Peers in PPLive join one channel per time, thus the control is exactly as Section 8.1. 8.3. Remote/Local Connection Control PPlive has an upper limit of the number of uploading and downloading connections. It fixes the number of both connections and the fixed number is related to the playback rate of the channel. It also provides an interface for users to modify these numbers. 8.4. Parallel Connection Control of A Single Task Since a peer can join only one channel at a time, the control is exactly as Section 8.3. 8.5. Connection Port Assignment PPLive provides the capability for users to assign a particular port for incoming connections. 8.6. Cache Size Control PPLive allocates a fixed size buffer for caching the stream in playback window, which will be used for uploading to neighbors. It also provides an interface for users to share certain contents on disk with LAN users. 8.7. Access Control Access control is not provided for remote connections. The users can choose whether to share an additional disk space of the media file folder to LAN users or not. Once a user chooses to share, this media Chen & Song Expires September 1, 2010 [Page 13] Internet-Draft Resource Control in P2P Systems February 2010 file folder will be bounded with the user's IP address and serve as a source to other users in LAN. They can directly recieve data from the sharing LAN user. 8.8. Priority Mechanism PPLive does not have any priority mechanism. 9. Donnybrook Donnybrook is a P2P game system that enables games with large scale high speed and peer management. For example, it enables games with hundreds of players interacting in one area at the same time. It is a research project at Carnegie Mellon University. 9.1. Total Upload/Download Bandwidth Control Donnybrook has an upper limit of total uploading bandwidth, as well as an upper limit of total downloading bandwidth. Peers are with heterogeneous capacity in the system. Donnybrook provides a method to reduce bandwidth demand by estimating what players are paying attention to, and thereby enabling to reduce the frequency of sending less important state updates. 9.2. Upload/Download Bandwidth Control of A Single Task Peers in Donnybrook joins in only one game in each time, thus the control is exactly as Section 9.1. 9.3. Remote/Local Connection Control Donnybrook has an upper limit of the number of uploading and downloading connections due to the peers' bandwidth constraint. it groups the peers having spare capacity into the forwarding pool to help pool peers forward updates. 9.4. Parallel Connection Control of A Single Task Since only one game exists, the control is exactly as Section 9.3. 9.5. Connection Port Assignment Not Provided. Chen & Song Expires September 1, 2010 [Page 14] Internet-Draft Resource Control in P2P Systems February 2010 9.6. Cache Size Control Donnybrook allocates a fixed size buffer for caching the updates. 9.7. Access Control Donnybrook has an automatic access control which automatically estimate the interest set of a player and sends/receives updates to that set only. 9.8. Priority Mechanism Donnybrook does not have any priority mechanism. 10. Recommendations and Conclusions From this survey of a diverse set of P2P applications, it is clear that connections, bandwidth and storage are the primary resources that are controlled. To enable better usability of DECADE as in- network storage for a wide range of P2P applications, these resource control functions should be supported by DECADE. Note that this document is a work in progress. This document will be updated with survey material and recommendations to track future discussions and input by the community. 11. Security Considerations This draft is a survey of existing systems, and does not introduce any security problem itself. However, there will be security concerns if messages in DECADE are used to do the resource control functions mentioned in this draft. For more information on security considerations of DECADE, see [I-D.song-decade-problem-statement]. 12. IANA Considerations This document does not have any IANA Considerations. 13. Acknowledgments The authors would like to thank Richard Alimi, Yang Richard Yang, Zhihui Lv and Yingjie Gu for comments and contributions to this Chen & Song Expires September 1, 2010 [Page 15] Internet-Draft Resource Control in P2P Systems February 2010 document. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 14.2. Informative References [I-D.song-decade-problem-statement] Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", draft-song-decade-problem-statement-00 (work in progress), October 2009. [EmuleWikipedia] "eMule", http://en.wikipedia.org/wiki/Emule/. Authors' Addresses Lijiang Chen Peking University & Yale University Email: lijiang.chen@yale.edu Song Haibin Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565867 Email: melodysong@huawei.com Chen & Song Expires September 1, 2010 [Page 16]