draft-ietf-decade-problem-statement-06.txt   rfc6646.txt 
DECADE H. Song Internet Engineering Task Force (IETF) H. Song
Internet-Draft N. Zong Request for Comments: 6646 N. Zong
Intended status: Informational Huawei Category: Informational Huawei
Expires: November 8, 2012 Y. Yang ISSN: 2070-1721 Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
May 7, 2012 July 2012
DECoupled Application Data Enroute (DECADE) Problem Statement DECoupled Application Data Enroute (DECADE) Problem Statement
draft-ietf-decade-problem-statement-06
Abstract Abstract
Peer-to-peer (P2P) applications have become widely used on the Peer-to-peer (P2P) applications have become widely used on the
Internet today and make up a large portion of the traffic in many Internet today and make up a large portion of the traffic in many
networks. In P2P applications, one technique for reducing the networks. In P2P applications, one technique for reducing the
transit and uplink P2P traffic is to introduce storage capabilities transit and uplink P2P traffic is to introduce storage capabilities
within the network. Traditional caches (e.g., P2P and Web caches) within the network. Traditional caches (e.g., P2P and Web caches)
provide such storage, but they are complex (due to explicitly provide such storage, but they can be complex (e.g., P2P caches need
supporting individual P2P application protocols and cache refresh to explicitly support individual P2P application protocols), and do
mechanisms) and they do not allow users to manage access to content not allow users to manage resource usage policies for content in the
in the cache. For example, content providers wishing to use in- cache. This document discusses the introduction of in-network
network storage cannot easily control cache access and resource usage storage for P2P applications and shows the need for a standard
policies to satisfy their own requirements. This document discusses protocol for accessing this storage.
the introduction of in-network storage for P2P applications, and
shows the need for a standard protocol for accessing this storage.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on November 8, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6646.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 19 skipping to change at page 2, line 22
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Concepts ........................................3
3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Problems ....................................................4
3.1. P2P infrastructural stress and inefficiency . . . . . . . 4 3.1. P2P Infrastructural Stress and Inefficiency ................4
3.2. P2P cache: a complex in-network storage . . . . . . . . . 5 3.2. P2P Cache: A Complex Type of In-Network Storage ............5
3.3. Ineffective integration of P2P applications . . . . . . . 6 3.3. Ineffective Integration of P2P Applications ................6
4. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 4. Usage Scenarios .................................................6
4.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. BitTorrent .................................................6
4.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 7 4.2. Content Publisher ..........................................7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations .........................................8
5.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 8 5.1. Denial-of-Service Attacks ..................................8
5.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 8 5.2. Copyright and Legal Issues .................................8
5.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 8 5.3. Traffic Analysis ...........................................8
5.4. Modification of Information . . . . . . . . . . . . . . . 8 5.4. Modification of Information ................................8
5.5. Masquerade . . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Masquerade .................................................9
5.6. Disclosure . . . . . . . . . . . . . . . . . . . . . . . . 9 5.6. Disclosure .................................................9
5.7. Message Stream Modification . . . . . . . . . . . . . . . 9 5.7. Message Stream Modification ................................9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments .................................................9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Informative References .........................................10
8. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Peer-to-peer (P2P) applications, including both P2P streaming and P2P Peer-to-peer (P2P) applications, including both P2P streaming and P2P
filesharing applications, make up a large fraction of the traffic in file-sharing applications, make up a large fraction of the traffic in
many ISP networks today. One way to reduce bandwidth usage by P2P many Internet Service Provider (ISP) networks today. One way to
applications is to introduce storage capabilities in networks. reduce bandwidth usage by P2P applications is to introduce storage
Allowing P2P applications to store and retrieve data from inside capabilities in networks. Allowing P2P applications to store and
networks can reduce traffic on the last-mile uplink, as well as on retrieve data from inside networks can reduce traffic on the last-
backbone and transit links. mile uplink, as well as on backbone and transit links.
P2P caches provide in-network storage and have been deployed in some
networks. However, 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 from effectively utilizing in-
network storage. In particular, P2P caches typically do not allow
users to explicitly store content into in-network storage. They also
do not allow users to implement control over the content that has
been placed into the in-network storage.
P2P applications suffer decreased efficiency, and the network Existing P2P caches provide in-network storage and have been deployed
infrastructure suffers increased load because there is no in some networks. However, the current P2P caching architecture
standardized interface for accessing storage and data transport poses challenges to both P2P cache vendors and P2P application
services in the Internet. 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
application developers, closed P2P caching systems limit P2P
applications from effectively utilizing in-network storage. In
particular, P2P caches typically do not allow users to explicitly
store content into in-network storage. They also do not allow
applications to specific resource and access control policies over
the usage of in-network storage. The challenges, if not addressed,
may lead to reduced efficiency for P2P applications, and increased
load on the network infrastructure.
Both of these challenges can be effectively addressed by using an The challenges can be effectively addressed by using a standard, open
open, standard protocol to access in-network storage [Data_Lockers]. protocol to access in-network storage [Data_Lockers]. P2P
P2P applications can store and retrieve content in the in-network applications can store and retrieve content in the in-network
storage, as well as control resources (e.g., bandwidth, connections) storage, as well as control resources (e.g., bandwidth, connections)
consumed by peers in a P2P application. As a simple example, a peer 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 of a P2P application may upload to other peers through its in-network
storage, saving its usage of last-mile uplink bandwidth. storage, saving its usage of last-mile uplink bandwidth.
In this document, we distinguish between two functional components of In this document, we distinguish between two functional components of
the native P2P application protocol: signaling and data access. the native P2P application protocol: signaling and data access.
Signaling includes operations such as handshaking and discovering Signaling includes operations such as handshaking and discovering
peer and content availability. The data access component transfers peer and content availability. The data access component transfers
content from one peer to another. content from one peer to another.
In essence, coupling of the signaling and data access makes in- In essence, coupling of the signaling and data access makes
network storage very complex to support various application services. in-network storage complex to support various application services.
However, these applications have common requirements for data access, However, these applications have common requirements for data access,
making it possible to develop a standard protocol. making it possible to develop a standard protocol.
2. Terminology and Concepts 2. Terminology and Concepts
The following terms have special meaning in the definition of the in- The following terms have special meaning in the definition of the
network storage system. in-network storage system.
in-network storage: A service inside a network that provides In-network storage: A service inside a network that provides storage
storage and bandwidth to network applications. In-network storage and bandwidth to network applications. In-network storage may
may reduce upload/transit/backbone traffic and improve network reduce upload/transit/backbone traffic and improve network
application performance. The position of in-network storage is in application performance. The position of in-network storage is in
the core of a network, for example, co-located with the border the core of a network -- for example, co-located with the border
router (network attached storage) or inside a data center. router (network attached storage) or inside a data center.
P2P cache (Peer to Peer cache): A kind of in-network storage that P2P cache (peer-to-peer cache): A kind of in-network storage that
understands the signaling and transport of specific P2P understands the signaling and transport of specific P2P
application protocols. It caches the content for those specific application protocols. It caches the content for those specific
P2P applications in order to serve peers and reduce traffic on P2P applications in order to serve peers and reduce traffic on
certain links. certain links.
3. The Problems 3. The Problems
The emergence of peer-to-peer (P2P) as a major network application The emergence of P2P as a major network application (especially P2P
(especially P2P file sharing and streaming) has led to substantial file sharing and streaming) has led to substantial opportunities.
opportunities. The P2P paradigm can be utilized to design highly The P2P paradigm can be utilized to design highly scalable and robust
scalable and robust applications at low cost, compared to the applications at low cost, compared to the traditional client-server
traditional client-server paradigm. paradigm.
However, P2P applications also face substantial design challenges. A However, P2P applications also face substantial design challenges. A
particular problem facing P2P applications is the additional stress particular challenge facing P2P applications is the additional stress
that they place on the network infrastructure. Furthermore, lack of that they place on the network infrastructure. At the same time,
infrastructure support can lead to unstable P2P application lack of infrastructure support can lead to unstable P2P application
performance during peer churns and flash crowds, when a large group performance, in particular during peer churns and flash crowds, when
of users begin to retrieve the content during a short period of time. a large group of users begin to retrieve the content during a short
A potential way to solve it would be to make it possible for peers period of time, leading to stress on bandwidth-constrained access
that were on bandwidth constrained access to put things in a place uplinks. A potential way to reduce network stress and improve P2P
that is both not bandwidth constrained and accessible by other peers. application performance would be to make it possible for peers that
are on bandwidth-constrained access to put data in a place that is
free of bandwidth constraints and also accessible by other peers.
These problems are now discussed in further detail. These problems are now discussed in further detail.
3.1. P2P infrastructural stress and inefficiency 3.1. P2P Infrastructural Stress and Inefficiency
A particular problem of the P2P paradigm is the stress that P2P A particular problem of the P2P paradigm is the stress that P2P
application traffic places on the infrastructure of Internet service application traffic places on the infrastructure of ISPs. Multiple
providers (ISPs). Multiple measurements (e.g., measurements (e.g., [ipoque_Internet_Study]) have shown that P2P
[Internet_Study_2008-2009]) have shown that P2P traffic has become a traffic has become a major type of traffic on some networks.
major type of traffic on some networks. Furthermore, the Furthermore, the inefficiency of network-agnostic peering (at the P2P
inefficiency of network-agnostic peering (at the P2P transmission transmission level) leads to unnecessary traversal across network
level) leads to unnecessary traversal across network domains or domains or spanning the backbone of a network [RFC5693].
spanning the backbone of a network [RFC5693].
Using network information alone to construct more efficient P2P Using network information alone to construct more efficient P2P
swarms is not sufficient to reduce P2P traffic in access networks, as swarms is not sufficient to reduce P2P traffic in access networks, as
the total access upload traffic is equal to the total access download the total access upload traffic is equal to the total access download
traffic in a traditional P2P system. On the other hand, it is traffic in a traditional P2P system. On the other hand, it is
reported that P2P traffic is becoming the dominant traffic on the reported that P2P traffic is becoming the dominant traffic on the
access networks of some networks, reaching as high as 50-60% on the access networks of some networks, reaching as high as 50-60% on the
downlinks and 60-90% on the uplinks ([DCIA], [ICNP], downlinks and 60-90% on the uplinks [DCIA] [ICNP] [ipoque_P2P_Survey]
[ipoque.P2P_survey.], [P2P_file_sharing]). Consequently, it becomes [P2P_File_Sharing]. Consequently, it becomes increasingly important
increasingly important to reduce upload access traffic, in addition to reduce upload access traffic, in addition to cross-domain and
to cross-domain and backbone traffic. backbone traffic.
The inefficiency is also represented when traffic is sent upstream as The inefficiency of P2P is also observed when traffic is sent
many times as there are remote peers interested in getting the upstream as many times as there are remote peers interested in
corresponding information. For example, the P2P application transfer getting the corresponding information. For example, the P2P
completion times remain affected by potentially (relatively) slow application transfer completion times remain affected by potentially
upstream transmission. Similarly, the performance of real-time P2P (relatively) slow upstream transmission. Similarly, the performance
applications may be affected by potentially (relatively) higher of real-time P2P applications may be affected by potentially
upstream latencies. (relatively) higher upstream latencies.
3.2. P2P cache: a complex in-network storage 3.2. P2P Cache: A Complex Type of In-Network Storage
An effective technique to reduce P2P infrastructural stress and An effective technique to reduce P2P infrastructural stress and
inefficiency is to introduce in-network storage. The existing in- inefficiency is to introduce in-network storage. A survey of
network storage systems can be found in [RFC6392]. existing in-network storage systems can be found in [RFC6392].
In the current Internet, in-network storage is introduced as P2P In the current Internet, in-network storage is introduced as P2P
caches, either transparently or explicitly as a P2P peer. To provide caches, either transparently or explicitly as a P2P peer. To provide
service to a specific P2P application, the P2P cache server must service to a specific P2P application, the P2P cache server must
support the specific signaling and transport protocols of the support the specific signaling and transport protocols of the
specific P2P application. This can lead to substantial complexity specific P2P application. This can lead to substantial complexity
for the P2P Cache vendor. for the P2P cache vendor.
First, there are many P2P applications on the Internet (e.g., First, there are many P2P applications on the Internet (e.g.,
BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast,
Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming).
Consequently, a P2P cache vendor faces the challenge of supporting a Consequently, a P2P cache vendor faces the challenge of supporting a
large number of P2P application protocols, leading to product large number of P2P application protocols, leading to product
complexity and increased development cost. complexity and increased development cost.
Furthermore, a specific P2P application protocol may evolve Second, a specific P2P application protocol may evolve continuously
continuously, to add new features or fix bugs. This forces a P2P to add new features or fix bugs. This in turn forces a P2P cache
cache vendor to continuously update to track the changes of the P2P vendor to continuously monitor application updates to track such
application, leading to product complexity and increased costs. changes, leading to product complexity and increased costs.
Third, many P2P applications use proprietary protocols or support Third, many P2P applications use proprietary protocols or support
end-to-end encryption. This can render P2P caches ineffective. So end-to-end encryption. This can render P2P caches ineffective.
these three problems make the P2P cache as a network middle-box, hard Therefore, these three problems make it difficult to use the P2P
to support these P2P application distribution in their own ways. cache as a network middlebox to support P2P application distribution.
Finally, a P2P cache is likely to be much better connected to end Finally, an end host has better connectivity and connection quality
hosts than remote peers that connected to end hosts. Without the to a P2P cache than to a remote peer. Without the ability to manage
ability to manage bandwidth usage, the P2P cache may increase the bandwidth usage, the P2P cache may increase the volume of download
volume of download traffic, which runs counter to the reduction of traffic, which runs counter to the reduction of upload access
upload access traffic. traffic.
3.3. Ineffective integration of P2P applications 3.3. Ineffective Integration of P2P Applications
As P2P applications evolve, it has become increasingly clear that As P2P applications evolve, it has become increasingly clear that
usage of in-network resources can improve user experience. For usage of in-network resources can improve the user's experience. For
example, multiple P2P streaming systems seek additional in-network example, multiple P2P streaming systems seek additional in-network
resources during a flash crowd, such as just before a major live resources during a flash crowd, such as just before a major live
streaming event. In asymmetric networks when the aggregated upload streaming event. In asymmetric networks, when the aggregated upload
bandwidth of a channel cannot meet the download demand, a P2P bandwidth of a channel cannot meet the download demand, a P2P
application may seek additional in-network resources to maintain a application may seek additional in-network resources to maintain a
stable system. stable system.
However, some P2P applications using in-network infrastructural However, some P2P applications using in-network infrastructural
resources require flexibility in implementing resource allocation resources require flexibility in implementing resource allocation
policies. A major competitive advantage of many successful P2P policies. A major competitive advantage of many successful P2P
systems is their substantial expertise in how to most efficiently systems is their substantial expertise in how to most efficiently
utilize peer and infrastructural resources. For example, many live utilize peer and infrastructural resources. For example, many live
P2P systems have specific algorithms to select those peers that P2P systems have specific algorithms to select those peers that
behave as stable, higher-bandwidth sources. Similarly, the higher- behave as stable, higher-bandwidth sources. Similarly, the higher-
bandwidth sources frequently use algorithms to chose to which peers bandwidth sources frequently use algorithms to choose to which peers
the source should send content. Developers of these systems continue the source should send content. Developers of these systems continue
to fine-tune these algorithms over time. to fine-tune these algorithms over time.
To permit developers to evolve and fine-tune their algorithms and To permit developers to evolve and fine-tune their algorithms and
policies, the in-network storage should expose basic mechanisms and policies, the in-network storage should expose basic mechanisms and
allow as much flexibility as possible to P2P applications. This allow as much flexibility as possible to P2P applications. This
conforms to the end-to-end systems principle and allows innovation conforms to the end-to-end systems principle and allows innovation
and satisfaction of specific business goals. Existing techniques for and satisfaction of specific business goals. Existing techniques for
P2P application in-network storage lack these capabilities. in-network storage in P2P applications lack these capabilities.
4. Usage Scenarios 4. Usage Scenarios
Usage scenarios are presented to illustrate the problems in both Usage scenarios are presented to illustrate the problems in both
Content Distribution Network (CDN) and P2P scenarios. Content Distribution Network (CDN) and P2P scenarios.
4.1. BitTorrent 4.1. BitTorrent
When a BitTorrent client A uploads a block to multiple peers, the When a BitTorrent client A uploads a block to multiple peers, the
block traverses the last-mile uplink once for each peer. And after block traverses the last-mile uplink once for each peer. After that,
that, the peer B who just received the block from A also needs to the peer B that just received the block from A also needs to upload
upload through its own last-mile uplink to others when sharing this through its own last-mile uplink to others when sharing this block.
block. This is not an efficient use of the last-mile uplink. With This is not an efficient use of the last-mile uplink. With an
in-network storage server however, the BitTorrent client may upload in-network storage server, however, the BitTorrent client may upload
the block to its in-network storage. Peers may retrieve the block 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- from the in-network storage, reducing the amount of data on the
mile uplink. If supported by the in-network storage, a peer can also last-mile uplink. If supported by the in-network storage, a peer can
save the block in its own in-network storage while it is being also save the block in its own in-network storage while it is being
retrieved; the block can then be uploaded from the in-network storage retrieved; the block can then be uploaded from the in-network storage
to other peers. to other peers.
As previously discussed, BitTorrent or other P2P applications As previously discussed, BitTorrent or other P2P applications
currently cannot explicitly manage which content is placed in the currently cannot explicitly manage which content is placed in the
existing P2P caches, nor access and resource control polices. existing P2P caches, nor can they manage access and resource control
Applications need to retain flexibility to control the content policies. Applications need to retain flexibility to control the
distribution policies and topology among peers. content distribution policies and topology among peers.
4.2. Content Publisher 4.2. Content Publisher
Content publishers may also utilize in-network storage. For example, Content publishers may also utilize in-network storage. For example,
consider a P2P live streaming application. A Content Publisher consider a P2P live streaming application. A Content Publisher
typically maintains a small number of sources, each of which typically maintains a small number of sources, each of which
distributes blocks in the current play buffer to a set of the P2P distributes blocks in the current play buffer to a set of P2P peers.
peers.
Some content publishers use another hybrid content distribution Some content publishers use another hybrid content distribution
approach incorporating both P2P and CDN modes. As an example, approach incorporating both P2P and CDN modes. As an example,
Internet TV may be implemented as a hybrid CDN/P2P application by Internet TV may be implemented as a hybrid CDN/P2P application by
distributing content from central servers via a CDN, and also distributing content from central servers via a CDN, and also
incorporating a P2P mode amongst endhosts and set-top boxes. In- incorporating a P2P mode amongst end hosts and set-top boxes.
network storage may be beneficial to hybrid CDN/P2P applications as In-network storage may be beneficial to hybrid CDN/P2P applications
well to support P2P distribution and to enable content publisher as well to support P2P distribution and to enable content publisher
standard interfaces and controls. standard interfaces and controls.
However, there is no standard interface for different content However, there is no standard interface for different content
publishers to access in-network storage. One streaming content publishers to access in-network storage. One streaming content
publisher may need the existing in-network storage to support publisher may need the existing in-network storage to support
streaming signaling or such capability, such as transcoding streaming signaling or another such capability, such as transcoding
capability, bitmap information, intelligent retransmission, etc, capability, bitmap information, intelligent retransmission, etc.,
while a different content publisher may only need the in-network while a different content publisher may only need the in-network
storage to distribute files. However it is reasonable that the storage to distribute files. However, it is reasonable that the
application services are only supported by content publisher's application services are only supported by content publishers'
original servers and clients, and intelligent data plane transport original servers and clients, and intelligent data plane transport
for those content publishers are supported by in-network storage. for those content publishers are supported by in-network storage.
A content publisher also benefits from a standard interface to access A content publisher also benefits from a standard interface to access
in-network storage servers provided by different providers. The in-network storage servers provided by different providers. The
standard interface must allow the content publisher to retain control standard interface must allow content publishers to retain control
over content placed in their own in-network storage, and grant access over content placed in their own in-network storage and to grant
and resources only to the desired endhosts and peers. access and resources only to the desired end hosts and peers.
In the hybrid CDN/P2P scenario, if only the endhosts can store In the hybrid CDN/P2P scenario, if only the end hosts can store
content in the in-network storage server, the content must be content in the in-network storage server, the content must be
downloaded and then uploaded over the last-mile access link before downloaded and then uploaded over the last-mile access link before
another peer may retrieve it from a in-network storage server. Thus, another peer may retrieve it from an in-network storage server.
in this deployment scenario, it may be advantageous for a content Thus, in this deployment scenario, it may be advantageous for a
publisher or CDN provider to store content in in-network storage content publisher or CDN provider to store content in in-network
servers. storage servers.
5. Security Considerations 5. Security Considerations
There are several security considerations to the in-network storage. There are several security considerations related to in-network
storage.
5.1. Denial of Service Attacks 5.1. Denial-of-Service Attacks
An attacker can try to consume a large portion of the in-network An attacker can try to consume a large portion of the in-network
storage, or exhaust the connections of the in-network storage through storage, or exhaust the connections of the in-network storage through
a Denial of Service (DoS) attack. Authentication, authorization and a denial-of-service (DoS) attack. Authentication, authorization, and
accounting mechanisms should be considered in the cross domain accounting mechanisms should be considered in the cross-domain
environment. Limitation of access from an administrative domain sets environment. Limitation of access from an administrative domain sets
up barriers for content distribution. up barriers for content distribution.
5.2. Copyright and Legal Issues 5.2. Copyright and Legal Issues
Copyright and other laws may prevent the distribution of certain Copyright and other laws may prevent the distribution of certain
content in various localities. In-network storage operators may content in various localities. In-network storage operators may
adopt system-wide ingress or egress filters to implement necessary adopt system-wide ingress or egress filters to implement necessary
policies for storing or retrieving content, and applications may policies for storing or retrieving content, and applications may
apply DRM to the data stored in the network storage. However, the apply Digital Rights Management (DRM) to the data stored in the
specification and implementation of such policies (e.g., filtering network storage. However, the specification and implementation of
and DRM) is not in scope for the problem this document proposes such policies (e.g., filtering and DRM) is not in scope for the
solving. problem this document proposes to solve.
5.3. Traffic Analysis 5.3. Traffic Analysis
If the content is stored in the provider-based in-network storage, If the content is stored in the provider-based in-network storage,
there may be a privacy risk that the provider can correlate the there may be a risk to privacy: a malicious service provider could
people who are accessing the same data object using the same object use some link that a victim user is interested in, estimate that
identity. This correlation can be used to presume that they have the another user accessing the same data may have the same interest, and
same interest, so as to use it as a basis for a phishing attack. use this information as a basis to perform a phishing attack on the
other user.
5.4. Modification of Information 5.4. Modification of Information
The modification threat is the danger that some unauthorized entity This type of threat means that some unauthorized entity may alter
may alter in-transit in-network storage access messages generated on in-transit in-network storage access messages generated on behalf of
behalf of an authorized principal in such a way as to effect an authorized principal in such a way as to effect unauthorized
unauthorized management operations, including falsifying the value of management operations, including falsifying the value of an object.
an object. This threat may result in false data being supplied This threat may result in false data being supplied either because
either through the data on a legitimate store being modified, or the data on a legitimate store is modified or because a bogus store
through a bogus store being introduced into the network. is introduced into the network.
5.5. Masquerade 5.5. Masquerade
A type of threat action whereby an unauthorized entity gains access This type of threat means that an unauthorized entity gains access to
to a system or performs a malicious act by illegitimately posing as a system or performs a malicious act by illegitimately posing as an
an authorized entity. In the context of this spec, when accessing authorized entity. In the context of this specification, when
in-network storage, one malicious end host can try to act as another accessing in-network storage, one malicious end host can masquerade
authorized end host or application server to access a protected as another authorized end host or application server to access a
resource in the in-network storage. protected resource in the in-network storage.
5.6. Disclosure 5.6. Disclosure
The disclosure threat is the danger of eavesdropping on the exchanges This type of threat involves the danger of someone eavesdropping on
between in-network storage and application clients. Protecting exchanges between in-network storage and application clients.
against this threat may be required as a matter of application Protecting against this threat may be required as a matter of
policy. application policy.
5.7. Message Stream Modification 5.7. Message Stream Modification
The message stream modification threat is the danger that messages This type of threat means that messages may be maliciously
may be maliciously re-ordered, delayed or replayed to an extent which re-ordered, delayed, or replayed to an extent greater than what would
is greater than can occur through natural network system, in order to occur in a natural network system, in order to effect unauthorized
effect unauthorized management operations to in-network storage. If management operations on in-network storage. If the middlebox (such
the middle box, such like NAT (network address translator) or proxy as a Network Address Translator (NAT)) or proxy between an end host
between an end host and in-network storage is compromised, it is easy and in-network storage is compromised, it is easy to do a stream
to do the stream modification attack. modification attack.
6. IANA Considerations
There are no IANA considerations in this document.
7. Acknowledgments 6. Acknowledgments
We would like to thank the following people for contributing to this We would like to thank the following people for contributing to this
document: document:
David Bryan
Ronald Bonica Ronald Bonica
David Bryan
Kar Ann Chew Kar Ann Chew
Roni Even
Lars Eggert Lars Eggert
Francois Le Faucheur Roni Even
Adrian Farrel Adrian Farrel
Yingjie Gu Yingjie Gu
David Harrington David Harrington
Leif Johansson Leif Johansson
Francois Le Faucheur
Hongqiang Liu Hongqiang Liu
Tao Ma Tao Ma
Borje Ohlman Borje Ohlman
Akbar Rahman Akbar Rahman
Robert Sparks
Peter Saint-Andre Peter Saint-Andre
Robert Sparks
Sean Turner Sean Turner
Yu-shun Wang Yu-shun Wang
Richard Woundy Richard Woundy
Yunfei Zhang Yunfei Zhang
8. Informative References 7. Informative References
[Internet_Study_2008-2009]
"Internet Study 2008/2009", <http://www.ipoque.com/
resources/internet-studies/internet-study-2008_2009>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- [DCIA] Parker, A., "P2P Media Summit presentation", Distributed
Network Storage Systems", RFC 6392, October 2011. Computing Industry Association, October 2006,
<http://www.dcia.info/activities/p2pmsla2006/
CacheLogic.ppt>.
[Data_Lockers] [Data_Lockers]
Yang, Y., "Open Content Distribution using Data Lockers", Yang, Y., "Open Content Distribution using Data Lockers",
<http://cs-www.cs.yale.edu/homes/yry/projects/p4p/ CoXNet Workshop, Beijing, China, November 2010,
<http:// cs-www.cs.yale.edu/homes/yry/projects/p4p/
open-data-lockers-nov-2010-coxnet.pdf>. open-data-lockers-nov-2010-coxnet.pdf>.
[I-D.ietf-p2psip-base] [ICNP] Wu, H., "Challenges and Opportunities of Internet
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Developments in China", ICNP 2007 Keynote Speech,
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) October 2007,
Base Protocol", draft-ietf-p2psip-base-21 (work in <http://www.ieee-icnp.org/2007/keynote_D.html>.
progress), March 2012.
[DCIA] http://www.dcia.info, "Distributed Computing Industry
Association".
[ipoque.P2P_survey.]
"Emerging Technologies Conference at MIT", Sept. 2007.
[P2P_file_sharing]
Parker, A., "The true picture of peer-to-peer
filesharing", July 2004.
[Octoshape]
"http://www.octoshape.com/?page=company/about".
[PPLive] "http://www.synacast.com/products/".
[ICNP] Wu, H., "Challenges and opportunities of Internet
developments in China, ICNP 2007 Keynote", Oct. 2007.
Appendix A. Other Related Work in IETF
(To the RFC editor: Please remove this section and the related
references in this section upon publication. The purpose of this
section is to give the IESG and RFC editor a better understanding of
the current P2P related work in IETF and the relationship with DECADE
WG.)
Note that DECADE WG's work is independent of current IETF work on
P2P. The ALTO work is aimed for better peer selection and the RELOAD
[I-D.ietf-p2psip-base] protocol is used for P2P overlay maintenance
and resource discovery.
The Peer to Peer Streaming Protocol effort in the IETF is
investigating the specification of signaling protocols (called the
PPSP tracker protocol and peer protocol) for multiple entities (e.g.,
intelligent endpoints, caches, content distribution network nodes,
and/or other edge devices) to participate in P2P streaming systems in
both fixed and mobile Internet. As discussed in the PPSP problem
statement, one important PPSP use case is the support of an in-
network edge cache for P2P Streaming. However, this approach to
providing in-network cache has different applicability, different
objectives and different implications for the in-network cache
operator. The goal of DECADE WG is to provide in-network storage
service that can be used for any application transparently to the in-
network storage operator: it can be used for any P2P Streaming
application (whether it supports PPSP protocols or not), for any
other P2P application, and for non P2P applications that simply want
to benefit from in-network storage. With DECADE, the operator is
providing a generic in-network storage service that can be used by
any application without application involvement or awareness by the
operator; in the PPSP cache use case, the cache operator is
participating in the specific P2P streaming service.
DECADE and PPSP can both contribute independently, and (where
appropriate) simultaneously, to making content available closer to
peers. Here are a number of example scenarios:
A given network supports DECADE in-network storage, and its CDN
nodes do not participate as PPSP Peers for a given "stream" (e.g.,
because no CDN arrangement has been put in place between the
content provider and the particular network provider). In that
case, PPSP Peers will all be "off-net" but will be able to use
DECADE in-network storage to exchange chunks.
A given network does not support DECADE in-network storage, and [P2P_File_Sharing]
(some of) its CDN nodes participate as PPSP Peers for a given Casadesus-Masanell, R. and A. Hervas-Drane, "Peer-to-Peer
"stream" (e.g., say because an arrangement has been put in place File Sharing and the Market for Digital Information
between the content provider and the particular network provider). Goods", Journal of Economics & Management Strategy,
In that case, the CDN nodes will participate as in-network PPSP Vol. 19, No. 2, pp. 333-373, Summer 2010.
Peers. The off-net PPSP Peers (i.e., end users) will be able to
get chunks from the in-network CDN nodes (using PPSP protocols
with the CDN nodes).
A given network supports DECADE in-network storage, and (some of) [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
its CDN nodes participate as PPSP Peers for a given "stream" Optimization (ALTO) Problem Statement", RFC 5693,
(e.g., because an arrangement has been put in place between the October 2009.
content provider and the particular network provider). In that
case, the CDN nodes will participate as in-network PPSP Peers.
The off-net PPSP Peers (i.e., end users) will be able to get
chunks from the in-network CDN nodes (using PPSP protocols with
the CDN nodes) as well as be able to get chunks / share chunks
using DECADE in-network storage populated by PPSP Peers (both off-
net end-users and in-network CDN Nodes).
PPSP and DECADE jointly provide P2P streaming service for [RFC6392] Alimi, R., Ed., Rahman, A., Ed., and Y. Yang, Ed., "A
heterogeneous networks including both fixed and mobile connections Survey of In-Network Storage Systems", RFC 6392,
and enables the mobile nodes to use DECADE. In this case there October 2011.
may be some solutions that require more information in PPSP
tracker protocol, e.g., the mobile node can indicate its DECADE
in-network proxy to the PPSP tracker and the following requesting
peer can finish data transfer with the DECADE proxy.
An ALTO (Application Layer Traffic Optimization) server provides P2P [ipoque_Internet_Study]
applications with network information so that they can perform Schulze, H. and K. Mochalski, "Internet Study 2008/2009",
better-than-random initial peer selection [RFC5693]. However, there 2009, <http://www.ipoque.com/resources/internet-studies>.
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 traditional P2P system. Consequently, it becomes
increasingly important to complement the ALTO effort and reduce
upload access traffic, in addition to cross-domain and backbone
traffic.
The IETF Low Extra Delay Background Transport (LEDBAT) Working Group [ipoque_P2P_Survey]
is focusing on techniques that allow large amounts of data to be "ipoque's 2007 P2P Survey to be presented at Technology
consistently transmitted without substantially affecting the delays Review's Emerging Technologies Conference at MIT",
experienced by other users and applications. It is expected that August 2007, <http://www.ipoque.com/en/news-events/
some P2P applications would start using such techniques, thereby press-center/press-releases/2007/
somewhat alleviating the perceivable impact (at least on other ipoque%C2%B4s-2007-p2p-survey-to-be-presented-at-
applications) of their high volume traffic. However, such techniques technology>.
may not be adopted by all P2P applications. Also, when adopted,
these techniques do not remove all inefficiencies, such as those
associated with traffic being sent upstream as many times as there
are remote peers interested in getting the corresponding information.
For example, the P2P application transfer completion times remain
affected by potentially (relatively) slow upstream transmission.
Similarly, the performance of real-time P2P applications may be
affected by potentially (relatively) higher upstream latencies.
Authors' Addresses Authors' Addresses
Haibin Song Haibin Song
Huawei Huawei
101 Software Avenue, Yuhua District, 101 Software Avenue, Yuhua District
Nanjing, Jiangsu Province 210012 Nanjing, Jiangsu Province 210012
China China
Phone: +86-25-56624792 EMail: haibin.song@huawei.com
Email: haibin.song@huawei.com
Ning Zong Ning Zong
Huawei Huawei
101 Software Avenue, Yuhua District, 101 Software Avenue, Yuhua District
Nanjing, Jiangsu Province 210012 Nanjing, Jiangsu Province 210012
China China
Phone: +86-25-56624760 EMail: zongning@huawei.com
Email: zongning@huawei.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
Email: yry@cs.yale.edu EMail: yry@cs.yale.edu
Richard Alimi Richard Alimi
Google Google
Email: ralimi@google.com EMail: ralimi@google.com
 End of changes. 77 change blocks. 
349 lines changed or deleted 240 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/