draft-ietf-decade-problem-statement-04.txt   draft-ietf-decade-problem-statement-05.txt 
DECADE H. Song DECADE H. Song
Internet-Draft N. Zong Internet-Draft N. Zong
Intended status: Informational Huawei Intended status: Informational Huawei
Expires: April 14, 2012 Y. Yang Expires: August 11, 2012 Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
October 12, 2011 February 8, 2012
DECoupled Application Data Enroute (DECADE) Problem Statement DECoupled Application Data Enroute (DECADE) Problem Statement
draft-ietf-decade-problem-statement-04 draft-ietf-decade-problem-statement-05
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 (the download traffic may increase because the in- within the network. Traditional caches (e.g., P2P and Web caches)
network storage is likely much better connected). Traditional caches provide such storage, but they are complex (due to explicitly
(e.g., P2P and Web caches) provide such storage, but they are complex supporting individual P2P application protocols and cache refresh
(due to explicitly supporting individual P2P application protocols mechanisms) and they do not allow users to manage access to content
and cache refreshing mechanisms) and they do not have the feature to in the cache. For example, content providers wishing to use in-
allow users to manage access to content in the cache. For example, network storage cannot easily control cache access and resource usage
Content Providers cannot easily control cache access and resource policies to satisfy their own requirements. This document discusses
usage policies to satisfy their own requirements. In this document, the introduction of in-network storage for P2P applications, and
a content provider is also the user of in-network storage. This shows the need for a standard protocol for accessing this storage.
document discusses the introduction of in-network storage for P2P
applications, and shows the need for a standard protocol for
accessing this storage. It can also be used by other applications
with similar requirements.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2012.
Copyright Notice This Internet-Draft will expire on August 11, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright Notice
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. P2P infrastructural stress and inefficiency . . . . . . . 6 3.1. P2P infrastructural stress and inefficiency . . . . . . . 4
3.2. P2P cache: a complex in-network storage . . . . . . . . . 6 3.2. P2P cache: a complex in-network storage . . . . . . . . . 5
3.3. Ineffective integration of P2P applications . . . . . . . 7 3.3. Ineffective integration of P2P applications . . . . . . . 6
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 7
5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.3. CDN/P2P hybrid . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 8
6.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 11 5.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 8
6.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 11 5.4. Modification of Information . . . . . . . . . . . . . . . 8
6.3. Privacy issue . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Masquerade . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.6. Disclosure . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 5.7. Message Stream Modification . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
P2P applications, including both P2P streaming and P2P filesharing P2P applications, including both P2P streaming and P2P filesharing
applications, make up a large fraction of the traffic in many ISP applications, make up a large fraction of the traffic in many ISP
networks today. One way to reduce bandwidth usage by P2P networks today. One way to reduce bandwidth usage by P2P
applications is to introduce storage capabilities in the networks. applications is to introduce storage capabilities in the networks.
Allowing P2P applications to store and retrieve data from inside Allowing P2P applications to store and retrieve data from inside
networks can reduce traffic on the last-mile uplink, as well as networks can reduce traffic on the last-mile uplink, as well as on
backbone and transit links. backbone and transit links.
P2P caches provide in-network storage and have been deployed in some P2P caches provide in-network storage and have been deployed in some
networks. But the current P2P caching architecture poses challenges networks. However, the current P2P caching architecture poses
to both P2P cache vendors and P2P application developers. For P2P challenges to both P2P cache vendors and P2P application developers.
cache vendors, it is challenging to support a number of continuously For P2P cache vendors, it is challenging to support a number of
evolving P2P application protocols, due to lack of documentation, continuously evolving P2P application protocols, due to lack of
ongoing protocol changes, and rapid introduction of new features by documentation, ongoing protocol changes, and rapid introduction of
P2P applications. For P2P applications, closed P2P caching systems new features by P2P applications. For P2P applications, closed P2P
limit P2P applications from effectively utilizing in-network storage. caching systems limit P2P applications from effectively utilizing in-
In particular, P2P caches typically do not allow users to explicitly network storage. In particular, P2P caches typically do not allow
store content into in-network storage. They do not allow users to users to explicitly store content into in-network storage. They also
implement control over the content that has been placed into the in- do not allow users to implement control over the content that has
network storage either. been placed into the in-network storage.
P2P applications suffer decreased efficiency, and the network
infrastructure suffers increased load because there is no
standardized interface for accessing storage and data transport
services in the Internet.
Both of these challenges can be effectively addressed by using an Both of these challenges can be effectively addressed by using an
open, standard protocol to access in-network storage. P2P open, standard protocol to access in-network storage. 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.
This document introduces DECADE, a standard interface for various P2P In essence, coupling of the signaling and data access makes in-
applications to access storage and data transport services in the network storage very complex to support various application services.
network to improve their efficiency and reduce load on the network However, these applications have common requirements for data access,
infrastructure. making it possible to develop a standard protocol.
With DECADE, P2P applications can still use their native protocols
for signaling and data transport. However, they may use a standard
protocol for data access incorporating in-network storage, and fall
back to their native data transport protocols if in-network storage
is not available or not used.
In essence, an open, standard protocol to access in-network storage
provides an alternative mechanism for P2P application data access
that is decoupled from P2P application control and signaling. This
decoupling leads to many advantages, which is explained further in
Section 4.
And further, either the existing P2P cache or any new type of in-
network storage should be deployed near the edge of the ISP's network
so as to gain better performance.
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 in-
network storage system. network storage system.
In-network Storage: A service inside a network that provides in-network storage: A service inside a network that provides
storage and bandwidth to network applications. In-network storage storage and bandwidth to network applications. In-network storage
may reduce upload/transit/backbone traffic and improve network may reduce upload/transit/backbone traffic and improve network
application performance. application performance.
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.
Content Publisher: An entity that originates content.
3. The Problems 3. The Problems
The emergence of peer-to-peer (P2P) as a major network application The emergence of peer-to-peer (P2P) as a major network application
(esp. P2P file sharing and streaming apps) has led to substantial (especially P2P file sharing and streaming) has led to substantial
opportunities. The P2P paradigm can be utilized in designing highly opportunities. The P2P paradigm can be utilized to design highly
scalable and robust applications at low cost, compared with scalable and robust applications at low cost, compared to the
traditional client-server paradigms. For example, CNN reported that traditional client-server paradigm. For example, CNN reported that
P2P streaming by Octoshape played a major role in its distribution of P2P streaming by Octoshape played a major role in its distribution of
the historic inauguration address of President Obama[Octoshape]. the historic inauguration address of President Obama[Octoshape].
PPLive, one of the largest P2P streaming vendors, is able to PPLive, one of the largest P2P streaming vendors, is able to
distribute large-scale, live streaming programs to more than 2 distribute large-scale, live streaming programs to more than 2
million users with only a handful of servers[PPLive]. million users with only a handful of servers [PPLive].
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 substantial stress particular problem facing P2P applications is the additional stress
that they place on the network infrastructure. Also, lack of that they place on the network infrastructure. Furthermore, lack of
infrastructure support can lead to unstable P2P application infrastructure support can lead to unstable P2P application
performance during peer churns and flash crowd. Here flash crowds performance during peer churns and flash crowds, when a large group
means a large group of application users begin to access the same of users begin to retrieve the content during a short period of time.
service during a very short period of time, which is a challenge to These problems are now discussed in further detail.
the system. Below we elaborate on the problems in more 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 Internet service
providers (ISPs). Multiple measurements (e.g., [ipoque]) have shown providers (ISPs). Multiple measurements (e.g., [Internet Study 2008/
that P2P traffic has become a major type of traffic on some networks. 2009][Internet_Study_2008-2009]) have shown that P2P traffic has
Furthermore, network-agnostic peering (P2P transmission level) leads become a major type of traffic on some networks. Furthermore, the
to unnecessary traversal across network domains or spanning the inefficiency of network-agnostic peering (at the P2P transmission
backbone of a network, leading to network inefficiency [RFC5693]. level) leads to unnecessary traversal across network domains or
spanning the backbone of a network [RFC5693].
An ALTO (Application Layer Traffic Optimization) server provides P2P Using network information alone to construct more efficient P2P
applications with network information so that they can perform swarms is not sufficient to reduce P2P traffic in access networks, as
better-than-random initial peer selection [RFC5693]. 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 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 traffic in a traditional P2P system. On the other hand, it is
P2P traffic is becoming the dominant traffic on the access networks reported that P2P traffic is becoming the dominant traffic on the
of some networks, reaching as high as 50-60% at the down-links and access networks of some networks, reaching as high as 50-60% on the
60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], downlinks and 60-90% on the uplinks ([DCIA], [ICNP],
[P2P_file_sharing]). Consequently, it becomes increasingly important [ipoque.P2P_survey.], [P2P_file_sharing]). Consequently, it becomes
to complement the ALTO effort and reduce upload access traffic, in increasingly important to reduce upload access traffic, in addition
addition to cross-domain and backbone traffic. to cross-domain and backbone traffic.
The IETF Low Extra Delay Background Transport (LEDBAT) Working Group The inefficiency is also represented when traffic is sent upstream as
is focusing on techniques that allow large amounts of data to be many times as there are remote peers interested in getting the
consistently transmitted without substantially affecting the delays corresponding information. For example, the P2P application transfer
experienced by other users and applications. It is expected that completion times remain affected by potentially (relatively) slow
some P2P applications would start using such techniques, thereby upstream transmission. Similarly, the performance of real-time P2P
somewhat alleviating the perceivable impact (at least on other applications may be affected by potentially (relatively) higher
applications) of their high volume traffic. However, such techniques upstream latencies.
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.
3.2. P2P cache: a complex in-network storage 3.2. P2P cache: a complex 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. inefficiency is to introduce in-network storage.
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 be evolving Furthermore, a specific P2P application protocol may evolve
continuously, to add new features or fix bugs. This forces a P2P continuously, to add new features or fix bugs. This forces a P2P
cache vendor to continuously update to track the changes of the P2P cache vendor to continuously update to track the changes of the P2P
application, leading to product complexity, high cost, and low application, leading to product complexity and increased costs.
reliability.
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. end-to-end encryption. This can render P2P caches ineffective.
3.3. Ineffective integration of P2P applications Finally, a P2P cache is likely to be much better connected to end
hosts than to remote peers. Without the ability to manage bandwidth
As P2P applications evolve, it is becoming increasingly clear that usage, the P2P cache may increase the volume of download traffic,
they will need in-network resources to provide positive user which runs counter to the reduction of upload access traffic.
experiences. For example, multiple P2P streaming systems seek
additional in-network resources during a 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.
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 specific algorithms to select those peers
that behave as stable, higher bandwidth sources. They continue to
fine-tune such algorithms. In other words, in-network storage should
expose 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.
4. Motivation
DECADE aims to 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 aims to provide a standard interface
for various P2P applications (both content publishers and end users)
to access in-network storage. This decoupling of P2P data access
from P2P application control and signaling reduces the complexity of
in-network storage services. Furthermore, DECADE is aimed to provide
basic access mechanisms and allows P2P applications to implement
flexible policies to create an ecosystem for application innovation
and various business goals. Besides that, it also improves the
availability of P2P contents because the in-network storage is
always-on.
-----------+
| DECADE |
| v
+--------------------+
| In-network Storage |
+--------------------+
DECADE ^ DECADE ^
| |
+-------------v-+ +-v-------------+
| P2P | | Content |
| application | | publishers |
| clients | +---------------+
+---------------+
| ^
| |
+-------------+
P2P application
native protocol
Figure 1 Overview 3.3. Ineffective integration of P2P applications
5. Usage Scenarios As P2P applications evolve, it has become increasingly clear that
usage of in-network resources can improve user experience. For
example, multiple P2P streaming systems seek additional in-network
resources during a 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.
Usage scenarios are presented to illustrate how DECADE in-network However, some P2P applications using in-network infrastructural
storage may be used in both CDN and P2P scenarios. Interactions with resources require flexibility in implementing resource allocation
in-network storage are described at an abstract level so as not to policies. A major competitive advantage of many successful P2P
constrain future protocol development. systems is their substantial expertise in how to most efficiently
utilize peer and infrastructural resources. For example, many live
P2P systems have specific algorithms to select those peers that
behave as stable, higher-bandwidth sources. Similarly, the higher-
bandwidth sources frequently use algorithms to chose to which peers
the source should send content. Developers of these systems continue
to fine-tune these algorithms over time.
5.1. BitTorrent To permit developers to evolve and fine-tune their algorithms and
policies, the in-network storage should expose basic mechanisms and
allow as much flexibility as possible to P2P applications. 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.
BitTorrent may be integrated with DECADE to be more network efficient 4. Usage Scenarios
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.
We now describe in more detail how BitTorrent can utilize DECADE. Usage scenarios are presented to illustrate the problems in both CDN
For illustration, we assume that both the BitTorrent client (A) and and P2P scenarios.
its peer (B) utilize in-network storage. When A requests a block,
peer B replies with a 'redirect' message indicating that the content
should be retrieved from in-network storage. If the peer B had not
previously stored the content in in-network storage, it uploads the
block before A retrieves it. If there is support, A may first copy
the block to in-network storage that is nearer to it before
retrieving it.
Note that this requires extensions to the BitTorrent protocol. While 4.1. BitTorrent
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 a standard protocol.
This example has illustrated how utilizing DECADE can increase When a BitTorrent client A uploads a block to multiple peers, the
BitTorrent's network efficiency. First, notice that peer B does not block traverses the last-mile uplink once for each peer. And after
utilize any uplink bandwidth if the block was already present in its that, the peer B who just received the block from A also needs to
in-network storage. Second, notice that the block may be copied to upload through its own last-mile uplink to others when sharing this
in-network storage nearer to A. When A wishes to share the block with block. This is not an efficient use of the last-mile uplink. With
another peer (say, peer C) that supports DECADE, it may upload in-network storage server however, the BitTorrent client may upload
directly from its in-network storage, again avoiding usage of the the block to its in-network storage. Peers may retrieve the block
last-mile uplink. from the in-network storage, reducing the amount of data on the last-
mile uplink. If supported by the in-network storage, a peer can 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
to other peers.
This technique can be applied to other P2P applications as well. As previously discussed, BitTorrent or other P2P applications
Since P2P applications use a standard for communicating with in- currently cannot explicitly manage which content is placed in the
network storage, they no longer require in-network storage to existing P2P caches, nor can they manage access and resource control
explicitly support their protocol. P2P applications retain the polices. Applications need to retain flexibility to control the
ability to explicitly manage which content is placed in in-network content distribution policies and topology among peers.
storage, as well as access and resource control polices.
5.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 the P2P
peers. peers.
Consider a case where the Content Publisher owns an in-network Some content publishers use another hybrid content distribution
storage account within ISP A. If there are multiple P2P peers within approach incorporating both P2P and CDN modes. As an example,
ISP A, the Content Publisher may utilize DECADE to distribute content Internet TV may be implemented as a hybrid CDN/P2P application by
to the peers. distributing content from central servers via a CDN, and also
incorporating a P2P mode amongst endhosts and set-top boxes. In-
network storage may be beneficial to hybrid CDN/P2P applications as
well to support P2P distribution and to enable content publisher
standard interfaces and controls.
First, the Content Publisher stores a block in the in-network However, there is no standard interface for different content
storage, configures necessary access control, and notifies peers in publishers to access in-network storage. One streaming content
ISP A. Second, each peer may then download from the Content publisher may need the existing in-network storage to support
Publisher's in-network storage. streaming signaling or such capability, such as transcoding
capability, bitmap information, intelligent retransmission, etc,
while a different content publisher may only need the in-network
storage to distribute files. However it is reasonable that the
application services are only supported by content publisher's
original servers and clients, and intelligent data plane transport
for those content publishers are supported by in-network storage.
In this example, the block is distributed in a more network efficient A content publisher also benefits from a standard interface to access
way (the content only traverses the ISP's interdomain link once), in-network storage servers provided by different providers. The
while the Content Publisher retains explicit control over access to standard interface must allow the content publisher to retain control
the content placed in its own storage. The Content Publisher can over content placed in their own in-network storage, and grant access
remove content from its in-network storage when it is stale or needs and resources only to the desired endhosts and peers.
to be replaced, and grant access and resources to only the desired
peers.
Note that Content Publishers and individual peers can each use in- In the hybrid CDN/P2P scenario, if only the endhosts can store
network storage. For example, after downloading content from the content in the in-network storage server, the content must be
Content Publisher's in-network storage, peers may each utilize their downloaded and then uploaded over the last-mile access link before
own in-networks storage similar to the usage scenario in Section 5.1. another peer may retrieve it from a in-network storage server. Thus,
This can have the benefit of increased network efficiency, while in this deployment scenario, it may be advantageous for a content
Content Publishers and peers still retain control over content placed publisher or CDN provider to store content in in-network storage
in their own in-network storage. servers.
If it desires, a content publisher may still apply DRM to the 5. Security Considerations
payload. This is independent of any authentication or authorization
provided by DECADE.
5.3. CDN/P2P hybrid There are several security considerations to the in-network storage.
Some applications use a hybrid content distribution approach 5.1. Denial of Service Attacks
incorporating both P2P and CDN modes. As an example, Internet TV may
be implemented as a hybrid CDN/P2P application by distributing
content from central servers via a CDN, and also incorporating a P2P
mode amongst endhosts and set-top boxes.
DECADE may be beneficial to hybrid CDN/P2P applications as well. An attacker can try to consume a large portion of the in-network
However, if only the endhost can store content in the DECADE server, storage, or exhaust the connections of the in-network storage through
the content must be downloaded and then uploaded over the last-mile a Denial of Service (DoS) attack. Authentication, authorization and
access link before another peer may retrieve it from a DECADE server. accounting mechanisms should be considered in the cross domain
Thus, in this deployment scenario, it may be advantageous for a environment. Limitation of access from an administrative domain sets
Content Publisher or CDN provider to store content to DECADE servers. up barriers for content distribution.
6. Security Considerations 5.2. Copyright and Legal Issues
There are multiple security considerations. We can not enumerate all Copyright and other laws may prevent the distribution of certain
of them but focus on three main concerns in this section. content in various localities. In-network storage operators may
adopt system-wide ingress or egress filters to implement necessary
policies for storing or retrieving content, and applications may
apply DRM to the data stored in the network storage. However, the
specification and implementation of such policies (e.g., filtering
and DRM) is outside of the scope of this document.
6.1. Denial of Service Attacks 5.3. Traffic Analysis
An attacker can try to consume a large portion of the in-network If the content is stored in the provider-based in-network storage,
storage, or exhaust the connections of the in-network storage through there may be a privacy risk that the provider can correlate the
a Denial of Service (DoS) attack. people who are accessing the same data object using the same object
identity.
6.2. Copyright and Legal Issues 5.4. Modification of Information
Copyright and other laws may prevent the distribution of certain The modification threat is the danger that some unauthorized entity
content in various localities. While in-network storage operators may alter in-transit in-network storage access messages generated on
may adopt system-wide ingress or egress filters to implement behalf of an authorized principal in such a way as to effect
necessary policies for storing or retrieving content, and unauthorized management operations, including falsifying the value of
applications may still apply DRM to the data stored in the network an object. See [RFC3414].
storage, the specification and implementation of such policies (e.g.,
filtering and DRM) is outside of the scope of this working group.
6.3. Privacy issue 5.5. Masquerade
If the content stored in the provider-based in-network storage, there The masquerade threat is the danger that management operations may be
may be a privacy risk that the provider can correlate the people who attempted by assuming the identity of another user that has the
are accessing the same data object using the same object identity. appropriate authorizations. See [RFC3414].
7. IANA Considerations 5.6. Disclosure
The disclosure threat is the danger of eavesdropping on the exchanges
between in-network storage and application clients. Protecting
against this threat may be required as a matter of application
policy. See [RFC3414].
5.7. Message Stream Modification
The message stream modification threat is the danger that messages
may be maliciously re-ordered, delayed or replayed to an extent which
is greater than can occur through natural network system, in order to
effect unauthorized management operations. See [RFC3414].
6. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
8. Acknowledgments 7. 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 David Bryan
Kar Ann Chew Kar Ann Chew
Roni Even Roni Even
skipping to change at page 12, line 15 skipping to change at page 10, line 4
Hongqiang Liu Hongqiang Liu
Tao Ma Tao Ma
Borje Ohlman Borje Ohlman
Akbar Rahman Akbar Rahman
Yu-shun Wang Yu-shun Wang
Richard Woundy Richard Woundy
Yunfei Zhang Yunfei Zhang
9. Informative References 8. Informative References
[ipoque.com] [Internet_Study_2008-2009]
"http://www.ipoque.com/resources/internet-studies/ "Internet Study 2008/2009", <http://www.ipoque.com/
internet-study-2008_2009". resources/internet-studies/internet-study-2008_2009>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
October 2009. October 2009.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-18 (work in Base Protocol", draft-ietf-p2psip-base-20 (work in
progress), August 2011. progress), January 2012.
[DCIA] http://www.dcia.info, "Distributed Computing Industry [DCIA] http://www.dcia.info, "Distributed Computing Industry
Association". Association".
[ipoque.P2P_survey.] [ipoque.P2P_survey.]
"Emerging Technologies Conference at MIT", Sept. 2007. "Emerging Technologies Conference at MIT", Sept. 2007.
[P2P_file_sharing] [P2P_file_sharing]
Parker, A., "The true picture of peer-to-peer Parker, A., "The true picture of peer-to-peer
filesharing", July 2004. filesharing", July 2004.
skipping to change at page 13, line 10 skipping to change at page 10, line 48
[Octoshape] [Octoshape]
"http://www.octoshape.com/?page=company/about". "http://www.octoshape.com/?page=company/about".
[PPLive] "http://www.synacast.com/products/". [PPLive] "http://www.synacast.com/products/".
[ICNP] Wu, H., "Challenges and opportunities of Internet [ICNP] Wu, H., "Challenges and opportunities of Internet
developments in China, ICNP 2007 Keynote", Oct. 2007. developments in China, ICNP 2007 Keynote", Oct. 2007.
Appendix A. Other Related Work in IETF Appendix A. Other Related Work in IETF
Note that DECADE is independent of current IETF work on P2P. The ALTO (To the RFC editor: Please remove this section and the related
work as described above is aimed for better peer selection and the references in this section upon publication. The purpose of this
RELOAD [I-D.ietf-p2psip-base] protocol is used for P2P overlay section is to give the IESG and RFC editor a better understanding of
maintenance and resource discovery. 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 The Peer to Peer Streaming Protocol effort in the IETF is
investigating the specification of signaling protocols (called the investigating the specification of signaling protocols (called the
PPSP tracker protocol and peer protocol) for multiple entities (e.g. PPSP tracker protocol and peer protocol) for multiple entities (e.g.
intelligent endpoints, caches, content distribution network nodes, intelligent endpoints, caches, content distribution network nodes,
and/or other edge devices) to participate in P2P streaming systems in and/or other edge devices) to participate in P2P streaming systems in
both fixed and mobile Internet. As discussed in the PPSP problem both fixed and mobile Internet. As discussed in the PPSP problem
statement, one important PPSP use case is the support of an in- statement, one important PPSP use case is the support of an in-
network edge cache for P2P Streaming. However, this approach to network edge cache for P2P Streaming. However, this approach to
providing in-network cache has different applicability, different providing in-network cache has different applicability, different
objectives and different implications for the in-network cache objectives and different implications for the in-network cache
operator. A DECADE service can be used for any application operator. The goal of DECADE WG is to provide in-network storage
transparently to the DECADE in-network storage operator: it can be service that can be used for any application transparently to the in-
used for any P2P Streaming application (whether it supports PPSP network storage operator: it can be used for any P2P Streaming
protocols or not), for any other P2P application, and for non P2P application (whether it supports PPSP protocols or not), for any
applications that simply want to benefit from in-network storage. So other P2P application, and for non P2P applications that simply want
with DECADE the operator is providing a generic in-network storage to benefit from in-network storage. With DECADE, the operator is
service that can be used by any application without application providing a generic in-network storage service that can be used by
involvement or awareness by the operator; in the PPSP cache use case, any application without application involvement or awareness by the
the cache operator is participating in the specific P2P streaming operator; in the PPSP cache use case, the cache operator is
service. participating in the specific P2P streaming service.
DECADE and PPSP can both contribute independently, and (where DECADE and PPSP can both contribute independently, and (where
appropriate) simultaneously, to making content available closer to appropriate) simultaneously, to making content available closer to
peers. Here are a number of example scenarios: peers. Here are a number of example scenarios:
A given network supports DECADE in-network storage, and its CDN A given network supports DECADE in-network storage, and its CDN
nodes do not participate as PPSP Peers for a given "stream" (e.g. nodes do not participate as PPSP Peers for a given "stream" (e.g.
because no CDN arrangement has been put in place between the because no CDN arrangement has been put in place between the
Content Provider and the particular network provider). In that content provider and the particular network provider). In that
case, PPSP Peers will all be "off-net" but will be able to use case, PPSP Peers will all be "off-net" but will be able to use
DECADE in-network storage to exchange chunks. DECADE in-network storage to exchange chunks.
A given network does not support DECADE in-network storage, and A given network does not support DECADE in-network storage, and
(some of) its CDN nodes participate as PPSP Peers for a given (some of) its CDN nodes participate as PPSP Peers for a given
"stream" (e.g. say because an arrangement has been put in place "stream" (e.g. say because an arrangement has been put in place
between the Content Provider and the particular network provider). between the content provider and the particular network provider).
In that case, the CDN nodes will participate as in-network PPSP 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 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 get chunks from the in-network CDN nodes (using PPSP protocols
with the CDN nodes). with the CDN nodes).
A given network supports DECADE in-network storage, and (some of) A given network supports DECADE in-network storage, and (some of)
its CDN nodes participate as PPSP Peers for a given "stream" (e.g. its CDN nodes participate as PPSP Peers for a given "stream" (e.g.
say because an arrangement has been put in place between the because an arrangement has been put in place between the content
Content Provider and the particular network provider). In that provider and the particular network provider). In that case, the
case, the CDN nodes will participate as in-network PPSP Peers. CDN nodes will participate as in-network PPSP Peers. The off-net
The off-net PPSP Peers (i.e., end users) will be able to get PPSP Peers (i.e., end users) will be able to get chunks from the
chunks from the in-network CDN nodes (using PPSP protocols with in-network CDN nodes (using PPSP protocols with the CDN nodes) as
the CDN nodes) as well as be able to get chunks / share chunks well as be able to get chunks / share chunks using DECADE in-
using DECADE in-network storage populated by PPSP Peers (both off- network storage populated by PPSP Peers (both off-net end-users
net end-users and in-network CDN Nodes). and in-network CDN Nodes).
PPSP and DECADE jointly to provide P2P streaming service for PPSP and DECADE jointly provide P2P streaming service for
heterogeneous networks including both fixed and mobile connections heterogeneous networks including both fixed and mobile connections
and enables the mobile nodes to use DECADE. In this case there and enables the mobile nodes to use DECADE. In this case there
may be some solutions to require more information in PPSP tracker may be some solutions that require more information in PPSP
protocol, e.g., the mobile node can indicate its DECADE in-network tracker protocol, e.g., the mobile node can indicate its DECADE
proxy to PPSP tracker and the following requesting peer can finish in-network proxy to the PPSP tracker and the following requesting
data transfer with the DECADE proxy. peer can finish data transfer with the DECADE proxy.
An ALTO (Application Layer Traffic Optimization) server provides P2P
applications with network information so that they can perform
better-than-random initial peer selection [RFC5693]. 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 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
is focusing on techniques that allow large amounts of data to be
consistently transmitted without substantially affecting the delays
experienced by other users and applications. It is expected that
some P2P applications would start using such techniques, thereby
somewhat alleviating the perceivable impact (at least on other
applications) of their high volume traffic. However, such techniques
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 Phone: +86-25-56624792
 End of changes. 66 change blocks. 
319 lines changed or deleted 297 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/