RFC 6029 - A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem 日本語訳

URL : https://tools.ietf.org/html/rfc6029
タイトル : RFC 6029 - アプリケーション層のトラフィックの最適化に関する研究調査（ALTO）問題
翻訳編集 : 自動生成

Internet Research Task Force (IRTF)                             I. Rimac
Request for Comments: 6029                                       V. Hilt
Category: Informational                                         M. Tomsu
ISSN: 2070-1721                                               V. Gurbani
                                               Bell Labs, Alcatel-Lucent
                                                              E. Marocco
                                                          Telecom Italia
                                                            October 2010

                        A Survey on Research on
       the Application-Layer Traffic Optimization (ALTO) Problem

Abstract

抽象

A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization.

今日は、ピア・ツー・ピア（P2P）アプリケーションによって生成されるインターネットトラフィックの大部分は、リアルタイム通信やライブメディアストリーミングのために、最近でファイル共有のために最初に使用、と。そのようなアプリケーションは、基礎となるネットワークトポロジーのほとんど知識を有するオーバーレイ・ネットワークを介して経路を発見します。その結果、彼らは次善の選択肢につながることができます実験的測定から推定情報に基づいてピアを選択することができます。この文書で、P2P研究グループの製品は、アプリケーションレイヤトラフィックの最適化のためのネットワークトポロジー情報を発見し、使用上の既存の文献の調査を提示します。

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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Peer-to-Peer Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットリサーチタスクフォースのピアツーピア研究グループ（IRTF）のコンセンサスを表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc6029.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6029で取得することができます。

著作権表示

著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Survey of Existing Literature  . . . . . . . . . . . . . . . .  4
     2.1.  Application-Level Topology Estimation  . . . . . . . . . .  5
     2.2.  Topology Estimation through Layer Cooperation  . . . . . .  8
       2.2.1.  P4P Architecture . . . . . . . . . . . . . . . . . . .  9
       2.2.2.  Oracle-Based ISP-P2P Collaboration . . . . . . . . . .  9
       2.2.3.  ISP-Driven Informed Path Selection (IDIPS) Service . . 10
   3.  Application-Level Topology Estimation and the ALTO Problem . . 10
   4.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Coordinate Estimation or Path Latencies? . . . . . . . . . 12
     4.2.  Malicious Nodes  . . . . . . . . . . . . . . . . . . . . . 12
     4.3.  Information Integrity  . . . . . . . . . . . . . . . . . . 12
     4.4.  Richness of Topological Information  . . . . . . . . . . . 13
     4.5.  Hybrid Solutions . . . . . . . . . . . . . . . . . . . . . 13
     4.6.  Negative Impact of Over-Localization . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 14

1. Introduction

1. はじめに

A significant part of today's Internet traffic is generated by peer-to-peer (P2P) applications, used originally for file sharing, and more recently for real-time multimedia communications and live media streaming. P2P applications pose serious challenges to the Internet infrastructure; by some estimates, P2P systems are so popular that they make up anywhere between 40% and 85% of the entire Internet traffic [Karagiannis], [LightReading], [LinuxReviews], [Parker], [Glasner].

今日のインターネットトラフィックの大部分は、リアルタイムマルチメディア通信とライブメディアストリーミングのために最近では、ピア・ツー・ピア（P2P）アプリケーションによって生成されたファイル共有のために最初に使用され、。 P2Pアプリケーションは、インターネットのインフラに深刻な課題を提起します。いくつかの見積もりによって、P2Pシステムでは、彼らはどこかの間に40％と全体のインターネットトラフィック[Karagiannis]、[LightReading]、[LinuxReviews]、[パーカー]、[Glasner]の85％を占めるほど人気があります。

P2P systems ensure that popular content is replicated at multiple instances in the overlay. But perhaps ironically, a peer searching for that content may ignore the topology of the latent overlay network and instead select among available instances based on information it deduces from empirical measurements, which in some particular situations may lead to suboptimal choices. For example, a shorter round-trip time estimation is not indicative of the bandwidth and reliability of the underlying links, which have more of an influence than delay for large file transfer P2P applications.

P2Pシステムでは、人気のあるコンテンツがオーバーレイで複数のインスタンスで複製されていることを確認してください。おそらく皮肉なことに、そのコンテンツを検索ピアは、潜在オーバーレイ・ネットワークのトポロジを無視し、代わりに、それは経験的な測定から推測情報に基づいて、利用可能なインスタンス間で選択し、いくつかの特定の状況では次善の選択肢をもたらし得ることができます。例えば、短い往復時間の推定は、大きなファイル転送P2Pアプリケーションのための遅延よりも影響力の多くを持っている基礎となるリンクの帯域幅と信頼性を示すものではありません。

Most Distributed Hash Tables (DHT) -- the data structures that impose a specific ordering for P2P overlays -- use greedy forwarding algorithms to reach their destination, making locally optimal decisions that may not turn out to be globally optimized [Gummadi]. This naturally leads to the Application-Layer Traffic Optimization (ALTO) problem [RFC5693]: how to best provide the topology of the underlying network while at the same time allowing the requesting node to use such information to effectively reach the node on which the content resides. Thus, it would appear that P2P networks with their application-layer routing strategies based on overlay topologies are in direct competition against the Internet routing and topology.

ほとんどの分散ハッシュテーブル（DHT） - P2Pオーバーレイのための特定の順序を課すデータ構造 - その宛先に到達するために貪欲な転送アルゴリズムを使用し、判明しないことがあり、ローカルに最適な意思決定を行うには、世界的に[Gummadi]最適化されます。これは自然にアプリケーション層のトラフィックの最適化（ALTO）問題[RFC5693]につながる：同時に要求ノードが効果的にコンテンツれているノードに到達するために、このような情報を使用することを可能にしながら、最高の基盤となるネットワークのトポロジを提供する方法常駐します。このように、彼らのアプリケーション層のルーティング戦略とP2Pネットワークは、オーバーレイ・トポロジーに基づくように思われるインターネットルーティングとトポロジに対する直接の競争関係にあります。

One way to solve the ALTO problem is to build distributed application-level services for location and path selection [Francis], [Ng], [Dabek], [Costa], [Wong], [Madhyastha] in order to enable peers to estimate their position in the network and to efficiently select their neighbors. Similar solutions have been embedded into P2P applications such as Vuze [Vuze]. A slightly different approach is to have the Internet service provider (ISP) take a proactive role in the routing of P2P application traffic; the means by which this can be achieved have been proposed [Aggarwal], [Xie], [Saucez]. There is an intrinsic struggle between the layers -- P2P overlay and network underlay -- when performing the same service (routing); however, there are strategies to mitigate this dichotomy [Seetharaman].

ALTOの問題を解決する1つの方法は、位置及び経路選択[フランシス]のために、分散アプリケーション・レベルのサービスを構築することである、[ン]、[Dabek]、[コスタ]、[ウォン]、[Madhyastha]推定するピアを可能にするために効率的に隣人を選択するために、ネットワーク内の位置と。同様のソリューションは、Vuzeの[Vuzeの】としてP2Pアプリケーションに埋め込まれています。わずかに異なるアプローチは、インターネットサービスプロバイダ（ISP）はP2Pアプリケーショントラフィックのルーティングで積極的な役割を担うことです。これを達成することができる手段が提案されている[アガルワル]、[謝]、[Saucez]。 P2Pオーバーレイネットワークとアンダーレイ - - 層の間の固有の闘争がある同一のサービス（ルーティング）を行います。しかし、この二分法[Seetharaman]を軽減するための戦略があります。

This document, initially intended as a complement to RFC 5693 [RFC5693] and discussed during the creation of the IETF ALTO Working Group, has been completed and refined in the IRTF P2P Research Group. Its goal is to summarize the contemporary research activities on the Application-Layer Traffic Optimization problem as input to the ALTO working group protocol designers.

最初はRFC 5693 [RFC5693]とIETF ALTOワーキンググループの作成中に議論を補完するものとして意図され、この文書では、完成しIRTF P2P研究グループでは、洗練されています。その目標はALTOワーキンググループのプロトコル設計者への入力として、アプリケーションレイヤトラフィック最適化問題への現代的な研究活動を要約することです。

1.1. Terminology

1.1. 用語

Terminology adopted in this document includes terms such as "ring geometry", "tree structure", and "butterfly network", borrowed from P2P scientific literature. [RFC4981] provides an exhaustive definition of such terminology.

本書で採用用語は、P2P科学文献から借りた「環幾何学」、「木構造」、および「バタフライネットワーク」、などの用語を含んでいます。 [RFC4981]は、そのような用語の徹底的な定義を提供します。

Certain security-related terms are to be understood in the sense defined in [RFC4949]; such terms include, but are not limited to, "attack", "authentication", "confidentiality", "encryption", "identity", and "integrity". Other security-related terms (for example, "denial of service") are to be understood in the sense defined in the referenced specifications.

特定のセキュリティ関連の用語は[RFC4949]で定義された意味で理解されるべきです。このような用語には、それだけ、「攻撃」、「認証」、「機密性」、「暗号化」、「アイデンティティ」、および「整合性」に限定されるものではありません。他のセキュリティ関連の用語（例えば、「サービスの拒否」）は、参照仕様で定義された意味で理解されるべきです。

2. Survey of Existing Literature

既存の文献の2調査

Gummadi et al. [Gummadi] compare popular DHT algorithms, and besides analyzing their resilience, provide an accurate evaluation of how well the logical overlay topology maps on the physical network layer. In their paper, relying only on measurements independently performed by overlay nodes without the support of additional location information provided by external entities, they demonstrate that the most efficient algorithms in terms of resilience and proximity performance are those based on the simplest geometric concept (i.e., the ring geometry, rather than tree structures, butterfly networks, and hybrid geometries).

Gummadiら。 [Gummadi]人気のDHTアルゴリズムを比較し、その回復力を分析するほか、物理ネットワーク層の上にどれだけ論理的なオーバーレイ・トポロジマップの正確な評価を提供しています。彼らの論文では、独立して、外部エンティティによって提供される追加のロケーション情報の支援なしにオーバーレイノードによって実行される測定にのみ依存する、彼らは（レジリエンスおよび近接性能の点で最も効率的なアルゴリズムは、それらの最も単純な幾何学的な概念に基づいていることを実証している、すなわち、むしろ、ツリー構造、バタフライネットワーク、及びハイブリッドの形状よりもリング・ジオメトリ）。

Regardless of the geometrical properties of the distributed data structures involved, interactions between application-layer overlays and the underlying networks are a rich area of investigation. The available literature in this field can be divided into two categories (Figure 1): using application-level techniques to estimate topology, and using some kind of layer cooperation to estimate topology.

かかわらず、関与する分散データ構造の幾何学的特性の、アプリケーション層オーバーレイと、基礎となるネットワークの間の相互作用は、調査の豊富な領域です。トポロジーを推定するために、アプリケーション・レベルの技術を用いて、トポロジーを推定する層協力のいくつかの種類を使用して、この分野で利用可能な文献は、2つのカテゴリ（図1）に分けることができます。

     Application-layer traffic optimization
       |
       +--> Application-level topology estimation
       |      |
       |      +--> Coordinates-based systems
       |      |      |
       |      |      +--> GNP
       |      |      |
       |      |      +--> Vivaldi
       |      |      |
       |      |      +--> PIC
       |      |
       |      +--> Path selection services
       |      |      |
       |      |      +--> IDMaps
       |      |      |
       |      |      +--> Meridian
       |      |      |
       |      |      +--> Ono
       |      |
       |      +--> Link-layer Internet maps
       |             |
       |             +--> iPlane
       |
       +--> Topology estimation through layer cooperation
              |
              +--> P4P: Provider portal for applications
              |
              +--> Oracle-based ISPs and P2P cooperation
              |
              +--> ISP-driven informed path selection

Figure 1: Taxonomy of Solutions for the Application-Layer Traffic Optimization Problem

図1：アプリケーションレイヤトラフィックの最適化問題のためのソリューションの分類

2.1. Application-Level Topology Estimation

2.1. アプリケーションレベルのトポロジ推定

Estimating network topology information on the application layer has been an area of active research. Early systems used triangulation techniques to bound the distance between two hosts using a common landmark host. In such a technique, given a cost function C, a set of vertexes V and their corresponding edges, the triangle inequality holds if for any triple {a, b, c} in V, C(a, c) is always less than or equal to C(a, g) + C(b, c). The cost function C could be expressed in terms of desirable metrics such as bandwidth or latency.

アプリケーションレイヤ上のネットワークトポロジー情報を推定することは活発な研究の領域でした。初期のシステムは、一般的なランドマークのホストを使用して、2つのホスト間の距離を結合するために三角測量技術を使用します。任意トリプルため、{A、B、C} Vにおいて、Cは、（C）は、常に以下であればそのような技術では、コスト関数C、頂点V及びそれらの対応する辺の集合が与えられ、三角不等式が成立しますC（G）+ C（B、C）に等しいです。コスト関数Cは、帯域幅又は待ち時間などの望ましい指標で表すことができます。

We note that the techniques presented in this section are only representative of the sizable research in this area. Rather than trying to enumerate an exhaustive list, we have chosen certain techniques because they represent an advance in the area that further led to derivative works.

私たちは、ここで説明する技術はこの分野でかなりの研究の唯一の代表であることに注意してください。むしろ完全なリストを列挙しようとするよりも、彼らはさらに派生作品につながった領域における進歩を表しているので、我々は特定の技術を選択しました。

Francis et al. proposed IDMaps [Francis], a system where one or more special hosts called tracers are deployed near an autonomous system. The distance measured in round-trip time (RTT) between hosts A and B is estimated as the cumulative distance between A and its nearest tracer Ta, plus the distance between B and its nearest tracer Tb, plus the shortest distance from Ta to Tb. To aid in scalability beyond that provided by the client-server design of IDMaps, Ng et al. proposed a P2P-based Global Network Positioning (GNP) architecture [Ng]. GNP was a network coordinate system based on absolute coordinates computed from modeling the Internet as a geometric space. It proposed a two-part architecture: in the first part, a small set of finite distributed hosts called landmarks compute their own coordinates in a fixed geometric space. In the second part, a host wishing to participate computes its own coordinates relative to those of the landmark hosts. Thus, armed with the computed coordinates, hosts can then determine interhost distance as soon as they discover each other.

フランシスら。提案IDMaps [フランシス]、トレーサーと呼ばれる1つ以上の特別なホストが自律システムの近くに配備されているシステム。ホストAとBとの間の往復時間（RTT）で測定された距離をAと最も近いトレーサーのTa、プラスBとその最も近いトレーサーTbを、プラスTbのへのTaからの最短距離との間の距離との間の累積距離として推定されます。 IDMaps、呉らのクライアント - サーバ設計によって提供されるものを超えてスケーラビリティを助けるために。【ン】P2Pベースのグローバルネットワークポジショニング（GNP）アーキテクチャを提案しました。 GNPは、幾何学的空間としてインターネットをモデリングから計算絶対座標に基づいて、ネットワーク座標系でした。これは、2つの部分からなるアーキテクチャを提案した：最初の部分では、ランドマークと呼ばれる有限の分散ホストの小さなセットは、固定された幾何学的な空間内に独自の座標を計算します。第二部では、参加を希望するホストは、ランドマークのホストのものと比べ、独自の座標を計算します。したがって、計算された座標で武装し、ホストは、次いで、すぐそれらが互いを発見するようにホスト間の距離を決定することができます。

Both IDMaps and GNP require fixed network infrastructure support in the form of tracers or landmark hosts; this often introduces a single point of failure and inhibits scalability. To combat this, new techniques were developed that embedded the network topology in a low-dimensional coordinate space to enable network distance estimation through vector analysis. Costa et al. introduced Practical Internet Coordinates (PIC) [Costa]. While PIC used the notion of landmark hosts, it did not require explicit network support to designate specific landmark hosts. Any node whose coordinates have been computed could act as a landmark host. When a node joined the system, it probed the network distance to some landmark hosts. Then, it obtained the coordinates of each landmark host and computed its own coordinates relative to each landmark host, subject to the constraint of minimizing the error in the predicted distance and computed distance.

両方IDMapsとGNPは、トレーサーまたはランドマークホストの形態における固定ネットワーク・インフラストラクチャのサポートを必要とします。これは、多くの場合、単一障害点を紹介し、拡張性を阻害します。これに対処するために、新しい技術は、ベクトル解析を介してネットワーク距離推定を可能にするために低次元座標空間におけるネットワークトポロジを埋設することを開発しました。コスタら。 [コスタ]実用インターネット座標（PIC）を導入しました。 PICは、画期的なホストの概念を使用しますが、それは特定のランドマークのホストを指定する明示的なネットワークサポートを必要としませんでした。座標が計算されている任意のノードは、ランドマークのホストとして作用することができます。ノードがシステムに参加したときに、それはいくつかの画期的なホストへのネットワーク距離をプローブしました。そして、各ランドマークホストの座標を取得し、予測距離と計算された距離の誤差を最小化する制約を受ける各ランドマークのホストに対して、自身の座標を計算しました。

Like PIC, Vivaldi [Dabek] proposed a fully distributed network coordinate system without any distinguished hosts. Whenever a node A communicates with another node B, it measures the RTT to that node and learns that node's current coordinates. Node A subsequently adjusts its coordinates such that it is closer to, or further from, B by computing new coordinates that minimize the squared error. A Vivaldi node is thus constantly adjusting its position based on a simulation of interconnected mass springs. Vivaldi is now being used in the popular P2P application Vuze, and studies indicate that it scales well to very large networks [Ledlie].

PICのように、ビバルディは[Dabek】完全分散型ネットワークは、任意の区別なしにホスト座標系を提案しました。ノードAが他のノードBと通信するときはいつでも、そのノードへのRTTを測定し、そのノードの現在の座標を学習します。ノードAは、その後、それは二乗誤差を最小化する新しい座標を計算することによって、またはさらにB、からに近くなるように、その座標を調整します。ビバルディ・ノードは、このように常に相互接続されたマススプリングのシミュレーションに基づいてその位置を調整しています。ヴィヴァルディは、今人気のP2PアプリケーションのVuzeに使用されている、との研究では、それは非常に大規模なネットワーク[Ledlie]にも拡大縮小することを示しています。

Network coordinate systems require the embedding of the Internet topology into a coordinate system. This is not always possible without errors, which impacts the accuracy of distance estimations. In particular, it has proved to be difficult to embed the triangular inequalities found in Internet path distances [Ledlie]. Thus, Meridian [Wong] abandons the generality of network coordinate systems and provides specific distance evaluation services. In Meridian, each node keeps track of a small fixed number of neighbors and organizes them in concentric rings, ordered by distance from the node. Meridian locates the closest node by performing a multi-hop search where each hop exponentially reduces the distance to the target. Although less general than virtual coordinates, Meridian incurs significantly less error for closest node discovery.

ネットワーク座標系は、座標系にインターネットトポロジーの埋め込みを必要とします。これは、影響を与え、距離推定の精度エラー、なしで常に可能ではありません。特に、インターネットの経路距離[Ledlie]に見出さ三角不等式を埋め込むことが困難であることが証明されています。したがって、メリディアン[ウォン]はネットワークの一般座標系を放棄し、特定の距離の評価サービスを提供します。メリディアンに、各ノードは、近隣の小さい固定数を追跡し、ノードからの距離によって順序付けられ、同心リングでそれらを編成します。経線は、各ホップが指数関数的に対象物までの距離を減少させるマルチホップ探索を行うことにより、最も近いノードを見つけ。仮想座標未満一般が、メリディアンは最も近いノード発見のための有意に少ないエラーを招きます。

The Ono project [Ono] takes a different approach and uses network measurements from Content Distribution Networks (CDNs) such as Akamai to find nearby peers. Used as a plugin to the Vuze bittorrent client, Ono provides 31% average download rate improvement [Su].

小野プロジェクト[小野]は異なるアプローチをとり、近くのピアを見つけるために、そのようなアカマイのようなコンテンツ配信ネットワーク（のCDN）からネットワーク測定値を使用します。 VuzeのはBitTorrentクライアントのプラグインとして使用される、小野は31％、平均ダウンロード速度の改善[蘇]を提供します。

Comparison of application-level topology estimation techniques, as reported in literature. Results in terms of number of (D)imensions and (L)andmarks, 90th percentile relative error.

文献に報告されているように、アプリケーションレベルトポロジー推定技術の比較。（D）imensionsの数及び（L）andmarks、90パーセンタイル相対誤差に関する結果。

   +----------------+---------------+----------------+-----------------+
   | GNP vs.        | PIC(b) vs.    | Vivaldi vs.    | Meridian vs.    |
   | IDMaps(a) (7D, | GNP (8D, 16L) | GNP (2D, 32L)  | GNP (8D, 15L)   |
   | 15L)           |               |                |                 |
   +----------------+---------------+----------------+-----------------+
   | GNP: 0.50,     | PIC: 0.38,    | Vivaldi: 0.65, | Meridian: 0.78, |
   | IDMaps: 0.97   | GNP: 0.37     | GNP: 0.65      | GNP: 1.18       |
   +----------------+---------------+----------------+-----------------+

                 (a) Does not use dimensions or landmarks.
            (b) Uses results from the hybrid strategy for PIC.

Table 1

表1

Table 1 summarizes the application-level topology estimation techniques. The salient performance metric is the relative error. While all approaches define this metric a bit differently, it can be generalized as how close a predicted distance comes to the corresponding measured distance. A value of zero implies perfect prediction, and a value of 1 implies that the predicted distance is in error by a factor of two. PIC, Vivaldi, and Meridian compare their results with that of GNP, while GNP itself compares its results with a precursor technique, IDMaps. Because each of the techniques uses a different Internet topology and a varying number of landmarks and dimensions to interpret the data set, it is impossible to normalize the relative error across all techniques uniformly. Thus, we present the relative error data in pairs, as reported in the literature describing the specific technique. Readers are urged to compare the relative error performance in each column on its own and not draw any conclusions by comparing the data across columns.

表1は、アプリケーションレベルトポロジー推定技術をまとめました。顕著なパフォーマンスメトリックは相対誤差です。すべてのアプローチは少し異なるこの指標を定義しますが、それは予測距離は、対応する測定距離まで来てどれだけ近いかのように一般化することができます。ゼロの値は完全な予測を意味し、1の値は、予測された距離が2倍に誤りがあることを意味します。 PIC、ヴィヴァルディ、及びメリディアンGNP自体は前駆体技術、IDMapsとその結果を比較しながら、GNPのもので、その結果を比較します。技術の各々は、データ・セットを解釈するために、異なるインターネットトポロジーとランドマークと寸法の変化する数を使用するので、一様に全ての技術を横切って相対誤差を正規化することは不可能です。特定の技術を記載する文献に報告されているようにこのように、我々は、ペアの相対誤差データを提示します。読者は自分自身で各列の相対誤差の性能を比較すると、列にわたってデータを比較することにより、任意の結論を引き出すしないように要請されています。

Most of the work on estimating topology information focuses on predicting network distance in terms of latency and does not provide estimates for other metrics such as throughput or packet loss rate. However, for many P2P applications latency is not the most important performance metric, and these applications could benefit from a richer information plane. Sophisticated methods of active network probing and passive traffic monitoring are generally very powerful and can generate network statistics indirectly related to performance measures of interest, such as delay and loss rate on link-level granularity. Extraction of these hidden attributes can be achieved by applying statistical inference techniques developed in the field of inferential network monitoring or network tomography subsequent to sampling of the network state. Thus, network tomography enables the extraction of a richer set of topology information, but at the same time inherently increases complexity of a potential information plane and introduces estimation errors. For both active and passive methods, statistical models for the measurement process need to be developed, and the spatial and temporal dependence of the measurements should be assessed. Moreover, measurement methodology and statistical inference strategy must be considered jointly. For a deeper discussion of network tomography and recent developments in the field, we refer the reader to [Coates].

トポロジ情報を推定する上での作業のほとんどは、待ち時間の観点からネットワーク距離を予測し、そのようなスループットやパケット損失率など、他のメトリックの推定値を提供していないに焦点を当てています。しかし、多くのP2Pアプリケーションのための待ち時間は、最も重要な性能指標ではなく、これらのアプリケーションは、より豊富な情報面から利益を得ることができます。プロービングアクティブなネットワークおよびパッシブトラフィック監視の洗練された方法は、一般的に非常に強力であり、間接的なリンクレベルの粒度での遅延と損失率など興味のパフォーマンス指標に関連するネットワーク統計情報を生成することができます。これらの隠された属性の抽出は、推論ネットワーク監視やネットワークの状態のサンプリングの後、ネットワークトモグラフィの分野で開発された統計的推論技術を適用することによって達成することができます。したがって、ネットワークトモグラフィは、トポロジ情報の豊富な抽出を可能にするが、同時に、本質的に電位情報面の複雑さを増大させ、推定誤差を導入します。能動および受動の両方の方法のために、測定プロセスのための統計モデルを開発する必要があり、測定の空間的及び時間的依存性を評価すべきです。また、測定手法と統計的推論戦略が共同で考慮しなければなりません。ネットワークトモグラフィと分野における最近の進展のより深い議論については、我々は[コーツ]を読者に参照してください。

One system providing such a service is iPlane [Madhyastha], which aims at creating an annotated atlas of the Internet that contains information about latency, bandwidth, capacity, and loss rate. To determine features of the Internet topology, iPlane bridges and builds upon different ideas, such as active probing based on packet dispersion techniques to infer available bandwidth along path segments. These ideas are drawn from different fields, including network measurement as described by Dovrolis et al. in [Dovrolis] and network tomography [Coates].

そのようなサービスを提供する1つのシステムは、レイテンシ、帯域幅、容量、およびロス率についての情報を含むインターネットの注釈付きアトラスを作成することを目的iPlane [Madhyastha]、です。インターネットトポロジー、iPlaneブリッジの機能を決定し、そのような活性のようなさまざまなアイデアは、経路セグメントに沿って利用可能な帯域幅を推定するパケット分散技術に基づくプロービングに基づいて構築します。 Dovrolisらによって記載されているように、これらのアイデアは、ネットワーク測定を含む種々の分野から引き出されます。【Dovrolis]において、ネットワークトモグラフィ[コーツ]。

2.2. Topology Estimation through Layer Cooperation

2.2. レイヤ連携によるトポロジー推定

Instead of estimating topology information on the application level through distributed measurements, this information could be provided by the entities running the physical networks -- usually ISPs or network operators. In fact, they have full knowledge of the topology of the networks they administer and, in order to avoid congestion on critical links, are interested in helping applications to optimize the traffic they generate. The remainder of this section briefly describes three recently proposed solutions that follow such an approach to address the ALTO problem.

通常のISPまたはネットワークオペレータ - 代わりに、分散の測定を介して、アプリケーションレベルでのトポロジ情報を推定する、この情報は、物理的なネットワークを実行するエンティティによって提供され得ます。実際に、彼らは、彼らが管理するネットワークのトポロジの完全な知識を持っていると、重要なリンク上の混雑を避けるために、彼らは発生するトラフィックを最適化するためにアプリケーションを助けることに興味を持っています。このセクションの残りの部分は簡単にALTOの問題に対処するために、このようなアプローチに従う3最近提案された解決策について説明します。

2.2.1. P4P Architecture

2.2.1. P4Pのアーキテクチャ

The architecture proposed by Xie et al. [Xie] has been adopted by the Distributed Computing Industry Association (DCIA) P4P working group [P4P], an open group established by ISPs, P2P software distributors, and technology researchers, with the dual goal of defining mechanisms to (1) accelerate content distribution and (2) optimize utilization of network resources.

謝らによって提案されたアーキテクチャ。 [謝]（1）加速するコンテンツへのメカニズムを定義するという二重の目的で、分散コンピューティング産業協会（DCIA）P4Pワーキンググループ[P4P]、ISPは、P2Pソフトウェア販売代理店、および技術の研究者によって確立されたオープンなグループによって採用されています分布及びネットワーク資源（2）を最適化活用。

The main role in the P4P architecture is played by servers called "iTrackers", deployed by network providers and accessed by P2P applications (or, in general, by elements of the P2P system) in order to make optimal decisions when selecting a peer to which the element will connect. An iTracker may offer three interfaces:

これにピアを選択する際P4Pアーキテクチャの主な役割は、最適な意思決定を行うために、（P2Pシステムの要素によって、一般的にまたは、）ネットワークプロバイダによって展開し、P2Pアプリケーションがアクセスし、「iTrackers」と呼ばれるサーバによって再生されます要素が接続されます。 iTrackerは、3つのインタフェースを提供することがあります：

1. Info: Allows P2P elements (e.g., peers or trackers) to get opaque information associated to an IP address. Such information is kept opaque to hide the actual network topology, but can be used to compute the network distance between IP addresses.

1.情報：IPアドレスに関連付けられた不透明な情報を得るためにP2P要素（例えば、ピア又はトラッカー）を許可します。そのような情報は、実際のネットワークトポロジーを隠蔽するために、不透明な維持されているが、IPアドレスとの間のネットワーク距離を計算するために使用することができます。

2. Policy: Allows P2P elements to obtain policies and guidelines of the network, which specify how a network provider would like its networks to be utilized at a high level, regardless of P2P applications.

2.ポリシー：P2P要素は、ネットワークプロバイダは関係なく、P2Pアプリケーションの、高いレベルで利用されるために、そのネットワークをご希望の方法を指定するネットワークのポリシーとガイドラインを、取得できるようにします。

3. Capability: Allows P2P elements to request network providers' capabilities.

3.機能は：P2P要素がネットワークプロバイダの能力を要求することができます。

The P4P architecture is under evaluation with simulations, experiments on the PlanetLab distributed testbed, and in field tests with real users. Initial simulations and PlanetLab experiment results [P4P] indicate that improvements in BitTorrent download completion time and link utilization in the range of 50-70% are possible. Results observed on Comcast's network during a field test trial conducted with a modified version of the software used by the Pando content delivery network (documented in RFC 5632 [RFC5632]) show average improvements in download rate in different scenarios varying between 57% and 85%, and a 34% to 80% drop in the cross-domain traffic generated by such an application.

P4Pのアーキテクチャは、シミュレーションによる評価の下で、PlanetLabの分散テストベッド上での実験、および実際のユーザーによるフィールドテストです。初期のシミュレーションおよびPlanetLabの実験結果[P4Pは]のBitTorrentの改善は50から70パーセントの範囲で完了時間とリンク利用率をダウンロードすることも可能であることを示しています。（RFC 5632に[RFC5632]を文書化）パンドコンテンツ配信ネットワークによって使用されるソフトウェアの修正版を用いて実施フィールド試験トライアル中Comcastのネットワーク上で観察された結果は、57％と85％の間で変化する異なるシナリオでダウンロード速度の平均改善を示しますそのようなアプリケーションによって生成されたクロスドメイントラフィックに、34％〜80％低下。

2.2.2. Oracle-Based ISP-P2P Collaboration

2.2.2. OracleベースのISP-P2Pコラボレーション

In the general solution proposed by Aggarwal et al. [Aggarwal], network providers offer host servers, called "oracles", that help P2P users choose optimal neighbors.

アガルワルらによって提案された一般的な解決策です。 [アガルワル]、ネットワークプロバイダは、「神託」と呼ばれ、ホストサーバを提供し、そのヘルプP2Pユーザーが最適な隣人を選択してください。

The oracle concept uses the following mechanism: a P2P client sends the list of potential peers to the oracle hosted by its ISP and receives a re-arranged peer list, ordered according to the ISP's local routing policies and preferences. For instance, to keep the traffic local, the ISP may prefer peers within its network, or it may pick links with higher bandwidth or peers that are geographically closer to improve application performance. Once the client has obtained this ordered list, it has enough information to perform better-than-random initial peer selection.

オラクルのコンセプトは、以下のメカニズムを使用しています：P2Pクライアントは、そのISPによってホストされているオラクルへの潜在的なピアのリストを送信し、ISPのローカルルーティングポリシーや好みに応じて注文し、再配置されたピアリストを受け取ります。たとえば、ローカルトラフィックを維持するために、ISPは、そのネットワーク内のピアを好む場合もあれば、より高い帯域幅や地理的にアプリケーションのパフォーマンスを改善するために接近しているピアとのリンクを選択することがあります。クライアントがこの順序付きリストを取得したら、それはより良いよりも、ランダムな初期ピア選択を実行するための十分な情報を持っています。

Such a solution has been evaluated with simulations and experiments run on the PlanetLab testbed, and the results show both improvements in content download time and a reduction of overall P2P traffic, even when only a subset of the applications actually query the oracle to make their decisions.

このような解決策は、PlanetLabのテストベッド上で動作シミュレーションと実験で評価されている、との結果がアプリケーションのサブセットのみが、実際に自分の意思決定を行うためにオラクルを照会しても、コンテンツのダウンロード時間と全体的なP2Pトラフィックの削減の両方で改善を示します。

2.2.3. ISP-Driven Informed Path Selection (IDIPS) Service

2.2.3. ISPドリブンな情報に経路選択（IDIPS）サービス

The solution proposed by Saucez et al. [Saucez] is essentially a modified version of the oracle-based approach described in Section 2.2.2, intended to provide a network-layer service for finding the best source and destination addresses when establishing a connection between two endpoints in multi-homed environments (which are common in IPv6 networking). Peer selection optimization in P2P systems -- the ALTO problem in today's Internet -- can be addressed by the IDIPS solution as a specific sub-case where the options for the destination address consist of all the peers sharing a desired resource, while the choice of the source address is fixed. An evaluation performed on IDIPS shows that costs for both providing and accessing the service are negligible.

Saucezらによって提案された解決策。 [Saucez]（マルチホーム環境で2つのエンドポイント間の接続を確立する際に最適なソースおよび宛先アドレスを見つけるためのネットワーク層サービスを提供することを意図し、本質的に、セクション2.2.2に記載のOracleベースのアプローチの修正版でありますこれはIPv6のネットワークでは一般的です）。 P2Pシステムにおけるピア選択の最適化 - 今日のインターネットでのALTOの問題 - の選択肢ながら、宛先アドレスのためのオプションが必要なリソースを共有するすべてのピアから構成され、特定のサブケースとしてIDIPSソリューションによって対処することができます送信元アドレスは固定されています。 IDIPSに行った評価は、両方のサービスを提供し、アクセスするためのコストは無視できることを示しています。

3. Application-Level Topology Estimation and the ALTO Problem

3.アプリケーションレベルのトポロジ推定とALTO問題

The application-level techniques described in Section 2.1 provide tools for peer-to-peer applications to estimate parameters of the underlying network topology. Although these techniques can improve application performance, there are limitations of what can be achieved by operating only on the application level.

セクション2.1で記述されたアプリケーション・レベルの技術は、基礎となるネットワークトポロジーのパラメータを推定するためにピア・ツー・ピア・アプリケーションのためのツールを提供します。これらの技術は、アプリケーションのパフォーマンスを向上させることができますが、アプリケーションレベルでのみ動作させることによって達成することができるかの制限があります。

Topology estimation techniques use abstractions of the network topology, which often hide features that would be of interest to the application. Network coordinate systems, for example, are unable to detect overlay paths shorter than the direct path in the Internet topology. However, these paths frequently exist in the Internet [Wang]. Similarly, application-level techniques may not accurately estimate topologies with multipath routing.

トポロジー推定技術は、多くの場合、アプリケーションに興味があるであろう機能を非表示にし、ネットワークトポロジの抽象化を使用します。ネットワークは、座標系、例えば、インターネットトポロジ内の直接経路よりも短いオーバーレイパスを検出することができません。しかし、これらの経路は、しばしばインターネット[王]に存在します。同様に、アプリケーションレベルの技術を正確にマルチパスルーティングとトポロジを推定しなくてもよいです。

When using network coordinates to estimate topology information, the underlying assumption is that distance in terms of latency determines performance. However, for file sharing and content distribution applications, there is more to performance than just the network latency between nodes. The utility of a long-lived data transfer is determined by the throughput of the underlying TCP protocol, which depends on the round-trip time as well as the loss rate experienced on the corresponding path [Padhye]. Hence, these applications benefit from a richer set of topology information that goes beyond latency, including loss rate, capacity, and available bandwidth.

ネットワークを使用するトポロジ情報を推定する座標が、基礎となる仮定は、レイテンシの点で距離が性能を決定することです。ただし、ファイル共有やコンテンツ配信アプリケーションのために、ノード間の単なるネットワーク遅延よりもパフォーマンスに多くあります。長寿命のデータ転送の有用性は、ラウンドトリップ時間に依存する下層のTCPプロトコルのスループット、ならびに対応するパス[Padhye]を経験損失率によって決定されます。したがって、これらのアプリケーションは、損失率、容量、および利用可能な帯域幅を含め、レイテンシーを超えたトポロジ情報の豊富な恩恵を受ける。

Some of the topology estimation techniques used by P2P applications need time to converge to a result. For example, current BitTorrent clients implement local, passive traffic measurements and a tit-for-tat bandwidth reciprocity mechanism to optimize peer selection at a local level. Peers eventually settle on a set of neighbors that maximizes their download rate, but because peers cannot reason about the value of neighbors without actively exchanging data with them, and because the number of concurrent data transfers is limited (typically to 5-7), convergence is delayed and easily can be sub-optimal.

P2Pアプリケーションで使用されるトポロジー推定技術のいくつかは結果に収束する時間が必要です。例えば、現在のBitTorrentクライアントは、ローカルレベルでピア選択を最適化するために、ローカル、パッシブトラフィック測定およびTIT-FOR-TAT帯域幅の相互関係メカニズムを実装します。ピアは、最終的にダウンロード速度を最大化する隣人のセットに落ち着くが、ピアは積極的に彼らとデータを交換することなく、隣人の値を推論することができないため、同時データ転送の数は（通常は5-7に）限られているので、収束遅れていると簡単に最適であることができます。

Skype's P2P Voice over IP (VoIP) application chooses a relay node in cases where two peers are behind NATs and cannot connect directly. Measurements taken by Ren et al. [Ren] showed that the relay selection mechanism of Skype (1) is not able to discover the best possible relay nodes in terms of minimum RTT, (2) requires a long setup and stabilization time, which degrades the end user experience, and (3) is creating a non-negligible amount of overhead traffic due to probing a large number of nodes. They further showed that the quality of the relay paths could be improved when the underlying network Autonomous System (AS) topology is considered.

SkypeのP2PボイスオーバーIP（VoIP）のアプリケーションでは、2つのピアがNATの背後にあると直接接続できない場合には、中継ノードを選択します。レンらによって得られた測定値。【レンは、（2）エンドユーザ体験を劣化長いセットアップおよび安定化時間を必要とし、（、スカイプの中継選択機構は、（1）最小RTTの点で最良の可能な中継ノードを発見することができないことを示しました3）により、多数のノードをプロービングするオーバーヘッドトラフィックの無視できない量を作成しています。彼らはさらに、基礎となるネットワークの自律システム（AS）トポロジーを考慮した場合、中継パスの品質を向上させることができることを示しました。

Some features of the network topology are hard to infer through application-level techniques, and it may not be possible to infer them at all, e.g., service-provider policies and preferences such as the state and cost associated with interdomain peering and transit links. Another example is the traffic engineering policy of a service provider, which may counteract the routing objective of the overlay network, leading to a poor overall performance [Seetharaman].

ネットワークトポロジの一部の機能は、アプリケーションレベルの技術を介して推測するのは難しいですし、すべてでそれらを推測することは可能ではないかもしれないが、例えば、そのようなドメイン間のピアリングとトランジットリンクに関連付けられた状態とコストなどのサービス・プロバイダーのポリシーと設定。別の例は、乏しい全体の性能[Seetharaman]に至る、オーバーレイ・ネットワークのルーティング目的を打ち消すことができるサービスプロバイダのトラフィックエンジニアリングポリシーです。

Finally, application-level techniques often require applications to perform measurements on the topology. These measurements create traffic overhead, in particular, if measurements are performed individually by all applications interested in estimating topology.

最後に、アプリケーションレベルの技術は、多くの場合、トポロジに測定を実行するアプリケーションが必要です。測定は、トポロジを推定することに興味のすべてのアプリケーションで個別に行われている場合、これらの測定は、具体的には、トラフィックのオーバーヘッドを作成します。

4. Open Issues

4.未解決の問題

Beyond a significant amount of research work on the topic, we believe that there are sizable open issues to address in an infrastructure-based approach to traffic optimization. The following is not an exhaustive list, but a representative sample of the pertinent issues.

トピックの研究活動にかなりの量を超えて、私たちは、トラフィックの最適化へのインフラベースのアプローチに対処するためにかなりの未解決の問題があると考えています。以下は完全なリストではありませんが、関連の問題の代表的なサンプル。

4.1. Coordinate Estimation or Path Latencies?

4.1. 推定またはパスレイテンシ座標？

Despite the many solutions that have been proposed for providing applications with topology information in a fully distributed manner, there is currently an ongoing debate in the research community whether such solutions should focus on estimating nodes' coordinates or path latencies. Such a debate has recently been fed by studies showing that the triangle inequality on which coordinate systems are based is often proved false in the Internet [Ledlie]. Proposed systems following both approaches -- in particular, Vivaldi [Dabek] and PIC [Costa] following the former, and Meridian [Wong] and iPlane [Madhyastha] the latter -- have been simulated, implemented, and studied in real-world trials, each one showing different points of strength and weaknesses. Concentrated work will be needed to determine which of the two solutions will be conducive to the ALTO problem.

完全に分散的にトポロジ情報をアプリケーションに提供するために提案されてきた多くのソリューションにもかかわらず、このようなソリューションは、ノードの座標やパスの待ち時間を推定するに焦点を当てる必要があるかどうかの研究コミュニティにおける継続的な議論は、現在存在しています。このような議論は、最近のシステムをベースとしている座標た上三角不等式は、多くの場合、インターネットで偽証明されていることを示す研究[Ledlie]によって供給されています。両方のアプローチ以下の提案されたシステム - 特に、ヴィヴァルディ[Dabek]とPIC [コスタ]以下の元、及びメリディアン[ウォン]とiPlane [Madhyastha]後者 - 、シミュレートされた実装、および実世界の試験で研究されています、強さと弱さの異なる点を示すそれぞれ。濃縮作業はALTOの問題を助長される2つのソリューションのどちらかを決定するために必要とされるであろう。

4.2. Malicious Nodes

4.2. 悪意のあるノード

Another open issue common in most distributed environments consisting of a large number of peers is the resistance against malicious nodes. Security mechanisms to identify misbehavior are based on triangle inequality checks [Costa], which, however, tend to fail and thus return false positives in the presence of measurement inaccuracies induced, for example, by traffic fluctuations that occur quite often in large networks [Ledlie]. Beyond the issue of using triangle inequality checks, authoritatively authenticating the identity of an oracle, and preventing an oracle from attacks are also important. Existing techniques -- such as Public Key Infrastructure (PKI) [RFC5280] or identity-based encryption [Boneh] for authenticating the identity and the use of secure multi-party computation techniques to prevent an oracle from collusion attacks -- need to be explored and studied for judicious use in ALTO-type solutions.

多数のピアからなるほとんどの分散環境での一般的なもう一つの未解決の問題は、悪意のあるノードに対する抵抗です。不正行為を識別するためのセキュリティメカニズムは、しかし、失敗し、したがって大規模なネットワークでは非常に頻繁に発生するトラフィックの変動によって、例えば、誘導された測定の不正確の存在下での偽陽性を返す傾向にある三角不等式をチェック[コスタ]、に基づいている[Ledlie ]。正式オラクルのアイデンティティを認証する、三角不等式のチェックを使用して、そして攻撃から神託を防ぐの問題を超えても重要です。既存の技術 - など公開鍵基盤（PKI）のように[RFC5280]やアイデンティティと共謀攻撃から神託を防止するための安全なマルチパーティ計算技術の使用を認証するためのIDベース暗号[Boneh] - 探求する必要がありますそしてALTO型ソリューションで賢明な使用のために勉強しました。

4.3. Information Integrity

4.3. 情報の整合性

Similarly, even in controlled architectures deployed by network operators where system elements may be authenticated [Xie], [Aggarwal],[Saucez], it is still possible that the information returned to applications is deliberately altered, for example, assigning higher priority to financially inexpensive links instead of neutrally applying proximity criteria. What are the effects of such deliberate alterations if multiple peers collude to determine a different route to the target, one that is not provided by an oracle? Similarly, what are the consequences if an oracle targets a particular node in another AS by redirecting an inordinate number of querying peers to it causing, essentially, a Distributed Denial-of-Service (DDoS) [RFC4732] attack on the node? Furthermore, does an oracle broadcast or multicast a response to a query? If so, techniques to protect the confidentiality of the multicast stream will need to be investigated to thwart "free riding" peers.

同様に、偶数のシステム要素が認証することができるネットワークオペレータによって展開制御アーキテクチャ[謝]、[アガルワル]、[Saucez]には、アプリケーションに返される情報を意図的に経済的に高い優先度を割り当て、例えば、変更されることが依然として可能です代わりに、中立的近接性基準を適用した安価なリンク。複数のピアは、ターゲットへの別の経路は、Oracleによって提供されていないものを決定するために共謀した場合、そのような意図的な変更の効果は何ですか？オラクルは、本質的に、原因とそれにピアを問い合わせるの過度の数、ノード上の分散サービス拒否（DDoS攻撃）[RFC4732]攻撃をリダイレクトすることなどによって、別の特定のノードをターゲット場合同様、結果は何ですか？さらに、オラクルのブロードキャストやマルチキャストクエリに応答していますか？その場合は、マルチキャストストリームの機密性を保護するための技術は、「ただ乗り」仲間を阻止するために調査する必要があります。

4.4. Richness of Topological Information

4.4. トポロジー情報の豊かさ

Many systems already use RTT to account for delay when establishing connections with peers (e.g., Content-Addressable Network (CAN) [Ratnasamy], Bamboo [Rhea]). An operator can provide not only the delay metric but other metrics that the peer cannot figure out on its own. These metrics may include the characteristics of the access links to other peers, bandwidth available to peers (based on operators' engineering of the network), network policies, preferences such as state and cost associated with intradomain peering links, and so on. Exactly what kinds of metrics an operator can provide to stabilize the network throughput will also need to be investigated.

多くのシステムは、既にピアとの接続を確立する際の遅延を考慮するためにRTTを使用して（例えば、連想ネットワーク（CAN）[Ratnasamy]、竹[レア]）。オペレータは、ピアが独自に把握することはできませんだけでなく、遅延メトリックが、他の指標を提供することができます。これらのメトリックは、ように他のピア、（ネットワークのオペレータの工学に基づく）のピアに利用可能な帯域幅、ネットワークポリシー、そのようなドメイン内のピアリングリンクに関連付けられた状態及びコストなどの好み、及びアクセスリンクの特性を含むことができます。正確にオペレータがネットワークのスループットを安定させるために提供することができますメトリックの何種類も検討する必要があります。

4.5. Hybrid Solutions

4.5. ハイブリッド・ソリューション

It is conceivable that P2P users may not be comfortable with operator intervention to provide topology information. To eliminate this intervention, alternative schemes to estimate topological distance can be used. For instance, Ono uses client redirections generated by Akamai CDN servers as an approximation for estimating distance to peers; Vivaldi, GNP, and PIC use synthetic coordinate systems. A neutral third party can make available a hybrid layer-cooperation service -- without the active participation of the ISP -- that uses alternative techniques discussed in Section 2.1 to create a topological map. This map can be subsequently used by a subset of users who may not trust the ISP.

P2Pユーザーがトポロジ情報を提供するために、オペレータの介入と快適ではないかもしれないと考えられます。この介入を排除するために、位相的距離を推定するための代替手法を使用することができます。例えば、小野はピアまでの距離を推定するための近似として、アカマイのCDNサーバによって生成されたクライアントのリダイレクトを使用しています。ヴィヴァルディ、GNP、およびPIC用の合成は、座標系。中立の第三者が利用できるハイブリッド層連携サービスを行うことができます - トポロジーマップを作成するために、2.1節で説明した代替技術を使用する - ISPの積極的な参加なし。このマップは、その後ISPを信用しないことがあり、ユーザーのサブセットで使用することができます。

4.6. Negative Impact of Over-Localization

4.6. 過ローカライズのマイナスの影響

The literature presented in Section 2 shows that a certain level of locality-awareness in the peer selection process of P2P algorithms is usually beneficial to application performance. However, an excessive localization of the traffic might cause partitioning in the overlay interconnecting these peers, which will negatively affect the performance experienced by the peers themselves.

第2に示す文献はP2Pアルゴリズムのピア選択プロセスにおける局所性認識の特定のレベルは、アプリケーションのパフォーマンスに通常有益であることを示しています。しかし、トラフィックの過度の局在はマイナスピア自身が経験したパフォーマンスに影響しますこれらのピアを、相互接続するオーバーレイでパーティショニングが発生する可能性があります。

Finding the right balance between localization and randomness in peer selection is an open issue. At the time of writing, it seems that different applications have different levels of tolerance and should be addressed separately. Le Blond et al. [LeBlond] have studied the specific case of BitTorrent, proposing a simple mechanism to prevent partitioning in the overlay, yet reach a high level of cross-domain traffic reduction without adversely impacting peers.

ピア選択にローカライズし、ランダム性の間で適切なバランスを見つけることは未解決の問題です。執筆の時点では、異なるアプリケーションが許容範囲の異なるレベルを持っており、個別に対処しなければならないようです。ルブロンドら。【ルブロン]オーバーレイに分割を防ぐ、まだ悪影響ピアに影響を与えることなく、クロスドメイントラフィック低減の高いレベルに到達するための簡単な機構を提案し、ビットトレントの特定の場合を検討しました。

5. Security Considerations

5.セキュリティについての考慮事項

This document is a survey of existing literature on topology estimation. As such, it does not introduce any new security considerations to be taken into account beyond what is already discussed in each paper surveyed.

この文書では、トポロジー推定に関する既存文献の調査です。このように、それはすでに調査し、各論文で議論されている以上に考慮されるように任意の新しいセキュリティの考慮事項を導入しません。

Insofar as topology estimation is used to provide a solution to the ALTO problem, the issues in Sections 4.2 and 4.3 deserve special attention. There are efforts underway in the IETF ALTO working group to design a protocol that protects the privacy of the peer-to-peer users as well as the service providers. [Chen] provides an overview of ALTO security issues, Section 11 of [Alimi] is an exhaustive overview of ALTO security, and Section 6 of RFC 5693 [RFC5693] also lists the privacy and confidentiality aspects of an ALTO solution.

トポロジー推定はALTOの問題に対する解決策を提供するために使用される限り、セクション4.2と4.3での問題は、特別な注意に値します。ピア・ツー・ピアのユーザーだけでなく、サービスプロバイダーのプライバシーを保護プロトコルを設計するIETF ALTOワーキンググループで進行中の努力があります。 [陳] ALTOのセキュリティ問題の概要を説明し、[Alimi]のセクション11は、ALTOセキュリティの徹底的な概要であり、RFC 5693のセクション6 [RFC5693]もALTOソリューションのプライバシーや機密性の側面を示しています。

The following references provide a starting point for general peer-to-peer security issues: [Wallach], [Sit], [Douceur], [Castro], and [Friedman].

[フリードマン] [ウォラック]、[シット]、[ドゥスール]、[カストロ]、および以下の参考文献は、一般的なピア・ツー・ピアのセキュリティ問題のための出発点を提供します。

6. Acknowledgments

6.謝辞

This document is a derivative work of a position paper submitted at the IETF RAI area/MIT workshop held on May 28th, 2008 on the topic of Peer-to-Peer Infrastructure (P2Pi) [RFC5594]. The article on a similar topic, also written by the authors of this document and published in IEEE Communications [Gurbani], was also partially derived from the same position paper. The authors thank profusely Arnaud Legout, Richard Yang, Richard Woundy, Stefano Previdi, and the many people that have participated in discussions and provided insightful feedback at any stage of this work.

この文書では、ピア・ツー・ピア・インフラストラクチャー（P2Pi）[RFC5594]の話題に5月28日、2008年に開催されたIETF RAIエリア/ MITのワークショップに提出ポジションペーパーの派生作品です。同様のトピックに関する記事、この文書の著者によって書かれており、IEEEコミュニケーションズ[Gurbani]に掲載されたが、また、部分的に同一の位置の紙に由来しました。著者は、やたらとアルノーLegout、リチャード・ヤン、リチャードWoundy、ステファノPrevidi、との議論に参加し、この作品のいずれかの段階で洞察に満ちたフィードバックを提供している多くの人々に感謝します。

7. Informative References

7.参考文献

[Aggarwal] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P users cooperate for improved performance?", in ACM SIGCOMM Computer Communications Review, vol. 37, no. 3.

[アガルワル]アガルワル、V.、フェルドマン、A.、およびC. Scheidelerは、 "ISPやP2Pユーザーはパフォーマンスの向上のために協力することはできますか？"、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻中。 37、ありません。 3。

[Alimi] Alimi, R., Ed., Penno, R., Ed., and Y. Yang, Ed., "ALTO Protocol", Work in Progress, July 2010.

[Alimi] Alimi、R.、エド。、Penno、R.、エド。、およびY.ヤン、エド。、 "ALTO議定書"、進歩、2010年7月での作業。

[Boneh] Boneh, D. and M. Franklin, "Identity-Based Encryption from the Weil Pairing", in Proceedings of the 21st Annual International Cryptology Conference on Advances in Cryptology, August 2001.

第21回国際暗号学会議の議事録で[Boneh] Boneh、D.とM.フランクリン、「ワイルペアリングからIDベース暗号化」、暗号学、2001年8月の進歩に。

[Castro] Castro, M., Druschelw, P., Ganesh, A., Rowstron, A., and D. Wallach, "Security for Structured Peer-to-peer Overlay Networks", in Proceedings of Symposium on Operating Systems Design and Implementation (OSDI'02), December 2002.

[カストロ]カストロ、M.、Druschelw、P.、ガネーシャ、A.、Rowstron、A.、およびD.ウォラック、「構造化ピアツーピア・オーバーレイ・ネットワークのセキュリティ」、オペレーティングシステムの設計上のシンポジウムでとインプリメンテーション（OSDI'02）、2002年12月。

[Chen] Chen, S., Gao, F., Beijing, X., and M. Xiong, "Overview for ALTO Security Issues", Work in Progress, February 2010.

[陳]チェン、S.、ガオ、F.、北京、X.、およびM.熊、 "ALTOセキュリティの問題についての概要"、進歩、2010年2月での作業。

[Coates] Coates, M., Hero, A., Nowak, R., and B. Yu, "Internet Tomography", in IEEE Signal Processing Magazine, vol. 19, no. 3.

IEEE信号処理マガジン、VOLの[コーツ]コーツ、M.、ヒーロー、A.、貰える、R.、およびB.優、 "インターネットトモグラフィー"、。 19、ありません。 3。

[Costa] Costa, M., Castro, M., Rowstron, A., and P. Key, "PIC: Practical Internet coordinates for distance estimation", in Proceedings of International Conference on Distributed Systems 2003.

[コスタ]コスタ、M.、カストロ、M.、Rowstron、A.、およびP.キー、「PIC：実用的なインターネットは、距離推定のための座標」分散システム2003年の国際会議の議事録には、。

[Dabek] Dabek, F., Cox, R., Kaashoek, F., and R. Morris, "Vivaldi: A Decentralized Network Coordinate System", in ACM SIGCOMM: Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, vol. 34, no. 4.

ACM SIGCOMMで、：[Dabek] Dabek、F.、コックス、R.、Kaashoek、F.、およびR.モリス、 "分散ネットワーク座標系ヴィヴァルディ"：アプリケーションで2004年の会議の議事録、技術、アーキテクチャ、およびコンピュータ通信のためのプロトコル、巻。 34、ありません。 4。

[Douceur] Douceur, J., "The Sybil Attack", in Proceedings of the First International Workshop on Peer-to-Peer Systems, March 2002.

[ドゥスール]ドゥスール、J.、ピアツーピアシステムに関する第一回国際ワークショップの議事録で「シビル・アタック」、2002年3月。

[Dovrolis] Dovrolis, C., Ramanathan, P., and D. Moore, "What do packet dispersion techniques measure?", in Proceedings of IEEE INFOCOM 2001.

[Dovrolis] Dovrolis、C.、ラマナサン、P.、およびD.ムーア、 "パケット分散技術は何を測るのか？"、IEEE INFOCOM 2001の議事インチ

[Francis] Francis, P., Jamin, S., Jin, C., Jin, Y., Raz, D., Shavitt, Y., and L. Zhang, "IDMaps: A global Internet host distance estimation service", in Proceedings of IEEE INFOCOM 2001.

【フランシス]フランシス、P.、ヤミン、S.、ジン、C.、ジン、Y.、ラズ、D.、Shavitt、Y.、およびL.チャン、 "IDMaps：グローバルインターネットホスト距離推定サービス"、 IEEEインフォコム2001の議事インチ

[Friedman] Friedman, A. and A. Camp, "Peer-to-Peer Security", in The Handbook of Information Security, J. Wiley & Sons, 2005.

情報セキュリティ、J。ワイリー＆サンズ、2005年ハンドブック[フリードマン]フリードマン、A.及びA.キャンプ、「ピア・ツー・ピアセキュリティ」、。

[Glasner] Glasner, J., "P2P fuels global bandwidth binge", available from http://www.wired.com/.

【Glasner] Glasner、J.、http://www.wired.com/から入手可能な "P2P燃料グローバル帯域過食"、。

[Gummadi] Gummadi, K., Gummadi, R., Gribble, S., Ratnasamy, S., Shenker, S., and I. Stoica, "The impact of DHT routing geometry on resilience and proximity", in ACM SIGCOMM: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications.

【Gummadi] Gummadi、K.、Gummadi、R.、Gribble、S.、Ratnasamy、S.、Shenker、S.、およびI.ストイカ、ACM SIGCOMMの中に、 "回復力と近接にDHTルーティングジオメトリの影響"：アプリケーション、技術、アーキテクチャ、およびコンピュータ通信のためのプロトコルの2003年の会議の議事録。

[Gurbani] Gurbani, V., Hilt, V., Rimac, I., Tomsu, M., and E. Marocco, "A Survey of Research on the Application-Layer Traffic Optimization Problem and the Need for Layer Cooperation", in IEEE Communications, vol. 47, no. 8.

[Gurbani] Gurbani、V.、柄、V.、Rimac、I.、Tomsu、M.、およびE. Marocco、 "アプリケーションレイヤトラフィック最適化問題およびレイヤ協力の必要性についての研究の調査"、中IEEEコミュニケーションズ、体積47、ありません。 8。

[Karagiannis] Karagiannis, T., Broido, A., Brownlee, N., Claffy, K., and M. Faloutsos, "Is P2P dying or just hiding?", in Proceedings of IEEE GLOBECOM 2004 Conference.

[Karagiannis] Karagiannis、T.、Broido、A.、ブラウンリー、N.、Claffy、K.、およびM. Faloutsos、 "P2Pは死ぬか、単に隠れていますか？"、IEEEのGLOBECOM 2004会議の議事インチ

[LeBlond] Le Blond, S., Legout, A., and W. Dabbous, "Pushing BitTorrent Locality to the Limit", available at http://hal.inria.fr/.

【ルブロン】ル金髪、S.、Legout、A.、およびW. Dabbous、http://hal.inria.fr/で入手可能な、 "限界までのBitTorrent地域を押します"。

[Ledlie] Ledlie, J., Gardner, P., and M. Seltzer, "Network Coordinates in the Wild", in USENIX: Proceedings of NSDI 2007.

【Ledlie] Ledlie、J.、ガードナー、P.、およびM.セルツァーは、USENIXで、 "ネットワーク野生座標"：NSDI 2007議事。

[LightReading] LightReading, "Controlling P2P traffic", available from http://www.lightreading.com/.

[LightReading] LightReading、 "P2Pトラフィックの制御"、http://www.lightreading.com/から入手できます。

[LinuxReviews] linuxReviews.org, "Peer to peer network traffic may account for up to 85% of Internet's bandwidth usage", available from http://linuxreviews.org/.

[LinuxReviews] linuxReviews.org、http://linuxreviews.org/から入手できる、「インターネットの帯域幅の使用量の最大85％を占めてネットワークトラフィックをピアツーピア」。

[Madhyastha] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T., Krishnamurthy, A., and A. Venkataramani, "iPlane: an information plane for distributed services", in USENIX: Proceedings of the 7th symposium on Operating systems design and implementation.

【Madhyastha] Madhyastha、H.、Isdal、T.、Piatek、M.、ディクソン、C.、アンダーソン、T.、Krishnamurthy、A.、およびA. Venkataramani、 "iPlane：分散サービスのための情報面" でUSENIX：オペレーティング・システムの設計と実装第7回シンポジウムの議事録。

[Ng] Ng, T. and H. Zhang, "Predicting internet network distance with coordinates-based approaches", in Proceedings of INFOCOM 2002.

【ン】ン、T.及びH.チャンは、INFOCOM 2002会報で、「座標ベースのアプローチを用いてインターネット網距離を予測します」。

[Ono] "Northwestern University Ono Project", <http:// www.aqualab.cs.northwestern.edu/projects/Ono.html>.

[小野] "ノースウェスタン大学小野プロジェクト"、<のhttp：// www.aqualab.cs.northwestern.edu/projects/Ono.html>。

[P4P] "DCIA P4P Working group", <http://www.dcia.info/activities/#P4P>.

[P4P] "DCIA P4Pワーキンググループ"、<http://www.dcia.info/activities/#P4P>。

[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP throughput: A simple model and its empirical validation", in Technical Report UM-CS-1998-008, University of Massachusetts 1998.

[Padhye] Padhye、J.、Firoiu、V.、Towsley、D.、およびJ.黒瀬、 "モデルTCPスループット：シンプルなモデルとその実証的検証" テクニカルレポートUM-CS-1998から008の大学では、マサチューセッツ州1998。

[Parker] Parker, A., "The true picture of peer-to-peer filesharing", available from http://www.cachelogic.com/.

【パーカー】パーカー、A.、http://www.cachelogic.com/から入手可能な、「ピア・ツー・ピアファイル共有の真絵」。

[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.

[RFC4732]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.

[RFC4949] Shirey、R.、 "インターネットセキュリティ用語集、バージョン2"、FYI 36、RFC 4949、2007年8月。

[RFC4981] Risson, J. and T. Moors, "Survey of Research towards Robust Peer-to-Peer Networks: Search Methods", RFC 4981, September 2007.

[RFC4981] Risson、J.およびT.ムーアズ、「堅牢なピアツーピアネットワークに向けた研究の調査：検索方法」、RFC 4981、2007年9月。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。

[RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", RFC 5594, July 2009.

[RFC5594]ピーターソン、J.、およびA.クーパー、 "ピア・ツー・ピア（P2P）インフラストラクチャ上のIETFワークショップからの報告書、2008年5月28日"、RFC 5594、2009年7月。

[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and Y. Yang, "Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial", RFC 5632, September 2009.

[RFC5632]グリフィス、C.、Livingood、J.、Popkin、L.、Woundy、R.、およびY.ヤン、 "P2P（P4P）技術試作のための積極的なネットワークプロバイダ参加にComcastのISP経験"、RFC 5632、 2009年9月。

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

[RFC5693]セードルフ、J.およびE.バーガー、 "アプリケーション層のトラフィックの最適化（ALTO）問題文"、RFC 5693、2009年10月。

[Ratnasamy] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S. Shenker, "A Scalable Content-Addressable Network", in ACM SIGCOMM: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, January 2001.

[Ratnasamy] Ratnasamy、S.、フランシス、P.、ハンドリー、M.、カープ、R.、およびS. Shenker、 "スケーラブルな連想ネットワーク" ACM SIGCOMMで、：アプリケーション上の2001の会議の議事録、技術コンピュータ通信、2001年1月のために、アーキテクチャ、およびプロトコル。

[Ren] Ren, S., Guo, L., and X. Zhang, "ASAP: An AS-aware peer-relay protocol for high quality VoIP", in Proceedings of IEEE ICDCS 2006.

[レン]漣、S.、郭、L.、およびX.張、 "できるだけ早く：高品質のVoIP用AS-認識ピア・リレープロトコル"、IEEE ICDCS 2006の議事インチ

[Rhea] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: a public DHT service and its uses", in ACM SIGCOMM: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, August 2005.

【レア】レア、S.、ゴッド、B.、カープ、B.、Kubiatowicz、J.、Ratnasamy、S.、Shenker、S.、ストイカ、I.、およびH.優、「OpenDHT：公共DHTサービスそしてACM SIGCOMMにおけるその使用」、：アプリケーション、技術、アーキテクチャ、およびコンピュータ通信、2005年8月のためのプロトコルの2005の会議の議事録を。

[Saucez] Saucez, D., Donnet, B., and O. Bonaventure, "Implementation and Preliminary Evaluation of an ISP-Driven Informed Path Selection", in Proceedings of ACM CoNEXT 2007.

ACM CoNEXT 2007の議事録では、[Saucez] Saucez、D.、Donnet、B.、およびO.ボナベンチャー、 "ISPドリブンな情報に経路選択の実装と予備的評価"。

[Seetharaman] Seetharaman, S., Hilt, V., Hofmann, M., and M. Ammar, "Preemptive Strategies to Improve Routing Performance of Native and Overlay Layers", in Proceedings of IEEE INFOCOM 2007.

[Seetharaman] Seetharaman、S.、柄、V.、ホフマン、M.、およびM.アマル、IEEE INFOCOM 2007の議事録では、 "プリエンプティブ戦略は、ネイティブとオーバーレイレイヤーのルーティングパフォーマンスを向上させます"。

[Sit] Sit, E. and R. Morris, "Security Considerations for Peer-to-Peer Distributed Hash Tables, Revised Papers from the First", in Proceedings of the First International Workshop on Peer-to-Peer Systems, March 2002.

[シット]シット、E.およびR.モリス、「ピアツーピア分散ハッシュテーブルのためのセキュリティの考慮事項、初の改訂論文」ピア・ツー・ピア・システムズ、2002年3月に第一回国際ワークショップの議事録では、。

[Su] Su, A., Choffnes, D., Kuzmanovic, A., and F. Bustamante, "Drafting behind Akamai (travelocity-based detouring)", in ACM SIGCOMM: Proceedings of the 2006 conference on Applications, technologies, architectures, and protocols for computer communications.

[蘇]蘇、A.、Choffnes、D.、Kuzmanovic、A.、およびF.ブスタマンテ、ACMのSIGCOMMで、 "アカマイ（旅行ベースの迂回）の後ろに製図"：アプリケーション、技術、アーキテクチャ上の2006年の会議の議事録コンピュータ通信のための、およびプロトコル。

[Vuze] "Vuze bittorrent client", <http://www.vuze.com/>.

[Vuzeの] "のVuze BitTorrentクライアント"、<http://www.vuze.com/>。

[Wallach] Wallach, D., "A survey of peer-to-peer security issues", in Proceedings of International Symposium on Software Security, 2002.

[ウォラック]ウォラック、D.、ソフトウェアセキュリティ、2002年の国際シンポジウムでは、「ピア・ツー・ピアのセキュリティ問題の調査」。

[Wang] Wang, G., Zhang, B., and T. Ng, "Towards Network Triangle Inequality Violation Aware Distributed Systems", in ACM SIGCOMM: Proceedings of the 7th conference on Internet measurement.

インターネット測定で7会議の議事録：ACM SIGCOMMにおいて、「ネットワーク三角不等式違反認識分散システムに向けて」[王]王、G.、張、B.、およびT.ン、。

[Wong] Wong, B., Slivkins, A., and E. Sirer, "Meridian: A lightweight network location service without virtual coordinates", in ACM SIGCOMM: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications.

[ウォン】ウォン、B.、Slivkins、A.、およびE. Sirer、「メリディアン：仮想座標なしの軽量ネットワーク・ロケーション・サービス」のためのアプリケーション、技術、アーキテクチャ、およびプロトコル2005会議の議事録のACM SIGCOMMにおいて、コンピュータ通信。

[Xie] Xie, H., Krishnamurthy, A., Silberschatz, A., and Y. Yang, "P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers", in ACM SIGCOMM Computer Communication Review, vol. 38, no. 4.

[謝]謝、H.、Krishnamurthy、A.、Silberschatz、A.、およびY.ヤン、 "P4P：P2Pとネットワークプロバイダ間の協調制御のための明示的なコミュニケーション"、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻インチ38、ありません。 4。

Authors' Addresses

著者のアドレス

Ivica Rimac Bell Labs, Alcatel-Lucent EMail: rimac@bell-labs.com

イビツァRimacベル研究所、アルカテル・ルーセントEメール：rimac@bell-labs.com

Volker Hilt Bell Labs, Alcatel-Lucent EMail: volkerh@bell-labs.com

フォルカー柄ベル研究所、アルカテル・ルーセントEメール：volkerh@bell-labs.com

Marco Tomsu Bell Labs, Alcatel-Lucent EMail: marco.tomsu@alcatel-lucent.com

マルコTomsuベル研究所、アルカテル・ルーセントEメール：marco.tomsu@alcatel-lucent.com

Vijay K. Gurbani Bell Labs, Alcatel-Lucent EMail: vkg@bell-labs.com

ビジェイK. Gurbaniベル研究所、アルカテル・ルーセントEメール：vkg@bell-labs.com

Enrico Marocco Telecom Italia EMail: enrico.marocco@telecomitalia.it

エンリコ・モロッコテレコムイタリアメール：enrico.marocco@telecomitalia.it