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]