draft-ietf-decade-problem-statement-01.txt   draft-ietf-decade-problem-statement-02.txt 
DECADE H. Song DECADE H. Song
Internet-Draft N. Zong Internet-Draft N. Zong
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: June 21, 2011 Y. Yang Expires: July 26, 2011 Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
December 18, 2010 January 22, 2011
DECoupled Application Data Enroute (DECADE) Problem Statement DECoupled Application Data Enroute (DECADE) Problem Statement
draft-ietf-decade-problem-statement-01 draft-ietf-decade-problem-statement-02
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 total
amount of P2P traffic is to introduce storage capabilities within the amount of P2P traffic is to introduce storage capabilities within the
network. Traditional caches (e.g., P2P and Web caches) provide such network. Traditional caches (e.g., P2P and Web caches) provide such
storage, but they are complex (due to explicitly supporting storage, but they are complex (due to explicitly supporting
individual P2P application protocols) and they do not allow users to individual P2P application protocols) and they do not allow users to
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 June 21, 2011. This Internet-Draft will expire on July 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3.1. P2P infrastructural stress and inefficiency . . . . . . . 5 3.1. P2P infrastructural stress and inefficiency . . . . . . . 5
3.2. P2P cache: a complex in-network storage . . . . . . . . . 6 3.2. P2P cache: a complex in-network storage . . . . . . . . . 6
3.3. Ineffective integration of P2P applications . . . . . . . 6 3.3. Ineffective integration of P2P applications . . . . . . . 6
4. DECADE as an In-network Storage Capability . . . . . . . . . . 7 4. DECADE as an In-network Storage Capability . . . . . . . . . . 7
4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 9 4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 9
5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 11 5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 11
5.3. hybrid Internet TV . . . . . . . . . . . . . . . . . . . . 11 5.3. CDN/P2P hybrid . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 12 5.4. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 12
5.4.1. Both Sender and Receiver Accounts are Used . . . . . . 12 5.4.1. Both Sender and Receiver Accounts are Used . . . . . . 12
5.4.2. Only Sender's Storage Account is Used . . . . . . . . 12 5.4.2. Only Sender's Storage Account is Used . . . . . . . . 13
5.4.3. Only Receiver's Storage Account is Used . . . . . . . 13 5.4.3. Only Receiver's Storage Account is Used . . . . . . . 13
5.4.4. No Storage Accounts are Used . . . . . . . . . . . . . 13 5.4.4. No Storage Accounts are Used . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Denial of Service attack . . . . . . . . . . . . . . . . . 14 6.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 14
6.2. Copyright and Legal issues . . . . . . . . . . . . . . . . 14 6.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 16 Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
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. Neither do they allow users store content into in-network storage. They do not allow users to
to implement control over the content that have been placed into the implement control over the content that have been placed into the in-
in-network storage. network storage either.
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
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
Section 4. Section 4.
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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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.
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
skipping to change at page 4, line 40 skipping to change at page 4, line 42
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 to consumers.
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
applications (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
[CNN] reported that P2P streaming by Octoshape played a major role in reported that P2P streaming by Octoshape played a major role in its
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. 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. million users with only a handful of servers.
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, lacking 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 crowd. Here flash crowd
means a large group of application users begin to acess the same means a large group of application users begin to acess the same
skipping to change at page 5, line 43 skipping to change at page 5, line 45
Consequently, it becomes increasingly important to complement the Consequently, it becomes increasingly important to complement the
ALTO effort and reduce upload access traffic, in addition to cross- ALTO effort and reduce upload access traffic, in addition to cross-
domain and backbone traffic. domain and backbone traffic.
The IETF Low Extra Delay Background Transport (LEDBAT) Working Group The IETF Low Extra Delay Background Transport (LEDBAT) Working Group
is focusing on techniques that allow large amounts of data to be is focusing on techniques that allow large amounts of data to be
consistently transmitted without substantially affecting the delays consistently transmitted without substantially affecting the delays
experienced by other users and applications. It is expected that experienced by other users and applications. It is expected that
some P2P applications would start using such techniques, thereby some P2P applications would start using such techniques, thereby
somewhat alleviating the perceivable impact (at least on other somewhat alleviating the perceivable impact (at least on other
applications) of their high volume traffic . However, such applications) of their high volume traffic. However, such techniques
techniques may not be adopted by all P2P applications. Also, when may not be adopted by all P2P applications. Also, when adopted,
adopted, these techniques do not remove all inefficiencies, such as these techniques do not remove all inefficiencies, such as those
those associated with traffic being sent upstream as many times as associated with traffic being sent upstream as many times as there
there are remote peers interested in getting the corresponding are remote peers interested in getting the corresponding information.
information. For example, the P2P application transfer completion For example, the P2P application transfer completion times remain
times remain affected by potential (relatively) slow upstream affected by potential (relatively) slow upstream transmission.
transmission. Similarly, the performance of real-time P2P Similarly, the performance of real-time P2P applications may be
applications may be affected by potential (relatively) higher affected by potential (relatively) higher upstream latencies.
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. 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
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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, high cost, and low
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 becomes increasingly clear that they As P2P applications evolve, it is becoming increasingly clear that
will need in-network resources to provide positive user experiences. they will need in-network resources to provide positive user
For example, multiple P2P streaming systems seek additional in- experiences. For example, multiple P2P streaming systems seek
network resources during flash crowd, such as just before a major additional in-network resources during flash crowd, such as just
live streaming event. In asymmetric networks when the aggregated before a major live streaming event. In asymmetric networks when the
upload bandwidth of a channel cannot meet the download demand, a P2P aggregated upload bandwidth of a channel cannot meet the download
application may seek additional in-network resources to maintain a demand, a P2P application may seek additional in-network resources to
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 their specific algorithms in selecting the
peers that behave as the more stable, higher bandwidth sources. They peers that behave as the more stable, higher bandwidth sources. They
continue to fine-tune such algorithms. In other words, in-network continue to fine-tune such algorithms. In other words, in-network
storage should export basic mechanisms and allow as much flexibility storage should export basic mechanisms and allow as much flexibility
as possible to P2P applications to implement specific policies. This as possible to P2P applications to implement specific policies. This
conforms to the end-to-end systems principle and allows innovation conforms to the end-to-end systems principle and allows innovation
and satisfaction of specific business goals. Existing techniques for and satisfaction of specific business goals. Existing techniques for
P2P application in-network storage lack these capabilities. P2P 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, an in- The objective of this working group is to design DECADE, which
network storage protocol to address the problems discussed in the primarily consists of an in-network storage access protocol (IAP) to
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
P2P caching architecture, DECADE is a standard interface for various P2P caching architecture, DECADE is a standard interface for various
P2P applications (both content publishers and end users) to access P2P applications (both content publishers and end users) to access
in-network storage. This decoupling of P2P data access from P2P in-network storage. This decoupling of P2P data access from P2P
application control and signaling reduces the complexity of in- application control and signaling reduces the complexity of in-
network storage services. Furthermore, DECADE provides basic access network storage services. Furthermore, DECADE provides basic access
mechanisms and allows P2P applications to implement flexible policies mechanisms and allows P2P applications to implement flexible policies
skipping to change at page 8, line 49 skipping to change at page 8, line 49
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.
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 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 an existing IETF
protocols. The WG will not limit itself to a single data transport protocols. The WG will not limit itself to a single data transport
protocol since different protocols may have varying implementation protocol since different protocols may have varying implementation
costs and performance tradeoffs. However, to keep interoperability costs and performance tradeoffs. However, to keep interoperability
manageable, a small number of specific, targeted, data transport manageable, a small number of specific, targeted, data transport
protocols will be identified and used. If a protocol is found to be protocols will be identified and used. If a protocol is found to be
skipping to change at page 9, line 33 skipping to change at page 9, line 33
4.2. Authorization 4.2. Authorization
DECADE ensures that access to the in-network storage is subject to DECADE ensures that access to the in-network storage is subject to
authorization by the user owning the in-network storage service. The authorization by the user owning the in-network storage service. The
authorization can take into account the user trying to access, the authorization can take into 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 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., the bandwidth or
connections. The resource control policies could be based on connections. The resource control policies could be based on
individual remote peers or a whole application. 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.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
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
utilize any uplink bandwidth if the block was already present in its utilize any uplink bandwidth if the block was already present in its
in-network storage. Second, notice that the block is downloaded in-network storage. Second, notice that the block is downloaded
directly into A's in-network storage. When A wishes to share the directly into A's in-network storage. When A wishes to share the
block with another peer (say, peer C) that supports DECADE, it may block with another peer (say, peer C) that supports DECADE, it may
upload directly from its in-network storage, again avoiding usage of upload directly from its in-network storage, again avoiding usage of
the last-mile uplink. the last-mile uplink.
In this case, in order to avoid the connectivity issue brought by Redirection to a DECADE server does not only need to come from a
NATs, B can also attach its in-network storage address in the message peer. In this case, in order to avoid the connectivity issue brought
to its tracker. When A sends the content request message with the by NATs, B can also attach its in-network storage address in the
content ID to the tracker, the tracker replies with B's in-network message to its tracker. When A sends the content request message
storage address and the BitMap info. Then A sends a request using with the content ID to the tracker, the tracker replies with B's in-
IAP protocol to B's in-network storage for the pieces of this network storage address and the BitMap info. Then A sends a request
content, with the unique identities of these pieces in the storage. using IAP protocol to B's in-network storage for the pieces of this
content, with the unique identity of the content in the storage.
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
skipping to change at page 11, line 39 skipping to change at page 11, line 39
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.
5.3. hybrid Internet TV If it desires, a content publisher may still apply DRM to the
payload. This is independent of any authentication or authorization
provided DECADE.
A particular interesting Internet TV variant is "hybrid Internet TV" 5.3. CDN/P2P hybrid
based on an Internet TV distribution service that is a hybrid between
traditional CDN and a P2P service. Such a service would distribute Some applications use a hybrid content distribution approach
content from central servers, make use of CDN caches on the way and incorporating both P2P and CDN modes. As an example, Internet TV may
finally use the end hosts/STB as caches for the P2P part of the be implemented as a hybrid CDN/P2P application by distributing
application. If only the P2P application in the host/STB can store content from central servers via a CDN, and also incorporating a P2P
content in the DECADE storage, the content first has to be downloaded mode amongst endhosts and set-top boxes.
from the Internet TV server/CDN cache over the access link to the
host/STB and then uploaded, over the same access link, to the DECADE DECADE may be beneficial to hybrid CDN/P2P applications as well.
storage before any peer in the P2P part of the application can access However, if only the endhost can store content in the DECADE server,
it from the DECADE storage (instead of downloading it from the the content must be downloaded and then uploaded over the last-mile
client). access link before another peer may retrieve it from a DECADE server.
Thus, in this deployment scenario, it may be advantageous for a
Content Publisher or CDN provider to store content to 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.
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
skipping to change at page 14, line 10 skipping to change at page 14, line 18
+-------+*******************>+-------+ +-------+*******************>+-------+
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 attack 6.1. Denial of Service Attacks
Without access control or resource control, an attacker can try to Without access control or resource control, an attacker can try to
consume a large portion of the in-network storage, or exhaust the consume a large portion of the in-network storage, or exhaust the
connections of the in-network storage to commit a Denial of Service connections of the in-network storage to commit a Denial of Service
(DoS) attack. Thus, access control and resource control mechanisms (DoS) attack. Thus, access control and resource control mechanisms
are mandatory. A resource control mechanism should be used to allow are mandatory. A resource control mechanism should be used to allow
a user to allocate the resource in its in-network storage account to a user to allocate the resource in its in-network storage account to
be utilized by other clients. be utilized by other clients.
6.2. Copyright and Legal issues 6.2. Copyright and Legal Issues
Copyright and other laws may prevent the distribution of certain Copyright and other laws may prevent the distribution of certain
content in various localities. While in-network storage operators content in various localities. While in-network storage operators
may adopt system-wide ingress or egress filters to implement may adopt system-wide ingress or egress filters to implement
necessary policies for storing or retrieving content, the necessary policies for storing or retrieving content, and
specification and implementation of such policies (e.g., filtering applications may still apply DRM to the data stored in the network
and DRM) is outside of the scope of this working group. storage, the specification and implementation of such policies (e.g.,
filtering and DRM) is outside of the scope of this working group.
7. IANA Considerations 7. IANA Considerations
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:
Akbar Rahman
David Bryan David Bryan
Francois Le Faucheur Kar Ann Chew
Roni Even
Hongqiang Law. Yingjie Gu
Kar Ann Chew Francois Le Faucheur
Richard Woundy Hongqiang Liu
Roni Even Tao Ma
Yunfei Zhang
Yu-shun Wang Borje Ohlman
Yingjie Gu Akbar Rahman
9. References Yu-shun Wang
9.1. Normative References Richard Woundy
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Yunfei Zhang
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9. Informative References
[ipoque.com] [ipoque.com]
"http://www.ipoque.com/resources/internet-studies/ "http://www.ipoque.com/resources/internet-studies/
internet-study-2008_2009". internet-study-2008_2009".
[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.weaver-alto-edge-caches] [I-D.weaver-alto-edge-caches]
Weaver, N., "Peer to Peer Localization Services and Edge Weaver, N., "Peer to Peer Localization Services and Edge
Caches", draft-weaver-alto-edge-caches-00 (work in Caches", draft-weaver-alto-edge-caches-00 (work in
progress), March 2009. progress), March 2009.
[I-D.zhang-ppsp-problem-statement] [I-D.ietf-ppsp-problem-statement]
Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang,
"Problem Statement of P2P Streaming Protocol (PPSP)", "Problem Statement of P2P Streaming Protocol (PPSP)",
draft-zhang-ppsp-problem-statement-06 (work in progress), draft-ietf-ppsp-problem-statement-01 (work in progress),
July 2010. January 2011.
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
and E. Zeidner, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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 16, line 28 skipping to change at page 16, line 24
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, PPSP. For example, peers discovered by either RELOAD
or ALTO can all use DECADE to share data. 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.zhang-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.
say 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 (ie end users) will be able to get
skipping to change at page 18, line 4 skipping to change at page 17, line 40
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
Email: haibin.song@huawei.com Email: haibin.song@huawei.com
Ning Zong Ning Zong
Huawei Huawei
101 Software Avenue, Yuhua District, 101 Software Avenue, Yuhua District,
Nanjing, Jiangsu Province 210012 Nanjing, Jiangsu Province 210012
China China
Phone: +86-25-56624760 Phone: +86-25-56624760
Email: zongning@huawei.com Email: zongning@huawei.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Richard Alimi Richard Alimi
Google Google
Email: rich@velvetsea.net Email: ralimi@google.com
 End of changes. 44 change blocks. 
104 lines changed or deleted 93 lines changed or added

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