DECADE                                                           H. Song
Internet-Draft                                                   N. Zong
Intended status: Informational                                    Huawei
Expires: September 15, 2011 April 14, 2012                                          Y. Yang
                                                         Yale University
                                                                R. Alimi
                                                                  Google
                                                          March 14,
                                                        October 12, 2011

     DECoupled Application Data Enroute (DECADE) Problem Statement
                 draft-ietf-decade-problem-statement-03
                 draft-ietf-decade-problem-statement-04

Abstract

   Peer-to-peer (P2P) applications have become widely used on the
   Internet today and make up a large portion of the traffic in many
   networks.  In P2P applications, one technique for reducing the
   transit and uplink P2P traffic is to introduce storage capabilities
   within the network (the download traffic may increase because the in-
   network storage is likely much better connected).  Traditional caches
   (e.g., P2P and Web caches caches) provide such storage, but they are complex
   (due to explicitly supporting individual P2P application protocols
   and cache refreshing mechanisms) and they do not have the feature to
   allow users to manage access to content in the cache.  For example, content providers
   Content Providers cannot easily control cache access and resource
   usage policies to satisfy their own requirements, in the case when the requirements.  In this document,
   a content provider is also the user of in-network storage.  This
   document discusses the introduction of in-network storage for P2P
   applications, and shows the need for a standard protocol for
   accessing this storage, and
   identifies the scope of this protocol.  The access protocol storage.  It can also be used by other applications
   with similar requirements.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   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.

   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. April 14, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology and Concepts . . . . . . . . . . . . . . . . . . .  5
   3.  The Problems . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  P2P infrastructural stress and inefficiency  . . . . . . .  6
     3.2.  P2P cache: a complex in-network storage  . . . . . . . . .  7  6
     3.3.  Ineffective integration of P2P applications  . . . . . . .  7
   4.  DECADE as an In-network Storage Capability . . . . . . . . . .  8
     4.1.  Data access  . . . . . . . . . .  Motivation . . . . . . . . . . . . .  9
     4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Resource control . . . . . . . . . . . . . . . . . . . . . 10  8
   5.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . . 10  8
     5.1.  BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 10  9
     5.2.  Content Publisher  . . . . . . . . . . . . . . . . . . . . 12  9
     5.3.  CDN/P2P hybrid . . . . . . . . . . . . . . . . . . . . . . 12
     5.4.  Data Transfer Scenarios  . . . . . . . . . . . . . . . . . 13
       5.4.1.  Both Sender and Receiver Accounts are Used . . . . . . 13
       5.4.2.  Only Sender's Storage Account is Used  . . . . . . 10
   6.  Security Considerations  . . 14
       5.4.3.  Only Receiver's Storage Account is Used . . . . . . . 14
       5.4.4.  No Storage Accounts are Used . . . . . . . . . . 11
     6.1.  Denial of Service Attacks  . . . 15
   6.  Security Considerations . . . . . . . . . . . . . 11
     6.2.  Copyright and Legal Issues . . . . . . 15
     6.1.  Denial of Service Attacks . . . . . . . . . . 11
     6.3.  Privacy issue  . . . . . . 15
     6.2.  Copyright and Legal Issues . . . . . . . . . . . . . . . . 15 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16 11
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16 11
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 16 12
   Appendix A.  Other Related Work in IETF  . . . . . . . . . . . . . 17 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 14

1.  Introduction

   P2P applications, including both P2P streaming and P2P filesharing
   applications, make up a large fraction of the traffic in many ISP
   networks today.  One way to reduce bandwidth usage by P2P
   applications is to introduce storage capabilities in the networks.
   Allowing P2P applications to store and retrieve data from inside
   networks can reduce traffic on the last-mile uplink, as well as
   backbone and transit links [I-D.weaver-alto-edge-caches]. links.

   P2P caches provide in-network storage and have been deployed in some
   networks.  But the current P2P caching architecture poses challenges
   to both P2P cache vendors and P2P application developers.  For P2P
   cache vendors, it is challenging to support a number of continuously
   evolving P2P application protocols, due to lack of documentation,
   ongoing protocol changes, and rapid introduction of new features by
   P2P applications.  For P2P applications, closed P2P caching systems
   limit P2P applications to from effectively utilize utilizing in-network storage.
   In particular, P2P caches typically do not allow users to explicitly
   store content into in-network storage.  They do not allow users to
   implement control over the content that has been placed into the in-
   network storage either.

   Both of these challenges can be effectively addressed by using an
   open, standard protocols protocol to access in-network storage.  P2P
   applications can store and retrieve content in the in-network
   storage, as well as control resources (e.g., network access, bandwidth, connections)
   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
   storage, 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
   the native P2P application protocol: signaling and data access.
   Signaling includes operations such as handshaking and discovering
   peer and content availability.  The data access component transfers
   content from one peer to another.

   With

   This document introduces DECADE, a standard interface for various P2P
   applications can still use their native protocols
   for signaling and 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
   for signaling and data transport.  However, they may use a standard
   protocol for data access incorporating in-network storage, and fall
   back to their native data transport protocols if in-network storage
   is not available or not used.

   In essence, an open, standard protocol to access in-network storage
   provides an alternative mechanism for P2P application data access
   that is decoupled from P2P application control and signaling.  This
   decoupling leads to many advantages, which is explained further in
   Section 4.

   And further, either the existing P2P cache or any new type of in-
   network storage should be deployed near the edge of the ISP's network
   so as to gain better performance.

2.  Terminology and Concepts

   The following terms have special meaning in the definition of the in-
   network storage system.

      In-network Storage: A service inside a network that provides
      storage and network access to read/write data bandwidth to network applications.  In-network storage
      may reduce upload/transit/backbone traffic and improve network
      application performance.

      IAP (In-network storage Access Protocol): a standard protocol that
      is spoken between P2P applications and in-network storage.  The
      protocol may also be used between entities implementing the in-
      network storage service.  IAP may be a new protocol or existing
      protocol with extensions.

      P2P Cache (Peer to Peer Cache): a kind of in-network storage that
      understands the signaling and transport of specific P2P
      application protocols.  It protocols, it caches the content for those specific
      p2p
      P2P applications in order to serve peers and reduce traffic on
      certain links.

      Content Publisher: An entity that originates content.

3.  The Problems

   The emergence of peer-to-peer (P2P) as a major type of network application
   (esp.  P2P file sharing and streaming apps) has led to substantial
   opportunities.  The P2P paradigm can be utilized in designing highly
   scalable and robust applications at low cost, compared with
   traditional client-server paradigms.  For example, CNN reported that
   P2P streaming by Octoshape played a major role in its distribution of
   the historical historic inauguration address of President Obama[Octoshape].
   PPLive, one of the largest P2P streaming vendors, is able to
   distribute large-scale, live streaming programs to more than 2
   million users with only a handful of servers[PPLive].

   However, P2P applications also face substantial design challenges.  A
   particular problem facing P2P applications is the substantial stress
   that they place on the network infrastructure.  Also, lack of
   infrastructure support can lead to unstable P2P application
   performance during peer churns and flash crowds.  During a crowd.  Here flash
   crowd, crowds
   means a large group of application users begin to access the same
   service during a very short period of time, which is a challenge to
   the system.  Below we elaborate on the problems in more detail.

3.1.  P2P infrastructural stress and inefficiency

   A particular problem of the P2P paradigm is the stress that P2P
   application traffic places on the infrastructure of Internet service
   providers (ISP). (ISPs).  Multiple measurements (e.g., [ipoque.com]) [ipoque]) have shown
   that P2P traffic has become a major type of traffic on some networks.
   Furthermore, network-agnostic peering (P2P transmission level) leads
   to unnecessary traversal across network domains or spanning the
   backbone of a network, leading to network inefficiency [RFC5693].

   Recently, the IETF Application

   An ALTO (Application Layer Traffic Optimization (ALTO)
   Working Group was formed to provide Optimization) server provides P2P
   applications with network information so that they can perform
   better-than-random initial peer selection [RFC5693].  However, there
   are limitations on what ALTO can achieve alone.  For example, network
   information alone cannot reduce P2P traffic in access networks, as
   the total access upload traffic is equal to the total access download
   traffic in a pure P2P system.  On the other hand, it is reported that
   P2P traffic is becoming the
   dominating dominant traffic on the access networks
   of some networks, reaching as high as 50-60% at the down-links and
   60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.],
   [P2P_file_sharing]).  Consequently, it becomes increasingly important
   to complement the ALTO effort and reduce upload access traffic, in
   addition to cross-
   domain cross-domain and backbone traffic.

   The IETF Low Extra Delay Background Transport (LEDBAT) Working Group
   is focusing on techniques that allow large amounts of data to be
   consistently transmitted without substantially affecting the delays
   experienced by other users and applications.  It is expected that
   some P2P applications would start using such techniques, thereby
   somewhat alleviating the perceivable impact (at least on other
   applications) of their high volume traffic.  However, such techniques
   may not be adopted by all P2P applications.  Also, when adopted,
   these techniques do not remove all inefficiencies, such as those
   associated with traffic being sent upstream as many times as there
   are remote peers interested in getting the corresponding information.
   For example, the P2P application transfer completion times remain
   affected by potential potentially (relatively) slow upstream transmission.
   Similarly, the performance of real-time P2P applications may be
   affected by potential potentially (relatively) higher upstream latencies.

3.2.  P2P cache: a complex in-network storage

   An effective technique to reduce P2P infrastructural stress and
   inefficiency is to introduce in-network storage.  For example, in
   [I-D.weaver-alto-edge-caches], the author demonstrates clearly the
   potential benefits of introducing in-network storage to improve
   network efficiency and thus reduce network infrastructure stress.

   In the current Internet, in-network storage is introduced as P2P
   caches, either transparently or explicitly as a P2P peer.  To provide
   service to a specific P2P application, the P2P cache server must
   support the specific signaling and transport protocols of the
   specific P2P application.  This can lead to substantial complexity
   for the P2P cache Cache vendor.

   First, there are many P2P applications on the Internet (e.g.,
   BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast,
   Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming).
   Consequently, a P2P cache vendor faces the challenge of supporting a
   large number of P2P application protocols, leading to product
   complexity and increased development cost.

   Furthermore, a specific P2P application protocol may be evolving
   continuously, to add new features or fix bugs.  This forces a P2P
   cache vendor to continuously update to track the changes of the P2P
   application, leading to product complexity, high cost, and low
   reliability.

   Third, many P2P applications use proprietary protocols or support
   end-to-end encryption.  This can render P2P caches ineffective.

3.3.  Ineffective integration of P2P applications

   As P2P applications evolve, it is becoming increasingly clear that
   they will need in-network resources to provide positive user
   experiences.  For example, multiple P2P streaming systems seek
   additional in-network resources during a flash crowd, such as just
   before a major live streaming event.  In asymmetric networks when the
   aggregated upload bandwidth of a channel cannot meet the download
   demand, a P2P application may seek additional in-network resources to
   maintain a stable system.

   A requirement by some P2P applications in using in-network
   infrastructural resources, however, is flexibility in implementing
   resource allocation policies.  A major competitive advantage of many
   successful P2P systems is their substantial expertise in how to most
   efficiently utilize peer and infrastructural resources.  For example,
   many live P2P systems have specific algorithms to select those peers
   that behave as stable, higher bandwidth sources.  They continue to
   fine-tune such algorithms.  In other words, in-network storage should
   export
   expose basic mechanisms and allow as much flexibility as possible to
   P2P applications to implement specific policies.  This conforms to
   the end-to-end systems principle and allows innovation and
   satisfaction of specific business goals.  Existing techniques for P2P
   application in-network storage lack these capabilities.

4.  Motivation

   DECADE as an In-network Storage Capability

   The objective of this working group is to design DECADE, which
   primarily consists of an in-network storage access protocol (IAP) aims to
   address the problems discussed in the preceding section.

   DECADE will provide access to storage and data transport services
   in the network to P2P applications to improve their efficiency and
   reduce the stress on the network infrastructure.  Unlike the existing
   P2P caching architecture, DECADE is aims to provide a standard interface
   for various P2P applications (both content publishers and end users)
   to access in-network storage.  This decoupling of P2P data access
   from P2P application control and signaling reduces the complexity of in-
   network
   in-network storage services.  Furthermore, DECADE provides is aimed to provide
   basic access mechanisms and allows P2P applications to implement
   flexible policies to create an ecosystem for application innovation
   and various business goals.  Besides that, it also improves the
   availability of P2P contents because the in-network storage is
   always-on.

                            IAP

                        -----------+
                        |  DECADE  |
                        |          v
                   +--------------------+
                   | In-network Storage |
                   +--------------------+
             DECADE  ^       DECADE  ^
                 IAP
                     |           IAP               |
       +-------------v-+           +-v-------------+
       | P2P           |           |  Content      |
       | application   |           |  publishers   |
       | clients       |           +---------------+
       +---------------+
        |             ^
        |             |
        +-------------+
        P2P application
        native protocol

   Figure 1  Overview of protocol interaction between DECADE elements

   Specifically, the main component of

5.  Usage Scenarios

   Usage scenarios are presented to illustrate how DECADE is the in-network
   storage
   access protocol (IAP), which is a standard, P2P-application-agnostic
   protocol for different P2P applications to access in-network storage.
   IAP defines a set of commands that may be used in both CDN and P2P application elements can issue
   to scenarios.  Interactions with
   in-network storage are described at an abstract level so as not to store
   constrain future protocol development.

5.1.  BitTorrent

   BitTorrent may be integrated with DECADE to be more network efficient
   and retrieve data.  IAP includes reduce the
   following functionality:

   (1) Data access provides read/write by users (e.g., P2P application
   clients and content publishers) bandwidth consumed on ISP networks.  When a BitTorrent
   client uploads a block to peers, the corresponding in-network
   storage and between entities implementing block traverses the in-network storage;

   (2) Authorization implements access control to resources provided by
   in-network storage;

   (3) Resource control allows users to implement application policies last-mile
   uplink once for each peer.  With DECADE, however, the corresponding in-network storage.

   While DECADE will focus on P2P applications, BitTorrent
   client may upload the solution is expected block to be applicable in other contexts with similar requirements.

4.1.  Data access

   P2P application clients use its in-network storage.  Peers may
   retrieve the IAP protocol to read data block from an in-
   network storage, store data to an the in-network storage, or remove data
   from an in-network storage.  The data could be reducing the amount
   of various types.
   Existing protocols will be used wherever possible and appropriate to
   support DECADE's requirements.  In particular, data storage,
   retrieval, on the last-mile uplink.

   We now describe in more detail how BitTorrent can utilize DECADE.
   For illustration, we assume that both the BitTorrent client (A) and management may be provided by existing IETF protocols.
   The WG will not limit itself to
   its peer (B) utilize in-network storage.  When A requests a single data transport protocol
   since different protocols may have varying implementation costs and
   performance tradeoffs.  However, to keep interoperability manageable, block,
   peer B replies with a small number of specific, targeted, data transport protocols will 'redirect' message indicating that the content
   should be identified and used. retrieved from in-network storage.  If a protocol is found to be suitable but
   does the peer B had not fully meet
   previously stored the requirements, then content in in-network storage, it uploads the protocol may need to
   be extended.  The following considerations should be taken into
   account, although
   block before A retrieves it.  If there might be trade-offs among these
   considerations.

      o The protocol(s) should support deployments with a very large
      number of users without substantial increase to operational
      complexity for is support, A may first copy
   the block to in-network storage provider.

      o The protocol(s) should be easy for application integration,
      whether they want to use it for P2P applications (e.g. file-
      sharing or streaming) or for other content distribution
      applications.

4.2.  Authorization

   DECADE ensures that access to a user's in-network storage is subject nearer to authorization by it before
   retrieving it.

   Note that user.  The authorization can take into
   account the user trying this requires extensions to access, the content, the time period, etc.

4.3.  Resource control

   A user uses the IAP protocol BitTorrent protocol.  While
   there are multiple ways to manage do so, this example assumes the resources on native
   BitTorrent 'request' message is extended to carry additional
   information and that a new 'redirect' message is added.  Upload and
   download to/from in-network storage that uses a standard protocol.

   This example has illustrated how utilizing DECADE can be used by other peers, e.g., network access to the
   storage or increase
   BitTorrent's network connections themselves.  The resource control
   policies could be based on individual remote peers or a whole
   application.

5.  Usage Scenarios

   Usage scenarios are described from two perspectives. efficiency.  First, we
   introduce high-level use cases showing how P2P applications may notice that peer B does not
   utilize any uplink bandwidth if the block was already present in its
   in-network storage.  Second, we show how in more detail how
   users exchange data using IAP.

5.1.  BitTorrent

   BitTorrent notice that the block may be integrated with DECADE copied to be more network efficient
   and reduce the bandwidth consumed on ISP networks.
   in-network storage nearer to A. When a BitTorrent
   client uploads a block A wishes to peers, share the block traverses the last-mile
   uplink once for each peer.  With with
   another peer (say, peer C) that supports DECADE, however, the BitTorrent
   client it may upload the block to its in-network storage.  Peers may
   retrieve the block
   directly from the its in-network storage, reducing the amount again avoiding usage of data on the
   last-mile uplink.

   We now describe in more detail how BitTorrent

   This technique can utilize DECADE.
   For illustration, we assume that both be applied to other P2P applications as well.
   Since P2P applications use a standard for communicating with in-
   network storage, they no longer require in-network storage to
   explicitly support their protocol.  P2P applications retain the BitTorrent client (A)
   ability to explicitly manage which content is placed in in-network
   storage, as well as access and
   its peer (B) resource control polices.

5.2.  Content Publisher

   Content Publishers may also utilize in-network storage.  When  For example,
   consider a P2P live streaming application.  A requests Content Publisher
   typically maintains a block, it
   indicates that it would like the block stored small number of sources, each of which
   distributes blocks in its in-network
   storage and provides the necessary access control.  Instead current play buffer to a set of
   sending the 'piece' message with the desired block, peer B replies
   with P2P
   peers.

   Consider a 'redirect' message indicating that case where the content should be
   retrieved from its own Content Publisher owns an in-network
   storage and provides the necessary
   access control. account within ISP A. If there are multiple P2P peers within
   ISP A, the peer B had not previously stored the Content Publisher may utilize DECADE to distribute content
   in its in-network storage, it uploads the block.  A instructs its in-
   network storage
   to download the peers.

   First, the Content Publisher stores a block from B's in the in-network
   storage, configures necessary access control, and finally A itself retrieves the block.

   Note that this requires extensions to notifies peers in
   ISP A. Second, each peer may then download from the BitTorrent protocol.  While
   there are multiple ways to do so, Content
   Publisher's in-network storage.

   In this example assumes example, the native
   BitTorrent 'request' message block is extended to carry additional
   information and that distributed in a new 'redirect' message is added.  Upload and
   download to/from in-network storage uses the standard IAP protocol.

   This example has illustrated how utilizing DECADE can increase
   BitTorrent's more network efficiency.  First, notice that peer B does not
   utilize any uplink bandwidth if efficient
   way (the content only traverses the block was already present in its
   in-network storage.  Second, notice that ISP's interdomain link once),
   while the block is downloaded
   directly into A's in-network storage.  When A wishes Content Publisher retains explicit control over access to share the
   block with another peer (say, peer C) that supports DECADE, it may
   upload directly from its in-network storage, again avoiding usage of
   the last-mile uplink.

   Redirection to a DECADE server does not only need to come from a
   peer.  In this case, content placed in order to avoid the connectivity issue brought
   by NATs, B its own storage.  The Content Publisher can also attach
   remove content from its in-network storage address in the
   message when it is stale or needs
   to its tracker.  When A sends the content request message
   with the content ID be replaced, and grant access and resources to only the tracker, the tracker replies with B's desired
   peers.

   Note that Content Publishers and individual peers can each use in-
   network storage address and storage.  For example, after downloading content from the BitMap info.  Then A sends a request
   using IAP protocol to B's
   Content Publisher's in-network storage, peers may each utilize their
   own in-networks storage for similar to the pieces of this
   content, with usage scenario in Section 5.1.
   This can have the unique identity benefit of the increased network efficiency, while
   Content Publishers and peers still retain control over content placed
   in the their own in-network storage.

   This technique can be applied to other P2P applications as well.
   Since P2P applications use

   If it desires, a standard for communicating with in-
   network storage, they no longer require in-network storage to
   explicitly support their protocol.  P2P applications retain the
   ability to explicitly manage which content is placed in in-network
   storage, as well as access and resource control polices.

5.2.  Content Publisher

   Content publishers may also utilize in-network storage.  For example,
   consider a P2P live streaming application.  A content publisher
   typically maintains a small number of sources, each of which
   distributes blocks in the current play buffer may still apply DRM to a set of the P2P
   peers.

   Consider
   payload.  This is independent of any authentication or authorization
   provided by DECADE.

5.3.  CDN/P2P hybrid

   Some applications use a case where the hybrid content publisher owns an in-network
   storage account within ISP A. If there are multiple distribution approach
   incorporating both P2P peers within
   ISP A, the content publisher and CDN modes.  As an example, Internet TV may utilize DECADE to distribute content
   to the peers.

   First, the
   be implemented as a hybrid CDN/P2P application by distributing
   content publisher stores from central servers via a block in the in-network
   storage, CDN, and then sends to each peer in ISP A the block's identifier also incorporating a P2P
   mode amongst endhosts and necessary access control.  Second, each peer set-top boxes.

   DECADE may then download
   from the content publisher's in-network storage.

   In this example, the block is distributed in a more network efficient
   way (the content only traverses the ISP's interdomain link once),
   while the content publisher retains explicit control over access be beneficial to hybrid CDN/P2P applications as well.
   However, if only the content placed in its own storage.  The content publisher endhost can
   remove store content from its in-network storage when it is stale or needs
   to be replaced, and grant access and resources to only the desired
   peers.

   Note that content publishers and individual peers can each use in-
   network storage.  For example, after downloading content from the
   content publisher's in-network storage, peers may each utilize their
   own in-networks storage similar to the usage scenario in Section 5.1.
   This can have the benefit of increased network efficiency, while
   content publishers and peers still retain control over content placed
   in their own in-network storage.

   If it desires, a content publisher may still apply DRM to the
   payload.  This is independent of any authentication or authorization
   provided by DECADE.

5.3.  CDN/P2P hybrid

   Some applications use a hybrid content distribution approach
   incorporating both P2P and CDN modes.  As an example, Internet TV may
   be implemented as a hybrid CDN/P2P application by distributing
   content from central servers via a CDN, and also incorporating a P2P
   mode amongst endhosts and set-top boxes.

   DECADE may be beneficial to hybrid CDN/P2P applications as well.
   However, if only the endhost can store content in the DECADE server,
   the content must be downloaded and then uploaded over the last-mile
   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 on DECADE servers.

5.4.  Data Transfer Scenarios

   The previous usage scenarios have utilized the ability for peers to
   transfer data by storing and retrieving from in-network storage.
   This section describes in further detail an example solution of how
   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)
   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
   user independently decides if its in-network storage account is used,
   so there are four cases.

   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
   sent using the application's protocol.  To simplify the illustration,
   we omit details of the access control from the detailed scenarios
   below.

5.4.1.  Both Sender and Receiver Accounts are Used

   This scenario is illustrated in Figure 2.  B first requests an object
   from A using the application protocol indicating it wishes the object
   to be stored in Sb.  A responds using the application protocol
   indicating that B should download the object from Sa.  B sends a IAP
   request to Sb indicating that the object should be downloaded from
   Sa.  Sb uses IAP to download from Sa, and finally, B downloads the
   object from Sb (also using IAP).

         +-------+ 4. IAP Get +-------+
         |  Sa   | <----------+  Sb   |
         +-------+  *********>+-------+
              5. data transfer  ^  *
                      3. IAP Get \  * 6. data transfer
                1. App request    \  v
      +-------+<-------------------+-------+
      |User A |                    |User B |
      +-------+------------------->+-------+
                2. App response

   Figure 2: Usage Scenario 1 (Sender and receiver Accounts used)

5.4.2.  Only Sender's Storage Account is Used

   This scenario is illustrated in Figure 3.  B requests an object from
   A using the application protocol.  A responds using the application
   protocol indicating that B should download the object from Sa.
   Finally, B sends a IAP request to Sa to download the object.

               +-------+
               |  Sa   |
               +-------+ < *
                           \ *
                             \ *
                               \ *  4. data transfer
                      3. IAP Get \ *
                                   \ *
                 1. App request      \ v
       +-------+<-------------------+-------+
       |User A |                    |User B |
       +-------+------------------->+-------+
                 2. App response

   Figure 3: Usage Scenario 2 (Sender account used)

5.4.3.  Only Receiver's Storage Account is Used

   This scenario is illustrated in Figure 4.  B requests an object from
   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
   responds to B (using the application protocol) that it should
   download from Sb.  B uses IAP to download the object from Sb.

                        +---------+
                      > |   Sb    |
            2.       /  +---------+
         IAP Store /            ^  *
                 /    4. IAP Get \  * 5. data transfer
               / 1. App request   \  v
       +-------+<---------------+-------+
       |User A |                |User B |
       +-------+--------------->+-------+
                 3. App response

   Figure 4: Usage Scenario 3 (Receiver account used)

5.4.4.  No Storage Accounts are Used

   This scenario is illustrated DECADE server,
   the content must be downloaded and then uploaded over the last-mile
   access link before another peer may retrieve it from a DECADE server.
   Thus, in Figure 5.  In this deployment scenario, the
   application protocol is used directly to send data.  This scenario
   applies with one of the peers does not support IAP, it may be advantageous for a
   Content Publisher or neither of the
   peers are using in-network storage.

                  1. App request
        +-------+<-------------------+-------+
        |User A |   ...   ...   ...  |User B |
        +-------+*******************>+-------+
                  2. data transfer

   Figure 5: Usage Scenario 4 ( No storage accounts used) CDN provider to store content to DECADE servers.

6.  Security Considerations

   There are multiple security considerations.  We can not enumerate all
   of them but focus on two three main concerns in this section.

6.1.  Denial of Service Attacks

   Without access control or resource control, an

   An attacker can try to consume a large portion of the in-network
   storage, or exhaust the connections of the in-network storage to commit through
   a Denial of Service (DoS) attack.  Thus, access control and resource control mechanisms
   are mandatory.  A resource control mechanism should be used to allow
   a user to allocate the resource in its in-network storage account to
   be utilized by other clients.

6.2.  Copyright and Legal Issues

   Copyright and other laws may prevent the distribution of certain
   content in various localities.  While in-network storage operators
   may adopt system-wide ingress or egress filters to implement
   necessary policies for storing or retrieving content, and
   applications may still apply DRM to the data stored in the network
   storage, the specification and implementation of such policies (e.g.,
   filtering and DRM) is outside of the scope of this working group.

6.3.  Privacy issue

   If the content stored in the provider-based in-network storage, there
   may be a privacy risk that the provider can correlate the people who
   are accessing the same data object using the same object identity.

7.  IANA Considerations

   There is are no IANA consideration with considerations in this document.

8.  Acknowledgments

   We would like to thank the following people for contributing to this
   document:

   David Bryan

   Kar Ann Chew

   Roni Even

   Lars Eggert

   Yingjie Gu
   Francois Le Faucheur

   Hongqiang Liu

   Tao Ma

   Borje Ohlman

   Akbar Rahman

   Yu-shun Wang

   Richard Woundy

   Yunfei Zhang

9.  Informative References

   [ipoque.com]
              "http://www.ipoque.com/resources/internet-studies/
              internet-study-2008_2009".

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.

   [I-D.weaver-alto-edge-caches]
              Weaver, N., "Peer to Peer Localization Services and Edge
              Caches", draft-weaver-alto-edge-caches-00 (work in
              progress), March 2009.

   [I-D.ietf-ppsp-problem-statement]
              Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang,
              "Problem Statement of P2P Streaming Protocol (PPSP)",
              draft-ietf-ppsp-problem-statement-01

   [I-D.ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-18 (work in
              progress),
              January August 2011.

   [DCIA]     http://www.dcia.info, "Distributed Computing Industry
              Association".

   [ipoque.P2P_survey.]
              "Emerging Technologies Conference at MIT", Sept. 2007.

   [P2P_file_sharing]
              Parker, A., "The true picture of peer-to-peer
              filesharing", July 2004.

   [Octoshape]
              "http://www.octoshape.com/?page=company/about".

   [PPLive]   "http://www.synacast.com/products/".

   [ICNP]     Wu, H., "Challenges and opportunities of Internet
              developments in China, ICNP 2007 Keynote", Oct. 2007.

Appendix A.  Other Related Work in IETF

   Note that DECADE is independent of current IETF work on P2P, e.g.
   P2PSIP, ALTO, P2P. The ALTO
   work as described above is aimed for better peer selection and PPSP.  For example, peers discovered by either the
   RELOAD or ALTO can all use DECADE to share data. [I-D.ietf-p2psip-base] protocol is used for P2P overlay
   maintenance and resource discovery.

   The Peer to Peer Streaming Protocol effort in the IETF is
   investigating the specification of signaling protocols (called the
   PPSP
   protocols) tracker protocol and peer protocol) 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.ietf-ppsp-problem-statement],
   statement, one important PPSP use case is the support of an in-network in-
   network edge cache for P2P streaming. 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 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 Peers for a given "stream" (e.g.
      because no CDN arrangement has been put in place between the
      content provider
      Content Provider and the considered particular network provider).  In that
      case, PPSP Peers will all be "off-net" but will be able to use
      DECADE in-network storage to exchange chunks.

      A given network does not support DECADE in-network storage, and
      (some of) its CDN nodes participate as PPSP peers Peers for a given
      "stream" (e.g. say because an arrangement has been put in place
      between the content provider Content Provider and the considered particular network provider).
      In that case, the CDN nodes will participate as in-network PPSP
      peers.
      Peers.  The off-net PPSP peers Peers (i.e., end users) will be able to
      get chunks from the in-network CDN nodes (using PPSP protocols
      with the CDN nodes).

      A given network supports DECADE in-network storage, and (some of)
      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
      Content Provider and the considered particular network provider).  In that
      case, the CDN nodes will participate as in-network PPSP Peers.
      The off-net PPSP Peers (i.e., end users) will be able to get
      chunks from the in-network CDN nodes (using PPSP protocols with
      the CDN nodes) as well as be able to get chunks /share / share chunks
      using DECADE in-network storage populated (using IAP protocol) by PPSP peers Peers (both off-net off-
      net end-users and in-network CDN nodes). Nodes).

      PPSP and DECADE jointly to provide P2P streaming service for
      heterogeneous 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
      its
      data transfer with the DECADE proxy with IAP. proxy.

Authors' Addresses

   Haibin Song
   Huawei
   101 Software Avenue, Yuhua District,
   Nanjing, Jiangsu Province  210012
   China

   Phone: +86-25-56624792
   Email: haibin.song@huawei.com

   Ning Zong
   Huawei
   101 Software Avenue, Yuhua District,
   Nanjing, Jiangsu Province  210012
   China

   Phone: +86-25-56624760
   Email: zongning@huawei.com
   Y. Richard Yang
   Yale University

   Email: yry@cs.yale.edu

   Richard Alimi
   Google

   Email: ralimi@google.com