doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6646.txt b/doc/rfc/rfc6646.txt
new file mode 100644
index 0000000..d0e0b1a
--- /dev/null
+++ b/doc/rfc/rfc6646.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           H. Song
+Request for Comments: 6646                                       N. Zong
+Category: Informational                                           Huawei
+ISSN: 2070-1721                                                  Y. Yang
+                                                         Yale University
+                                                                R. Alimi
+                                                                  Google
+                                                               July 2012
+
+
+     DECoupled Application Data Enroute (DECADE) Problem Statement
+
+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.  Traditional caches (e.g., P2P and Web caches)
+   provide such storage, but they can be complex (e.g., P2P caches need
+   to explicitly support individual P2P application protocols), and do
+   not allow users to manage resource usage policies for content in the
+   cache.  This document discusses the introduction of in-network
+   storage for P2P applications and shows the need for a standard
+   protocol for accessing this storage.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6646.
+
+
+
+
+
+
+
+
+
+
+Song, et al.                  Informational                     [Page 1]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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 ....................................................2
+   2. Terminology and Concepts ........................................3
+   3. The Problems ....................................................4
+      3.1. P2P Infrastructural Stress and Inefficiency ................4
+      3.2. P2P Cache: A Complex Type of In-Network Storage ............5
+      3.3. Ineffective Integration of P2P Applications ................6
+   4. Usage Scenarios .................................................6
+      4.1. BitTorrent .................................................6
+      4.2. Content Publisher ..........................................7
+   5. Security Considerations .........................................8
+      5.1. Denial-of-Service Attacks ..................................8
+      5.2. Copyright and Legal Issues .................................8
+      5.3. Traffic Analysis ...........................................8
+      5.4. Modification of Information ................................8
+      5.5. Masquerade .................................................9
+      5.6. Disclosure .................................................9
+      5.7. Message Stream Modification ................................9
+   6. Acknowledgments .................................................9
+   7. Informative References .........................................10
+
+1.  Introduction
+
+   Peer-to-peer (P2P) applications, including both P2P streaming and P2P
+   file-sharing applications, make up a large fraction of the traffic in
+   many Internet Service Provider (ISP) networks today.  One way to
+   reduce bandwidth usage by P2P applications is to introduce storage
+   capabilities in networks.  Allowing P2P applications to store and
+   retrieve data from inside networks can reduce traffic on the last-
+   mile uplink, as well as on backbone and transit links.
+
+
+
+
+
+Song, et al.                  Informational                     [Page 2]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+   Existing P2P caches provide in-network storage and have been deployed
+   in some networks.  However, 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
+   application developers, closed P2P caching systems limit P2P
+   applications from effectively utilizing in-network storage.  In
+   particular, P2P caches typically do not allow users to explicitly
+   store content into in-network storage.  They also do not allow
+   applications to specific resource and access control policies over
+   the usage of in-network storage.  The challenges, if not addressed,
+   may lead to reduced efficiency for P2P applications, and increased
+   load on the network infrastructure.
+
+   The challenges can be effectively addressed by using a standard, open
+   protocol to access in-network storage [Data_Lockers].  P2P
+   applications can store and retrieve content in the in-network
+   storage, as well as control resources (e.g., 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.
+
+   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.
+
+   In essence, coupling of the signaling and data access makes
+   in-network storage complex to support various application services.
+   However, these applications have common requirements for data access,
+   making it possible to develop a standard protocol.
+
+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 bandwidth to network applications.  In-network storage may
+      reduce upload/transit/backbone traffic and improve network
+      application performance.  The position of in-network storage is in
+      the core of a network -- for example, co-located with the border
+      router (network attached storage) or inside a data center.
+
+
+
+
+
+Song, et al.                  Informational                     [Page 3]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+   P2P cache (peer-to-peer cache):  A kind of in-network storage that
+      understands the signaling and transport of specific P2P
+      application protocols.  It caches the content for those specific
+      P2P applications in order to serve peers and reduce traffic on
+      certain links.
+
+3.  The Problems
+
+   The emergence of P2P as a major network application (especially P2P
+   file sharing and streaming) has led to substantial opportunities.
+   The P2P paradigm can be utilized to design highly scalable and robust
+   applications at low cost, compared to the traditional client-server
+   paradigm.
+
+   However, P2P applications also face substantial design challenges.  A
+   particular challenge facing P2P applications is the additional stress
+   that they place on the network infrastructure.  At the same time,
+   lack of infrastructure support can lead to unstable P2P application
+   performance, in particular during peer churns and flash crowds, when
+   a large group of users begin to retrieve the content during a short
+   period of time, leading to stress on bandwidth-constrained access
+   uplinks.  A potential way to reduce network stress and improve P2P
+   application performance would be to make it possible for peers that
+   are on bandwidth-constrained access to put data in a place that is
+   free of bandwidth constraints and also accessible by other peers.
+   These problems are now discussed in further 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 ISPs.  Multiple
+   measurements (e.g., [ipoque_Internet_Study]) have shown that P2P
+   traffic has become a major type of traffic on some networks.
+   Furthermore, the inefficiency of network-agnostic peering (at the P2P
+   transmission level) leads to unnecessary traversal across network
+   domains or spanning the backbone of a network [RFC5693].
+
+   Using network information alone to construct more efficient P2P
+   swarms is not sufficient to reduce P2P traffic in access networks, as
+   the total access upload traffic is equal to the total access download
+   traffic in a traditional P2P system.  On the other hand, it is
+   reported that P2P traffic is becoming the dominant traffic on the
+   access networks of some networks, reaching as high as 50-60% on the
+   downlinks and 60-90% on the uplinks [DCIA] [ICNP] [ipoque_P2P_Survey]
+   [P2P_File_Sharing].  Consequently, it becomes increasingly important
+   to reduce upload access traffic, in addition to cross-domain and
+   backbone traffic.
+
+
+
+
+Song, et al.                  Informational                     [Page 4]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+   The inefficiency of P2P is also observed when traffic is sent
+   upstream as many times as there are remote peers interested in
+   getting the corresponding information.  For example, the P2P
+   application transfer completion times remain affected by potentially
+   (relatively) slow upstream transmission.  Similarly, the performance
+   of real-time P2P applications may be affected by potentially
+   (relatively) higher upstream latencies.
+
+3.2.  P2P Cache: A Complex Type of In-Network Storage
+
+   An effective technique to reduce P2P infrastructural stress and
+   inefficiency is to introduce in-network storage.  A survey of
+   existing in-network storage systems can be found in [RFC6392].
+
+   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 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.
+
+   Second, a specific P2P application protocol may evolve continuously
+   to add new features or fix bugs.  This in turn forces a P2P cache
+   vendor to continuously monitor application updates to track such
+   changes, leading to product complexity and increased costs.
+
+   Third, many P2P applications use proprietary protocols or support
+   end-to-end encryption.  This can render P2P caches ineffective.
+   Therefore, these three problems make it difficult to use the P2P
+   cache as a network middlebox to support P2P application distribution.
+
+   Finally, an end host has better connectivity and connection quality
+   to a P2P cache than to a remote peer.  Without the ability to manage
+   bandwidth usage, the P2P cache may increase the volume of download
+   traffic, which runs counter to the reduction of upload access
+   traffic.
+
+
+
+
+
+
+
+
+Song, et al.                  Informational                     [Page 5]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+3.3.  Ineffective Integration of P2P Applications
+
+   As P2P applications evolve, it has become increasingly clear that
+   usage of in-network resources can improve the user's experience.  For
+   example, multiple P2P streaming systems seek additional in-network
+   resources during a flash crowd, such as just before a major live
+   streaming event.  In asymmetric networks, when the aggregated upload
+   bandwidth of a channel cannot meet the download demand, a P2P
+   application may seek additional in-network resources to maintain a
+   stable system.
+
+   However, some P2P applications using in-network infrastructural
+   resources require 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.  Similarly, the higher-
+   bandwidth sources frequently use algorithms to choose to which peers
+   the source should send content.  Developers of these systems continue
+   to fine-tune these algorithms over time.
+
+   To permit developers to evolve and fine-tune their algorithms and
+   policies, the in-network storage should expose basic mechanisms and
+   allow as much flexibility as possible to P2P applications.  This
+   conforms to the end-to-end systems principle and allows innovation
+   and satisfaction of specific business goals.  Existing techniques for
+   in-network storage in P2P applications lack these capabilities.
+
+4.  Usage Scenarios
+
+   Usage scenarios are presented to illustrate the problems in both
+   Content Distribution Network (CDN) and P2P scenarios.
+
+4.1.  BitTorrent
+
+   When a BitTorrent client A uploads a block to multiple peers, the
+   block traverses the last-mile uplink once for each peer.  After that,
+   the peer B that just received the block from A also needs to upload
+   through its own last-mile uplink to others when sharing this block.
+   This is not an efficient use of the last-mile uplink.  With an
+   in-network storage server, however, the BitTorrent client may upload
+   the block to its in-network storage.  Peers may retrieve the block
+   from the in-network storage, reducing the amount of data on the
+   last-mile uplink.  If supported by the in-network storage, a peer can
+   also save the block in its own in-network storage while it is being
+   retrieved; the block can then be uploaded from the in-network storage
+   to other peers.
+
+
+
+Song, et al.                  Informational                     [Page 6]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+   As previously discussed, BitTorrent or other P2P applications
+   currently cannot explicitly manage which content is placed in the
+   existing P2P caches, nor can they manage access and resource control
+   policies.  Applications need to retain flexibility to control the
+   content distribution policies and topology among peers.
+
+4.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 to a set of P2P peers.
+
+   Some content publishers use another 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 end hosts and set-top boxes.
+   In-network storage may be beneficial to hybrid CDN/P2P applications
+   as well to support P2P distribution and to enable content publisher
+   standard interfaces and controls.
+
+   However, there is no standard interface for different content
+   publishers to access in-network storage.  One streaming content
+   publisher may need the existing in-network storage to support
+   streaming signaling or another such capability, such as transcoding
+   capability, bitmap information, intelligent retransmission, etc.,
+   while a different content publisher may only need the in-network
+   storage to distribute files.  However, it is reasonable that the
+   application services are only supported by content publishers'
+   original servers and clients, and intelligent data plane transport
+   for those content publishers are supported by in-network storage.
+
+   A content publisher also benefits from a standard interface to access
+   in-network storage servers provided by different providers.  The
+   standard interface must allow content publishers to retain control
+   over content placed in their own in-network storage and to grant
+   access and resources only to the desired end hosts and peers.
+
+   In the hybrid CDN/P2P scenario, if only the end hosts can store
+   content in the in-network storage server, the content must be
+   downloaded and then uploaded over the last-mile access link before
+   another peer may retrieve it from an in-network storage server.
+   Thus, in this deployment scenario, it may be advantageous for a
+   content publisher or CDN provider to store content in in-network
+   storage servers.
+
+
+
+
+
+Song, et al.                  Informational                     [Page 7]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+5.  Security Considerations
+
+   There are several security considerations related to in-network
+   storage.
+
+5.1.  Denial-of-Service Attacks
+
+   An attacker can try to consume a large portion of the in-network
+   storage, or exhaust the connections of the in-network storage through
+   a denial-of-service (DoS) attack.  Authentication, authorization, and
+   accounting mechanisms should be considered in the cross-domain
+   environment.  Limitation of access from an administrative domain sets
+   up barriers for content distribution.
+
+5.2.  Copyright and Legal Issues
+
+   Copyright and other laws may prevent the distribution of certain
+   content in various localities.  In-network storage operators may
+   adopt system-wide ingress or egress filters to implement necessary
+   policies for storing or retrieving content, and applications may
+   apply Digital Rights Management (DRM) to the data stored in the
+   network storage.  However, the specification and implementation of
+   such policies (e.g., filtering and DRM) is not in scope for the
+   problem this document proposes to solve.
+
+5.3.  Traffic Analysis
+
+   If the content is stored in the provider-based in-network storage,
+   there may be a risk to privacy: a malicious service provider could
+   use some link that a victim user is interested in, estimate that
+   another user accessing the same data may have the same interest, and
+   use this information as a basis to perform a phishing attack on the
+   other user.
+
+5.4.  Modification of Information
+
+   This type of threat means that some unauthorized entity may alter
+   in-transit in-network storage access messages generated on behalf of
+   an authorized principal in such a way as to effect unauthorized
+   management operations, including falsifying the value of an object.
+   This threat may result in false data being supplied either because
+   the data on a legitimate store is modified or because a bogus store
+   is introduced into the network.
+
+
+
+
+
+
+
+
+Song, et al.                  Informational                     [Page 8]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+5.5.  Masquerade
+
+   This type of threat means that an unauthorized entity gains access to
+   a system or performs a malicious act by illegitimately posing as an
+   authorized entity.  In the context of this specification, when
+   accessing in-network storage, one malicious end host can masquerade
+   as another authorized end host or application server to access a
+   protected resource in the in-network storage.
+
+5.6.  Disclosure
+
+   This type of threat involves the danger of someone eavesdropping on
+   exchanges between in-network storage and application clients.
+   Protecting against this threat may be required as a matter of
+   application policy.
+
+5.7.  Message Stream Modification
+
+   This type of threat means that messages may be maliciously
+   re-ordered, delayed, or replayed to an extent greater than what would
+   occur in a natural network system, in order to effect unauthorized
+   management operations on in-network storage.  If the middlebox (such
+   as a Network Address Translator (NAT)) or proxy between an end host
+   and in-network storage is compromised, it is easy to do a stream
+   modification attack.
+
+6.  Acknowledgments
+
+   We would like to thank the following people for contributing to this
+   document:
+
+   Ronald Bonica
+
+   David Bryan
+
+   Kar Ann Chew
+
+   Lars Eggert
+
+   Roni Even
+
+   Adrian Farrel
+
+   Yingjie Gu
+
+   David Harrington
+
+   Leif Johansson
+
+
+
+Song, et al.                  Informational                     [Page 9]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+   Francois Le Faucheur
+
+   Hongqiang Liu
+
+   Tao Ma
+
+   Borje Ohlman
+
+   Akbar Rahman
+
+   Peter Saint-Andre
+
+   Robert Sparks
+
+   Sean Turner
+
+   Yu-shun Wang
+
+   Richard Woundy
+
+   Yunfei Zhang
+
+7.  Informative References
+
+   [DCIA]     Parker, A., "P2P Media Summit presentation", Distributed
+              Computing Industry Association, October 2006,
+              <http://www.dcia.info/activities/p2pmsla2006/
+              CacheLogic.ppt>.
+
+   [Data_Lockers]
+              Yang, Y., "Open Content Distribution using Data Lockers",
+              CoXNet Workshop, Beijing, China, November 2010,
+              <http:// cs-www.cs.yale.edu/homes/yry/projects/p4p/
+              open-data-lockers-nov-2010-coxnet.pdf>.
+
+   [ICNP]     Wu, H., "Challenges and Opportunities of Internet
+              Developments in China", ICNP 2007 Keynote Speech,
+              October 2007,
+              <http://www.ieee-icnp.org/2007/keynote_D.html>.
+
+   [P2P_File_Sharing]
+              Casadesus-Masanell, R. and A. Hervas-Drane, "Peer-to-Peer
+              File Sharing and the Market for Digital Information
+              Goods", Journal of Economics & Management Strategy,
+              Vol. 19, No. 2, pp. 333-373, Summer 2010.
+
+
+
+
+
+
+Song, et al.                  Informational                    [Page 10]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
+              Optimization (ALTO) Problem Statement", RFC 5693,
+              October 2009.
+
+   [RFC6392]  Alimi, R., Ed., Rahman, A., Ed., and Y. Yang, Ed., "A
+              Survey of In-Network Storage Systems", RFC 6392,
+              October 2011.
+
+   [ipoque_Internet_Study]
+              Schulze, H. and K. Mochalski, "Internet Study 2008/2009",
+              2009, <http://www.ipoque.com/resources/internet-studies>.
+
+   [ipoque_P2P_Survey]
+              "ipoque's 2007 P2P Survey to be presented at Technology
+              Review's Emerging Technologies Conference at MIT",
+              August 2007, <http://www.ipoque.com/en/news-events/
+              press-center/press-releases/2007/
+              ipoque%C2%B4s-2007-p2p-survey-to-be-presented-at-
+              technology>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Song, et al.                  Informational                    [Page 11]
+
+RFC 6646                DECADE Problem Statement               July 2012
+
+
+Authors' Addresses
+
+   Haibin Song
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu Province  210012
+   China
+
+   EMail: haibin.song@huawei.com
+
+
+   Ning Zong
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu Province  210012
+   China
+
+   EMail: zongning@huawei.com
+
+
+   Y. Richard Yang
+   Yale University
+
+   EMail: yry@cs.yale.edu
+
+
+   Richard Alimi
+   Google
+
+   EMail: ralimi@google.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Song, et al.                  Informational                    [Page 12]
+