From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6646.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc6646.txt (limited to 'doc/rfc/rfc6646.txt') 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, + . + + [Data_Lockers] + Yang, Y., "Open Content Distribution using Data Lockers", + CoXNet Workshop, Beijing, China, November 2010, + . + + [ICNP] Wu, H., "Challenges and Opportunities of Internet + Developments in China", ICNP 2007 Keynote Speech, + October 2007, + . + + [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, . + + [ipoque_P2P_Survey] + "ipoque's 2007 P2P Survey to be presented at Technology + Review's Emerging Technologies Conference at MIT", + August 2007, . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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] + -- cgit v1.2.3