[要約] RFC 5693は、ALTO(Application-Layer Traffic Optimization)の問題を明確にするための文書です。ALTOの目的は、アプリケーション層のトラフィックを最適化することです。

Network Working Group                                         J. Seedorf
Request for Comments: 5693                                           NEC
Category: Informational                                        E. Burger
                                                            Neustar Inc.
                                                            October 2009
        

Application-Layer Traffic Optimization (ALTO) Problem Statement

アプリケーション層トラフィック最適化(ALTO)問題ステートメント

Abstract

概要

Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.

ファイル共有、リアルタイム通信、ライブおよびオンデマンドメディアストリーミングなどの分散アプリケーションは、インターネットで一般的なネットワークリソースを使用しています。このようなアプリケーションは、多くの場合、基礎となるネットワークトポロジの知識がほとんどなく、インターネット全体に分散されたノード間に確立された接続を介して大量のデータを転送します。一部のアプリケーションは、データを交換するためのより大きなセットからピアのランダムなサブセットを選択するため、いくつかのアプリケーションが設計されています。このような選択を導くトポロジ情報がない場合、または測定および統計から得られた準最適またはローカル情報に基づいて行動することは、これらのアプリケーションが望ましい選択よりも少ないことを行うことがよくあります。

This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection.

このドキュメントでは、アプリケーションがランダムよりも優れたピア選択を実行できるようにする情報共有サービスに関連する問題について説明します。

Status of This Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

Copyright(c)2009 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 BSD License.

このドキュメントは、BCP 78およびIETFドキュメント(http://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  State-of-the-Art . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Problem  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  File sharing . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Cache/Mirror Selection . . . . . . . . . . . . . . . . . .  8
     4.3.  Live Media Streaming . . . . . . . . . . . . . . . . . . .  8
     4.4.  Real-Time Communications . . . . . . . . . . . . . . . . .  9
     4.5.  Distributed Hash Tables  . . . . . . . . . . . . . . . . .  9
   5.  Aspects of the Problem . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Information Provided by an ALTO Service  . . . . . . . . .  9
     5.2.  ALTO Service Providers . . . . . . . . . . . . . . . . . . 10
     5.3.  ALTO Service Implementation  . . . . . . . . . . . . . . . 10
     5.4.  User Privacy . . . . . . . . . . . . . . . . . . . . . . . 10
     5.5.  Topology Hiding  . . . . . . . . . . . . . . . . . . . . . 11
     5.6.  Coexistence with Caching . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 13
        
1. Introduction
1. はじめに
1.1. Overview
1.1. 概要

Distributed applications, both peer-to-peer (P2P) and client/server used for file sharing, real-time communication, and live and on-demand media streaming, use a significant amount of network capacity and CPU cycles in the routers [WWW.wired.fuel]. In contrast to centralized applications, distributed applications access resources such as files or media relays distributed across the Internet and exchange large amounts of data in connections that they establish directly with nodes sharing such resources.

ファイル共有、リアルタイム通信、ライブおよびオンデマンドメディアストリーミングに使用されるピアツーピア(P2P)とクライアント/サーバーの両方の分散アプリケーションは、ルーターでかなりの量のネットワーク容量とCPUサイクルを使用します[www.wired.fuel]。集中型アプリケーションとは対照的に、分散アプリケーションは、インターネット全体に配布されたファイルやメディアリレーなどのリソースにアクセスし、そのようなリソースを共有するノードと直接確立する大量のデータを交換します。

One advantage of highly distributed systems results from the fact that the resources such systems offer are often available through multiple replicas. However, applications generally do not have reliable information of the underlying network and thus have to select among the available peers that provide such replicas randomly or based on information they deduce from partial observations that, in some situations, lead to suboptimal choices. For example, one peer-selection algorithm is based only on the measurements during initial connection establishment between two peers. Since actual data transmission does not begin, the algorithm measures only the round-trip time and cannot reliably deduce actual throughput between the peers. Thus, such a peer-selection algorithm that simply uses round-trip time may result in a suboptimal choice of peers.

高度に分散されたシステムの1つの利点は、そのようなシステムが提供するリソースが複数のレプリカを通じて利用できることが多いという事実に起因します。ただし、アプリケーションには一般に、基礎となるネットワークの信頼できる情報がないため、そのようなレプリカをランダムに提供する利用可能なピアから選択する必要があります。たとえば、1つのピア選択アルゴリズムは、2つのピア間の初期接続確立中の測定にのみ基づいています。実際のデータ送信は開始されないため、アルゴリズムは往復時間のみを測定し、ピア間で実際のスループットを確実に推測することはできません。したがって、往復時間を単純に使用するこのようなピア選択アルゴリズムは、ピアの最適ではない選択になる可能性があります。

Many of today's P2P systems use an overlay network consisting of direct peer connections. Such connections often do not account for the underlying network topology. In addition to having suboptimal performance, such networks can lead to congestion and cause serious inefficiencies. As shown in [ACM.fear], traffic generated by popular P2P applications often cross network boundaries multiple times, overloading links that are frequently subject to congestion [ACM.bottleneck]. Moreover, such transits, besides resulting in a poor experience for the user, can be quite costly to the network operator.

今日のP2Pシステムの多くは、直接ピア接続で構成されるオーバーレイネットワークを使用しています。このような接続は、多くの場合、基礎となるネットワークトポロジを考慮していません。最適ではないパフォーマンスを発揮することに加えて、このようなネットワークは混雑につながり、深刻な非効率性を引き起こす可能性があります。[Acm.Fear]に示されているように、一般的なP2Pアプリケーションによって生成されるトラフィックは、多くの場合、ネットワークの境界を複数回横断し、頻繁に混雑の対象となるリンクを過負荷にします[Acm.BottleNeck]。さらに、このようなトランジットは、ユーザーの経験が悪いことに加えて、ネットワークオペレーターにとって非常に費用がかかる可能性があります。

Recent studies ([ACM.ispp2p], [WWW.p4p.overview], [ACM.ono]) show a possible solution to this problem. Internet Service Providers (ISPs), network operators, or third parties can collect more reliable network information. This information includes relevant information such as topology or link capacity. Normally, such information changes on a much longer time scale than information used for congestion control on the transport layer. Providing this information to P2P applications can enable them to apply better-than-random peer selection with respect to the underlying network topology. As a result, it may be possible to increase application performance, reduce congestion, and decrease the overall amount of traffic across different networks. Presumably, both applications and the network operator can benefit from such information. Thus, network operators have an incentive to provide, either directly themselves or indirectly through a third party, such information; applications have an incentive to use such information. This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection.

最近の研究([acm.ispp2p]、[www.p4p.overview]、[acm.ono])は、この問題に対する可能な解決策を示しています。インターネットサービスプロバイダー(ISP)、ネットワークオペレーター、または第三者は、より信頼性の高いネットワーク情報を収集できます。この情報には、トポロジやリンク容量などの関連情報が含まれています。通常、そのような情報は、輸送層の輻輳制御に使用される情報よりもはるかに長い時間尺度で変化します。この情報をP2Pアプリケーションに提供すると、基礎となるネットワークトポロジに関して、ランダムよりも優れたピア選択を適用できるようになります。その結果、アプリケーションのパフォーマンスを向上させ、混雑を減らし、さまざまなネットワーク全体のトラフィックの全体の量を減らすことができるかもしれません。おそらく、アプリケーションとネットワークオペレーターの両方がそのような情報の恩恵を受けることができます。したがって、ネットワークオペレーターは、そのような情報を第三者に直接または間接的に提供するインセンティブを持っています。アプリケーションには、そのような情報を使用するインセンティブがあります。このドキュメントでは、アプリケーションがランダムよりも優れたピア選択を実行できるようにする情報共有サービスに関連する問題について説明します。

Section 2 provides definitions. Section 3 introduces the problem. Section 4 describes some use cases where both P2P applications and network operators benefit from a solution to such a problem. Section 5 describes the main issues to consider when designing such a solution. Note a companion document to this document, "Application-Layer Traffic Optimization (ALTO) Requirements" [ALTO-REQS], goes into the details of these issues.

セクション2に定義があります。セクション3で問題を紹介します。セクション4では、P2Pアプリケーションとネットワーク演算子の両方がそのような問題の解決策から恩恵を受けるいくつかのユースケースについて説明します。セクション5では、そのようなソリューションを設計する際に考慮すべき主な問題について説明します。このドキュメントのコンパニオンドキュメント「アプリケーションレイヤートラフィック最適化(ALTO)要件」[ALTO-REQS]は、これらの問題の詳細に説明します。

1.2. State-of-the-Art
1.2. 最先端

The papers [ACM.ispp2p], [PATH-SEL], and [WWW.p4p.overview] present examples of contemporary solution proposals that address the problem described in this document. Moreover, these proposals have encouraging simulation and field test results. These and similar, independent, solutions all consist of two essential parts:

論文[acm.ispp2p]、[path-sel]、および[www.p4p.overview]は、この文書に記載されている問題に対処する現代の解決策提案の例を示しています。さらに、これらの提案には、シミュレーションとフィールドテストの結果が促進されています。これらおよび類似の独立したソリューションはすべて、2つの重要な部分で構成されています。

o a discovery mechanism that a P2P application uses to find a reliable information source, and

o P2Pアプリケーションが信頼できる情報源を見つけるために使用する発見メカニズム、および

o a protocol that P2P applications use to query such sources in order to retrieve the information needed to perform better-than-random selection of the endpoints providing a desired resource.

o P2Pアプリケーションがそのようなソースを照会するために使用するプロトコルは、目的のリソースを提供するエンドポイントのより良い選択を実行するために必要な情報を取得します。

It is not clear how such solutions will perform if deployed globally on the Internet. However, wide adoption is unlikely without agreement on a common solution, based upon an open standard.

インターネット上でグローバルに展開した場合、そのようなソリューションがどのように機能するかは明確ではありません。ただし、開かれた基準に基づいて、一般的なソリューションに合意することなく、広範囲に採用される可能性は低いです。

2. Definitions
2. 定義

The following terms have special meaning in the definition of the Application-Layer Traffic Optimization (ALTO) problem.

次の用語は、アプリケーション層トラフィック最適化(ALTO)問題の定義に特別な意味を持っています。

Application: A distributed communication system (e.g., file sharing) that uses the ALTO service to improve its performance or quality of experience while improving resource consumption in the underlying network infrastructure. Applications may use the P2P model to organize themselves, use the client-server model, or use a hybrid of both (i.e., a mixture between the P2P model and the client-server model).

アプリケーション:ALTOサービスを使用してパフォーマンスまたはエクスペリエンスの質を向上させながら、基礎となるネットワークインフラストラクチャのリソース消費を改善する分散通信システム(ファイル共有など)。アプリケーションは、P2Pモデルを使用して自分自身を整理したり、クライアントサーバーモデルを使用したり、両方のハイブリッド(つまり、P2Pモデルとクライアントサーバーモデルの混合物)を使用したりできます。

Peer: A specific participant in an application. Colloquially, a peer refers to a participant in a P2P network or system, and this definition does not violate that assumption. If the basis of the application is the client-server or hybrid model, then the usage of the terms "client" and "server" disambiguates the peer's role.

ピア:アプリケーションの特定の参加者。口語的には、ピアはP2Pネットワークまたはシステムの参加者を指し、この定義はその仮定に違反していません。アプリケーションの基礎がクライアントサーバーまたはハイブリッドモデルである場合、「クライアント」と「サーバー」という用語の使用は、ピアの役割を曖昧にします。

P2P: Peer-to-Peer.

P2P:ピアツーピア。

Resource: Content (such as a file or a chunk of a file) or a server process (for example, to relay a media stream or perform a computation) that applications can access. In the ALTO context, a resource is often available in several equivalent replicas. In addition, different peers share these resources, often simultaneously.

リソース:アプリケーションがアクセスできるコンテンツ(ファイルやファイルのチャンクなど)またはサーバープロセス(たとえば、メディアストリームをリレーしたり、計算を実行したりする)。ALTOコンテキストでは、リソースがいくつかの同等のレプリカで利用できることがよくあります。さらに、さまざまなピアがこれらのリソースを共有し、多くの場合同時に共有します。

Resource Identifier: An application-layer identifier used to identify a resource, no matter how many replicas exist.

リソース識別子:レプリカの数に関係なく、リソースを識別するために使用されるアプリケーション層識別子。

Resource Provider: For P2P applications, a resource provider is a specific peer that provides some resources. For client-server or hybrid applications, a provider is a server that hosts a resource.

リソースプロバイダー:P2Pアプリケーションの場合、リソースプロバイダーは、リソースを提供する特定のピアです。クライアントサーバーまたはハイブリッドアプリケーションの場合、プロバイダーはリソースをホストするサーバーです。

Resource Consumer: For P2P applications, a resource consumer is a specific peer that needs to access resources. For client-server or hybrid applications, a consumer is a client that needs to access resources.

リソース消費者:P2Pアプリケーションの場合、リソース消費者はリソースにアクセスするために必要な特定のピアです。クライアントサーバーまたはハイブリッドアプリケーションの場合、消費者はリソースにアクセスする必要があるクライアントです。

Transport Address: All address information that a resource consumer needs to access the desired resource at a specific resource provider. This information usually consists of the resource provider's IP address and possibly other information, such as a transport protocol identifier or port numbers.

トランスポートアドレス:すべてのアドレス情報リソース消費者が特定のリソースプロバイダーで目的のリソースにアクセスするために必要な情報。この情報は通常、リソースプロバイダーのIPアドレスと、輸送プロトコル識別子やポート番号などのその他の情報で構成されています。

Overlay Network: A virtual network consisting of direct connections on top of another network and established by a group of peers.

オーバーレイネットワーク:別のネットワークの上に直接接続され、ピアグループによって確立された仮想ネットワーク。

Resource Directory: An entity that is logically separate from the resource consumer and that assists the resource consumer to identify a set of resource providers. Some P2P applications refer to the resource directory as a P2P tracker.

リソースディレクトリ:リソース消費者と論理的に分離され、リソース消費者がリソースプロバイダーのセットを特定するのを支援するエンティティ。一部のP2Pアプリケーションは、リソースディレクトリをP2Pトラッカーと呼びます。

ALTO Service: Several resource providers may be able to provide the same resource. The ALTO service gives guidance to a resource consumer and/or resource directory about which resource provider(s) to select in order to optimize the client's performance or quality of experience, while improving resource consumption in the underlying network infrastructure.

ALTOサービス:いくつかのリソースプロバイダーが同じリソースを提供できる場合があります。ALTOサービスは、クライアントのパフォーマンスまたはエクスペリエンスの質を最適化し、基礎となるネットワークインフラストラクチャのリソース消費を改善するために選択するリソースプロバイダーについて、リソース消費者および/またはリソースディレクトリにガイダンスを提供します。

ALTO Server: A logical entity that provides interfaces to the queries to the ALTO service.

ALTO SERVER:ALTOサービスのクエリにインターフェイスを提供する論理エンティティ。

ALTO Client: The logical entity that sends ALTO queries. Depending on the architecture of the application, one may embed it in the resource consumer and/or in the resource directory.

Alto Client:Alto Queriesを送信する論理エンティティ。アプリケーションのアーキテクチャに応じて、リソース消費者やリソースディレクトリに埋め込むことができます。

ALTO Query: A message sent from an ALTO client to an ALTO server; it requests guidance from the ALTO service.

ALTOクエリ:ALTOクライアントからALTOサーバーに送信されたメッセージ。ALTOサービスにガイダンスを要求します。

ALTO Response: A message that contains guiding information from the ALTO service as a reply to an ALTO query.

Alto Response:ALTO Serviceからのガイド情報がALTOクエリへの返信として含まれるメッセージ。

ALTO Transaction: A transaction that consists of an ALTO query and the corresponding ALTO response.

ALTOトランザクション:ALTOクエリと対応するALTO応答で構成されるトランザクション。

Local Traffic: Traffic that stays within the network infrastructure of one Internet Service Provider (ISP). This type of traffic usually results in the least cost for the ISP.

ローカルトラフィック:1つのインターネットサービスプロバイダー(ISP)のネットワークインフラストラクチャ内にとどまるトラフィック。このタイプのトラフィックは通常、ISPのコストが最小になります。

Peering Traffic: Internet traffic exchanged by two Internet Service Providers whose networks connect directly. Apart from infrastructure and operational costs, peering traffic is often free to the ISPs, within the contract of a peering agreement.

ピアリングトラフィック:ネットワークが直接接続されている2つのインターネットサービスプロバイダーによって交換されるインターネットトラフィック。インフラストラクチャと運用コストは別として、ピアリング契約の契約の範囲内で、ピアリングトラフィックはISPに自由に行われることがよくあります。

Transit Traffic: Internet traffic exchanged on the basis of economic agreements amongst Internet Service Providers (ISPs). An ISP generally pays a transit provider for the delivery of traffic flowing between its network and remote networks to which the ISP does not have a direct connection.

トランジットトラフィック:インターネットサービスプロバイダー(ISP)間の経済協定に基づいて交換されたインターネットトラフィック。ISPは通常、ISPが直接接続していないネットワークとリモートネットワーク間で流れるトラフィックの配信のためにトランジットプロバイダーを支払います。

Application Protocol: A protocol used by the application for establishing an overlay network between the peers and exchanging data on it, as well as for data exchange between peers and resource directories, if applicable. These protocols play an important role in the overall ALTO architecture. However, defining them is out of the scope of the ALTO WG.

アプリケーションプロトコル:ピア間のオーバーレイネットワークを確立し、それに関するデータを交換するためにアプリケーションで使用されるプロトコル、および該当する場合、ピアとリソースディレクトリ間のデータ交換。これらのプロトコルは、全体的なALTOアーキテクチャにおいて重要な役割を果たします。ただし、それらを定義することは、ALTO WGの範囲外です。

ALTO Client Protocol: The protocol used for sending ALTO queries and ALTO replies between an ALTO client and ALTO server.

ALTOクライアントプロトコル:ALTOクライアントとALTOクライアントとALTOサーバーの間でALTOクエリとALTOの応答を送信するために使用されるプロトコル。

Provisioning Protocol: A protocol used for populating the ALTO server with information.

プロビジョニングプロトコル:ALTOサーバーに情報を入力するために使用されるプロトコル。

                                             +------+
                                          +-----+   | Peers
          +-----+       +------+    +=====|     |-*-+
          |     |.......|      |====+     +-*-*-+ *
          +-----+       +------+    |       * *****
        Source of        ALTO       |       *
        Information      Server     |     +-*---+
                                    +=====|     | Resource Directory
                                          +-----+ (Tracker, proxy)
        Legend:
        === ALTO client protocol
        *** Application protocol (out of scope)
        ... Provisioning or initialization (out of scope)
        

Figure 1: Overview of Protocol Interaction between ALTO Elements

図1:ALTO要素間のプロトコル相互作用の概要

Figure 1 shows the scope of the ALTO client protocol: peers or resource directories can use such a protocol as ALTO clients to query an ALTO server. The mapping of topological information onto an ALTO service as well as the application protocol interaction between peers and resource directories are out of scope for the ALTO client protocol.

図1は、ALTOクライアントのプロトコルの範囲を示しています。ピアまたはリソースディレクトリは、ALTOクライアントのようなプロトコルを使用してALTOサーバーを照会することができます。ALTOサービスへのトポロジー情報のマッピングと、ピアとリソースディレクトリ間のアプリケーションプロトコルの相互作用は、ALTOクライアントプロトコルの範囲外です。

3. The Problem
3. 問題

Network engineers have been facing the problem of traffic optimization for a long time and have designed mechanisms like MPLS [RFC3031] and Diffserv [RFC3260] to deal with it. The problem these protocols address consists in finding (or setting) optimal routes (or optimal queues in routers) for packets traveling between specific source and destination addresses. Solutions are based on requirements such as low latency, high reliability, and priority. Such solutions are usually implemented at the link and network layers and tend to be almost transparent.

ネットワークエンジニアは長い間トラフィックの最適化の問題に直面しており、MPLS [RFC3031]やDiffServ [RFC3260]などのメカニズムを設計して対処しています。これらのプロトコルが対処する問題は、特定のソースアドレスと宛先アドレス間を移動するパケットの最適なルート(またはルーターの最適なキュー)を見つける(または設定)際に構成されています。ソリューションは、低遅延、高い信頼性、優先度などの要件に基づいています。このようなソリューションは通常、リンクレイヤーとネットワークレイヤーに実装されており、ほとんど透明性がある傾向があります。

However, distributed applications in general and, in particular, bandwidth-greedy P2P applications that are used, for example, for file sharing, cannot directly use the aforementioned techniques. By cooperating with external services that are aware of the network topology, applications could greatly improve the traffic they generate. In fact, when a P2P application needs to establish a connection, the logical target is not a stable host, but rather a resource (e.g., a file or a media relay) that can be available in multiple instances on different peers. Selection of a good host from an overlay topological proximity has a large impact on the overall traffic generated.

ただし、一般的に分散アプリケーション、特に、ファイル共有に使用される帯域幅グレディP2Pアプリケーションは、前述の手法を直接使用することはできません。ネットワークトポロジを認識している外部サービスと協力することにより、アプリケーションが生成するトラフィックを大幅に改善する可能性があります。実際、P2Pアプリケーションが接続を確立する必要がある場合、論理ターゲットは安定したホストではなく、異なるピアで複数のインスタンスで利用できるリソース(ファイルやメディアリレーなど)です。オーバーレイトポロジカルの近接から優れたホストの選択は、生成された全体的なトラフィックに大きな影響を与えます。

Note that while traffic considerations are important, several other factors also play a role on the performance experienced by users of distributed applications. These include the need to avoid overloading individual nodes, fetching rare pieces of a file before those pieces are available at a multiplicity of nodes, and so on. However, better information about topological conditions does improve the overall selection algorithm on an important aspect.

トラフィックの考慮事項は重要ですが、他のいくつかの要因も、分散アプリケーションのユーザーが経験するパフォーマンスに役割を果たしていることに注意してください。これらには、個々のノードのオーバーロードを避ける必要があります。これらのピースが多数のノードで利用できるようになる前に、ファイルの珍しいピースを取得するなどが含まれます。ただし、トポロジー条件に関するより良い情報は、重要な側面に関する全体的な選択アルゴリズムを改善します。

Better-than-random peer selection is helpful in the initial phase of the process. Consider a P2P protocol in which a querying peer receives a list of candidate destinations where a resource resides. From this list, the peer will derive a smaller set of candidates to connect to and exchange information with. In another example, a streaming video client may be provided with a list of destinations from which it can stream content. In both cases, the use of topology information in an early stage will allow applications to improve their performance and will help ISPs make a better use of their network resources. In particular, an economic goal for ISPs is to reduce the transit traffic on interdomain links.

ランダムよりも優れたピア選択は、プロセスの初期段階で役立ちます。クエリピアがリソースが存在する候補の目的地のリストを受け取るP2Pプロトコルを検討してください。このリストから、ピアは、情報に接続して交換する候補者の小さなセットを導き出します。別の例では、ストリーミングビデオクライアントには、コンテンツをストリーミングできる宛先のリストが提供される場合があります。どちらの場合も、初期段階でトポロジー情報を使用することで、アプリケーションがパフォーマンスを改善することができ、ISPがネットワークリソースをより有効に活用できるようになります。特に、ISPの経済的目標は、ドメイン間リンクの輸送トラフィックを減らすことです。

Addressing the Application-Layer Traffic Optimization (ALTO) problem means, on the one hand, deploying an ALTO service to provide applications with information regarding the underlying network and, on the other hand, enhancing applications in order to use such information to perform better-than-random selection of the endpoints with which they establish connections.

アプリケーション層のトラフィック最適化(ALTO)の問題に対処することは、一方でALTOサービスを展開して、基礎となるネットワークに関する情報をアプリケーションに提供し、一方で、そのような情報を使用してより良い実行を行うためにアプリケーションを強化することを意味します。接続を確立するエンドポイントのランダム選択。

4. Use Cases
4. ユースケース
4.1. File sharing
4.1. ファイル共有

File-sharing applications allow users to search for content shared by other users and to download respective resources from other users. For instance, search results can consist of many instances of the same file (or chunk of a file) available from multiple sources. The goal of an ALTO solution is to help peers find the best ones according to the underlying networks.

ファイル共有アプリケーションにより、ユーザーは他のユーザーが共有するコンテンツを検索し、他のユーザーからそれぞれのリソースをダウンロードできます。たとえば、検索結果は、複数のソースから利用可能な同じファイル(またはファイルのチャンク)の多くのインスタンスで構成できます。ALTOソリューションの目標は、基礎となるネットワークに従って、ピアが最高のものを見つけるのを支援することです。

On the application side, integration of ALTO functionalities may happen at different levels. For example, in the completely decentralized Gnutella network, selection of the best sources is totally up to the user. In systems like BitTorrent and eDonkey, central elements such as trackers or servers act as mediators. Therefore, in the former case, improvement would require modification in the applications, while in the latter it could just be implemented in some central elements.

アプリケーション側では、ALTO機能の統合が異なるレベルで発生する場合があります。たとえば、完全に分散化されたGnutellaネットワークでは、最適なソースの選択は完全にユーザー次第です。BittorrentやEdonkeyなどのシステムでは、トラッカーやサーバーなどの中央要素がメディエーターとして機能します。したがって、前者のケースでは、改善にはアプリケーションの変更が必要になりますが、後者では一部の中心的な要素に実装するだけです。

4.2. Cache/Mirror Selection
4.2. キャッシュ/ミラーの選択

Providers of popular content, like media and software repositories, usually resort to geographically distributed caches and mirrors for load balancing. Today, selection of the proper mirror/cache for a given user is based on inaccurate geolocation data, on proprietary network-location systems, or is often delegated to the user herself. An ALTO solution could be easily adopted to ease such a selection in an automated way.

メディアやソフトウェアリポジトリなどの人気コンテンツのプロバイダーは、通常、ロードバランスのために地理的に分散したキャッシュとミラーに頼ります。今日、特定のユーザーの適切なミラー/キャッシュの選択は、独自のネットワークロケーションシステムの不正確な地理配置データに基づいているか、ユーザー自身に委任されることがよくあります。ALTOソリューションを簡単に採用して、このような選択を自動化した方法で緩和できます。

4.3. Live Media Streaming
4.3. ライブメディアストリーミング

P2P applications for live streaming allow users to receive multimedia content produced by one source and targeted to multiple destinations, in a real-time or near-real-time way. This is particularly important for users or networks that do not support multicast. Peers often participate in the distribution of the content, acting as both receivers and senders. The goal of an ALTO solution is to help a peer to find effective communicating peers that exchange the media content.

ライブストリーミング用のP2Pアプリケーションにより、ユーザーは1つのソースによって生成され、複数の宛先をターゲットにしたマルチメディアコンテンツをリアルタイムまたはほぼリアルタイムで受信できます。これは、マルチキャストをサポートしていないユーザーまたはネットワークにとって特に重要です。ピアはしばしばコンテンツの分布に参加し、受信者と送信者の両方として機能します。ALTOソリューションの目標は、ピアがメディアコンテンツを交換する効果的なコミュニケーション仲間を見つけるのを支援することです。

4.4. Real-Time Communications
4.4. リアルタイム通信

P2P real-time communications allow users to establish direct media flows for real-time audio, video, and real-time text calls or to have text chats. In the basic case, media flows directly between the two endpoints. Unfortunately, however, a significant portion of users have limited access to the Internet due to NATs, firewalls, or proxies. Thus, other elements need to relay the media. Such media relays are distributed over the Internet with public addresses. An ALTO solution needs to help peers find the best relays.

P2Pリアルタイム通信により、ユーザーはリアルタイムオーディオ、ビデオ、リアルタイムのテキストコールのための直接メディアフローを確立したり、テキストチャットをしたりできます。基本的な場合、メディアは2つのエンドポイント間を直接流れます。ただし、残念ながら、NAT、ファイアウォール、またはプロキシにより、ユーザーのかなりの部分がインターネットへのアクセスが制限されています。したがって、他の要素はメディアを中継する必要があります。このようなメディアリレーは、パブリックアドレスでインターネット上に配布されます。ALTOソリューションは、ピアが最高のリレーを見つけるのに役立つ必要があります。

4.5. Distributed Hash Tables
4.5. 分散ハッシュテーブル

Distributed hash tables (DHTs) are a class of overlay algorithms used to implement lookup functionalities in popular P2P systems, without using centralized elements. In such systems, a peer maintains the addresses of a set of other peers participating in the same DHT in a routing table, sorted according to specific criteria. An ALTO solution can provide valuable information for DHT algorithms.

分散ハッシュテーブル(DHT)は、集中要素を使用せずに、一般的なP2Pシステムでルックアップ機能を実装するために使用されるオーバーレイアルゴリズムのクラスです。このようなシステムでは、ピアは、特定の基準に従ってソートされたルーティングテーブルで同じDHTに参加している他のピアのセットのアドレスを維持します。ALTOソリューションは、DHTアルゴリズムに貴重な情報を提供できます。

5. Aspects of the Problem
5. 問題の側面

This section introduces some aspects of the problem that some people may not be aware of when they first start studying the problem space.

このセクションでは、問題のスペースの研究を開始するときに一部の人々が気付いていないかもしれない問題のいくつかの側面を紹介します。

5.1. Information Provided by an ALTO Service
5.1. ALTOサービスが提供する情報

The goal of an ALTO service is to provide applications with information they can use to perform better-than-random peer selection. In principle, there are many types of information that can help applications in peer selection. However, not all of the information to be conveyed is amenable to an ALTO-like service. More specifically, information that can change very rapidly, such as transport-layer congestion, is out of scope for an ALTO service. Such information is better suited to be transferred through an in-band technique at the transport layer instead of an ALTO-like, out-of-band technique at the application layer. An ALTO solution for congestion will either have outdated information or must be contacted too frequently by applications. And finally, information such as end-to-end delay and available bandwidth can be more accurately measured by applications, themselves.

ALTOサービスの目標は、ランダムよりも優れたピア選択を実行するために使用できる情報をアプリケーションに提供することです。原則として、ピア選択のアプリケーションに役立つ多くの種類の情報があります。ただし、伝えられるすべての情報がALTOのようなサービスに適しているわけではありません。より具体的には、輸送層の混雑など、非常に急速に変化する可能性のある情報は、ALTOサービスの範囲外です。このような情報は、アプリケーション層でのALTOのような帯域外技術の代わりに、輸送層での帯域内の手法を介して転送するのに適しています。混雑のためのALTOソリューションには、時代遅れの情報があるか、アプリケーションによって頻繁に連絡する必要があります。そして最後に、エンドツーエンドの遅延や利用可能な帯域幅などの情報は、アプリケーション自体によってより正確に測定できます。

The kind of information that is meaningful to convey to applications via an out-of-band ALTO service is any information that applications cannot easily obtain themselves and that changes on a much longer time scale than the instantaneous information used for congestion control on the transport layer. Examples for such information are operator's policies, geographical location or network proximity (e.g., the topological distance between two peers), the transmission costs associated with sending/receiving a certain amount of data to/ from a peer, or the remaining amount of traffic allowed by a peer's operator (e.g., in case of quotas or limited flat-rate pricing models).

バンド外のALTOサービスを介してアプリケーションに伝えることが意味のある情報は、アプリケーションが簡単に取得できず、輸送層の輻輳制御に使用される瞬間的な情報よりもはるかに長い時間尺度で変更される情報です。このような情報の例は、オペレーターのポリシー、地理的位置またはネットワークの近接性(2つのピア間のトポロジ距離など)、ピアからの特定の量のデータの送信/受信に関連する送信コスト、または許可されているトラフィックの残りの量です。ピアのオペレーターによって(たとえば、クォータまたは限られた平坦な価格設定モデルの場合)。

5.2. ALTO Service Providers
5.2. ALTOサービスプロバイダー

At least three different kinds of entities can provide ALTO services:

少なくとも3種類のエンティティがALTOサービスを提供できます。

1. Network operators. Network operators usually have full knowledge of the network they administer and are aware of their network topology and policies.

1. ネットワークオペレーター。ネットワークオペレーターは通常、管理するネットワークについて完全な知識を持ち、ネットワークトポロジとポリシーを認識しています。

2. Third parties. Third parties are entities separate from network operators but that may either have collected network information or have arrangements with network operators to learn the network information. Examples of such entities are content-delivery networks like Akamai, which control wide and highly distributed infrastructures, or companies providing an ALTO service on behalf of ISPs.

2. 第三者。第三者はネットワークオペレーターとは別のエンティティですが、ネットワーク情報を収集したか、ネットワークオペレーターとの取り決めを持っている可能性があります。このようなエンティティの例は、Akamaiのようなコンテンツ配信ネットワークであり、広く分散したインフラストラクチャを制御したり、ISPに代わってALTOサービスを提供しています。

3. User communities. User communities run distributed algorithms, for example, for estimating the topology of the Internet.

3. ユーザーコミュニティ。ユーザーコミュニティは、たとえば、インターネットのトポロジを推定するために、分散アルゴリズムを実行します。

5.3. ALTO Service Implementation
5.3. ALTOサービスの実装

It is important for the reader to understand there are significant user communities that expect an ALTO server to be a centralized service. Likewise, there are other user communities that expect the ALTO service be a distributed service, possibly even based on or integrating with a P2P service.

読者にとって、ALTOサーバーが集中サービスになることを期待する重要なユーザーコミュニティがあることを理解することが重要です。同様に、ALTOサービスが分散サービスであると予想される他のユーザーコミュニティがあり、おそらくP2Pサービスに基づいたり統合したりすることもあります。

As a result, one can reasonably expect there to be some sort of service-discovery mechanism to go along with the ALTO protocol definition.

その結果、ALTOプロトコルの定義に沿って何らかのサービス配置メカニズムがあることが合理的に期待できます。

5.4. User Privacy
5.4. ユーザープライバシー

On the one hand, there are data elements an ALTO client could provide in its query to an ALTO server that could help increase the level of accuracy in the replies. For example, if the querying client indicates what kind of application it is using (e.g., real-time communications or bulk data transfer), the server will be able to indicate priorities in its replies, accommodating the requirements of the traffic the application will generate. On the other hand, applications might consider such information private. In addition, some applications may not know a priori what kind of request they will be making.

一方では、ALTOクライアントがALTOサーバーにクエリで提供できるデータ要素があり、応答の精度のレベルを高めるのに役立ちます。たとえば、クエリクライアントが使用しているアプリケーションの種類(リアルタイム通信またはバルクデータ転送など)を示した場合、サーバーはその返信の優先順位を示すことができ、アプリケーションが生成するトラフィックの要件に対応することができます。。一方、アプリケーションはそのような情報を非公開と見なすかもしれません。さらに、一部のアプリケーションは、どのようなリクエストを行うか先のアプリケーションを知らない場合があります。

5.5. Topology Hiding
5.5. トポロジーが隠れています

Operators, with their intimate knowledge of their network topology, can play an important role in addressing the ALTO problem. However, operators often consider revealing details of such network information to be confidential.

ネットワークトポロジに関する知識を持つオペレーターは、ALTOの問題に対処する上で重要な役割を果たすことができます。ただし、オペレーターはしばしば、このようなネットワーク情報の詳細を露出させることを秘密にすることを検討します。

5.6. Coexistence with Caching
5.6. キャッシュとの共存

Caching is an approach to improving traffic generated by applications, and it requires large amounts of data transfers. In some cases, such techniques have proven to be extremely effective in both enhancing user experience and saving network resources.

キャッシュは、アプリケーションによって生成されるトラフィックを改善するためのアプローチであり、大量のデータ転送が必要です。場合によっては、このような手法は、ユーザーエクスペリエンスの向上とネットワークリソースの節約の両方に非常に効果的であることが証明されています。

A cache, either explicitly or transparently, replaces the content source. Thus, a cache must, in principle, use and support the same protocol as the querying peer. That is, if a cache stores web content, it must present an HTTP interface to the web client. Any cache solution for a given protocol needs to present that same protocol to the client. Said differently, each caching solution for a different protocol needs to implement that specific protocol. For this reason, one can only reasonably expect caching solutions for the most popular protocols, such as HTTP and BitTorrent.

キャッシュは、明示的または透過的に、コンテンツソースを交換します。したがって、キャッシュは、原則として、クエリピアと同じプロトコルを使用およびサポートする必要があります。つまり、キャッシュがWebコンテンツを保存する場合、WebクライアントにHTTPインターフェイスを提示する必要があります。特定のプロトコルのキャッシュソリューションは、同じプロトコルをクライアントに提示する必要があります。別の言い方をすれば、異なるプロトコルの各キャッシュソリューションは、その特定のプロトコルを実装する必要があります。このため、HTTPやBitTorrentなどの最も人気のあるプロトコルのキャッシュソリューションを合理的に期待することしかできません。

It is extremely important to realize that caching and ALTO are entirely orthogonal. ALTO, especially if it is aware of caches, can in fact direct clients to nearby caches where the user could get a much better quality of experience.

キャッシュとアルトが完全に直交していることを認識することは非常に重要です。アルトは、特にキャッシュを認識している場合、実際には、ユーザーがより良い経験を得ることができる近くのキャッシュにクライアントを導くことができます。

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

This document is neither a requirements document nor a protocol specification. However, we believe it is important for the reader to understand areas of security and privacy that will be important for the design and implementation of an ALTO solution. Moreover, issues such as digital rights management are out of scope for ALTO, as they are not technically enforceable at this level.

このドキュメントは、要件ドキュメントでもプロトコル仕様でもありません。ただし、読者がALTOソリューションの設計と実装に重要なセキュリティとプライバシーの分野を理解することが重要であると考えています。さらに、デジタル権利管理などの問題は、このレベルで技術的に強制力がないため、ALTOの範囲外です。

Some environments and use cases of ALTO may require client or server authentication before providing sensitive information. In order to support those environments interoperably, the ALTO requirements document [ALTO-REQS] outlines minimum-to-implement authentication and other security requirements.

ALTOの一部の環境とユースケースは、機密情報を提供する前にクライアントまたはサーバー認証を必要とする場合があります。これらの環境を相互にサポートするために、ALTO要件は[ALTO-REQS]を文書化して、最小限の認証およびその他のセキュリティ要件を概説します。

Applications can decide to rely on information provided by an ALTO server to enhance the peer-selection process. In principle, this enables the ALTO service that provides such information to influence the behavior of the application, basically letting a third-party -- the ALTO service provider -- take an important role in a distributed system it was not previously involved in.

アプリケーションは、ピア選択プロセスを強化するために、ALTOサーバーが提供する情報に依存することを決定できます。原則として、これにより、アプリケーションの動作に影響を与えるような情報を提供するALTOサービスが可能になり、基本的にサードパーティ(ALTOサービスプロバイダー)が以前に関与していなかった分散システムで重要な役割を果たすことができます。

For example, in the case of an ALTO server deployed and run by an ISP, the P2P community might consider such a server hostile because the operator could:

たとえば、ISPによって展開および実行されたALTOサーバーの場合、P2Pコミュニティは、オペレーターが次のように敵対的であると考えるかもしれません。

o use ALTO to prevent content distribution and enforce copyrights;

o ALTOを使用して、コンテンツの配布を防ぎ、著作権を実施します。

o redirect applications to corrupted mediators providing malicious content;

o 悪意のあるコンテンツを提供する破損したメディエーターにアプリケーションをリダイレクトします。

o track connections to perform content inspection or logging;

o 接続を追跡して、コンテンツ検査またはロギングを実行します。

o apply policies based on criteria other than network efficiency. For example, the service provider may suggest routes suboptimal from the user's perspective in order to avoid peering points regulated by inconvenient economic agreements.

o ネットワーク効率以外の基準に基づいてポリシーを適用します。たとえば、サービスプロバイダーは、不便な経済協定によって規制されているポイントの覗き見を避けるために、ユーザーの観点からのルートを提案する場合があります。

It is important to note there is no protocol mechanism to require ALTO for P2P applications. If, for some reason, ALTO fails to improve the performance of P2P applications, ALTO will not gain popularity and the P2P community will not use it.

P2PアプリケーションにALTOを必要とするプロトコルメカニズムがないことに注意することが重要です。何らかの理由で、ALTOがP2Pアプリケーションのパフォーマンスを改善できなかった場合、Altoは人気を獲得せず、P2Pコミュニティはそれを使用しません。

At the time of this writing, the privacy issues described in Section 5.4 are relevant for an ALTO solution. Users may be reluctant to disclose sensitive information to an ALTO server. Operators, on the other hand, may not wish to disclose information that would expose details of their interior topology. When exploring the solution space in detail, one needs to consider these issues so that an ALTO protocol does not presume mandatory information disclosure, by either clients or servers.

この執筆時点で、セクション5.4で説明されているプライバシーの問題は、ALTOソリューションに関連しています。ユーザーは、機密情報をALTOサーバーに開示することに消極的かもしれません。一方、オペレーターは、内部トポロジの詳細を公開する情報を開示したくない場合があります。ソリューションスペースを詳細に探索する際には、ALTOプロトコルがクライアントまたはサーバーのいずれかが必須の情報開示を推定しないように、これらの問題を考慮する必要があります。

7. Contributors
7. 貢献者

This document was initially edited by Enrico Marocco and Vijay Gurbani. In the role of Working Group chairs, they have continued to provide significant edits and inputs to the current authors.

このドキュメントは、最初にEnrico MaroccoとVijay Gurbaniによって編集されました。ワーキンググループチェアの役割では、現在の著者に重要な編集と入力を提供し続けています。

8. Acknowledgments
8. 謝辞

Vinay Aggarwal and the P4P working group conducted the research work done outside the IETF. Emil Ivov, Rohan Mahy, Anthony Bryan, Stanislav Shalunov, Laird Popkin, Stefano Previdi, Reinaldo Penno, Dimitri Papadimitriou, Sebastian Kiesel, Greg DePriest, and many others provided insightful discussions, specific comments, and much needed corrections.

Vinay AggarwalとP4Pワーキンググループは、IETFの外で行われた研究作業を実施しました。エミール・イボフ、ローハン・マヒー、アンソニー・ブライアン、スタニスラフ・シャルノフ、レアード・ポプキン、ステファノ・プレビディ、レイナルド・ペノ、ディミトリ・パパジミトリウ、セバスチャン・キーゼル、その他多くの人々は、洞察に富んだ議論、特定のコメント、および必要な修正を提供しました。

Jan Seedorf and Sebastian Kiesel are partially supported by the NAPA-WINE project (Network-Aware P2P-TV Application over Wise Networks, http://www.napa-wine.org), a research project supported by the European Commission under its 7th Framework Program (contract no. 214412). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the NAPA-WINE project or the European Commission.

ヤン・シードルフとセバスチャン・キーゼルは、NAPA-Wineプロジェクト(Wise Networksを介したネットワーク認識P2P-TVアプリケーション、http://www.napa-wine.org)によって部分的にサポートされています。フレームワークプログラム(契約番号214412)。本明細書に含まれる見解と結論は著者の見解であり、NAPA-Wineプロジェクトまたは欧州委員会の表明または黙示のいずれかの公式政策または承認を必ずしも代表するものとして解釈すべきではない。

Thanks in particular to Richard Yang for several reviews.

特にいくつかのレビューをしてくれたリチャード・ヤンに感謝します。

9. Informative References
9. 参考引用

[ACM.bottleneck] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM, October 2003.

[Acm.Bottleneck] Akella、A.、Seshan、S。、およびA. Shaikh、「Widearea Internet BottleNecksの経験的評価」、ACM Sigcommの議事録、2003年10月。

[ACM.fear] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should ISPs fear Peer-Assisted Content Distribution?", ACM USENIX IMC, Berkeley 2005.

[Acm.fear] Karagiannis、T.、Rodriguez、P。、およびK. Papagiannaki、「ISPSはピアアシストコンテンツの分布を恐れるべきですか?」、ACM USENIX IMC、Berkeley 2005。

[ACM.ispp2p] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved performance?", ACM SIGCOMM Computer Communications Review (CCR), 37:3, pp. 29-40.

[ACM.ISPP2P] Aggarwal、V.、Feldmann、A。、およびC. Scheideler、「ISPSとP2Pシステムはパフォーマンスの向上を採用できますか?」、ACM Sigcomm Computer Communications Review(CCR)、37:3、pp。29-40。

[ACM.ono] Choffnes, D. and F. Bustamante, "Taming the Torrent: A practical approach to reducing cross-ISP traffic in P2P systems", Proceedings of ACM SIGCOMM, August 2008.

[Acm.Ono] Choffnes、D。およびF. Bustamante、「TAMING THE TORRENT:P2P SystemsのクロスISPトラフィックを減らすための実用的なアプローチ」、ACM Sigcommの議事録、2008年8月。

[ALTO-REQS] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", Work in Progress, April 2009.

[Alto-Reqs] Kiesel、S.、Popkin、L.、Previdi、S.、Wundy、R。、およびY. Yang、「アプリケーションレイヤートラフィック最適化(ALTO)要件」、2009年4月の進行中。

[PATH-SEL] Saucez, D. and B. Donnet, "The case for an informed path selection service", Work in Progress, February 2008.

[Path-Sel] Saucez、D。およびB. Donnet、「情報に基づいたパス選択サービスのケース」、2008年2月に進行中の作業。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。

[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.

[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。

[WWW.p4p.overview] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, "P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers", <http://www.dcia.info/documents/P4P_Overview.pdf>.

[www.p4p.Overview] Xie、H.、Krishnamurthy、A.、Silberschatz、A。、およびR. Yang、「P4P:P2Pとネットワークプロバイダー間の協同制御のための明示的な通信」、<http://www.dcia.info/documents/p4p_overview.pdf>。

[WWW.wired.fuel] Glasner, J., "P2P Fuels Global Bandwidth Binge", April 2005, <http://www.wired.com>.

[www.wired.fuel] Glasner、J。、「P2P Fuels Global Bandwidth Binge」、2005年4月、<http://www.wired.com>。

Authors' Addresses

著者のアドレス

Jan Seedorf NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany

Jan Seedorf Nec Laboratories Europe、Nec Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ

   Phone: +49 (0) 6221 4342 221
   EMail: jan.seedorf@nw.neclab.eu
   URI:   http://www.nw.neclab.eu
        

Eric W. Burger Neustar Inc. 46000 Center Oak Plaza Sterling, VA 20166-6579 USA

Eric W. Burger Neustar Inc. 46000 Center Oak Plaza Sterling、VA 20166-6579 USA

   Phone:
   Fax:   +1 530 267 7447
   EMail: eburger@standardstrack.com
   URI:   http://www.standardstrack.com