One document matched: draft-song-decade-problem-statement-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC4330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4330.xml">
<!ENTITY RFC4981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4981.xml">
<!ENTITY I-D.ietf-alto-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-problem-statement.xml">
<!ENTITY I-D.weaver-alto-edge-caches SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.weaver-alto-edge-caches.xml">
]>
<rfc category="std" docName="draft-song-decade-problem-statement-00"
ipr="trust200902" submissionType="IETF" updates="" xml:lang="">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no"?>
<?rfc strict="no"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="DECADE Problem Statement">DECoupled Application Data
Enroute (DECADE) Problem Statement</title>
<author fullname="Song Haibin" initials="H." surname="Song">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-84565867</phone>
<email>melodysong@huawei.com</email>
</address>
</author>
<author fullname="Ning Zong" initials="N" surname="Zong">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-84565866</phone>
<email>zongning@huawei.com</email>
</address>
</author>
<author fullname="Y. Richard Yang" initials="Y" surname="Yang">
<organization>Yale University</organization>
<address>
<email>yry@cs.yale.edu</email>
</address>
</author>
<author fullname="Richard Alimi " initials="R" surname="Alimi">
<organization>Yale University</organization>
<address>
<email>richard.alimi@yale.edu</email>
</address>
</author>
<date day="14" month="October" year="2009" />
<area>Applications Area</area>
<workgroup></workgroup>
<keyword>In-network storage</keyword>
<keyword>P2P</keyword>
<abstract>
<t>Peer-to-peer (P2P) applications have become widely used on the
Internet today and make up a large portion of the traffic in many
networks. In P2P applications, one technique for reducing the total
amount of P2P traffic is to introduce storage capabilities within the
network. Traditional caches (e.g., P2P and Web caches) provide such
storage, but they are complex (due to explicitly supporting individual
P2P application protocols) and they do not allow users to manage access
to content in the cache. For example, Content Providers cannot easily
control access and resource usage policies to satisfy their own
requirements. This document discusses the introduction of in-network
storage for P2P applications, shows the need for a standard protocol for
accessing this storage, and identifies the scope of this protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>P2P applications, including both P2P streaming and P2P filesharing
applications, make up a large fraction of the traffic in many Internet
networks today. One way to reduce bandwidth usage by P2P applications is
to introduce storage capabilities in the networks. Allowing P2P
applications to store and retrieve data from inside networks can reduce
traffic on the last-mile uplink, as well as backbone and transit links
<xref target="I-D.weaver-alto-edge-caches"></xref>.</t>
<t>P2P caches provide in-network storage and have been deployed in some
networks. But the current P2P caching architecture poses challenges to
both P2P cache vendors and P2P application developers. For P2P cache
vendors, it is challenging to support a number of continuously evolving
P2P application protocols, due to lack of documentation, ongoing
protocol changes, and rapid introduction of new features by P2P
applications. For P2P applications, closed P2P caching systems limit P2P
applications to effectively utilize in-network storage. In particular,
P2P caches typically do not allow users to explicitly store content into
in-network storage. Neither do they allow users to implement controlover
the content that have have placed into the in-network storage.</t>
<t>Both of these challenges can be effectively addressed by using an
open, standard protocol to access in-network storage. P2P applications
can store and retrieve content in the in-network storage, as well as
control resources (e.g., bandwidth, connections) consumed by peers in a
P2P application. As a simple example, a peer of a P2P application may
upload to other peers through its in-network storage, saving its usage
of last-mile uplink bandwidth.</t>
<t>In this document, we distinguish between two functional components of
the native P2P application protocol: signaling and data transport.
Signaling includes operations such as handshaking and discovering peer
and content availability. The data transport component transfers content
from one peer to another.</t>
<t>With DECADE, P2P applications can still use their native protocols
for signaling and data transport. However, they may use a standard
protocol for data transport incorporating in-network storage, and fall
back to their native data transport protocols if in-network storage is
not available or not used.</t>
<t>In essence, an open, standard protocol to access in-network storage
provides an alternative mechanism for P2P application data transport
that is decoupled from P2P application control and signaling. This
decoupling leads to many advantages, which is explained further in <xref
target="in-network-storage-capability"></xref>.</t>
</section>
<section title="Terminology and Concepts" toc="default">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>The following terms have special meaning in the definition of the
in-network storage system. <list>
<t>In-network Storage: A service inside a network that provides
storage and bandwidth to network applications. In-network storage
may reduce upload/transit/backbone traffic and improve network
application performance.</t>
<t>P2P Cache (Peer to Peer Cache): a kind of in-network storage that
understands the signaling and transport of specific P2P application
protocols.</t>
<t>IAP (In-network storage Access Protocol): a standard protocol
that is spoken between P2P applications and in-network storage. The
protocol may also be used between entities implementing the
in-network storage service.</t>
<t>Content Publisher: An entity that originates content to
consumers.</t>
</list></t>
</section>
<section title="The Problems">
<t>The emergence of peer-to-peer (P2P) as a major type of network
applications (esp. P2P file sharing and streaming apps) has led to
substantial opportunities. The P2P paradigm can be utilized in designing
highly scalable and robust applications at low cost, compared with
traditional client-server paradigms. For example, CNN [CNN] reported
that P2P streaming by Octoshape played a major role in its distribution
of the historical inauguration address of President Obama. PPLive, one
of the largest P2P streaming vendors, is able to distribute large-scale,
live streaming programs to more than 2 million users with only a handful
of servers.</t>
<t>However, P2P applications also face substantial design challenges. A
particular problem facing P2P applications is the substantial stress
that they place on the network infrastructure. Also, lacking of
infrastructure support can lead to unstable P2P application performance
during peer churns and flash crowd. Below we elaborate on the problems
in more detail.</t>
<section title="P2P infrastructural stress and inefficiency">
<t>A particular problem of the P2P paradigm is the stress that P2P
application traffic places on the infrastructure of Internet service
providers (ISP). Multiple measurements (e.g., [ipoque]) have shown
that P2P traffic has become a major type of traffic on some networks.
Furthermore, network-agnostic peering leads to unnecessary traversal
across network domains or spanning the backbone of a network, leading
to network inefficiency <xref
target="I-D.ietf-alto-problem-statement"></xref>.</t>
<t>Recently, the IETF Application Layer Traffic Optimization (ALTO)
Working Group is formed to provide P2P applications with network
information so that they can perform better-than-random initial peer
selection <xref target="I-D.ietf-alto-problem-statement"></xref>.
However, there are limitations on what ALTO can achieve alone. For
example, network information alone cannot reduce P2P traffic in access
networks, as the total access upload traffic is equal to the total
access download traffic in a pure P2P system. On the other hand, it is
reported that P2P traffic is becoming the dominating traffic on the
access networks of some networks, reaching as high as 50-60% at the
down-links and 60-90% at the uplinks (<xref target="DCIA"></xref><xref
target="ICNP">,</xref><xref target="ipoque.P2P_survey.">,</xref><xref
target="P2P_file_sharing">,</xref>). Consequently, it becomes
increasingly important to complement the ALTO effort and reduce upload
access traffic, in addition to cross-domain and backbone traffic.</t>
</section>
<section title="P2P cache: a complex in-network storage">
<t>An effective technique to reduce P2P infrastructural stress and
inefficiency is to introduce in-network storage. For example, in <xref
target="I-D.weaver-alto-edge-caches"></xref>, the author demonstrates
clearly the potential benefits of introducing in-network storage to
improve network efficiency and thus reduce network infrastructure
stress.</t>
<t>In the current Internet, in-network storage is introduced as P2P
caches, either transparently or explicitly as a P2P peer. To provide
service to a specific P2P application, the P2P cache server must
support the specific signaling and transport protocols of the specific
P2P application. This can lead to substantial complexity.</t>
<t>First, there are multiple P2P applications on the Internet (e.g.,
BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast,
Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming).
Consequently, a P2P cache vendor faces the challenge of supporting a
large number of P2P application protocols, leading to product
complexity and increased development cost.</t>
<t>Furthermore, a specific P2P application protocol may be evolving
continuously, to add new features or fix bugs. This forces a P2P cache
vendor to continuously update to track the changes of the P2P
application, leading to product complexity, high cost, and low
reliability.</t>
<t>Third, many P2P applications use proprietary protocols or support
end-to-end encryption. This can render P2P caches ineffective.</t>
</section>
<section title="Ineffective integration of P2P applications and in-network storage">
<t>As P2P applications evolve, it becomes increasingly clear that they
will need in-network resources to provide positive user experiences.
For example, multiple P2P streaming systems seek additional in-network
resources during flash crowd, such as just before a major live
streaming event. In asymmetric networks when the aggregated upload
bandwidth of a channel cannot meet the download demand, a P2P
application may seek additional in-network resources to maintain a
stable system.</t>
<t>A requirement by some P2P applications in using in-network
infrastructural resources, however, is flexibility in implementing
resource allocation policies. A major competitive advantage of many
successful P2P systems is their substantial expertise in how to most
efficiently utilize peer and infrastructural resources. For example,
many live P2P systems have their specific algorithms in selecting the
peers that should receive from the more stable, higher bandwidth
sources. They continue to fine-tune such algorithms. In other words,
in-network storage should export basic mechanisms and allow as much
flexibility as possible to P2P applications to implement specific
policies. This conforms to the end-to-end systems principle and allows
innovation and satisfaction of specific business goals. Existing
techniques for P2P application in-network storage lack these
capabilities.</t>
</section>
</section>
<section anchor="in-network-storage-capability"
title="DECADE as an In-network Storage Capability">
<t>The objective of this working group is to design DECADE, an
in-network storage protocol to address the problems discussed in the
preceding section.</t>
<t>DECADE will provide access to storage and data transport services in
the network to P2P applications to improve their efficiency and reduce
the stress on the network infrastructure. Unlike the existing P2P
caching architecture, DECADE is a standard interface for various P2P
applications (both content publishers and end users) to access
in-network storage. This decoupling of P2P data transport from P2P
application control and signaling reduces the complexity of in-network
storage services. Furthermore, DECADE provides basic access mechanisms
and allows P2P applications to implement flexible policies to create an
ecosystem for application innovation and various business goals.</t>
<figure>
<artwork>
IAP
-----------+
| |
| v
+--------------------+
| In-network Storage |
+--------------------+
^ ^
IAP | IAP |
+-------------v-+ +-v-------------+
| P2P | | Content |
| application | | publishers |
| clients | +---------------+
+---------------+
| ^
| |
+-------------+
P2P application
native protocol
Figure 1 Overview of protocol interaction between DECADE elements</artwork>
</figure>
<t>Specifically, the main component of DECADE is the in-network storage
access protocol (IAP), which is a standard, P2P-application-agnostic
protocol for different P2P applications to access in-network storage.
IAP defines a set of commands that P2P application elements can issue to
in-network storage to store and retrieve data. IAP includes the
following functionalities:</t>
<t>(1) Data access provides read/write by users (e.g., P2P application
clients and content publishers) to the corresponding in-network storage
and between entities implementing the in-network storage;</t>
<t>(2) Authorization implements access control to resources provided by
in-network storage;</t>
<t>(3) Resource control allows users to implement application policies
for the corresponding in-network storage.</t>
<t>Note that DECADE is independent of current IETF work on P2P, e.g.
P2PSIP, ALTO, PPSP. For example, peers discovered by either RELOAD or
ALTO can all use DECADE to share data. DECADE will focus on the problems
of P2P applications, although the solution might be used in other
context.</t>
<section title="Data access">
<t>P2P application clients use the protocol to read data from an in-
network storage, store data to an in-network storage, or remove data
from an in-network storage. The data could be of various types.</t>
</section>
<section title="Authorization">
<t>In-network storage only permits the users with authorization to
access the corresponding contents. The admission could be based on
user, content, time period, etc.</t>
</section>
<section title="Resource control">
<t>A user uses the protocol to manage the resources on in-network
storage that can be used by other peers, e.g., the bandwidth or
connections.</t>
</section>
</section>
<section title="Usage Scenarios">
<t>Usage scenarios are described from two perspectives. First, we
introduce high-level use cases showing how P2P applications may utilize
in-network storage. Second, we show how in more detail how users
exchange data using IAP.</t>
<section anchor="BitTorrent" title="BitTorrent">
<t>BitTorrent may be integrated with DECADE to be more network
efficient and reduce the bandwidth consumed on ISP networks. When a
BitTorrent client uploads a block to peers, the block traverses the
last-mile uplink once for each peer. With DECADE, however, the
BitTorrent client may upload the block to its in-network storage.
Peers may retrieve the block from the in-network storage, reducing the
amount of data on the last-mile uplink.</t>
<t>We now describe in more detail how BitTorrent can utilize DECADE.
For illustration, we assume that both the BitTorrent client (A) and
its peer (B) utilize in-network storage. When A requests a block, it
indicates that it would like the block stored in its in-network
storage and provides the necessary access control. Instead of sending
the 'piece' message with the desired block, peer B replies with a
'redirect' message indicating that the content should be retrieved
from its own in-network storage and provides the necessary access
control. If the peer B had not previously stored the content in its
in-network storage, it uploads the block. A downloads the block into
its own in-network storage from B's in-network storage, and finally A
itself retrieves the block.</t>
<t>Note that this requires extensions to the BitTorrent protocol.
While there are multiple ways to do so, this example assumes the
native BitTorrent 'request' message is extended to carry additional
information and that a new 'redirect' message is added. Upload and
download to/from in-network storage uses the standard IAP
protocol.</t>
<t>This example has illustrated how utilizing DECADE can increase
BitTorrent's network efficiency. First, notice that peer B does not
utilize any uplink bandwidth if the block was already present in its
in-network storage. Second, notice that the block is downloaded
directly into A's in-network storage. When A wishes to share the block
with another peer (say, peer C) that supports DECADE, it may upload
directly from its in-network storage, again avoiding usage of the
last-mile uplink.</t>
<t>This technique can be applied to other P2P applications as well.
Since P2P applications use a standard for communicating with
in-network storage, they no longer require in-network storage to
explicitly support their protocol. P2P applications retain the ability
to explicitly manage which content is placed in in-network storage, as
well as access and resource control polices.</t>
</section>
<section title="Content Publisher">
<t>Content Publishers may also utilize in-network storage. For
example, consider a P2P live streaming application. A Content
Publisher typically maintains a small number of sources, each of which
distributes blocks in the current play buffer to a set of the P2P
peers.</t>
<t>Consider a case where the Content Publisher owns an in-network
storage account within ISP A. If there are multiple P2P peers within
ISP A, the Content Publisher may utilize DECADE to distribute content
to the peers.</t>
<t>First, the Content Publisher stores a block in the in-network
storage, and then sends to each peer in ISP A the block's identifier
and necessary access control. Second, each peer may then download from
the Content Publisher's in-network storage.</t>
<t>In this example, the block is distributed in a more network
efficient way (the content only traverses the ISP's interdomain link
once), while the Content Publisher retains explicit control over
access to the content placed in its own storage. The Content Publisher
can remove content from its in-network storage when it is stale or
needs to be replaced, and grant access and resources to only the
desired peers.</t>
<t>Note that Content Publishers and individual peers can each use
in-network storage. For example, after downloading content from the
Content Publisher's in-network storage, peers may each utilize their
own in-networks storage similar to the usage scenario in <xref
target="BitTorrent"></xref>. This can have the benefit of increased
network efficiency, while Content Publishers and peers still retain
control over content placed in their own in-network storage.</t>
</section>
<section title="Data Transfer Scenarios">
<t>The previous usage scenarios have utilized the ability for peers to
transfer data by storing and retrieving from in-network storage. This
section describes in further detail an example solution of how DECADE
can provide this capability.</t>
<t>In this section, we consider the case of a user B (the receiver)
requesting data from user A (the sender). We use Sa to denote User A's
storage account, and Sb to denote User B's storage account. Each user
independently decides if its in-network storage account is used, so
there are four cases.</t>
<t>When a user indicates that it wishes to use its in-network storage,
it provides an access control token the other user. The token is sent
using the application's protocol. To simplify the illustration, we
omit details of the access control from the detailed scenarios
below.</t>
<section title="Both Sender and Receiver Accounts are Used">
<t>This scenario is illustrated in Figure 2. B first requests an
object from A using the application protocol indicating it wishes
the object to be stored in Sb. A responds using the application
protocol indicating that B should download the object from Sa. B
sends a IAP request to Sb indicating that the object should be
downloaded from Sa. Sb uses IAP to download from Sa, and finally, B
downloads the object from Sb (also using IAP).</t>
<figure>
<artwork>
+-------+ IAP Get +-------+
| Sa | <-------+ Sb |
+-------+ 4 +-------+
^
\ 3 IAP Get
1 App request \
+-------+<-------------------+-------+
|User A | |User B |
+-------+------------------->+-------+
2 App response
Figure 2: Usage Scenario 1 (Sender and receiver Accounts used)</artwork>
</figure>
</section>
<section title="Only Sender's Storage Account is Used">
<t>This scenario is illustrated in Figure 3. B requests an object
from A using the application protocol. A responds using the
application protocol indicating that B should download the object
from Sa. Finally, B sends a IAP request to Sa to download the
object.</t>
<figure>
<artwork>
+-------+
| Sa |
+-------+
^
\ 3 IAP Get
1 App request \
+-------+<-------------------+-------+
|User A | |User B |
+-------+------------------->+-------+
2 App response
Firgure 3: Usage Scenario 2 (Sender account used)</artwork>
</figure>
</section>
<section title="Only Receiver's Storage Account is Used">
<t>This scenario is illustrated in Figure 4. B requests an object
from A using the application protocol indicating that it wishes the
object to be stored in Sb. A stores the object in Sb (using IAP),
and responds to B (using the application protocol) that it should
download from Sb. B uses IAP to download the object from Sb.</t>
<figure>
<artwork> +-------+
> | Sb |
3. / +-------+
IAP Store / ^
/ \ 3.IAP Get
/ 1.App request \
+-------+<-------------------+-------+
|User A | |User B |
+-------+------------------->+-------+
2.App response
Figure 4: Usage Scenario 3 (Receiver account used)</artwork>
</figure>
</section>
<section title="No Storage Accounts are Used">
<t>This scenario is illustrated in Figure 5. In this scenario, the
application protocol is used directly to send data. This scenario
applies with one of the peers does not support IAP, or neither of
the peers are using in-network storage.</t>
<figure>
<artwork>
1.App request
+-------+<-------------------+-------+
|User A | ... ... ... |User B |
+-------+------------------->+-------+
2.data transfer
Figure 5: Usage Scenario 4 ( No storage accounts used)</artwork>
</figure>
</section>
</section>
</section>
<section title="Security Considerations">
<t>There are multiple security considerations. We focus on two in this
section.</t>
<section title="Denial of Service attack">
<t>Without access control or resource control, an attacker can try to
consume a large portion of the in-network storage, or exhaust the
connections of the in-network storage to commit a Denial of Service
(DoS) attack. Thus, access control and resource control mechanisms are
mandatory. A resource control mechanism should be used to allow a user
to allocate the resource in its in-network storage account to be
utilized by other clients.</t>
</section>
<section title="Copyright and Legal issues">
<t>Copyright and other laws may prevent the distribution of certain
content in various localities. While in-network storage operators may
adopt system-wide ingress or egress filters to implement necessary
policies for storing or retrieving content, the specification and
implementation of such policies (e.g., filtering and DRM) is outside
of the scope of this working group.</t>
</section>
</section>
<section title="IANA Considerations ">
<t>There is no IANA consideration with this document.</t>
</section>
<section title="Acknowledgments">
<t>We would like to thank the following people for contributing to the
discussion of this document:</t>
<t>Kar Ann Chew</t>
<t>Richard Woundy</t>
<t>Yunfei Zhang</t>
<t>Yu-shun Wang</t>
<t>David Bryan</t>
<t>Roni Even</t>
<t>Yingjie Gu</t>
<t>Hongqiang Law.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
<reference anchor="ipoque.com">
<front>
<title>http://www.ipoque.com/resources/internet-studies/internet-study-2008_2009</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
&I-D.ietf-alto-problem-statement;
&I-D.weaver-alto-edge-caches;
<reference anchor="DCIA">
<front>
<title>Distributed Computing Industry Association</title>
<author>
<organization>http://www.dcia.info</organization>
</author>
<date />
</front>
</reference>
<reference anchor="ipoque.P2P_survey.">
<front>
<title>Emerging Technologies Conference at MIT</title>
<author>
<organization></organization>
</author>
<date month="Sept." year="2007" />
</front>
</reference>
<reference anchor="P2P_file_sharing">
<front>
<title>The true picture of peer-to-peer filesharing</title>
<author initials="A." surname="Parker">
<organization>http://www.cachelogic.com</organization>
</author>
<date month="July" year="2004" />
</front>
</reference>
<reference anchor="ICNP">
<front>
<title>Challenges and opportunities of Internet developments in
China, ICNP 2007 Keynote</title>
<author initials="H." surname="Wu">
<organization></organization>
</author>
<date month="Oct." year="2007" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:28:53 |