[要約] RFC 6646は、DECADE(DECoupled Application Data Enroute)の問題声明を提供しています。その目的は、データの配信と保存を分離することで、大規模なデータ配信アプリケーションの効率とスケーラビリティを向上させることです。

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

DECoupled Application Data Enroute(DECADE)問題ステートメント

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.

ピアツーピア(P2P)アプリケーションは今日インターネットで広く使用されるようになり、多くのネットワークでトラフィックの大部分を占めています。 P2Pアプリケーションで、トランジットおよびアップリンクP2Pトラフィックを削減する1つの手法は、ネットワーク内にストレージ機能を導入することです。従来のキャッシュ(P2PやWebキャッシュなど)はこのようなストレージを提供しますが、複雑になる可能性があり(P2Pキャッシュは個々のP2Pアプリケーションプロトコルを明示的にサポートする必要があるなど)、ユーザーはキャッシュ内のコンテンツのリソース使用ポリシーを管理できません。このドキュメントでは、P2Pアプリケーション用のネットワーク内ストレージの紹介について説明し、このストレージにアクセスするための標準プロトコルの必要性を示します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

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.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6646で入手できます。

Copyright Notice

著作権表示

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

Copyright(c)2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。

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.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
1. はじめに

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.

P2PストリーミングアプリケーションとP2Pファイル共有アプリケーションの両方を含むピアツーピア(P2P)アプリケーションは、今日の多くのインターネットサービスプロバイダー(ISP)ネットワークのトラフィックの大部分を占めています。 P2Pアプリケーションによる帯域幅の使用を減らす1つの方法は、ネットワークにストレージ機能を導入することです。 P2Pアプリケーションが内部ネットワークからデータを保存および取得できるようにすることで、ラストマイルアップリンクだけでなく、バ​​ックボーンおよびトランジットリンクのトラフィックを削減できます。

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.

既存のP2Pキャッシュはネットワーク内ストレージを提供し、一部のネットワークに展開されています。ただし、現在のP2Pキャッシュアーキテクチャは、P2PキャッシュベンダーとP2Pアプリケーション開発者の両方に課題をもたらします。 P2Pキャッシュベンダーにとって、ドキュメントの不足、進行中のプロトコル変更、およびP2Pアプリケーションによる新機能の迅速な導入により、継続的に進化する多数のP2Pアプリケーションプロトコルをサポートすることは困難です。 P2Pアプリケーション開発者にとって、クローズドP2Pキャッシングシステムは、P2Pアプリケーションがネットワーク内ストレージを効果的に利用することを制限します。特に、P2Pキャッシュでは通常、ユーザーがコンテンツをネットワーク内ストレージに明示的に保存することはできません。また、アプリケーションは、ネットワーク内ストレージの使用に関する特定のリソースおよびアクセス制御ポリシーを許可しません。この課題に対処しないと、P2Pアプリケーションの効率が低下し、ネットワークインフラストラクチャの負荷が増大する可能性があります。

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.

課題は、標準のオープンプロトコルを使用してネットワーク内ストレージ[Data_Lockers]にアクセスすることで効果的に対処できます。 P2Pアプリケーションは、ネットワーク内ストレージのコンテンツを格納および取得できるだけでなく、P2Pアプリケーションのピアが消費するリソース(帯域幅、接続など)を制御できます。簡単な例として、P2Pアプリケーションのピアは、ネットワーク内ストレージを介して他のピアにアップロードし、ラストマイルアップリンク帯域幅の使用を節約できます。

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.

このドキュメントでは、ネイティブP2Pアプリケーションプロトコルの2つの機能コンポーネントであるシグナリングとデータアクセスを区別します。シグナリングには、ハンドシェイク、ピアとコンテンツの可用性の検出などの操作が含まれます。データアクセスコンポーネントは、あるピアから別のピアにコンテンツを転送します。

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
2. 用語と概念

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.

ネットワーク内ストレージ:ネットワークアプリケーションにストレージと帯域幅を提供するネットワーク内のサービス。ネットワーク内ストレージは、アップロード/トランジット/バックボーントラフィックを削減し、ネットワークアプリケーションのパフォーマンスを向上させる可能性があります。ネットワーク内ストレージの位置は、ネットワークのコアにあります。たとえば、ボーダールーター(ネットワーク接続ストレージ)と同じ場所に配置されるか、データセンター内に配置されます。

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.

P2Pキャッシュ(ピアツーピアキャッシュ):特定のP2Pアプリケーションプロトコルのシグナリングとトランスポートを理解する一種のネットワーク内ストレージ。ピアにサービスを提供し、特定のリンクのトラフィックを減らすために、これらの特定のP2Pアプリケーションのコンテンツをキャッシュします。

3. The Problems
3. 問題点

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.

主要なネットワークアプリケーション(特にP2Pファイルの共有とストリーミング)としてのP2Pの出現は、大きな機会をもたらしました。 P2Pパラダイムは、従来のクライアントサーバーパラダイムと比較して、拡張性が高く堅牢なアプリケーションを低コストで設計するために利用できます。

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.

ただし、P2Pアプリケーションも設計上の大きな課題に直面しています。 P2Pアプリケーションが直面する特定の課題は、ネットワークインフラストラクチャにかかる追加のストレスです。同時に、インフラストラクチャサポートの欠如は、特にピアチャーンやフラッシュクラウドの間に、大規模なユーザーグループが短期間にコンテンツを取得し始め、帯域幅にストレスがかかる場合に、不安定なP2Pアプリケーションパフォーマンスを引き起こす可能性があります。制限付きアクセスアップリンク。ネットワークのストレスを減らし、P2Pアプリケーションのパフォーマンスを向上させる潜在的な方法は、帯域幅に制約のあるアクセスを利用しているピアが、帯域幅の制約を受けず、他のピアからもアクセス可能な場所にデータを配置できるようにすることです。これらの問題について、さらに詳しく説明します。

3.1. P2P Infrastructural Stress and Inefficiency
3.1. P2Pインフラストラクチャストレスと非効率性

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].

P2Pパラダイムの特定の問題は、P2PアプリケーショントラフィックがISPのインフラストラクチャに与えるストレスです。複数の測定([ipoque_Internet_Study]など)により、P2Pトラフィックが一部のネットワークで主要なトラフィックタイプになっていることが示されています。さらに、(P2P送信レベルでの)ネットワークにとらわれないピアリングの非効率性は、ネットワークドメイン間またはネットワークのバックボーンにわたる不必要なトラバーサルにつながります[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.

ネットワーク情報だけを使用してより効率的なP2Pスウォームを構築しても、アクセスネットワークのP2Pトラフィックを削減するには不十分です。これは、アクセスアップロードトラフィックの合計が、従来のP2Pシステムのアクセスダウンロードトラフィックの合計と等しいためです。一方、一部のネットワークのアクセスネットワークでは、P2Pトラフィックが支配的なトラフィックになり、ダウンリンクでは50〜60%、アップリンクでは60〜90%に達すると報告されています[DCIA] [ICNP] [ ipoque_P2P_Survey] [P2P_File_Sharing]。したがって、クロスドメイントラフィックとバックボーントラフィックに加えて、アップロードアクセストラフィックを減らすことがますます重要になります。

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.

P2Pの非効率性は、対応する情報の取得に関心のあるリモートピアと同じ数のトラフィックがアップストリームに送信される場合にも見られます。たとえば、P2Pアプリケーションの転送完了時間は、潜在的に(比較的)遅いアップストリーム送信の影響を受けます。同様に、リアルタイムP2Pアプリケーションのパフォーマンスは、潜在的に(比較的)高いアップストリームレイテンシの影響を受ける可能性があります。

3.2. P2P Cache: A Complex Type of In-Network Storage
3.2. P2Pキャッシュ:複雑なタイプのネットワーク内ストレージ

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].

P2Pインフラストラクチャストレスと非効率性を低減する効果的な手法は、ネットワーク内ストレージを導入することです。既存のネットワーク内ストレージシステムの調査は、[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.

現在のインターネットでは、ネットワーク内ストレージはP2Pキャッシュとして導入され、透過的または明示的にP2Pピアとして導入されています。特定のP2Pアプリケーションにサービスを提供するには、P2Pキャッシュサーバーが特定のP2Pアプリケーションの特定のシグナリングおよびトランスポートプロトコルをサポートする必要があります。これにより、P2Pキャッシュベンダーがかなり複雑になる可能性があります。

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.

まず、インターネットには多くのP2Pアプリケーションがあります(ファイル共有にはBitTorrent、eMule、Flashget、Thunder、P2PストリーミングにはAbacast、Kontiki、Octoshape、PPLive、PPStream、UUSeeなど)。その結果、P2Pキャッシュベンダーは、多数のP2Pアプリケーションプロトコルをサポートするという課題に直面し、製品の複雑さと開発コストの増加につながります。

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.

次に、特定のP2Pアプリケーションプロトコルが継続的に進化して、新しい機能を追加したり、バグを修正したりする場合があります。これにより、P2Pキャッシュベンダーはアプリケーションの更新を継続的に監視してそのような変更を追跡する必要があり、製品の複雑さとコストの増加につながります。

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.

3番目に、多くのP2Pアプリケーションは独自のプロトコルを使用するか、エンドツーエンドの暗号化をサポートします。これにより、P2Pキャッシュが無効になる可能性があります。したがって、これらの3つの問題により、P2Pキャッシュをネットワークミドルボックスとして使用してP2Pアプリケーションの配布をサポートすることが困難になります。

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.

最後に、エンドホストは、リモートピアよりもP2Pキャッシュへの接続性と接続品質が優れています。帯域幅の使用を管理する機能がない場合、P2Pキャッシュはダウンロードトラフィックの量を増加させる可能性があり、アップロードアクセストラフィックの減少に逆行します。

3.3. Ineffective Integration of P2P Applications
3.3. P2Pアプリケーションの非効率的な統合

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.

P2Pアプリケーションが進化するにつれて、ネットワーク内リソースの使用がユーザーのエクスペリエンスを向上させることができることがますます明らかになっています。たとえば、主要なライブストリーミングイベントの直前など、フラッシュクラウドの最中に、複数のP2Pストリーミングシステムが追加のネットワーク内リソースを探します。非対称ネットワークでは、チャネルの集約アップロード帯域幅がダウンロード需要に対応できない場合、P2Pアプリケーションは追加のネットワーク内リソースを探して、安定したシステムを維持することがあります。

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.

ただし、ネットワーク内のインフラストラクチャリソースを使用する一部のP2Pアプリケーションは、リソース割り当てポリシーの実装に柔軟性を必要とします。成功している多くのP2Pシステムの主な競争上の利点は、ピアおよびインフラストラクチャリソースを最も効率的に利用する方法に関する実質的な専門知識です。たとえば、多くのライブP2Pシステムには、安定した高帯域幅のソースとして動作するピアを選択するための特定のアルゴリズムがあります。同様に、より高い帯域幅のソースは頻繁にアルゴリズムを使用して、ソースがコンテンツを送信するピアを選択します。これらのシステムの開発者は、時間とともにこれらのアルゴリズムを微調整し続けています。

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.

開発者がアルゴリズムとポリシーを進化および微調整できるようにするには、ネットワーク内ストレージが基本的なメカニズムを公開し、P2Pアプリケーションに可能な限り多くの柔軟性を許可する必要があります。これはエンドツーエンドのシステム原理に準拠し、特定のビジネス目標の革新と満足を可能にします。 P2Pアプリケーションでのネットワーク内ストレージの既存の手法には、これらの機能がありません。

4. Usage Scenarios
4. 使用シナリオ

Usage scenarios are presented to illustrate the problems in both Content Distribution Network (CDN) and P2P scenarios.

使用シナリオは、コンテンツ配信ネットワーク(CDN)とP2Pの両方のシナリオでの問題を説明するために提示されています。

4.1. BitTorrent
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.

BitTorrentクライアントAが複数のピアにブロックをアップロードすると、ブロックは各ピアについてラストマイルアップリンクを1回通過します。その後、Aからブロックを受信したばかりのピアBも、このブロックを共有するときに、独自のラストマイルアップリンクを介して他のユーザーにアップロードする必要があります。これはラストマイルアップリンクの効率的な使用ではありません。ただし、ネットワーク内ストレージサーバーでは、BitTorrentクライアントはブロックをネットワーク内ストレージにアップロードできます。ピアは、ネットワーク内ストレージからブロックを取得し、ラストマイルアップリンクのデータ量を削減できます。ネットワーク内ストレージでサポートされている場合、ピアは、ブロックが取得されている間、独自のネットワーク内ストレージにブロックを保存することもできます。次に、ブロックをネットワーク内ストレージから他のピアにアップロードできます。

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.

前述のように、BitTorrentまたは他のP2Pアプリケーションは現在、既存のP2Pキャッシュに配置されるコンテンツを明示的に管理できず、アクセスおよびリソース制御ポリシーを管理できません。アプリケーションは、ピア間のコンテンツ配信ポリシーとトポロジを制御する柔軟性を維持する必要があります。

4.2. Content Publisher
4.2. コンテンツパブリッシャー

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.

コンテンツ発行者は、ネットワーク内ストレージも利用できます。たとえば、P2Pライブストリーミングアプリケーションを考えてみます。 Content Publisherは通常、少数のソースを保持し、各ソースは現在の再生バッファー内のブロックを一連のP2Pピアに配布します。

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.

一部のコンテンツ発行者は、P2PモードとCDNモードの両方を組み込んだ別のハイブリッドコンテンツ配信アプローチを使用しています。例として、インターネットTVは、CDNを介して中央サーバーからコンテンツを配信し、エンドホストとセットトップボックスの間にP2Pモードを組み込むことにより、ハイブリッドCDN / P2Pアプリケーションとして実装できます。ネットワーク内ストレージは、ハイブリッドCDN / P2Pアプリケーションだけでなく、P2P配布をサポートし、コンテンツパブリッシャーの標準的なインターフェイスとコントロールを有効にするのに役立ちます。

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.

ハイブリッドCDN / P2Pシナリオでは、エンドホストのみがコンテンツをネットワーク内のストレージサーバーに保存できる場合、コンテンツをダウンロードし、ラストマイルアクセスリンクを介してアップロードしてから、別のピアがネットワーク内からコンテンツを取得する必要があります。ストレージサーバー。したがって、この展開シナリオでは、コンテンツ発行者またはCDNプロバイダーがコンテンツをネットワーク内のストレージサーバーに格納することが有利な場合があります。

5. Security Considerations
5. セキュリティに関する考慮事項

There are several security considerations related to in-network storage.

ネットワーク内ストレージに関連するセキュリティ上の考慮事項がいくつかあります。

5.1. Denial-of-Service Attacks
5.1. サービス拒否攻撃

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.

攻撃者は、ネットワーク内ストレージの大部分を消費したり、サービス拒否(DoS)攻撃によってネットワーク内ストレージの接続を使い果たしたりする可能性があります。クロスドメイン環境では、認証、承認、およびアカウンティングのメカニズムを検討する必要があります。管理ドメインからのアクセスを制限すると、コンテンツ配信の障壁が設定されます。

5.2. 著作権と法的問題

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.

著作権およびその他の法律により、特定のコンテンツをさまざまな地域で配布することが禁止されている場合があります。ネットワークストレージオペレーターは、システム全体の入力または出力フィルターを採用して、コンテンツの保存または取得に必要なポリシーを実装でき、アプリケーションは、ネットワークストレージに保存されているデータにデジタル著作権管理(DRM)を適用できます。ただし、このようなポリシー(フィルタリングやDRMなど)の仕様と実装は、このドキュメントで解決することを提案している問題の範囲外です。

5.3. Traffic Analysis
5.3. トラフィック分析

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
5.4. 情報の変更

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.

このタイプの脅威は、一部の不正なエンティティが、オブジェクトの値の改ざんを含む不正な管理操作を実行するような方法で、許可されたプリンシパルに代わって生成された転送中のネットワークストレージアクセスメッセージを変更する可能性があることを意味します。この脅威により、正当なストアのデータが変更されたか、偽のストアがネットワークに導入されたために、誤ったデータが提供される可能性があります。

5.5. Masquerade
5.5. 仮面舞踏会

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.

このタイプの脅威は、許可されていないエンティティがシステムにアクセスしたり、許可されたエンティティを装って違法に悪意のある行為を実行したりすることを意味します。この仕様のコンテキストでは、ネットワーク内ストレージにアクセスするときに、1つの悪意のあるエンドホストが別の承認済みエンドホストまたはアプリケーションサーバーになりすまして、ネットワーク内ストレージ内の保護されたリソースにアクセスできます。

5.6. Disclosure
5.6. 開示

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
5.7. メッセージストリームの変更

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.

この種の脅威は、ネットワーク内のストレージで不正な管理操作を実行するために、メッセージが悪意を持って並べ替えられたり、遅延したり、自然なネットワークシステムで発生するよりも多く再生されたりする可能性があることを意味します。エンドホストとネットワーク内ストレージ間のミドルボックス(Network Address Translator(NAT)など)またはプロキシが危険にさらされている場合、ストリーム変更攻撃を簡単に行うことができます。

6. Acknowledgments
6. 謝辞

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 Francois Le Faucheur

レイフ・ヨハンソン・フランソワ・ル・フォシェール

Hongqiang Liu

hongqiang l IU

Tao Ma

タオマ

Borje Ohlman

ボルジェ・オールマン

Akbar Rahman

アクバル・ラーマン

Peter Saint-Andre

ピーターサンタンドレ

Robert Sparks

ロバート・スパークス

Sean Turner

ショーンターナー

Yu-shun Wang

Y U-Shun Wang

Richard Woundy

リチャードウォンディ

Yunfei Zhang

国連は張ではない

7. Informative References
7. 参考引用

[DCIA] Parker, A., "P2P Media Summit presentation", Distributed Computing Industry Association, October 2006, <http://www.dcia.info/activities/p2pmsla2006/ CacheLogic.ppt>.

[DCIA]パーカーA。、「P2Pメディアサミットプレゼンテーション」、分散コンピューティング産業協会、2006年10月、<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>.

[Data_Lockers] Yang、Y。、「Data Lockersを使用したオープンコンテンツ配布」、CoXNet Workshop、北京、中国、2010年11月、<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>.

[ICNP] Wu、H。、「中国におけるインターネット開発の課題と機会」、ICNP 2007基調講演、2007年10月、<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.

[P2P_File_Sharing] Casadesus-Masanell、R。およびA. Hervas-Drane、「ピアツーピアファイル共有とデジタル情報商品の市場」、Journal of Economics&Management Strategy、Vol。 19、No。2、333-373ページ、2010年夏。

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

[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization(ALTO)Problem Statement」、RFC 5693、2009年10月。

[RFC6392] Alimi, R., Ed., Rahman, A., Ed., and Y. Yang, Ed., "A Survey of In-Network Storage Systems", RFC 6392, October 2011.

[RFC6392] Alimi、R。、編、Rahman、A。、編、Y。Yang、編、「A Survey of In-Network Storage Systems」、RFC 6392、2011年10月。

[ipoque_Internet_Study] Schulze, H. and K. Mochalski, "Internet Study 2008/2009", 2009, <http://www.ipoque.com/resources/internet-studies>.

[ipoque_Internet_Study] Schulze、H.および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>.

[ipoque_P2P_Survey]「MITで開催されたTechnology ReviewのEmerging Technologies Conferenceで発表されるipoqueの2007 P2P調査」、2007年8月、<http://www.ipoque.com/en/news-events/press-center/press-releases/2007 / ipoque%C2%B4s-2007-p2p-survey-to-be-presented-at-technology>。

Authors' Addresses

著者のアドレス

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

H AI bin Songhuaは101ソフトウェアアベニュー、Y Uは210012中国江蘇省NaN京区を描画します

   EMail: haibin.song@huawei.com
        

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

NIは、GH UAのZが101ソフトウェアの道であり、Y Uが210012中国江蘇省NaN京区を描く

   EMail: zongning@huawei.com
        

Y. Richard Yang Yale University

Y.リチャードヤンイェール大学

   EMail: yry@cs.yale.edu
        

Richard Alimi Google

リチャードアリミグーグル

   EMail: ralimi@google.com