draft-ietf-decade-problem-statement-02.txt   draft-ietf-decade-problem-statement-03.txt 
DECADE H. Song DECADE H. Song
Internet-Draft N. Zong Internet-Draft N. Zong
Intended status: Standards Track Huawei Intended status: Informational Huawei
Expires: July 26, 2011 Y. Yang Expires: September 15, 2011 Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
January 22, 2011 March 14, 2011
DECoupled Application Data Enroute (DECADE) Problem Statement DECoupled Application Data Enroute (DECADE) Problem Statement
draft-ietf-decade-problem-statement-02 draft-ietf-decade-problem-statement-03
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 total networks. In P2P applications, one technique for reducing the
amount of P2P traffic is to introduce storage capabilities within the transit and uplink P2P traffic is to introduce storage capabilities
network. Traditional caches (e.g., P2P and Web caches) provide such within the network (the download traffic may increase because the in-
storage, but they are complex (due to explicitly supporting network storage is likely much better connected). Traditional P2P
individual P2P application protocols) and they do not allow users to and Web caches provide such storage, but they are complex (due to
manage access to content in the cache. For example, Content explicitly supporting individual P2P application protocols and cache
Providers cannot easily control access and resource usage policies to refreshing mechanisms) and they do not allow users to manage access
satisfy their own requirements. This document discusses the to content in the cache. For example, content providers cannot
easily control cache access and resource usage policies to satisfy
their own requirements, in the case when the content provider is also
the user of in-network storage. This document discusses the
introduction of in-network storage for P2P applications, shows the introduction of in-network storage for P2P applications, shows the
need for a standard protocol for accessing this storage, and need for a standard protocol for accessing this storage, and
identifies the scope of this protocol. The accessing protocol can identifies the scope of this protocol. The access protocol can also
also be used by other applications with similar requirements. 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 to IETF 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), its areas, and its working groups. Note that
working documents as Internet-Drafts. The list of current Internet- other groups may also distribute working documents as Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
This Internet-Draft will expire on July 26, 2011. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 15 skipping to change at page 2, line 25
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 BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5
3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. P2P infrastructural stress and inefficiency . . . . . . . 5 3.1. P2P infrastructural stress and inefficiency . . . . . . . 6
3.2. P2P cache: a complex in-network storage . . . . . . . . . 6 3.2. P2P cache: a complex in-network storage . . . . . . . . . 7
3.3. Ineffective integration of P2P applications . . . . . . . 6 3.3. Ineffective integration of P2P applications . . . . . . . 7
4. DECADE as an In-network Storage Capability . . . . . . . . . . 7 4. DECADE as an In-network Storage Capability . . . . . . . . . . 8
4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 9 4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 10
5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 11 5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 12
5.3. CDN/P2P hybrid . . . . . . . . . . . . . . . . . . . . . . 11 5.3. CDN/P2P hybrid . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 12 5.4. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 13
5.4.1. Both Sender and Receiver Accounts are Used . . . . . . 12 5.4.1. Both Sender and Receiver Accounts are Used . . . . . . 13
5.4.2. Only Sender's Storage Account is Used . . . . . . . . 13 5.4.2. Only Sender's Storage Account is Used . . . . . . . . 14
5.4.3. Only Receiver's Storage Account is Used . . . . . . . 13 5.4.3. Only Receiver's Storage Account is Used . . . . . . . 14
5.4.4. No Storage Accounts are Used . . . . . . . . . . . . . 13 5.4.4. No Storage Accounts are Used . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 14 6.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 15
6.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 14 6.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 16 Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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
backbone and transit links [I-D.weaver-alto-edge-caches]. backbone and transit links [I-D.weaver-alto-edge-caches].
skipping to change at page 3, line 25 skipping to change at page 4, line 25
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. But the current P2P caching architecture poses challenges
to both P2P cache vendors and P2P application developers. For P2P to both P2P cache vendors and P2P application developers. For P2P
cache vendors, it is challenging to support a number of continuously cache vendors, it is challenging to support a number of continuously
evolving P2P application protocols, due to lack of documentation, evolving P2P application protocols, due to lack of documentation,
ongoing protocol changes, and rapid introduction of new features by ongoing protocol changes, and rapid introduction of new features by
P2P applications. For P2P applications, closed P2P caching systems P2P applications. For P2P applications, closed P2P caching systems
limit P2P applications to effectively utilize in-network storage. In limit P2P applications to effectively utilize in-network storage. In
particular, P2P caches typically do not allow users to explicitly particular, P2P caches typically do not allow users to explicitly
store content into in-network storage. They do not allow users to store content into in-network storage. They do not allow users to
implement control over the content that have been placed into the in- implement control over the content that has been placed into the in-
network storage either. network storage either.
Both of these challenges can be effectively addressed by using an Both of these challenges can be effectively addressed by using open,
open, standard protocol to access in-network storage. P2P standard protocols to access in-network storage. P2P applications
applications can store and retrieve content in the in-network can store and retrieve content in the in-network storage, as well as
storage, as well as control resources (e.g., bandwidth, connections) control resources (e.g., network access, connections) consumed by
consumed by peers in a P2P application. As a simple example, a peer peers in a P2P application. As a simple example, a peer of a P2P
of a P2P application may upload to other peers through its in-network application may upload to other peers through its in-network storage,
storage, saving its usage of last-mile uplink bandwidth. saving its usage of last-mile uplink bandwidth.
This document uses DECADE to refer to the protocol(s) developed or
employed by the DECADE Working Group to provide these capabilities.
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
applications to access storage and data transport services in the
network to improve their efficiency and reduce load on the network
infrastructure.
With DECADE, P2P applications can still use their native protocols With DECADE, P2P applications can still use their native protocols
for signaling and data transport. However, they may use a standard for signaling and data transport. However, they may use a standard
protocol for data access incorporating in-network storage, and fall protocol for data access incorporating in-network storage, and fall
back to their native data transport protocols if in-network storage back to their native data transport protocols if in-network storage
is not available or not used. is not available or not used.
In essence, an open, standard protocol to access in-network storage In essence, an open, standard protocol to access in-network storage
provides an alternative mechanism for P2P application data access provides an alternative mechanism for P2P application data access
that is decoupled from P2P application control and signaling. This that is decoupled from P2P application control and signaling. This
decoupling leads to many advantages, which is explained further in decoupling leads to many advantages, which is explained further in
skipping to change at page 4, line 21 skipping to change at page 5, line 18
And further, either the existing P2P cache or any new type of in- 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 network storage should be deployed near the edge of the ISP's network
so as to gain better performance. 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 network access to read/write data to applications.
may reduce upload/transit/backbone traffic and improve network In-network storage may reduce upload/transit/backbone traffic and
application performance. improve network application performance.
IAP (In-network storage Access Protocol): a standard protocol that IAP (In-network storage Access Protocol): a standard protocol that
is spoken between P2P applications and in-network storage. The is spoken between P2P applications and in-network storage. The
protocol may also be used between entities implementing the in- protocol may also be used between entities implementing the in-
network storage service. IAP may be a new protocol or existing network storage service. IAP may be a new protocol or existing
protocol with extensions. protocol with extensions.
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 to consumers. Content Publisher: An entity that originates content.
3. The Problems 3. The Problems
The emergence of peer-to-peer (P2P) as a major type of network The emergence of peer-to-peer (P2P) as a major type of network
application (esp. P2P file sharing and streaming apps) has led to application (esp. P2P file sharing and streaming apps) has led to
substantial opportunities. The P2P paradigm can be utilized in substantial opportunities. The P2P paradigm can be utilized in
designing highly scalable and robust applications at low cost, designing highly scalable and robust applications at low cost,
compared with traditional client-server paradigms. For example, CNN compared with traditional client-server paradigms. For example, CNN
reported that P2P streaming by Octoshape played a major role in its reported that P2P streaming by Octoshape played a major role in its
distribution of the historical inauguration address of President distribution of the historical inauguration address of President
Obama. PPLive, one of the largest P2P streaming vendors, is able to Obama[Octoshape]. PPLive, one of the largest P2P streaming vendors,
distribute large-scale, live streaming programs to more than 2 is able to distribute large-scale, live streaming programs to more
million users with only a handful of servers. than 2 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 substantial stress
that they place on the network infrastructure. Also, lacking of that they place on the network infrastructure. Also, 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 crowd performance during peer churns and flash crowds. During a flash
means a large group of application users begin to acess the same crowd, a large group of application users begin to access the same
service during a very short period of time, which is a chanllenge to service during a very short period of time, which is a challenge to
the system. Below we elaborate on the problems in more 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 (ISP). Multiple measurements (e.g., [ipoque]) have shown providers (ISP). Multiple measurements (e.g., [ipoque.com]) have
that P2P traffic has become a major type of traffic on some networks. shown that P2P traffic has become a major type of traffic on some
Furthermore, network-agnostic peering leads to unnecessary traversal networks. Furthermore, network-agnostic peering (P2P transmission
across network domains or spanning the backbone of a network, leading level) leads to unnecessary traversal across network domains or
to network inefficiency [RFC5693]. spanning the backbone of a network, leading to network inefficiency
[RFC5693].
Recently, the IETF Application Layer Traffic Optimization (ALTO) Recently, the IETF Application Layer Traffic Optimization (ALTO)
Working Group was formed to provide P2P applications with network Working Group was formed to provide P2P applications with network
information so that they can perform better-than-random initial peer information so that they can perform better-than-random initial peer
selection [RFC5693]. However, there are limitations on what ALTO can selection [RFC5693]. However, there are limitations on what ALTO can
achieve alone. For example, network information alone cannot reduce achieve alone. For example, network information alone cannot reduce
P2P traffic in access networks, as the total access upload traffic is P2P traffic in access networks, as the total access upload traffic is
equal to the total access download traffic in a pure P2P system. On equal to the total access download traffic in a pure P2P system. On
the other hand, it is reported that P2P traffic is becoming the the other hand, it is reported that P2P traffic is becoming the
dominating traffic on the access networks of some networks, reaching dominating traffic on the access networks of some networks, reaching
skipping to change at page 6, line 19 skipping to change at page 7, line 19
inefficiency is to introduce in-network storage. For example, in inefficiency is to introduce in-network storage. For example, in
[I-D.weaver-alto-edge-caches], the author demonstrates clearly the [I-D.weaver-alto-edge-caches], the author demonstrates clearly the
potential benefits of introducing in-network storage to improve potential benefits of introducing in-network storage to improve
network efficiency and thus reduce network infrastructure stress. network efficiency and thus reduce network infrastructure stress.
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 be evolving
continuously, to add new features or fix bugs. This forces a P2P continuously, to add new features or fix bugs. This forces a P2P
skipping to change at page 6, line 42 skipping to change at page 7, line 42
reliability. 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 3.3. Ineffective integration of P2P applications
As P2P applications evolve, it is becoming increasingly clear that As P2P applications evolve, it is becoming increasingly clear that
they will need in-network resources to provide positive user they will need in-network resources to provide positive user
experiences. For example, multiple P2P streaming systems seek experiences. For example, multiple P2P streaming systems seek
additional in-network resources during flash crowd, such as just additional in-network resources during a flash crowd, such as just
before a major live streaming event. In asymmetric networks when the before a major live streaming event. In asymmetric networks when the
aggregated upload bandwidth of a channel cannot meet the download aggregated upload bandwidth of a channel cannot meet the download
demand, a P2P application may seek additional in-network resources to demand, a P2P application may seek additional in-network resources to
maintain a stable system. maintain a stable system.
A requirement by some P2P applications in using in-network A requirement by some P2P applications in using in-network
infrastructural resources, however, is flexibility in implementing infrastructural resources, however, is flexibility in implementing
resource allocation policies. A major competitive advantage of many resource allocation policies. A major competitive advantage of many
successful P2P systems is their substantial expertise in how to most successful P2P systems is their substantial expertise in how to most
efficiently utilize peer and infrastructural resources. For example, efficiently utilize peer and infrastructural resources. For example,
many live P2P systems have their specific algorithms in selecting the many live P2P systems have specific algorithms to select those peers
peers that behave as the more stable, higher bandwidth sources. They that behave as stable, higher bandwidth sources. They continue to
continue to fine-tune such algorithms. In other words, in-network fine-tune such algorithms. In other words, in-network storage should
storage should export basic mechanisms and allow as much flexibility export basic mechanisms and allow as much flexibility as possible to
as possible to P2P applications to implement specific policies. This P2P applications to implement specific policies. This conforms to
conforms to the end-to-end systems principle and allows innovation the end-to-end systems principle and allows innovation and
and satisfaction of specific business goals. Existing techniques for satisfaction of specific business goals. Existing techniques for P2P
P2P application in-network storage lack these capabilities. application in-network storage lack these capabilities.
4. DECADE as an In-network Storage Capability 4. DECADE as an In-network Storage Capability
The objective of this working group is to design DECADE, which The objective of this working group is to design DECADE, which
primarily consists of an in-network storage access protocol (IAP) to primarily consists of an in-network storage access protocol (IAP) to
address the problems discussed in the preceding section. address the problems discussed in the preceding section.
DECADE will provide access to storage and data transport services in DECADE will provide access to storage and data transport services in
the network to P2P applications to improve their efficiency and the network to P2P applications to improve their efficiency and
reduce the stress on the network infrastructure. Unlike the existing reduce the stress on the network infrastructure. Unlike the existing
skipping to change at page 8, line 32 skipping to change at page 9, line 32
P2P application P2P application
native protocol native protocol
Figure 1 Overview of protocol interaction between DECADE elements Figure 1 Overview of protocol interaction between DECADE elements
Specifically, the main component of DECADE is the in-network storage Specifically, the main component of DECADE is the in-network storage
access protocol (IAP), which is a standard, P2P-application-agnostic access protocol (IAP), which is a standard, P2P-application-agnostic
protocol for different P2P applications to access in-network storage. protocol for different P2P applications to access in-network storage.
IAP defines a set of commands that P2P application elements can issue IAP defines a set of commands that P2P application elements can issue
to in-network storage to store and retrieve data. IAP includes the to in-network storage to store and retrieve data. IAP includes the
following functionalities: following functionality:
(1) Data access provides read/write by users (e.g., P2P application (1) Data access provides read/write by users (e.g., P2P application
clients and content publishers) to the corresponding in-network clients and content publishers) to the corresponding in-network
storage and between entities implementing the in-network storage; storage and between entities implementing the in-network storage;
(2) Authorization implements access control to resources provided by (2) Authorization implements access control to resources provided by
in-network storage; in-network storage;
(3) Resource control allows users to implement application policies (3) Resource control allows users to implement application policies
for the corresponding in-network storage. for the corresponding in-network storage.
skipping to change at page 9, line 5 skipping to change at page 10, line 5
While DECADE will focus on P2P applications, the solution is expected While DECADE will focus on P2P applications, the solution is expected
to be applicable in other contexts with similar requirements. to be applicable in other contexts with similar requirements.
4.1. Data access 4.1. Data access
P2P application clients use the IAP protocol to read data from an in- P2P application clients use the IAP protocol to read data from an in-
network storage, store data to an in-network storage, or remove data network storage, store data to an in-network storage, or remove data
from an in-network storage. The data could be of various types. from an in-network storage. The data could be of various types.
Existing protocols will be used wherever possible and appropriate to Existing protocols will be used wherever possible and appropriate to
support DECADE's requirements. In particular, data storage, support DECADE's requirements. In particular, data storage,
retrieval, and management may be provided by an existing IETF retrieval, and management may be provided by existing IETF protocols.
protocols. The WG will not limit itself to a single data transport The WG will not limit itself to a single data transport protocol
protocol since different protocols may have varying implementation since different protocols may have varying implementation costs and
costs and performance tradeoffs. However, to keep interoperability performance tradeoffs. However, to keep interoperability manageable,
manageable, a small number of specific, targeted, data transport a small number of specific, targeted, data transport protocols will
protocols will be identified and used. If a protocol is found to be be identified and used. If a protocol is found to be suitable but
suitable but does not fully meet the requirements, then the protocol does not fully meet the requirements, then the protocol may need to
may need to be extended. The following considerations should be be extended. The following considerations should be taken into
taken into account. But it might be a trade-off when making account, although there might be trade-offs among these
decision. considerations.
o The protocol(s) should support deployments with a very large o The protocol(s) should support deployments with a very large
number of users without substantial increase to operational number of users without substantial increase to operational
complexity for the storage provider. complexity for the storage provider.
o The protocol(s) should be easy for applications to integrate o The protocol(s) should be easy for application integration,
with when they want to use it for P2P applications (e.g. file- whether they want to use it for P2P applications (e.g. file-
sharing or streaming) or other content distribution applications. sharing or streaming) or for other content distribution
applications.
4.2. Authorization 4.2. Authorization
DECADE ensures that access to the in-network storage is subject to DECADE ensures that access to a user's in-network storage is subject
authorization by the user owning the in-network storage service. The to authorization by that user. The authorization can take into
authorization can take into account the user trying to access, the account the user trying to access, the content, the time period, etc.
content, the time period, etc.
4.3. Resource control 4.3. Resource control
A user uses the IAP protocol to manage the resources on in-network A user uses the IAP protocol to manage the resources on in-network
storage that can be used by other peers, e.g., the bandwidth or storage that can be used by other peers, e.g., network access to the
connections. The resource control policies could be based on storage or network connections themselves. The resource control
individual remote peers or a whole application. policies could be based on individual remote peers or a whole
application.
5. Usage Scenarios 5. Usage Scenarios
Usage scenarios are described from two perspectives. First, we Usage scenarios are described from two perspectives. First, we
introduce high-level use cases showing how P2P applications may introduce high-level use cases showing how P2P applications may
utilize in-network storage. Second, we show how in more detail how utilize in-network storage. Second, we show how in more detail how
users exchange data using IAP. users exchange data using IAP.
5.1. BitTorrent 5.1. BitTorrent
skipping to change at page 10, line 17 skipping to change at page 11, line 18
We now describe in more detail how BitTorrent can utilize DECADE. We now describe in more detail how BitTorrent can utilize DECADE.
For illustration, we assume that both the BitTorrent client (A) and For illustration, we assume that both the BitTorrent client (A) and
its peer (B) utilize in-network storage. When A requests a block, it its peer (B) utilize in-network storage. When A requests a block, it
indicates that it would like the block stored in its in-network indicates that it would like the block stored in its in-network
storage and provides the necessary access control. Instead of storage and provides the necessary access control. Instead of
sending the 'piece' message with the desired block, peer B replies sending the 'piece' message with the desired block, peer B replies
with a 'redirect' message indicating that the content should be with a 'redirect' message indicating that the content should be
retrieved from its own in-network storage and provides the necessary retrieved from its own in-network storage and provides the necessary
access control. If the peer B had not previously stored the content access control. If the peer B had not previously stored the content
in its in-network storage, it uploads the block. A downloads the in its in-network storage, it uploads the block. A instructs its in-
block into its own in-network storage from B's in-network storage, network storage to download the block from B's in-network storage,
and finally A itself retrieves the block. and finally A itself retrieves the block.
Note that this requires extensions to the BitTorrent protocol. While Note that this requires extensions to the BitTorrent protocol. While
there are multiple ways to do so, this example assumes the native there are multiple ways to do so, this example assumes the native
BitTorrent 'request' message is extended to carry additional BitTorrent 'request' message is extended to carry additional
information and that a new 'redirect' message is added. Upload and information and that a new 'redirect' message is added. Upload and
download to/from in-network storage uses the standard IAP protocol. download to/from in-network storage uses the standard IAP protocol.
This example has illustrated how utilizing DECADE can increase This example has illustrated how utilizing DECADE can increase
BitTorrent's network efficiency. First, notice that peer B does not BitTorrent's network efficiency. First, notice that peer B does not
skipping to change at page 11, line 7 skipping to change at page 12, line 7
This technique can be applied to other P2P applications as well. This technique can be applied to other P2P applications as well.
Since P2P applications use a standard for communicating with in- Since P2P applications use a standard for communicating with in-
network storage, they no longer require in-network storage to network storage, they no longer require in-network storage to
explicitly support their protocol. P2P applications retain the explicitly support their protocol. P2P applications retain the
ability to explicitly manage which content is placed in in-network ability to explicitly manage which content is placed in in-network
storage, as well as access and resource control polices. storage, as well as access and resource control polices.
5.2. Content Publisher 5.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 Consider a case where the content publisher owns an in-network
storage account within ISP A. If there are multiple P2P peers within storage account within ISP A. If there are multiple P2P peers within
ISP A, the Content Publisher may utilize DECADE to distribute content ISP A, the content publisher may utilize DECADE to distribute content
to the peers. to the peers.
First, the Content Publisher stores a block in the in-network First, the content publisher stores a block in the in-network
storage, and then sends to each peer in ISP A the block's identifier storage, and then sends to each peer in ISP A the block's identifier
and necessary access control. Second, each peer may then download and necessary access control. Second, each peer may then download
from the Content Publisher's in-network storage. from the content publisher's in-network storage.
In this example, the block is distributed in a more network efficient In this example, the block is distributed in a more network efficient
way (the content only traverses the ISP's interdomain link once), way (the content only traverses the ISP's interdomain link once),
while the Content Publisher retains explicit control over access to while the content publisher retains explicit control over access to
the content placed in its own storage. The Content Publisher can the content placed in its own storage. The content publisher can
remove content from its in-network storage when it is stale or needs remove content from its in-network storage when it is stale or needs
to be replaced, and grant access and resources to only the desired to be replaced, and grant access and resources to only the desired
peers. peers.
Note that Content Publishers and individual peers can each use in- Note that content publishers and individual peers can each use in-
network storage. For example, after downloading content from the network storage. For example, after downloading content from the
Content Publisher's in-network storage, peers may each utilize their content publisher's in-network storage, peers may each utilize their
own in-networks storage similar to the usage scenario in Section 5.1. own in-networks storage similar to the usage scenario in Section 5.1.
This can have the benefit of increased network efficiency, while This can have the benefit of increased network efficiency, while
Content Publishers and peers still retain control over content placed content publishers and peers still retain control over content placed
in their own in-network storage. in their own in-network storage.
If it desires, a content publisher may still apply DRM to the If it desires, a content publisher may still apply DRM to the
payload. This is independent of any authentication or authorization payload. This is independent of any authentication or authorization
provided DECADE. provided by DECADE.
5.3. CDN/P2P hybrid 5.3. CDN/P2P hybrid
Some applications use a hybrid content distribution approach Some applications use a hybrid content distribution approach
incorporating both P2P and CDN modes. As an example, Internet TV may incorporating both P2P and CDN modes. As an example, Internet TV may
be implemented as a hybrid CDN/P2P application by distributing be implemented as a hybrid CDN/P2P application by distributing
content from central servers via a CDN, and also incorporating a P2P content from central servers via a CDN, and also incorporating a P2P
mode amongst endhosts and set-top boxes. mode amongst endhosts and set-top boxes.
DECADE may be beneficial to hybrid CDN/P2P applications as well. DECADE may be beneficial to hybrid CDN/P2P applications as well.
However, if only the endhost can store content in the DECADE server, However, if only the endhost can store content in the DECADE server,
the content must be downloaded and then uploaded over the last-mile the content must be downloaded and then uploaded over the last-mile
access link before another peer may retrieve it from a DECADE server. access link before another peer may retrieve it from a DECADE server.
Thus, in this deployment scenario, it may be advantageous for a Thus, in this deployment scenario, it may be advantageous for a
Content Publisher or CDN provider to store content to DECADE servers. content publisher or CDN provider to store content on DECADE servers.
5.4. Data Transfer Scenarios 5.4. Data Transfer Scenarios
The previous usage scenarios have utilized the ability for peers to The previous usage scenarios have utilized the ability for peers to
transfer data by storing and retrieving from in-network storage. transfer data by storing and retrieving from in-network storage.
This section describes in further detail an example solution of how This section describes in further detail an example solution of how
DECADE can provide this capability. DECADE can provide this capability. It is important to note that
this example is provided to illustrate more concretely the
capabilities provided by DECADE, and is not intended to reflect any
particular solution methodology or protocol(s) developed by the
DECADE Working Group.
In this section, we consider the case of a user B (the receiver) In this section, we consider the case of a user B (the receiver)
requesting data from user A (the sender). We use Sa to denote User requesting data from user A (the sender). We use Sa to denote User
A's storage account, and Sb to denote User B's storage account. Each A's storage account, and Sb to denote User B's storage account. Each
user independently decides if its in-network storage account is used, user independently decides if its in-network storage account is used,
so there are four cases. so there are four cases.
When a user indicates that it wishes to use its in-network storage, When a user indicates that it wishes to use its in-network storage,
it provides an access control token the other user. The token is it provides an access control token the other user. The token is
sent using the application's protocol. To simplify the illustration, sent using the application's protocol. To simplify the illustration,
skipping to change at page 12, line 38 skipping to change at page 14, line 5
5.4.1. Both Sender and Receiver Accounts are Used 5.4.1. Both Sender and Receiver Accounts are Used
This scenario is illustrated in Figure 2. B first requests an object This scenario is illustrated in Figure 2. B first requests an object
from A using the application protocol indicating it wishes the object from A using the application protocol indicating it wishes the object
to be stored in Sb. A responds using the application protocol to be stored in Sb. A responds using the application protocol
indicating that B should download the object from Sa. B sends a IAP indicating that B should download the object from Sa. B sends a IAP
request to Sb indicating that the object should be downloaded from request to Sb indicating that the object should be downloaded from
Sa. Sb uses IAP to download from Sa, and finally, B downloads the Sa. Sb uses IAP to download from Sa, and finally, B downloads the
object from Sb (also using IAP). object from Sb (also using IAP).
+-------+ 4 IAP Get +-------+ +-------+ 4. IAP Get +-------+
| Sa | <----------+ Sb | | Sa | <----------+ Sb |
+-------+ *********>+-------+ +-------+ *********>+-------+
5 data transfer ^ * 5. data transfer ^ *
3 IAP Get \ * 6 data transfer 3. IAP Get \ * 6. data transfer
1 App request \ \ / 1. App request \ v
+-------+<-------------------+-------+ +-------+<-------------------+-------+
|User A | |User B | |User A | |User B |
+-------+------------------->+-------+ +-------+------------------->+-------+
2 App response 2. App response
Figure 2: Usage Scenario 1 (Sender and receiver Accounts used) Figure 2: Usage Scenario 1 (Sender and receiver Accounts used)
5.4.2. Only Sender's Storage Account is Used 5.4.2. Only Sender's Storage Account is Used
This scenario is illustrated in Figure 3. B requests an object from This scenario is illustrated in Figure 3. B requests an object from
A using the application protocol. A responds using the application A using the application protocol. A responds using the application
protocol indicating that B should download the object from Sa. protocol indicating that B should download the object from Sa.
Finally, B sends a IAP request to Sa to download the object. Finally, B sends a IAP request to Sa to download the object.
+-------+ +-------+
| Sa | | Sa |
+-------+ +-------+ < *
^ * \ *
3 IAP Get \ * 4 data transfer \ *
1 App request \ \/ \ * 4. data transfer
3. IAP Get \ *
\ *
1. App request \ v
+-------+<-------------------+-------+ +-------+<-------------------+-------+
|User A | |User B | |User A | |User B |
+-------+------------------->+-------+ +-------+------------------->+-------+
2 App response 2. App response
Firgure 3: Usage Scenario 2 (Sender account used) Figure 3: Usage Scenario 2 (Sender account used)
5.4.3. Only Receiver's Storage Account is Used 5.4.3. Only Receiver's Storage Account is Used
This scenario is illustrated in Figure 4. B requests an object from This scenario is illustrated in Figure 4. B requests an object from
A using the application protocol indicating that it wishes the object A using the application protocol indicating that it wishes the object
to be stored in Sb. A stores the object in Sb (using IAP), and to be stored in Sb. A stores the object in Sb (using IAP), and
responds to B (using the application protocol) that it should responds to B (using the application protocol) that it should
download from Sb. B uses IAP to download the object from Sb. download from Sb. B uses IAP to download the object from Sb.
+---------+ +---------+
> | Sb | > | Sb |
3. / +---------+ 2. / +---------+
IAP Store / ^ * IAP Store / ^ *
/ 3.IAP Get \ * 4 data transfer / 4. IAP Get \ * 5. data transfer
/ 1.App request \ \/ / 1. App request \ v
+-------+<-------------------+-------+ +-------+<---------------+-------+
|User A | |User B | |User A | |User B |
+-------+------------------->+-------+ +-------+--------------->+-------+
2.App response 3. App response
Figure 4: Usage Scenario 3 (Receiver account used) Figure 4: Usage Scenario 3 (Receiver account used)
5.4.4. No Storage Accounts are Used 5.4.4. No Storage Accounts are Used
This scenario is illustrated in Figure 5. In this scenario, the This scenario is illustrated in Figure 5. In this scenario, the
application protocol is used directly to send data. This scenario application protocol is used directly to send data. This scenario
applies with one of the peers does not support IAP, or neither of the applies with one of the peers does not support IAP, or neither of the
peers are using in-network storage. peers are using in-network storage.
1.App request 1. App request
+-------+<-------------------+-------+ +-------+<-------------------+-------+
|User A | ... ... ... |User B | |User A | ... ... ... |User B |
+-------+*******************>+-------+ +-------+*******************>+-------+
2.data transfer 2. data transfer
Figure 5: Usage Scenario 4 ( No storage accounts used) Figure 5: Usage Scenario 4 ( No storage accounts used)
6. Security Considerations 6. Security Considerations
There are multiple security considerations. We focus on two in this There are multiple security considerations. We focus on two in this
section. section.
6.1. Denial of Service Attacks 6.1. Denial of Service Attacks
skipping to change at page 15, line 4 skipping to change at page 16, line 22
There is no IANA consideration with this document. There is no IANA consideration with this document.
8. Acknowledgments 8. 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
Lars Eggert
Yingjie Gu Yingjie Gu
Francois Le Faucheur Francois Le Faucheur
Hongqiang Liu Hongqiang Liu
Tao Ma Tao Ma
Borje Ohlman Borje Ohlman
skipping to change at page 16, line 9 skipping to change at page 17, line 31
[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.
[Octoshape]
"http://www.octoshape.com/?page=company/about".
[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, e.g. Note that DECADE is independent of current IETF work on P2P, e.g.
P2PSIP, ALTO, PPSP. For example, peers discovered by either RELOAD P2PSIP, ALTO, and PPSP. For example, peers discovered by either
or ALTO can all use DECADE to share data. RELOAD or ALTO can all use DECADE to share data.
The Peer to Peer Streaming Protocol effort in the IETF is The Peer to Peer Streaming Protocol effort in the IETF is
investigating specification of signaling protocols (called PPSP investigating specification of signaling protocols (called PPSP
protocols) for multiple types of entities (e.g. intelligent protocols) for multiple types of entities (e.g. intelligent
endpoints, caches, content distribution network nodes, and/or other endpoints, caches, content distribution network nodes, and/or other
edge devices) to participate in P2P streaming systems in both fixed edge devices) to participate in P2P streaming systems in both fixed
and mobile Internet. As discussed in the PPSP problem statement and mobile Internet. As discussed in the PPSP problem statement
document [I-D.ietf-ppsp-problem-statement], one important PPSP use document [I-D.ietf-ppsp-problem-statement], one important PPSP use
case is the support of an in-network edge cache for P2P Streaming. case is the support of an in-network edge cache for P2P streaming.
However, this approach to providing in-network cache has different However, this approach to providing in-network cache has different
applicability, different objectives and different implications for applicability, different objectives and different implications for
the in-network cache operator. A DECADE service can be used for any the in-network cache operator. A DECADE service can be used for any
application transparently to the DECADE in-network storage operator: application transparently to the DECADE in-network storage operator:
it can be used for any P2P Streaming application (whether it supports it can be used for any P2P streaming application (whether it supports
PPSP protocols or not), for any other P2P application, and for non PPSP protocols or not), for any other P2P application, and for non
P2P applications that simply want to benefit from in-network storage. P2P applications that simply want to benefit from in-network storage.
So with DECADE the operator is providing a generic in-network storage So with DECADE the operator is providing a generic in-network storage
service that can be used by any application without application service that can be used by any application without application
involvement or awareness by the operator; in the PPSP cache use case, involvement or awareness by the operator; in the PPSP cache use case,
the cache operator is participating in the specific P2P streaming the cache operator is participating in the specific P2P streaming
service. 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 considered network provider). In that content provider and the considered 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 considered network provider). between the content provider and the considered 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 (ie end users) will be able to get peers. The off-net PPSP peers (i.e., end users) will be able to
chunks from the in-network CDN nodes (using PPSP protocols with get chunks from the in-network CDN nodes (using PPSP protocols
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 say because an arrangement has been put in place between the
Content Provider and the considered network provider). In that content provider and the considered network provider). In that
case, the CDN nodes will participate as in-network PPSP Peers. case, the CDN nodes will participate as in-network PPSP Peers.
The off-net PPSP Peers (ie end users) will be able to get chunks The off-net PPSP Peers (i.e., end users) will be able to get
from the in-network CDN nodes (using PPSP protocols with the CDN chunks from the in-network CDN nodes (using PPSP protocols with
nodes) as well as be able to get chunks /share chunks using DECADE the CDN nodes) as well as be able to get chunks /share chunks
in-network storage populated (using IAP protocol) by PPSP Peers using DECADE in-network storage populated (using IAP protocol) by
(both off-net end-users and in-network CDN Nodes). PPSP peers (both off-net end-users and in-network CDN nodes).
PPSP and DECADE jointly to provide P2P streaming service for PPSP and DECADE jointly to provide P2P streaming service for
hetergeneous 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 to require more information in PPSP tracker
protocol, e.g.,the mobile node can indicate its DECADE in-network protocol, e.g., the mobile node can indicate its DECADE in-network
proxy to PPSP tracker and the following requesting peer can finish proxy to PPSP tracker and the following requesting peer can finish
data transfer with the DECADE proxy with IAP. its data transfer with the DECADE proxy with IAP.
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. 70 change blocks. 
166 lines changed or deleted 191 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/