draft-ietf-decade-problem-statement-00.txt   draft-ietf-decade-problem-statement-01.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: February 25, 2011 Y. Yang Expires: June 21, 2011 Y. Yang
R. Alimi
Yale University Yale University
August 24, 2010 R. Alimi
Google
December 18, 2010
DECoupled Application Data Enroute (DECADE) Problem Statement DECoupled Application Data Enroute (DECADE) Problem Statement
draft-ietf-decade-problem-statement-00 draft-ietf-decade-problem-statement-01
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 46 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 February 25, 2011. This Internet-Draft will expire on June 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . 5 3.2. P2P cache: a complex in-network storage . . . . . . . . . 6
3.3. Ineffective integration of P2P applications and 3.3. Ineffective integration of P2P applications . . . . . . . 6
in-network storage . . . . . . . . . . . . . . . . . . . . 6
4. DECADE as an In-network Storage Capability . . . . . . . . . . 7 4. DECADE as an In-network Storage Capability . . . . . . . . . . 7
4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Data access . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 10 4.3. Resource control . . . . . . . . . . . . . . . . . . . . . 9
5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 10 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 11 5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 11
5.3. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 12 5.3. hybrid Internet TV . . . . . . . . . . . . . . . . . . . . 11
5.3.1. Both Sender and Receiver Accounts are Used . . . . . . 12 5.4. Data Transfer Scenarios . . . . . . . . . . . . . . . . . 12
5.3.2. Only Sender's Storage Account is Used . . . . . . . . 13 5.4.1. Both Sender and Receiver Accounts are Used . . . . . . 12
5.3.3. Only Receiver's Storage Account is Used . . . . . . . 13 5.4.2. Only Sender's Storage Account is Used . . . . . . . . 12
5.3.4. No Storage Accounts are Used . . . . . . . . . . . . . 13 5.4.3. Only Receiver's Storage Account is 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 attack . . . . . . . . . . . . . . . . . 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 16
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 applications, make up a large fraction of the traffic in many ISP
Internet 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].
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,
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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-
network storage should be deployed near the edge of the ISP's network
so as to gain better performance.
2. Terminology and Concepts 2. Terminology and Concepts
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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
skipping to change at page 4, line 50 skipping to change at page 5, line 7
[CNN] reported that P2P streaming by Octoshape played a major role in [CNN] reported that P2P streaming by Octoshape played a major role in
its distribution of the historical inauguration address of President its 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. Below we elaborate performance during peer churns and flash crowd. Here flash crowd
on the problems in more detail. means a large group of application users begin to acess the same
service during a very short period of time, which is a chanllenge to
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]) have shown
that P2P traffic has become a major type of traffic on some networks. that P2P traffic has become a major type of traffic on some networks.
Furthermore, network-agnostic peering leads to unnecessary traversal Furthermore, network-agnostic peering leads to unnecessary traversal
across network domains or spanning the backbone of a network, leading across network domains or spanning the backbone of a network, leading
to network inefficiency [I-D.ietf-alto-problem-statement]. 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 [I-D.ietf-alto-problem-statement]. However, there are selection [RFC5693]. However, there are limitations on what ALTO can
limitations on what ALTO can achieve alone. For example, network achieve alone. For example, network information alone cannot reduce
information alone cannot reduce P2P traffic in access networks, as P2P traffic in access networks, as the total access upload traffic is
the total access upload traffic is equal to the total access download equal to the total access download traffic in a pure P2P system. On
traffic in a pure P2P system. On the other hand, it is reported that the other hand, it is reported that P2P traffic is becoming the
P2P traffic is becoming the dominating traffic on the access networks dominating traffic on the access networks of some networks, reaching
of some networks, reaching as high as 50-60% at the down-links and as high as 50-60% at the down-links and 60-90% at the uplinks
60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], ([DCIA], [ICNP], [ipoque.P2P_survey.], [P2P_file_sharing]).
[P2P_file_sharing]). Consequently, it becomes increasingly important Consequently, it becomes increasingly important to complement the
to complement the ALTO effort and reduce upload access traffic, in ALTO effort and reduce upload access traffic, in addition to cross-
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 may not be adopted by all P2P applications. Also, when techniques may not be adopted by all P2P applications. Also, when
adopted, these techniques do not remove all inefficiencies, such as adopted, these techniques do not remove all inefficiencies, such as
skipping to change at page 6, line 29 skipping to change at page 6, line 37
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
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 and in-network storage 3.3. Ineffective integration of P2P applications
As P2P applications evolve, it becomes increasingly clear that they As P2P applications evolve, it becomes increasingly clear that they
will need in-network resources to provide positive user experiences. will need in-network resources to provide positive user experiences.
For example, multiple P2P streaming systems seek additional in- For example, multiple P2P streaming systems seek additional in-
network resources during flash crowd, such as just before a major network resources during flash crowd, such as just before a major
live streaming event. In asymmetric networks when the aggregated live streaming event. In asymmetric networks when the aggregated
upload bandwidth of a channel cannot meet the download demand, a P2P upload bandwidth of a channel cannot meet the download demand, a P2P
application may seek additional in-network resources to maintain a application may seek additional in-network resources to maintain a
stable system. stable system.
skipping to change at page 8, line 17 skipping to change at page 8, line 44
(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.
Note that DECADE is independent of current IETF work on P2P, e.g.
P2PSIP, ALTO, PPSP. For example, peers discovered by either RELOAD
or ALTO can all use DECADE to share data.
The Peer to Peer Streaming Protocol effort in the IETF is
investigating specification of signaling protocols (called PPSP
protocols) for multiple types of entities (e.g. intelligent
endpoints, caches, content distribution network nodes, and/or other
edge devices) to participate in P2P streaming systems in both fixed
and mobile Internet. As discussed in the PPSP problem statement
document [I-D.zhang-ppsp-problem-statement], one important PPSP use
case is the support of an in-network edge Cache for P2P Streaming.
However, this approach to providing in-network cache has different
applicability, different objectives and different implications for
the in-network cache operator. A DECADE service can be used for any
application transparently to the DECADE in-network storage operator:
it can be used for any P2P Streaming application (whether it supports
PPSP protocols or not), for any other P2P application, and for non
P2P applications that simply want to benefit from in-network storage.
So with DECADE the operator is providing a generic in-network storage
service that can be used by any application without application
involvement or awareness by the operator; in the PPSP cache use case,
the cache operator is participating in the specific P2P streaming
service.
DECADE and PPSP can both contribute independently, and (where
appropriate) simultaneously, to making content available closer to
peers. Here are a number of example scenarios:
A given network supports DECADE in-network storage, and its CDN
nodes do not participate as PPSP Peers for a given "stream" (e.g.
say because no CDN arrangement has been put in place between the
Content Provider and the considered network provider). In that
case, PPSP Peers will all be "off-net" but will be able to use
DECADE in-network storage to exchange chunks.
A given network does not support DECADE in-network storage, and
(some of) its CDN nodes participate as PPSP Peers for a given
"stream" (e.g. say because an arrangement has been put in place
between the Content Provider and the considered network provider).
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
chunks from the in-network CDN nodes (using PPSP protocols with
the CDN nodes).
A given network supports DECADE in-network storage, and (some of)
its CDN nodes participate as PPSP Peers for a given "stream" (e.g.
say because an arrangement has been put in place between the
Content Provider and the considered network provider). 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 chunks
from the in-network CDN nodes (using PPSP protocols with the CDN
nodes) as well as be able to get chunks /share chunks using DECADE
in-network storage populated (using IAP protocol) by PPSP Peers
(both off-net end-users and in-network CDN Nodes).
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 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,
skipping to change at page 11, line 16 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
NATs, B can also attach its in-network storage address in the message
to its tracker. When A sends the content request message with the
content ID to the tracker, the tracker replies with B's in-network
storage address and the BitMap info. Then A sends a request using
IAP protocol to B's in-network storage for the pieces of this
content, with the unique identities of these pieces 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
Content Publishers may also utilize in-network storage. For example, Content Publishers may also utilize in-network storage. For example,
skipping to change at page 12, line 9 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. Data Transfer Scenarios 5.3. hybrid Internet TV
A particular interesting Internet TV variant is "hybrid Internet TV"
based on an Internet TV distribution service that is a hybrid between
traditional CDN and a P2P service. Such a service would distribute
content from central servers, make use of CDN caches on the way and
finally use the end hosts/STB as caches for the P2P part of the
application. If only the P2P application in the host/STB can store
content in the DECADE storage, the content first has to be downloaded
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
storage before any peer in the P2P part of the application can access
it from the DECADE storage (instead of downloading it from the
client).
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
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,
we omit details of the access control from the detailed scenarios we omit details of the access control from the detailed scenarios
below. below.
5.3.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 +-------+
skipping to change at page 13, line 5 skipping to change at page 12, line 47
5 data transfer ^ * 5 data transfer ^ *
3 IAP Get \ * 6 data transfer 3 IAP Get \ * 6 data transfer
1 App request \ \ / 1 App request \ \ /
+-------+<-------------------+-------+ +-------+<-------------------+-------+
|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.3.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 3 IAP Get \ * 4 data transfer
1 App request \ \/ 1 App request \ \/
+-------+<-------------------+-------+ +-------+<-------------------+-------+
|User A | |User B | |User A | |User B |
+-------+------------------->+-------+ +-------+------------------->+-------+
2 App response 2 App response
Firgure 3: Usage Scenario 2 (Sender account used) Firgure 3: Usage Scenario 2 (Sender account used)
5.3.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. / +---------+ 3. / +---------+
IAP Store / ^ * IAP Store / ^ *
/ 3.IAP Get \ * 4 data transfer / 3.IAP Get \ * 4 data transfer
/ 1.App request \ \/ / 1.App request \ \/
+-------+<-------------------+-------+ +-------+<-------------------+-------+
|User A | |User B | |User A | |User B |
+-------+------------------->+-------+ +-------+------------------->+-------+
2.App response 2.App response
Figure 4: Usage Scenario 3 (Receiver account used) Figure 4: Usage Scenario 3 (Receiver account used)
5.3.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 |
+-------+*******************>+-------+ +-------+*******************>+-------+
skipping to change at page 14, line 46 skipping to change at page 14, line 38
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 Francois Le Faucheur
Hongqiang Law. Hongqiang Law.
Kar Ann Chew Kar Ann Chew
Richard Woundy Richard Woundy
Roni Even Roni Even
Yunfei Zhang Yunfei Zhang
Yu-shun Wang Yu-shun Wang
Yingjie Gu Yingjie Gu
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 15, line 31 skipping to change at page 15, line 23
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. 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".
[I-D.ietf-alto-problem-statement] [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693,
Optimization (ALTO) Problem Statement", October 2009.
draft-ietf-alto-problem-statement-04 (work in progress),
September 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.zhang-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-zhang-ppsp-problem-statement-06 (work in progress),
skipping to change at page 16, line 26 skipping to change at page 16, line 16
[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.
[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
Note that DECADE is independent of current IETF work on P2P, e.g.
P2PSIP, ALTO, PPSP. For example, peers discovered by either RELOAD
or ALTO can all use DECADE to share data.
The Peer to Peer Streaming Protocol effort in the IETF is
investigating specification of signaling protocols (called PPSP
protocols) for multiple types of entities (e.g. intelligent
endpoints, caches, content distribution network nodes, and/or other
edge devices) to participate in P2P streaming systems in both fixed
and mobile Internet. As discussed in the PPSP problem statement
document [I-D.zhang-ppsp-problem-statement], one important PPSP use
case is the support of an in-network edge Cache for P2P Streaming.
However, this approach to providing in-network cache has different
applicability, different objectives and different implications for
the in-network cache operator. A DECADE service can be used for any
application transparently to the DECADE in-network storage operator:
it can be used for any P2P Streaming application (whether it supports
PPSP protocols or not), for any other P2P application, and for non
P2P applications that simply want to benefit from in-network storage.
So with DECADE the operator is providing a generic in-network storage
service that can be used by any application without application
involvement or awareness by the operator; in the PPSP cache use case,
the cache operator is participating in the specific P2P streaming
service.
DECADE and PPSP can both contribute independently, and (where
appropriate) simultaneously, to making content available closer to
peers. Here are a number of example scenarios:
A given network supports DECADE in-network storage, and its CDN
nodes do not participate as PPSP Peers for a given "stream" (e.g.
say because no CDN arrangement has been put in place between the
Content Provider and the considered network provider). In that
case, PPSP Peers will all be "off-net" but will be able to use
DECADE in-network storage to exchange chunks.
A given network does not support DECADE in-network storage, and
(some of) its CDN nodes participate as PPSP Peers for a given
"stream" (e.g. say because an arrangement has been put in place
between the Content Provider and the considered network provider).
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
chunks from the in-network CDN nodes (using PPSP protocols with
the CDN nodes).
A given network supports DECADE in-network storage, and (some of)
its CDN nodes participate as PPSP Peers for a given "stream" (e.g.
say because an arrangement has been put in place between the
Content Provider and the considered network provider). 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 chunks
from the in-network CDN nodes (using PPSP protocols with the CDN
nodes) as well as be able to get chunks /share chunks using DECADE
in-network storage populated (using IAP protocol) by PPSP Peers
(both off-net end-users and in-network CDN Nodes).
PPSP and DECADE jointly to provide P2P streaming service for
hetergeneous networks including both fixed and mobile connections
and enables the mobile nodes to use DECADE. In this case there
may be some solutions to require more information in PPSP tracker
protocol, e.g.,the mobile node can indicate its DECADE in-network
proxy to PPSP tracker and the following requesting peer can finish
data transfer with the DECADE proxy with IAP.
Authors' Addresses Authors' Addresses
Haibin Song Haibin Song
Huawei Huawei
Baixia Road No. 91 101 Software Avenue, Yuhua District,
Nanjing, Jiangsu Province 210001 Nanjing, Jiangsu Province 210012
P.R.China China
Phone: +86-25-56622975
Email: melodysong@huawei.com
Phone: +86-25-56624792
Email: haibin.song@huawei.com
Ning Zong Ning Zong
Huawei Huawei
Baixia Road No. 91 101 Software Avenue, Yuhua District,
Nanjing, Jiangsu Province 210001 Nanjing, Jiangsu Province 210012
P.R.China China
Phone: +86-25-56622975 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
Yale University Google
Email: richard.alimi@yale.edu Email: rich@velvetsea.net
 End of changes. 33 change blocks. 
114 lines changed or deleted 155 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/