Network Working Group J. Peterson
Request for Comments: 5594 NeuStar
Category: Informational A. Cooper
Center for Democracy & Technology
July 2009
Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008
ピア・ツー・ピア（P2P）インフラストラクチャ、2008年5月28日にIETFワークショップからの報告
Abstract
抽象
This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community.
この文書では、増加したピア・ツー・ピア（P2P）トラフィック量に起因するネットワークの遅延や混雑の問題を議論するため、リアルタイムアプリケーションやIETFのインフラ分野の取締役が主催するワークショップの成果を報告します。ワークショップは、ケンブリッジ、MA、USAにMITで2008年5月28日に開催されました。ワークショップの目標は二重だった：ISPやエンドユーザーがP2Pトラフィックの大量の結果として経験している技術的な問題を理解するために、およびIETFは、これらの問題に対処する上で役立つかもしれない方法を理解し始めます。この作品が追求される可能性があり、どのように実現可能な作業項目を抽出するために、後者の目標を追求する上で重要なタスクとして強調された場所IETFでの理解を得ます。ワークショップは非常によく出席し、以来、IETFコミュニティのメンバーに取り込まれているいくつかの作業項目を作成しました。
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Scoping of the Problem and Solution Spaces ......................4
3. Service Provider Perspective ....................................4
3.1. DOCSIS Architecture and Upstream Contention ................4
3.2. TCP Flow Fairness and Service Flows ........................5
3.3. Service Provider Responses .................................6
4. Application Provider Perspective ................................7
5. Potential Solution Areas ........................................7
5.1. Improving Peer Selection: Information Sharing,
Localization, and Caches ...................................8
5.1.1. Leveraging AS Numbers ...............................9
5.1.2. P4P: Provider Portal for P2P Applications ...........9
5.1.3. Multi-Layer, Tracker-Based Architecture ............10
5.1.4. ISP-Aided Neighbor Selection .......................11
5.1.5. Caches .............................................12
5.1.6. Potential IETF Work ................................12
5.2. New Approaches to Congestion Control ......................14
5.2.1. End-to-End Congestion Control ......................15
5.2.2. Weighted Congestion Control ........................15
5.3. Quality of Service ........................................16
6. Applications Opening Multiple TCP Connections ..................17
7. Costs and Congestion ...........................................18
8. Next Steps .....................................................18
8.1. Transport Issues ..........................................19
8.2. Improved Peer Selection ...................................19
9. Security Considerations ........................................19
10. Acknowledgements ..............................................19
11. Informative References ........................................20
Appendix A. Program Committee ....................................21
Appendix B. Workshop Participants ................................21
Appendix C. Workshop Agenda ......................................24
Appendix D. Slides and Position Papers ..........................25
Increasingly, large ISPs are encountering issues with P2P traffic. The transfer of static, delay-tolerant data between nodes on the Internet is a well-understood problem, but traditional management of fairness at the transport level is under strain from applications designed to achieve the best end-user transfer rates. At peak times, this results in networks running near absolute capacity, causing all traffic to incur delays; the applications that bear the brunt of this additional latency are real-time applications like Voice over IP (VoIP) and Internet gaming. To explore how IETF standards work could be useful in addressing these issues, the Real-time Applications and Infrastructure area directors organized a "P2P Infrastructure" workshop and invited contributions from subject matter experts in the problem and solution spaces.
ますます、大規模なISPはP2Pトラフィックの問題が発生しています。インターネット上のノード間の静的、遅延トレラントデータの転送には、十分に理解の問題であるが、トランスポートレベルでの公正性の伝統的な管理は、最善のエンドユーザの転送速度を実現するように設計されたアプリケーションからの歪みの下にあります。ピーク時に、これは、ネットワークが、遅延が発生するすべてのトラフィックを引き起こして、絶対的な能力の近くに実行していることになります。この追加のレイテンシの矢面に立つのアプリケーションは、ボイスオーバーIP（VoIP）のインターネットゲームのようなリアルタイム・アプリケーションです。 IETF標準化作業は、これらの問題に対処する上で役立つ可能性がどのように調べるために、リアルタイムアプリケーションとインフラストラクチャのエリアディレクターは、「P2P基盤」ワークショップを開催し、問題と解決策スペースでの主題の専門家からの貢献を招待しました。
The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop's focus was on engineering solutions that promise some imminent benefit to the Internet as a whole, as opposed to longer-term research or closed proprietary solutions. While public policy must inform work in this space, crafting or debating public policy was outside the scope of the workshop.
ワークショップの目標は二重だった：ISPやエンドユーザーがP2Pトラフィックの大量の結果として経験している技術的な問題を理解するために、およびIETFは、これらの問題に対処する上で役立つかもしれない方法を理解し始めます。この作品が追求される可能性があり、どのように実現可能な作業項目を抽出するために、後者の目標を追求する上で重要なタスクとして強調された場所IETFでの理解を得ます。ワークショップの焦点は、長期的な研究や、閉じた独自のソリューションとは反対に、全体としてインターネットにいくつかの差し迫った利益を約束するエンジニアリングソリューションにありました。公共政策を作り上げるや公共政策を議論し、この空間に作品を知らせる必要がありますが、ワークショップの範囲外でした。
Position papers were solicited in the weeks prior to the workshop, and a limited number of speakers were invited to present their views at the workshop based on these submissions. This report is a summary of all participants' contributions. The program committee and participant list are attached in Appendices A and B, respectively. The agenda of the workshop can be found in Appendix C. A link to the presentations given at the workshop and the position papers submitted prior to the workshop is in Appendix D.
ポジション・ペーパーは、ワークショップの前に週に募集し、スピーカーの限られた数は、これらの提出に基づいてワークショップで自分の意見を提示する招待されました。このレポートでは、参加者全員の貢献の要約です。プログラム委員会と参加者リストは、それぞれ付録AおよびBに取り付けられています。ワークショップの議題は、ワークショップで与えられたプレゼンテーションやワークショップ開催前に提出された位置の論文へのリンクは、付録Dにある付録C.で見つけることができます
The workshop showcased the IETF community's recognition of the impact of P2P and other high-volume applications on the Internet as a whole. Participants welcomed the opportunity to discuss potential standardization work that network operators, applications providers, and end users would all find mutually beneficial. Two transport-related work items gained significant traction: designing a protocol for very deferential end-to-end congestion control for delay-tolerant applications, and producing an informational document about the reasoning behind and effects of applications opening multiple transport connections at once. A separate area of interest that emerged at the workshop focused on improving peer selection by having networks make more information available to applications. Finally, presenters also covered traditional approaches to multiple service-tier queuing such as Diffserv.
ワークショップでは、全体として、インターネット上のP2Pおよびその他の量産アプリケーションの影響のIETFコミュニティの認識を披露しました。参加者は、ネットワーク事業者、アプリケーションプロバイダ、およびエンドユーザーは、すべて相互に有益な見つけるだろう潜在的な標準化作業を議論する機会を歓迎しました。二つのトランスポート関連の作業項目は、重要な牽引力を得た：ディレイトレラントなアプリケーションのために非常に敬意をエンドツーエンドの輻輳制御のためのプロトコルを設計し、そして背後にある理由と一度に複数の交通機関の接続を開くアプリケーションの影響に関する情報のドキュメントを生成します。ネットワークは、アプリケーションへのより多くの情報を利用できるようにすることによってピア選択の改善に焦点を当てたワークショップで登場し、関心の独立したエリア。最後に、発表者はまた、Diffservのようなキューイング複数のサービス階層に伝統的なアプローチをカバーしました。
The genesis for the Peer-to-Peer Infrastructure (P2PI) workshop grew in large part out of specific pain points that ISPs are experiencing as a result of high volumes of P2P traffic. However, several workshop participants felt that the IETF should approach a more general space of problems, of which P2P-related congestion may be merely one instance.
ピアツーピアインフラ（P2PI）ワークショップのための起源は、ISPがP2Pトラフィックの大量の結果として発生している特定の疼痛点のうちの大部分が成長しました。しかし、いくつかのワークショップ参加者は、IETFがP2P関連輻輳は一例であってもよいの問題のより一般的な空間を近づける必要があることを感じました。
For example, high-volume applications besides P2P, whether they already exist or have yet to be developed, could cause congestion issues similar to those caused by P2P. The general class of congestion problems attributable to always-on, high-volume applications require the development of solutions that are reasonable for operators, applications, and subscribers. And while much attention has been paid to congestion on access links, increased traffic volumes could impact other parts of the network. Although the workshop focused primarily on the specific causes and effects of current P2P traffic volumes, it will likely be useful in the future for the IETF to consider how to pursue solutions to these larger problems.
例えば、P2P以外の大容量アプリケーションは、彼らがすでに存在しているか開発されてまだ持っているかどうか、P2Pによって引き起こされたものと同様の輻輳の問題を引き起こす可能性があります。常時オンに起因する輻輳問題の一般的なクラスは、量産アプリケーションは事業者、アプリケーション、および加入者のための合理的なソリューションの開発が必要。そして、しばらく注目は、交通量がネットワークの他の部分に影響を与える可能性が増加し、アクセスリンク上の混雑が注目されています。ワークショップでは、現在のP2Pトラフィック量の具体的な原因と効果に主に焦点を当てますが、それはおそらく、これらの大きな問題の解決策を追求する方法を検討するIETFのために、将来的に有用であろう。
Obtaining more data about Internet congestion may also be a helpful step before the IETF pursues solutions. This data collection could focus on where in the network congestion is occurring, its duration and frequency, its effects, and its root causes. Although individual service providers expressed interest in sharing congestion data, strategies for reliably and regularly obtaining and disseminating such data on a broad scale remain elusive.
IETFは、解決策を追求する前に、インターネットの混雑についてのより多くのデータを入手することも有益工程であってもよいです。このデータ収集は、ネットワーク内の輻輳が、その期間や頻度、その効果、およびその根本原因を発生している場所に集中できます。個々のサービスプロバイダが共有渋滞データに関心を示しているが、確実かつ定期的に広範な規模で、このようなデータを取得し、普及のための戦略は、とらえどころのないまま。
To help participants gain a fuller understanding of one specific network operator's view of P2P-induced congestion, Jason Livingood and Rich Woundy provided an overview of Comcast's network and approach to management of P2P traffic.
参加者がP2Pによって誘発される輻輳の一つの特定のネットワークオペレータのビューの完全な理解を得るのを助けるために、ジェイソンLivingoodとリッチWoundyは、P2Pトラフィックの管理にComcastのネットワークとアプローチの概要を説明しました。
In the Data Over Cable Service Interface Specification (DOCSIS) architecture [DOCSIS] that is used for many cable systems, there may be a single Cable Modem Termination System (CMTS) serving hundreds or thousands of residential cable customers. Each CMTS has multiple
多くのケーブルシステムに使用されるデータオーバーケーブルサービスインターフェース仕様（DOCSIS）アーキテクチャ[DOCSIS]で、住宅のケーブルの顧客の数百または数千にサービスを提供する単一ケーブルモデム終端システム（CMTS）があるかもしれません。各CMTSは複数を持っています
DOCSIS domains, each of which typically has a single downstream link and a number of upstream links. Each CMTS is connected through a hybrid fiber-coaxial (HFC) network to subscribers' cable modems.
典型的には、単一の下流リンクと上りリンクの数をそれぞれ有するDOCSISドメイン、。それぞれが加入者のケーブルモデムに、ハイブリッドファイバ同軸（HFC）ネットワークを介して接続されているCMTS。
The limiting resource in this architecture is usually bandwidth, so bandwidth is typically the measure used for capacity planning. As with all networks, congestion manifests itself when instantaneous load exceeds available capacity.
このアーキテクチャでのリソース制限は、通常、帯域幅なので、帯域幅は、通常、キャパシティプランニングのために使用さ尺度です。瞬時負荷が利用可能な容量を超える場合、すべてのネットワークと同様に、輻輳が現れます。
In the upstream direction, any cable modem connected to a CMTS can make a request to the CMTS to transmit, and requests are randomized to minimize collisions. With many cable modems issuing requests at once, the requests may collide, resulting in delays. DOCSIS does not specify a size for cable modem buffers, but buffer delays of one to four seconds have been observed with various cable modems from different vendors.
アップストリーム方向では、CMTSに接続されているケーブルモデムは、CMTSへの要求が送信を行うことができ、そして要求が衝突を最小化するためにランダム化されます。多くのケーブルモデムが一度にリクエストを発行すると、要求が遅れ、その結果、衝突することがあります。 DOCSISは、ケーブルモデムのバッファのサイズを指定しますが、1〜4秒の遅延が異なるベンダーからさまざまなケーブルモデムで観察されているバッファリングされません。
Once the CMTS has granted a cable modem the ability to transmit its data PDU, the modem can piggyback its next request on top of that data PDU. In situations with a lot of upstream traffic, piggybacking happens more often, which sends heavy upstream users to the front of the CMTS queue, ahead of interactive but less-upstream-intensive applications. For example, if the CMTS is granting requests approximately every one to three milliseconds, then a cable modem transmitting data for a service like VoIP with a packetization delay of 20-30 milliseconds may get into contention with another modem on the same CMTS that is constantly transmitting upstream and piggybacking each new request. This may explain how heavy upstream users ultimately dominate the pipe over more interactive applications. Consequentially, it is imperative that assessments of the problem space and potential solutions are mindful of the influence that specific layer-2 networks may exert on the behavior of Internet traffic, especially when considering the alleviation of congestion in an access network.
CMTSは、ケーブルモデムにそのデータPDUを送信する能力を付与された後、モデムはそのデータPDUの上に、その次の要求をピギーバックすることができます。アップストリームトラフィックの多い状況では、ピギーバッキングは、先にインタラクティブあまり-上流を多用するアプリケーションの、CMTSキューの先頭に重い上流のユーザーを送信する、より頻繁に起こります。 CMTSは約ごとに1〜3ミリ秒の要求を許可された場合、その後、20〜30ミリ秒のパケット化遅延とVoIPのようなサービスのためのデータを伝送するケーブルモデムは常にある同じCMTS上の別のモデムとの競合になることがあります上流の送信およびそれぞれの新しい要求を便乗。これは、上流のユーザーは、最終的に、よりインタラクティブなアプリケーションを介してパイプを支配どのように重い説明するかもしれません。結果的に、問題空間と潜在的な解決策の評価は、特定のレイヤ2ネットワークは、アクセスネットワークにおける混雑の緩和を検討する場合は特に、インターネットトラフィックの振る舞いに発揮することができるという影響に留意していることが不可欠です。
How TCP flow fairness applies to upstream requests to the CMTS is an open question. A CMTS sees many service flows, each of which could be a single TCP flow or many TCP flows (or UDP). The CMTS is not aware of the source or destination IP address of a packet until it has already been transmitted upstream, so those cannot be used to impose flow fairness.
TCPフロー公平性がCMTSへのアップストリームの要求に適用されますどのように未解決の問題です。 CMTSは、単一のTCPフローや多くのTCPフロー（またはUDP）可能性があり、それぞれが多くのサービスフローを、見ています。それは既に上流送信されるまで、それらをフロー公平性を課すために使用することができないので、CMTSは、パケットの送信元または宛先IPアドレスを知りません。
A particular cable modem can have multiple service flows defined. For example, a modem that is also a VoIP endpoint can provision a service flow for VoIP that would allow VoIP traffic to avoid the upstream request process to the CMTS (and thereby avoid contention with other modems). The service flow would have upstream capacity provisioned for it. The modem would have a separate service flow for best efforts traffic. Some ISPs provision such a flow for their own VoIP offerings; others allow subscribers to pay extra to have particular traffic assigned to a provisioned service flow.
特定のケーブルモデムは、定義された複数のサービスフローを有することができます。例えば、また、VoIPのエンドポイント缶提供VoIPトラフィックは、CMTSにアップストリーム要求処理を回避することを可能にするVoIPのサービスフローであるモデムは、（それによって他のモデムとの競合を避けるため）。サービスの流れはそれに対してプロビジョニング上流の能力を持っているでしょう。モデムは、ベストエフォートトラフィックに対して個別のサービスフローを持っているでしょう。自分自身のVoIP製品のため、このような流れのいくつかのISPの提供。他の人は、加入者がプロビジョニングされたサービスフローに割り当てられた特定のトラフィックを持っているために余分に支払うことができます。
It may also be possible for an ISP to provision such a flow on the fly when it recognizes the need for it. Diffserv [RFC2475] bits set by the customer premises equipment could be used to classify flows, for example.
また、それはそれのための必要性を認識し、その場で、このような流れをプロビジョニングするISPのために可能かもしれません。顧客宅内機器によって設定されたDiffServ [RFC2475]ビットは、例えば、フローを分類するために使用することができます。
In 2005, ISP customers began increasingly complaining about the performance of delay-sensitive traffic (VoIP and gaming), due in part to the issues arising out of the DOCSIS architecture as described above. At the same time, ISPs were seeing heavy growth in P2P traffic and an increasing correlation between high levels of P2P activity and packet loss.
2005年には、ISPの顧客は、上記のように、ますます一部起因DOCSISアーキテクチャから生じる問題のために、遅延に敏感なトラフィック（VoIPやゲーム）のパフォーマンスについて不満を始めました。同時に、ISPがP2Pトラフィックの重い成長とP2Pの活動やパケット損失の高レベル間の増加の相関関係を見ていました。
In responding to this situation, cable ISPs have several avenues to pursue. The newest generation of the DOCSIS specification, DOCSIS 3.0, enables faster transfer rates than most cable systems currently support. While the rollout of DOCSIS 3.0 will provide additional capacity, it will likely not obviate the need for congestion management in an environment where client software is designed to maximize bandwidth consumption regardless of available capacity.
このような状況への対応では、ケーブルISPは追求するには、いくつかの道を持っています。 DOCSIS仕様の最新世代、DOCSIS 3.0は、ほとんどのケーブルシステムよりも高速な転送速度は、現在サポートしています。 DOCSIS 3.0の展開は、追加の容量を提供しますが、それはおそらく、クライアントソフトウェアに関係なく利用可能な容量の帯域幅の消費を最大化するように設計された環境での輻輳管理のための必要性を取り除くことはありません。
Congestion management can take many forms; Jason and Rich explained the new protocol-agnostic approach that Comcast is currently trialing. Prior to these trials, all traffic was marked as "best efforts". During the trials, all traffic is re-classified as "priority". When a CMTS is approaching peak congestion on a particular upstream or downstream port (the "Near Congestion State"), some subscribers will have traffic re-classified as "best efforts". Both the threshold for determining when a CMTS port is in Near Congestion State and the number of minutes it remains in this state are parameters being explored during the trials. To re-classify upstream traffic, a new default DOCSIS service flow is used that has the same provisioned bandwidth as the "priority" stream but that is treated with lower priority.
輻輳管理は、多くの形態をとることができます。ジェイソンとリッチは、コムキャストが現在試用され、新たなプロトコルに依存しないアプローチを説明しました。これらの試験に先立ち、すべてのトラフィックは、「最善の努力」としてマークされました。試験中に、すべてのトラフィックは、「優先度」として再分類されています。 CMTSは特定のアップストリームまたはダウンストリームポート上のピーク輻輳（「ニア輻輳状態を」）に近づいているときに、いくつかの加入者は、トラフィックが「最善の努力」として再分類されています。両方のCMTSポートが近く輻輳状態であると分の数は、それがこの状態のままであるときを決定するための閾値は、試験中に探索されたパラメータです。アップストリームトラフィックを再分類するには、新しいデフォルトのDOCSISサービスフローは、「優先度」ストリームと同じプロビジョニングの帯域幅を持っていますが、それは低い優先順位で処理され使用されています。
The subscribers whose traffic is re-marked will be selected by determining whether they have temporarily entered a "Long Duration Bulk Consumption State". This state is achieved by consuming a certain amount of bandwidth over a certain period of minutes (both are tweakable parameters being explored during the trials). These thresholds will depend on the subscriber's service tier -- subscribers who pay for more bandwidth will have higher thresholds. The re-marking will not distinguish between multiple users of the same subscriber connection, so one family member's P2P usage could cause another family member's Web browsing traffic to be lowered in priority. There is no current mechanism for users to determine that their traffic has been re-marked.
トラフィックが再マークされている彼らは、一時的に「長期一括消費状態を」入力したか否かを決定することによって選択されます加入者。この状態は、分の一定期間（いずれも試験中に探索さ調整機能付きパラメータである）上に一定量の帯域幅を消費することによって達成されます。これらのしきい値は、加入者のサービス層に依存します - より多くの帯域幅のために支払う加入者は、より高い閾値を持つことになります。再マーキングは、同じ加入者接続の複数のユーザーを区別しないので、1つの家族のP2Pの利用は、他の家族のWebブラウジングトラフィックは優先順位が低下する可能性があります。そのトラフィックが再マークされていることを決定するために、ユーザーのための現在のメカニズムはありません。
By temporarily reducing the traffic priority of subscribers who have been consuming bandwidth in bulk for lengthy periods, this congestion management technique aims to preserve a good user experience for subscribers with burstier traffic patterns, including those using real-time applications. As compared to an approach that reduces particular subscribers' bandwidth during periods of congestion, this technique eliminates the ability for applications to set their own priority levels, but it also avoids the negative connotations that some users may associate with bandwidth reductions.
一時的に長い期間のために大量に帯域幅を消費してきた加入者のトラフィックの優先度を低下させることにより、この輻輳管理技術は、リアルタイム・アプリケーションを使用したものを含め、バースト的なトラフィックパターンを持つ加入者のための優れたユーザーエクスペリエンスを維持することを目指しています。輻輳の期間中に特定の加入者の帯域幅を減少させる手法に比べて、この技術は、独自の優先順位を設定するアプリケーションのための能力を排除するが、それはまた、一部のユーザーは帯域幅削減に関連付けることができる否定的な意味合いを回避します。
This approach involves many tweakable parameters. A large part of the trial process is aimed at determining the best settings for these parameters, but there may also be opportunities to work with the research community to identify the best way to adjust the thresholds necessary to optimize the performance of the management technique.
このアプローチは、多く微調整できるパラメータが含まれます。試用プロセスの大部分は、これらのパラメータの最適な設定を決定することを目的としているが、また、管理手法のパフォーマンスを最適化するために必要なしきい値を調整するための最良の方法を識別するために、研究コミュニティと仕事をする機会があるかもしれません。
Stanislav Shalunov provided an overview of BitTorrent's view of the impact of increased P2P traffic volumes and potential mitigations. The impact is described here; his proposed solutions (comprising the bulk of his talk) are addressed in the appropriate subsections of Section 5.
スタニスラフ・シャルノブは増加したP2Pトラフィック量と潜在的な緩和策の影響のBitTorrentの見解の概要を説明しました。影響は、ここで記載されています。 （彼の話の大部分を含んで）彼の提案された解決策は、第5節の適切なサブセクションで対処されています。
As uptake in P2P usage has grown, so has end-user latency. For example, a user whose uplink capacity is 250-500 Kbps and whose modem buffer has a capacity of 32-64 Kbps may easily fill the buffer (unless the modem uses Adaptive Queue Management (AQM), which is uncommon). This can result in delay on the order of seconds, with disastrous effects on application performance. On a cable system with shared capacity between neighbors, one neighbor could saturate the buffer and affect the latency of another neighbor's traffic. Even users with dedicated bandwidth can experience delays as their own P2P traffic saturates the link and dominates their own more latency-sensitive traffic.
P2P使用の取り込みが成長していたようなので、エンドユーザーの待ち時間があります。 （モデムはまれである適応キュー管理（AQM）を、使用していない限り）、例えば、そのアップリンク容量250〜500 Kbpsであり、そのモデムバッファユーザーは32-64 Kbpsでの容量を容易にバッファを満たすことができるしています。これは、アプリケーションのパフォーマンスに悲惨な効果で、秒の順に遅延が発生することができます。近隣諸国との間で共有容量のケーブルシステムでは、1人の隣人がバッファを飽和させ、別の隣人のトラフィックのレイテンシーに影響を与える可能性があります。自分のP2Pトラフィックがリンクを飽和させ、独自のより多くの待ち時間に敏感なトラフィックを支配してさえ、専用の帯域幅を持つユーザーは、遅延が発生することができます。
The submissions received in advance of the workshop covered a broad array of work addressing specific aspects of P2P traffic volume and other related issues. Solution suggestions generally fell into one or more of three topic areas: improving peer selection, new approaches to congestion control, and quality-of-service mechanisms. The workshop discussions and outcomes in each area are described below.
ワークショップの前に受け取った応募は、P2Pのトラフィック量やその他の関連する問題の特定の側面を扱う作業の幅広いをカバーしました。向上ピア選択、輻輳制御への新たなアプローチ、およびサービス品質のメカニズム：ソリューションの提案は、一般的に3つのトピック領域の一つ以上に落ちました。各地域でのワークショップでの議論と成果を以下に記載されています。
5.1. Improving Peer Selection: Information Sharing, Localization, and Caches
5.1. 改善ピア選択：情報共有、ローカライズ、およびキャッシュ
Peer selection is an integral factor in determining the efficiency of P2P networks from both the ISP and the P2P client points of view. How peers are selected will determine both network load and client performance.
ピア選択は、ISPとビューのP2Pクライアント・ポイントの両方からP2Pネットワークの効率を決定する積分要素です。ピアは、ネットワーク負荷とクライアントのパフォーマンスの両方を決定する選択されている方法。
The way that P2P clients select peers today varies from protocol to protocol and client to client but, in general, peers are largely oblivious to routing-level and network-topology information. This results in P2P topologies that are agnostic of underlay topologies and constraints.
P2Pクライアントは、今日のピアを選択する方法は、一般的には、ピアは、ルーティングレベルおよびネットワーク・トポロジー情報への大部分は気にしません、クライアントのプロトコルやクライアントへのプロトコルによって異なりますが。これは、アンダーレイトポロジと制約のとらわれないP2Pトポロジになります。
Approaches to closing this gap generally involve an entity that has knowledge of network topology, costs, or constraints (e.g., an ISP) making some of this information available to P2P clients or trackers. This information may be used to localize traffic based on some metric of locality or to otherwise alter peer-selection decisions based on the provided network information (hereafter referred to simply as "localization"). One special case of this kind of approach would help peers find caches containing the content they seek.
このギャップを閉鎖するためのアプローチは、一般に、ネットワークトポロジ、コスト、または制約（例えば、ISP）P2Pクライアントまたはトラッカーに利用可能な情報の一部を作る知識を有するエンティティを含みます。この情報は、地域のいくつかのメトリックに基づいてトラフィックをローカライズするか、そうでなければ提供されたネットワーク情報に基づいて、ピア選択決定を変更するために使用されてもよい（以下、単に「定位」と呼びます）。この種のアプローチの一つの特殊なケースは、ピアは、彼らが求めるコンテンツを含むキャッシュを見つけるのに役立つでしょう。
Any alteration to current peer-selection algorithms will have engineering trade-offs. BitTorrent, for example, used randomized peer selection by design. Choosing peers randomly out of a large selection helps to average out problems among peers and allows for connections to good peers that may be far away. Randomized peer selection also supports "rarest first" piece selection, which allows swarms to continue even when the original seed disappears and which distributes pieces so that more peers are likely to have pieces of interest to other peers. Any move away from randomized selection would have to take these factors into account.
現在のピア選択アルゴリズムへの任意の変更は、エンジニアリングのトレードオフになります。 BitTorrentは、例えば、設計によって無作為ピア選択を使用します。大規模な選択のうち、ランダムにピアを選択すると、ピア間の問題を平均化するのに役立ち、遠くかもしれ良いピアへの接続が可能になります。ランダム化されたピアの選択は、元の種が消え、よりピアが他のピアへの関心のある部分を有する可能性があるように部品を配布する場合であっても群れを継続することを可能にする「希少最初の」ピースの選択をサポートします。ランダム化された選択から離れた任意の動きは、アカウントにこれらの要因を取る必要があります。
Although localization has the potential to improve peer selection, the incentives for both parties to the information exchange are complex. ISPs may want to move traffic off of their own networks, which could motivate them to provide information to peers that has the opposite effect of what the peers would expect. Likewise, peers will want the use of the information they receive to result in performance improvements; otherwise, they have no incentive to consult with the network before selecting peers. Even when both parties find the information sharing to be beneficial, user experiences will not necessarily be uniform depending on the scope of the information provided and the peer's location. Localization information could form one component of a peer-selection decision, but it will likely need to be balanced against other factors.
局在化はピア選択を改善する可能性を有するが、情報交換の双方のためのインセンティブは複雑です。 ISPは、ピアが期待するものの逆の効果を持っているピアに情報を提供するために、彼らのやる気を引き出すことができ、自分のネットワークの外トラフィックを移動することができます。同様に、ピアは、彼らがパフォーマンスの改善をもたらすために受信情報の使用をお勧めします。それ以外の場合は、ピアを選択する前に、ネットワークに相談するインセンティブを持っていません。両当事者が有益であるとの情報共有を見つけた場合でも、ユーザ体験は必ずしも提供された情報及びピアの位置の範囲に応じて、均一ではないだろう。ローカライゼーション情報は、ピア選択判定の一の成分を形成することができるが、それは、おそらく他の要因に対してバランスされる必要があります。
Workshop participants discussed both current research efforts in this area and how IETF standards work may be useful in furthering the general concept of improved peer selection. Those discussions are summarized below.
ワークショップの参加者は、現在の研究のこの分野での努力とどのようにIETF標準に改善ピア選択の一般的な概念を進めるのに有用であり得る仕事の両方を議論しました。これらの議論は以下に要約されています。
One simple way to potentially make peer selection more efficient would be for a peer to prefer peers within its own Autonomous System (AS). Transfers between peers within the same AS may be faster on some networks, although more data is needed to determine the extent of the potential improvement. On mobile networks, for example, the utility of AS numbers is limited since they do not correlate to geographic location. Peers may also see improvements by connecting to other peers within a specific set of ASes or IP prefixes provided by their ISPs. Some ISPs may have an incentive to expose this granularity of information because it will potentially reduce their transit costs.
潜在的にピア選択をより効率的にするための一つの簡単な方法は、独自の自律システム（AS）内のピアを好む相手のためになります。より多くのデータが潜在的な改善の程度を決定するために必要とされるものの、同じAS内のピア間の転送は、いくつかのネットワーク上で高速であってもよいです。彼らは地理的な位置に相関していないので、モバイルネットワークでは、例えば、AS番号の有用性は限られています。ピアはまた、彼らのISPが提供するのASまたはIPプレフィックスの特定のセット内の他のピアに接続することによって改善することがあります。それは潜在的に彼らのトランジットコストを削減するため、一部のISPは、この情報の粒度を公開するインセンティブを有することができます。
A case study was conducted with the four most popular BitTorrent torrents to determine what the effect of localizing to an AS might be. The swarm sizes for the torrents were 9984, 3944, 2561, and 2023, with the size distributions appearing to be polynomial. With more than 20 peers in a single AS, peers within an AS could trade only with each other, avoiding interdomain traffic. More than half (57%) of peers in the four swarms were in ASes like this. Thus, in these cases connecting to peers within an AS could reduce transit traffic by at least 57%. If the ASes have asymmetric upload and download links, however, the resulting user experience may deteriorate since each peer's download speed would be limited by slower upload speeds.
ケーススタディは、ASへのローカライズの影響が何であるかを決定するために4つの最も人気のあるBitTorrentの急流を行いました。トレントのための群れのサイズは、サイズ分布が多項式であることを表示されると、9984、3944、2561、および2023でした。単一AS内の20人の以上の同僚と、AS内のピアは、ドメイン間のトラフィックを避け、お互いにだけ取引することができます。 4人の群れにおけるピアの半分以上（57％）は、このようなのASでした。したがって、AS内のピアに接続するような場合には少なくとも57％によって、通過トラフィックを減らすことができます。 ASが非対称アップロードとダウンロードのリンクをお持ちの場合は、各ピアのダウンロード速度が遅くアップロード速度によって制限されるので、しかし、結果としてユーザーエクスペリエンスが低下するおそれがあります。
With the largest swarm size at 9984, the probability of two peers being in the same neighborhood is too low to make localization to the neighborhood level worthwhile. Attempting a simple localization scheme, such as the AS localization described above, and determining its effectiveness likely makes more sense as a first step.
9984の最大の群れの大きさで、同じ地区にされている2つのピアの確率は、やりがいのある近所レベルへの局在化をするためには低すぎます。 ASの局在化は、上述のような、単純な局在化スキームを試み、その有効性を決定する可能性が高い最初のステップとして、より理にかなっています。
The Provider Portal for P2P Applications (P4P) project [P4P] aims to design a framework to enable cooperation between providers and applications (including P2P), where "providers" may be ISPs, content distribution networks, or caching services. In this architecture, each provider can communicate information to P2P clients through a portal known as an iTracker. An iTracker could be identified through a DNS SRV record (perhaps with its own new record type), a whois look-up, or a trusted third party.
P2Pアプリケーションのプロバイダポータル（P4P）プロジェクト[P4P]は、「プロバイダ」はISPの、コンテンツ配信ネットワーク、またはキャッシングサービスもあり（P2P含む）プロバイダーとアプリケーション間の連携を可能にするためのフレームワークを設計することを目指しています。このアーキテクチャでは、各プロバイダがiTrackerとして知られているポータルを介してP2Pクライアントに情報を通信することができます。 iTrackerは、（おそらく、独自の新しいレコードタイプを持つ）のDNS SRVレコード、whoisのルックアップ、または信頼できる第三者によって識別することができます。
An iTracker has different interfaces for different types of information that the provider may want to share. The core interface allows the provider to express the "virtual cost" of its intradomain or interdomain links. Virtual cost may reflect any kind of provider preferences and may be based on the provider's choice of metrics, including utilization, transit costs, or geography. It is up to the provider to decide how dynamic it wants to be in updating its virtual cost determinations.
iTrackerは、プロバイダが共有したいことがあり、情報の種類ごとに異なるインタフェースを持ちます。コアインタフェースは、プロバイダは、そのドメイン内又はドメイン間リンクの「仮想コスト」を表現することを可能にします。仮想コストは、プロバイダの好みのいずれかの種類を反映してもよいし、利用、輸送費、あるいは地理などのメトリクスのプロバイダーの選択に基づいてもよいです。それは、その仮想コスト決定の更新になりたがっているか、動的決定するプロバイダ次第です。
In tests of this framework, two parallel swarms were created with approximately the same number of clients and similar geographical and network distributions, both sharing the same file. One of the swarms used the P4P framework, with the ISP's network topology map as input to its iTracker, and the other swarm used traditional peer selection. The swarm without P4P saw 98% of traffic to and from peers external to the ISP, whereas with P4P that number was 50%. Download completion times for the P4P-enabled swarm improved approximately 20% on average.
このフレームワークのテストでは、二つの平行な群れは、クライアントと同様の地理的ネットワークの分布のほぼ同じ数で作成し、両方が同じファイルを共有しました。群れの一つは、そのiTrackerへの入力としてISPのネットワークトポロジマップに、P4Pフレームワークを使用し、他の群れは、伝統的なピアの選択を使用します。 P4Pなしの群れは、数は50％であったP4Pを有する一方、およびISPの外部ピアからのトラフィックの98％を見ました。 P4P対応の群れのダウンロード完了時間は平均で約20％向上しました。
The multi-layer, tracker-based P2P scheme described at the workshop is a generic example of an architecture that demonstrates how localization may be useful in principle.
ワークショップで説明した多層、追跡ベースのP2P方式は、局在が原理的に有用であり得る方法を示しアーキテクチャの一般的な例です。
In a traditional, tracker-based P2P system, trackers provide clients with information about seeds and peers where clients can find the content they seek. A multi-layered tracker architecture incorporates additional "local" trackers that provide the same information, but only for content located within their own local network scope. Client queries are re-directed from the global tracker to the appropriate local trackers. Local trackers may also exist on multiple levels, in which case queries would be further re-directed. This sort of architecture could also serve hybrid P2P/content delivery networks, where the global tracker functions as both a tracker and a content server, and local trackers track locally provisioned caches in addition to seeds and peers.
伝統的な、トラッカーベースのP2Pシステムでは、トラッカーは、クライアントは、彼らが求めるコンテンツを見つけることができる種子やピアに関する情報をクライアントに提供しています。多層トラッカアーキテクチャはだけ自分のローカルネットワークの範囲内にあるコンテンツのため、同じ情報を提供する追加の「ローカル」トラッカーを組み込んでいます。クライアントのクエリは、適切なローカルトラッカーにグローバルトラッカーからリダイレクトされます。ローカルトラッカーはまた、複数のレベルで存在し得る場合クエリーは、さらに再指向であろう。トラッカとコンテンツサーバ、及びローカルトラッカーの両方がシードとピアに加えて、局所的にプロビジョニングキャッシュを追跡するようにアーキテクチャのこの種は、グローバル追跡機能ハイブリッドP2P /コンテンツ配信ネットワークを、役立つことができます。
One challenge in this architecture is determining what "local" means for trackers, seeds, and peers. Locality could be dependent on traffic conditions, load balancing, static topology, policy, or some other metric. These same considerations would also be crucial for determining appropriate cache placement in a hybrid network.
このアーキテクチャでは1つの課題は、「ローカル」はトラッカー、種子、およびピアのために何を意味するのかを決定することです。産地は、交通状況、負荷分散、静的なトポロジ、ポリシー、またはいくつかの他のメトリックに依存することができます。これらの同じ考慮は、ハイブリッドネットワーク内の適切なキャッシュ配置を決定するために重要になります。
This architecture presents in the abstract the problem of re-directing from a global entity to a local entity. Client queries need to find their way to the appropriate local tracker. This can be accomplished through an off-path, explicit mechanism where local trackers register with the global tracker in advance, or through an on-path approach where the network proxies P2P requests. The off-path tracker format approach is preferable for performance and reliability reasons.
このアーキテクチャは、抽象的にローカルエンティティにグローバルエンティティから再指向の問題を提示しています。クライアントのクエリは、適切なローカルトラッカーに自分の道を見つける必要があります。これは、ローカルトラッカー事前に、又はネットワークプロキシのP2P要求のパスのアプローチを介してグローバルトラッカに登録オフパス、明示的な機構を介して達成することができます。オフパストラッカーフォーマットアプローチは、性能および信頼性の理由から好ましいです。
Inasmuch as the multi-layer scheme might require ISPs to aid peers in finding optimal paths to unauthorized copies of copyrighted content, ISPs may be concerned about the legal liability of participating.
多層方式は、著作権のあるコンテンツの不正コピーに最適なパスを見つけるの仲間を支援するためのISPが必要な場合があります限り、ISPは、参加の法的責任を心配することがあります。
ISPs have a lot of knowledge about their networks: everything from the bandwidth, geography, and service class of particular nodes to overarching routing policies, OSPF and BGP metrics, and distances to peering points. The ISP-aided neighbor selection service described below seeks to leverage this knowledge without requiring ISPs to reveal any information that could not already be discerned through reverse-engineering by client applications.
ISPは、彼らのネットワークに関する多くの知識を持っている：ポイントをピアリングに帯域幅、地域、および特定のノードのサービスクラスからの包括的なルーティングポリシー、OSPFやBGPメトリック、および距離に至るまで。下記のISP支援ネイバー選択サービスは、すでにクライアントアプリケーションによってリバース・エンジニアリングによって見分けることができませんでした任意の情報を明らかにするISPを必要とせずに、この知識を活用することを目指しています。
The service consists of an "oracle" hosted by an ISP. The oracle receives a list of IP addresses from a network node, sorts the list according to its own confidential criteria, and returns the sorted list to the node. The peer ranking provided by the oracle could be viewed as a special case of the virtual cost interface described in the previous section.
サービスは、ISPによってホストされている「神託」で構成されています。オラクルは、ネットワークノードからIPアドレスのリストを受け取り、自身の機密基準に従ってリストをソートし、ノードにソートされたリストを返します。オラクルが提供するピア・ランキングは、前のセクションで説明した仮想コストインターフェースの特別な場合とみなすことができます。
This service could be used by P2P clients or trackers, or by any other application that would benefit from learning its ISP's connection preferences. The oracle could be run as a web server or UDP service at a known location (perhaps similar to BIND).
このサービスは、P2Pクライアントやトラッカー、またはそのISPの接続設定を学ぶの恩恵を受ける他のアプリケーションで使用することができます。 Oracleは（バインドするために、おそらく似た）既知の場所にあるWebサーバまたはUDPサービスとして実行することができます。
For interdomain ranking, an ISP could rank its own peers first, or it could base its ranking on the AS number of the IPs in the provided list. Another option would be for multiple ISPs to work together to have their oracles exchange lists with each other.
ドメイン間のランキングのために、ISPはまず、自身のピアをランク付けすることができ、またはそれは、提供されたリストにあるIPアドレスのAS番号にその順位を基づかことができます。別のオプションは、お互いに自分の神託の交換リストを持っているために協力するために、複数のISPのためになります。
The main challenge in implementing the oracle service is scalability. If peers need to communicate to the oracle the IP address of every peer they know, the size of oracle requests may be inordinately large. Additionally, today's largest swarms approach 10000 peers, and with every peer requesting a sorted list, the oracle request volume will swell. With the growth of business models dependent upon P2P for distribution of content, swarms in the future may be far larger, further exacerbating the problem. Potential mitigations include having trackers, instead of peers, issue oracle requests, and using other peers' sorted lists as input, rather than always using an unsorted list.
Oracleサービスを実装する際の主な課題は、スケーラビリティです。ピアはオラクルに彼らが知っているすべてのピアのIPアドレスを通信する必要がある場合は、Oracleの要求のサイズが異常に大きいかもしれません。さらに、今日の最大の群れは10000のピアに近づくと、すべてのピアがソートされたリストを要求すると、Oracleの要求量が膨潤します。コンテンツの配信のためのP2Pに依存したビジネスモデルの成長とともに、将来の群れは、問題をさらに悪化させ、はるかに大きくてもよいです。潜在的な緩和策は、入力として他のピアのソートされたリストを使用して、というよりも常にソートされていないリストを使用したトラッカー、代わりのピア、発行オラクルの要求などがあります。
On the other hand, this approach is advantageous from a legal liability perspective, because it does not require ISPs to have any knowledge of where particular content might be located or to have any role in directing peers to particular content.
それは特定のコンテンツが配置される可能性がありますどこのいずれかの知識を持っているか、特定のコンテンツへのピアを向けるのいずれかの役割を持っているのISPを必要としないので、一方で、このアプローチは、法的責任の観点から有利です。
Deploying caches as peers in P2P networks was suggested as a component of multiple proposals put forth at the workshop. Caches may help to ease network load by reducing the need for peers to upload to each other and by localizing traffic.
P2Pネットワークにおけるピアは、ワークショップで出す複数の提案の構成要素として提案されたようにキャッシュを展開します。キャッシュは、ピアがお互いにアップロードするための必要性を減らすことによって、トラフィックをローカライズすることにより、ネットワークの負荷を軽減するのを助けることができます。
The two main concerns about P2P caches relate to network capacity and legal liability. For caches to be useful, they will likely need to be large (one suggestion was that a 1 TB cache could service 30% of requests within a single AS, and a 100 TB cache could service 80% of requests). Large caches will require sizable bandwidth in order to avoid contention among peers. Caches would not be usefully placed within an HFC network on a cable system, for example.
P2Pのキャッシュに関する二つの主な関心事は、ネットワーク容量と法的責任に関連しています。キャッシュが有用であるために、彼らはおそらく（1つの提案は、1 TBのキャッシュは、単一のAS内の要求の30％にサービスを提供でき、100 TBのキャッシュが要求の80％にサービスを提供するということでした）大きなものにする必要があります。大きなキャッシュは、ピア間の競合を避けるために、かなりの帯域幅を必要とします。キャッシュが有効例えば、ケーブルシステムにHFCネットワーク内に配置されないであろう。
The legal liability attached to hosting a P2P cache likely reduces the incentives to do so. Even under legal regimes where liability for caching may be unclear, ISPs and others may view hosting a cache as too great of a legal risk to be worthwhile.
P2Pのキャッシュをホストに接続法的責任はおそらくそうするインセンティブを減らします。でも、キャッシングのための責任が不明確かもしれ法制度の下で、ISPや他の人が価値があるために法的リスクの大きすぎるとして、キャッシュをホストしている見ることができます。
Much of the localization work discussed at the workshop is still in its initial stages, and many questions remain about the value that localization provides for varying network and overlay architectures. More data is needed to evaluate the effects on both traffic load and client performance. Understanding swarm distributions is important; swarms with long tails may not particularly benefit from localization.
ワークショップで議論ローカライズ作業の多くは、その初期段階にまだある、と多くの疑問が局在がネットワークとオーバーレイアーキテクチャを変えるために提供する価値についてのまま。より多くのデータは、トラフィック負荷とクライアントのパフォーマンスの両方の効果を評価するために必要とされます。群れの分布を理解することは重要です。長い尾を持つ群れは特にローカライズの恩恵を受けないかもしれません。
Against this backdrop, the key task for the IETF (as identified at the workshop) is to pinpoint incrementally beneficial work items in the spaces discussed above. In the future, it may be possible to standardize entire P2P mechanisms but, as a starting point, it makes more sense to single out core manageable components for standardization. The focus should be on items that are not so specific to one ISP or P2P network that standardization is rendered useless. Ideally, any mechanisms resulting from this work might apply to future applications that exhibit the same bandwidth-intensive properties as today's P2P file-sharing.
この背景に、IETFのための重要な課題は、（ワークショップで識別される）上述の空間における増分有益な作業項目を特定することです。将来的には、出発点として、それは標準化のためのコア管理コンポーネントを選び出すために、より理にかなって、全体P2Pメカニズムを標準化することが可能でなくてもよいです。焦点は、標準化が役に立たなくされるものISPまたはP2Pネットワークにそれほど特異的ではない項目になければなりません。理想的には、この作業に起因するいかなるメカニズムは、今日のP2Pファイル共有と同じ帯域幅集約型の特性を示す将来のアプリケーションに適用される場合があります。
In considering any of these items, it will be necessary to ensure that the information exchanged by networks and applications does not harm any of the parties involved. Not every piece of information exchanged will be beneficial or verifiable, and this fact must be recognized and accounted for. Solutions that leave applications or networks worse off than they already are today will not gain any traction.
これらの項目のいずれかを考えると、ネットワークとアプリケーションによって交換される情報は、当事者のいずれかに害を与えないことを確認する必要があります。交換される情報のないすべての部分は有益であるか、または検証になり、この事実を認識して考慮しなければなりません。彼らはすでに、今日よりもオフのアプリケーションやネットワークより悪いを離れソリューションは、任意のトラクションを得ることはありません。
It should also not be assumed that a particular party will be best suited to provide a particular kind of information. For example, an ISP may not know what the connection costs are in other ISPs' networks, whereas an overlay network that receives cost information from several ISPs may have a better handle on this kind of data. Standardization of information sharing should not assume the identity of particular parties doing the sharing.
また、特定の当事者が情報の特定の種類を提供するために最も適していると想定するべきではありません。たとえば、ISPは、いくつかのISPからの情報を受け取り、コストオーバーレイ・ネットワークは、この種のデータに優れたハンドルを有していてもよく、一方、接続コストは、他のISPのネットワークにあるのか分からないかもしれません。情報共有の標準化は、共有を行う特定の政党のアイデンティティを仮定するべきではありません。
The list of potential work items discussed at the workshop is provided below. Workshop participants showed particular interest in pursuing the first three items further.
ワークショップで議論潜在的な作業項目のリストを以下に示します。ワークショップの参加者は、さらに最初の3つの項目を追求する上で特に関心を示しました。
P2P clients are currently reliant on IP-to-AS mapping tables when they want to determine AS numbers. Providing a standard, easier way for clients to obtain this information may help to make peer selection more efficient on certain networks.
彼らはAS番号を決定したいときP2Pクライアントは、現在、IP-に-ASマッピングテーブルに依存しています。この情報を取得するためのクライアントのための標準的な、簡単な方法を提供することは、特定のネットワーク上のピア選択をより効率的にするのを助けることができます。
In situations where a peer or tracker can make requests in real time to a service that expresses its ISP's peering preferences, standardizing a format for requests and responses may be useful. The focus would be on the communication of the information, not on the criteria used to decide preferences. The information provided to peers would have to be crafted to ensure that it protects the privacy of other peers and safeguards proprietary network information.
ピアまたはトラッカーは、そのISPのピアリング好みを表現したサービスにリアルタイムで要求を行うことができます状況では、要求と応答のためのフォーマットを標準化することは有用である可能性があります。焦点はない嗜好を決定するために使用される基準について、情報の通信になります。ピアに提供される情報は、それが他のピアとの保障措置独自のネットワーク情報のプライバシーを保護することを保証するために細工されなければなりません。
With the deployment of trackers, iTrackers, oracles, or other mechanisms that provide some information specific to a node's locality, nodes will need a way to find these resources. One task for the IETF could be to explore a way to do discovery, potentially by leveraging an existing discovery protocol (DNS, DHCP, anycast, etc.). Depending on the resource to be discovered, discovery may require only a simple look-up, or it may require a more complex determination of which resource is "closest" to the node issuing the request.
トラッカー、iTrackers、神託、またはノードの地域に固有の情報を提供する他のメカニズムの展開では、ノードは、これらのリソースを見つける方法が必要になります。 IETFのための一つの課題は、既存の発見プロトコル（DNS、DHCP、エニーキャスト、など）を活用することで、潜在的に、発見を行うための方法を模索することであろう。発見されたリソースに応じて、発見は、単純なルックアップが必要な場合があり、またはそれは、要求を発行するノードに「最も近い」とするリソースのより複雑な決意が必要な場合があります。
Where ISP subscribers are bound by network usage policies or volume-based quotas, it may be useful to have a standard way of communicating the subscriber's current usage status. This would be similar to information about how many minutes of cell phone airtime are left in a subscriber's billing cycle. Applications could use this information to make decisions about when and how to transfer data. One challenge in implementing such a standard would be support for potentially limitless different ISP business models. The level of granularity that an ISP is able to provide may also be constrained depending on the pricing model and how dynamic the information is expected to be.
ISPの加入者は、ネットワークの使用ポリシーまたはボリュームベースのクォータに拘束されている場合、加入者の現在の使用状況を通信する標準的な方法を持っていることが有用であり得ます。これは、携帯電話の放送時間の何分は、加入者の請求サイクルに残されている方法に関する情報と同様です。アプリケーションは、データを転送する際に、どのようにについての決定を行うために、この情報を使用することができます。こうした標準を実装する際の1つの課題は、潜在的に無限の異なるISPのビジネスモデルをサポートするだろう。 ISPが提供することができる粒度のレベルはまた、価格決定モデルとどのように動的な情報があると予想されるに応じて拘束されてもよいです。
A multi-layered tracker approach could potentially be aided by a standard tracker format for re-directing from a global tracker to a local tracker. While the extent to which existing trackers will be willing to consult with other trackers is unclear, the re-direction format may have an analog in another context -- many HTTP servers build their own indexes of mirror information for a similar purpose, though these are not standardized. If the two problem spaces prove to be similar enough, there may be room to standardize a format across both.
多層追跡アプローチは、潜在的にローカルトラッカーにグローバルトラッカから再指向するための標準的なトラッカー形式によって支援することができます。これらはあるけれども、多くのHTTPサーバは、同様の目的のために、ミラー情報の独自のインデックスを構築する - 既存のトラッカーは、他のトラッカーと相談することをいとわないする程度は不明であるものの、再方向形式は、別のコンテキストでアナログを有することができます標準化されていません。 2つの問題のスペースが十分に類似であることを証明する場合は、両方の間でフォーマットを標準化する余地があるかもしれません。
One recent informal survey presented at the workshop found that ISPs perceive traffic volumes from heavy users to be a problem, but no single congestion management tool has been put to wide use. Within developer and research communities, congestion issues raised by increased P2P traffic volumes have spurred new thinking about congestion-control mechanisms at both the transport layer and the application layer. The subsections below explore some of these new ideas and highlight areas where IETF work may be appropriate.
ワークショップで発表された最近の非公式の調査では、ISPが問題にヘビーユーザーからのトラフィック量を知覚が、単一の輻輳管理ツールが幅広い用途に利用されていないことがわかりました。開発者や研究コミュニティの中で、増加したP2Pトラフィック量が提起した渋滞の問題は、トランスポート層とアプリケーション層の両方での輻輳制御機構についての新しい思考に拍車をかけています。以下のサブセクションでは、IETF作業が適切な場合があり、これらの新しいアイデアやハイライト領域のいくつかを探ります。
As noted previously, uptake in P2P usage can result in perceptible end-user latency on the order of seconds for interactive applications. One approach to resolving this "round-trip time (RTT) in seconds" problem would be for P2P clients to implement better congestion control that keeps the bottleneck full while yielding to keep the delay of competing traffic low. Such an algorithm has been implemented in BitTorrent's client by continuously sampling one-way delay (separating propagation from queuing delay) and targeting a small queuing delay value. This essentially approximates a scavenger service class in an end-to-end congestion-control mechanism by forcing bulk, elastic traffic to yield to competitors under congestion.
先に述べたように、P2Pの使用における取り込みは、インタラクティブなアプリケーションのための秒のオーダーの知覚エンドユーザーの待ち時間が発生することができます。一つのアプローチ「秒でラウンドトリップ時間（RTT）」これを解決する問題は、トラフィックの低い競合の遅延を維持するために得ながらフルボトルネックを維持し、より良い輻輳制御を実装するためにP2Pクライアントのためになります。このようなアルゴリズムは、連続的に（キューイング遅延から伝播を分離する）一方向遅延をサンプリングし、小さなキューイング遅延値を標的化することによってビットトレントのクライアントに実装されています。これは、本質的に輻輳下で競合に得バルク弾性トラフィックを強制することによって、エンドツーエンドの輻輳制御機構におけるスカベンジャーサービスクラスを近似します。
In a similar vein, the P4P framework supports a component that allows applications to mark traffic as "bulk data" (not time sensitive). Applications adjust their behavior according to the feedback they receive from such markings.
同様の静脈では、P4Pのフレームワークは、アプリケーションが「バルクデータ」（小文字を区別しない時間）としてトラフィックをマーキングすることを可能にするコンポーネントをサポートします。アプリケーションは、彼らがそのようなマーキングから受け取ったフィードバックに基づいて彼らの行動を調整します。
Experimenting with the standardization of these kinds of techniques or any congestion-control framework with design goals that differ from those of TCP may be helpful work for the IETF to pursue.
技術のこれらの種類の標準化で実験やTCPのものとは異なる設計目標を持つ任意の輻輳制御フレームワークは、追求するIETFのために役立つ仕事かもしれません。
Congestion control has typically been implemented at a protocol level as an optional, cooperative effort between endpoints experiencing congestion, but in looking for a long-term approach to congestion control, we may need a more rigorous way for available bandwidth to be allocated by and between the hosts using a network. The idea behind weighted congestion control is to allow hosts to give more weight to interactive applications during times of congestion.
輻輳制御は、一般的に輻輳を経験して、エンドポイント間の任意の、共同作業などのプロトコルレベルで実装されていますが、輻輳制御への長期的なアプローチを探しに、我々はによってとの間で割り当てられる使用可能な帯域幅のためのより厳密な方法を必要とするかもしれませんネットワークを使用しているホスト。加重輻輳制御の背後にある考え方は、ホストが輻輳時にインタラクティブなアプリケーションへのより多くの重みを与えることを可能にすることです。
Comparing such an approach with Diffserv showcases its strengths and weaknesses. Unlike Diffserv, weighted congestion control could be implemented on hosts with a simple extension to socket APIs (although consensus among OSes would be necessary for portability). Through weighted congestion control, control resides with the host, whereas even when Diffserv APIs are available, it is difficult for a host to know that the network is complying with its classifications. With weighted congestion control, hosts need some disincentive to setting their weights at maximum levels, whereas Diffserv was not designed for individual users to employ. Both approaches must rely on traffic senders to set policies, meaning that the congestion issues stemming from P2P use on the receiver side are not aided by either mechanism.
Diffservので、このようなアプローチを比較すると、その長所と短所を紹介しています。 Diffservのとは異なり、重み付けされた輻輳制御（のOS間でコンセンサスが移植のために必要であろうが）APIをソケットする単純な拡張でホスト上で実施することができます。 DiffservのAPIが用意されていた場合でも、ホストがネットワークがその分類に準拠していることを知っているため、それが困難であるのに対し、加重輻輳制御により、制御は、ホストとの常駐します。加重輻輳制御では、ホストはDiffservのが採用する個々のユーザーのために設計されていなかったのに対し、最高のレベルでその重みを設定するにはいくつかの阻害要因を必要としています。両方のアプローチは、受信側のP2Pの使用に起因する輻輳問題はどちらかのメカニズムによって支援されていないことを意味し、ポリシーを設定するには、トラフィックの送信者に依存する必要があります。
With Diffserv, a light user may waste his or her priority connecting to a heavy user on another network, which is not a problem with host-controlled weighting.
Diffservのでは、ライトユーザーには、ホスト制御の重み付けの問題ではありません別のネットワーク上のヘビーユーザーに接続する彼または彼女の優先順位を浪費することがあります。
Weighted congestion control is just one example of a generalized set of features that characterize useful approaches to congestion control. These characteristics include full user control of priorities within a user's own scope and no possibility of interpreting ISP behavior as discriminatory. The former means that ISPs should not override user decisions arbitrarily (though this does not preclude an ISP from offering prioritization as an option). The latter means that the metric for decision-making needs to obviate suspicion of ISP motivations.
加重輻輳制御は、輻輳制御に有用なアプローチを特徴付ける特徴の一般化されたセットのほんの一例です。これらの特性は、完全なユーザー、ユーザー自身のスコープ内の優先順位の制御と差別としてISPの行動を解釈するのがない可能性があります。前者は（これはオプションとして優先順位付けを提供するからISPを妨げるものではないが）ISPがユーザーが任意の決定をオーバーライドしてはならないことを意味します。後者は、意思決定のためのメトリックは、ISP動機の疑いを回避する必要があることを意味します。
One metric that meets these criteria is a harm (cost) metric, where cost is equal to the amount of data that was not served to its destination. Using this metric, cost is greatest when traffic peaks are greatest. It allows for a policy of not sending too much data during times of congestion, without specifying exactly how much is too much. The cost metric could be used either for a Diffserv approach or for weighted congestion control.
これらの基準を満たす1つのメトリックは、コストがその宛先に配信されなかったデータの量に等しいメトリック害（コスト）、です。このメトリックを使用して、コストは、トラフィックのピークが最大のとき最大です。それはあまりにもどのくらい正確に特定することなく、輻輳時にあまりにも多くのデータを送信しないという方針が可能になります。コストメトリックは、Diffservのアプローチのためにまたは加重輻輳制御のためにも使用することができます。
One important limitation on ISPs from a congestion-control perspective is that they do not have a window into congestion on other ISPs' networks. Solving this problem requires a separate mechanism to express congestion across domains.
輻輳制御の観点からのISPの一つの重要な制限は、彼らが他のISPのネットワーク上の混雑にウィンドウを持っていないということです。この問題を解決するドメイン間での輻輳を表現する別のメカニズムを必要とします。
One potential avenue for the IETF or IRTF to pursue would be to establish a long-term design team to assess congestion problems in general and the long-term effects of any proposed quick fixes. These issues are not necessarily confined to P2P and should be viewed in the broader context of massive increases in bandwidth use.
追求するIETFかIRTFのための一つの可能性の道は、一般的に輻輳問題と任意の提案クイックフィックスの長期的影響を評価するための長期的な設計チームを確立することです。これらの問題は、必ずしもP2Pに限定されず、使用帯域幅の大幅な増加のより広い文脈で見るべきです。
Although ISPs have implemented a wide variety of short-term approaches to dealing with congestion, several of these may not be viable in the long term. For example, some ISPs have found that using deep packet inspection to change the delivery characteristics of certain traffic at times of congestion is more cost effective than adding additional bandwidth. Over time, this approach could lead to a cat-and-mouse game where applications providers continually adapt to avoid being correctly classified by Deep Packet Inspection (DPI) equipment. Similarly, ISPs implementing traffic analysis to identify P2P traffic may find that, in the long run, the overhead required of an effective classification scheme will be excessive.
ISPが混雑に対処する短期的なアプローチを幅広く実施しているが、これらのいくつかは、長期的に実行可能ではないかもしれません。例えば、いくつかのISPは、混雑の時間に特定のトラフィックの送達特性を変更するためにディープパケットインスペクションを使用すると、追加の帯域幅を追加するよりも費用効果的であることを見出しました。時間が経つにつれて、このアプローチは、アプリケーションプロバイダは継続的に正しくディープパケットインスペクション（DPI）機器によって分類されるのを避けるために適応いたちごっこにつながる可能性があります。同様に、P2Pトラフィックを識別するために、トラフィック分析を実行するISPは、長期的には、効果的な分類スキームの必要なオーバーヘッドが過剰になる、ということかもしれません。
Quality of service (QoS) arrangements may be more suitable in the long term. One approach that distinguishes certain classes of traffic during times of congestion was described in Section 3.3. A standardized mechanism that may be useful for implementing QoS is Differentiated Services Code Points (DSCP) [RFC2474].
サービスの品質（QoS）の構成が長期的にはより適している可能性があります。輻輳時に特定のトラフィッククラスを区別する一つの方法は、3.3節で説明しました。 QoSを実装するために有用であり得る標準化機構は、差別化サービスコードポイント（DSCP）[RFC2474]です。
With DSCP, devices at the edge of the network mark packets with the service level they should receive. Nodes within the network do not need to remember anything about service flows, and applications do not need to request a particular service level. Users effectively avoid self-interference through service classification.
DSCPを使用すると、サービス・レベルとネットワークマークパケットの端のデバイスは、彼らが受け取るべきです。ネットワーク内のノードはサービスフローについては何も覚えておく必要はありませんし、アプリケーションは、特定のサービス・レベルを要求する必要はありません。ユーザーは効果的にサービスの分類による自己干渉を避けます。
Although DSCP may have many uses, perhaps the most relevant to the P2P congestion issue is its ability to facilitate usage-based charging. User pricing agreements that charge a premium for real-time traffic and best-effort traffic could potentially shape user behavior, resulting in reduced congestion (although ISPs would need a mechanism to mitigate the risk of charging subscribers for things like unintentional malware downloads or DoS attacks). DSCP could also be used to limit a user's supply of high-priority bandwidth, resulting in a similar effect.
DSCPは、多くの用途を持っているかもしれないが、おそらくP2Pの輻輳の問題に最も関連が使用量ベースの充電を促進する能力です。潜在的にISPが意図しないマルウェアのダウンロードやDoS攻撃のようなもののために加入者を充電するリスクを軽減するための仕組みが必要になりますが、（縮小混雑で、その結果、ユーザの行動を形作ることができ、リアルタイムのトラフィックとベストエフォートトラフィックのための保険料を課金ユーザー価格協定）。 DSCPも同様の効果が得られ、優先度の高い帯域幅のユーザの供給を制限するために使用することができます。
Equipment to support DSCP is already available. Although there has been some concern about a perceived lack of DSCP deployment, it is widely used by enterprise customers, and growth has been strong due to uptake in VoIP at the enterprise level.
DSCPをサポートするための機器はすでに利用可能です。 DSCP展開の認知不足に関するいくつかの懸念があったが、それは広く、企業の顧客によって使用され、成長が企業レベルでのVoIPにおける取り込みに起因する強いてきました。
However, DSCP still faces deployment hurdles on many networks. Perhaps the largest barrier of all to wide deployment is the lack of uniform code points to be used across networks. For example, the latest Windows Vista API marks voice traffic as CS7, above the priority reserve for router traffic. To properly take advantage of this change, every switch will need to re-mark all traffic. In addition, disparate ISPs are currently without a means of verifying each others' markings and thus may be unwilling to trust the markings they receive.
しかし、DSCPはまだ多くのネットワーク上で展開ハードルに直面しています。おそらく、幅広い展開にすべての最大の障壁は、ネットワーク全体で使用する均一なコードポイントの欠如です。たとえば、Windows Vistaの最新のAPIは、ルータトラフィックの優先予約の上、CS7として音声トラフィックをマーク。適切にこの変更を利用するには、すべてのスイッチはすべてのトラフィックをマークし直す必要があります。加えて、異なるISPは互いのマーキングを検証する手段なしに、現在であり、従って、それらが受信マーキングを信頼するように不本意であってもよいです。
The workshop discussions about P2P congestion spurred a related discussion about applications (P2P or otherwise) that open multiple TCP connections. With multiple users sharing one link, TCP flow fairness gives users with multiple open connections a larger proportion of bandwidth. Since some P2P protocols use multiple open connections for a single file transfer and users often pursue multiple transfers at once, this can cause a P2P user to have many more open connections at once than other users on the same link. The same is true for users of other applications that open multiple connections. A single user with multiple open connections is not necessarily a problem on its face, but the fact that fairness is determined per flow rather than per user leaves that impression. Workshop participants thought it may be useful for the IETF to provide some information about such situations.
P2Pの混雑についてのワークショップでの議論は、複数のTCP接続を開くアプリケーション（P2Pまたはそれ以外）についての関連の議論に拍車をかけました。複数のユーザが一つのリンクを共有すると、TCPフローの公平性が複数開いている接続の帯域幅の大きな割合をユーザーに提供します。いくつかのP2Pプロトコルは、単一のファイル転送とユーザーのための複数のオープン接続を使用しているので、一度に複数の転送を追求し、多くの場合、これは、同じリンク上の他のユーザーよりも一度に多くのより多くのオープン接続を持っているP2Pユーザーを引き起こす可能性があります。同じことが、複数の接続を開く他のアプリケーションのユーザーのために真です。複数のオープン接続を持つ単一のユーザーは、必ずしもその顔に問題はありませんが、公平性フローごとではなく、ユーザーごとに決定されるという事実は、その印象を残します。ワークショップの参加者は、それがこのような状況に関するいくつかの情報を提供するために、IETFのために有用であるかもしれないと思いました。
Workshop participants expressed diverging opinions about how much the cost of transferring data -- as experienced by ISPs and, by extension, their subscribers -- should factor into IETF thinking on P2P traffic issues.
P2Pトラフィックの問題に関するIETF思考に考慮すべきである - のISPが経験したように、拡張により、加入者 - ワークショップの参加者は、どのくらいのデータを転送するコストについての発散の意見を表明しました。
On one hand, bandwidth costs may be significant, even when viewed in isolation from congestion issues. Some estimates put the total cost of shipping 1 GB between $0.10 and $2. The cost of transit bandwidth in markets where subscribers are charged flat rates appears to have leveled off and may no longer be getting cheaper. Thus, it may be reasonable to expect more service providers to move to volume-based pricing (where they have not already done so) as a means to control congestion and increase revenues. This is only feasible if bandwidth consumption is visible to end users, which argues for some mechanism of exposing quotas and usage to applications. However, expressing cost information may be outside of the technical purview of the IETF.
一方で、帯域幅のコストは、輻輳の問題から切り離して見ても、重要となり得ます。いくつかの見積もりは$ 0.10から$ 2との間で1ギガバイトの出荷の総コストを置きます。加入者が定額料金を請求されている市場でのトランジット帯域幅のコストは横ばいしているように見え、もはや安くなってないかもしれません。このように、より多くのサービスプロバイダーが混雑して増加収入を制御する手段として、（彼らはまだ行っていない）ボリュームベースの価格設定に移動することを期待するのが妥当かもしれません。これは、帯域幅の消費がアプリケーションにクォータおよび使用を露出させるいくつかのメカニズムを主張れ、エンドユーザーに表示されている場合にのみ可能です。しかしながら、コスト情報を発現するIETFの技術的範囲の外であってもよいです。
On the other hand, congestion can be viewed merely as a manifestation of cost. An ISP that invests in capacity could be considered to be paying to relieve congestion. Or, if subscribers are charged for congesting the network, then cost and congestion could be viewed as one and the same. The distinction between them may thus be artificial.
一方、輻輳がコストの現れとしてのみ見ることができます。能力に投資ISPは、混雑を緩和するために支払うことを考えることができます。加入者は、ネットワークを混雑のために充電されている場合は、その後、コストと混雑は1と同じと見ることができます。それらの間の区別は、このように人工的かもしれません。
Workshop participants felt that the issues highlighted here may be useful fodder for IRTF work.
ワークショップの参加者は、ここで強調表示の問題はIRTFの仕事のために有用飼料であり得ることを感じました。
The IETF community recognizes the significance of both increasing P2P traffic volumes and network load at large. The importance of addressing the impact of high-volume, delay-tolerant data transfer on end-user experiences was highly apparent at the workshop.
IETFコミュニティは大で増加P2Pトラフィック量とネットワーク負荷の両方の重要性を認識しています。大容量の影響に対処することの重要性は、エンドユーザエクスペリエンスに遅延耐性データ転送は、ワークショップで非常に明らかでした。
At the conclusion of the workshop and in the days following, it became clear that the largest areas of interest fell into two categories: transport-related issues and improved peer selection.
輸送関連の問題や改善ピア選択：ワークショップの最後に、次の日に、それは関心の最大の領域を2つのカテゴリに落ちたことが明らかになりました。
Two main transport-related work items evolved out of the workshop. The first was the creation of a standardized, delay-based, end-to-end congestion-control mechanism that applications such as P2P clients could use to reduce their own impact on interactive applications in use on shared links (as described in Section 5.2.1). The second was an informational document that describes the current practice of P2P applications opening multiple transport connections and that makes recommendations about the best practices for doing so (as discussed in Section 6).
二つの主要な輸送関連の作業項目は、ワークショップの外に発展しました。最初は、P2Pクライアントのようなアプリケーションは、セクション5.2で説明したように（共有リンク上で使用されているインタラクティブなアプリケーションに独自の影響を低減するために使用することができる標準化され、遅延に基づく、エンドツーエンドの輻輳制御メカニズムの作成でした。 1）。第二は、複数の交通機関の接続を開くP2Pアプリケーションの現在の練習を説明し、それが（第6節で述べたように）そのようにするためのベストプラクティスについての勧告を行う情報提供文書でした。
Participants expressed strong interest in further pursuing the range of concepts described in Section 5.1 that support mechanisms for information sharing between networks and applications to help improve peer selection. Adding to the appeal of this topic is its potential utility for applications other than P2P that may also benefit from information about the network. Because the scope of potential solutions discussed at the workshop was broad, extracting out the most feasible pieces to pursue is the necessary first step.
参加者はさらにピア選択を改善するためのネットワークとアプリケーションとの間での情報共有のためのメカニズムをサポートセクション5.1で説明した概念の範囲を追求に強い関心を表明しました。このトピックの魅力に追加することも、ネットワークに関する情報から利益を得ることができるP2P以外の用途のためにその潜在的なユーティリティです。ワークショップで議論潜在的な解決策の範囲が広いたので、追求するために最も可能片を抽出する必要が最初のステップです。
The workshop discussions covered a range of potential engineering activities, each with its own security considerations. For example, if networks are to provide preference or topology information to applications, the applications may desire some means of verifying the authenticity of the information. As the IETF community begins to pursue specific avenues arising out of this workshop, addressing relevant security requirements will be crucial.
ワークショップでの議論は、独自のセキュリティ上の考慮事項とそれぞれの潜在的なエンジニアリング活動の範囲をカバーしました。ネットワークは、アプリケーションに優先またはトポロジ情報を提供することである場合、例えば、アプリケーションが情報の真正性を検証する手段を望むかもしれません。 IETFコミュニティがこのワークショップから生じる特定の道を追求し始めると、関連するセキュリティ要件に対処することは非常に重要になります。
The IETF would like to thank MIT, which hosted the workshop, and all those people at MIT and elsewhere who assisted with the organization and logistics of the workshop.
IETFは、ワークショップを開催しましたMIT、およびワークショップの組織化と物流を支援し、すべての人々MITで、他の場所に感謝したいと思います。
The IETF is grateful to the program committee (listed in Appendix A) for their time and energy in organizing the workshop, reviewing the position papers, and crafting an event of value for all participants. The IETF would also like to thank the scribes, Spencer Dawkins and Alissa Cooper, who diligently recorded the proceedings during the workshop.
IETFは、ワークショップの整理ポジションペーパーを見直して、すべての参加者のために価値のイベントを作り上げる中に自分の時間とエネルギーのため（付録Aに記載されている）プログラム委員会に感謝しています。 IETFはまた、熱心にワークショップ中に議事録を記録した律法学者スペンサードーキンスとアリッサ・クーパーを、感謝したいと思います。
A special thanks to all the participants in the workshop (listed in Appendix B) who took the time, came to the workshop to participate in the discussions, and put in the effort to make this workshop a success. The IETF especially appreciates the effort of those that prepared and made presentations at the workshop.
時間がかかった（付録Bに記載されている）ワークショップ内のすべての参加者に特別な感謝は、議論に参加するワークショップに来て、このワークショップを成功させるための努力に置きます。 IETFは特に用意し、ワークショップでプレゼンテーションを行ったものの努力を高く評価しています。
[DOCSIS] CableLabs, "DOCSIS Specifications - DOCSIS 2.0 Interface", 2008, <http://www.cablemodem.com/specifications/ specifications20.html>.
[DOCSIS] CableLabsの、 "DOCSIS仕様 - DOCSIS 2.0インターフェイス"、2008年、<http://www.cablemodem.com/specifications/ specifications20.html>。
[P4P] Xie, H., Yang, Y., Krishnamurthy, A., and A. Silberschatz, "P4P: Provider Portal for Applications", August 2008, <http://uwnews.org/relatedcontent/2008/August/ rc_parentID43281_thisID43282.pdf>.
[P4P]謝、H.、ヤン、Y.、Krishnamurthy、A.、およびA. Silberschatz、 "P4P：アプリケーションのためのプロバイダポータル"、2008年8月、<http://uwnews.org/relatedcontent/2008/August/ rc_parentID43281_thisID43282.pdf>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
Appendix A. Program Committee
付録A.プログラム委員会
Dave Clark, MIT
デイブ・クラーク、MIT
Lars Eggert, TSV AD
ラースEggertのTSVのAD
Cullen Jennings, RAI AD
カレンジェニングス、RAI AD
John Morris, Center for Democracy and Technology
ジョン・モリス、民主主義と技術のためのセンター
Jon Peterson, RAI AD
ジョンピーターソン、RAI AD
Danny Weitzner, MIT
ダニーWeitzner、MIT
Appendix B. Workshop Participants
付録B.ワークショップ参加者
Vinay Aggarwal, Deutsche Telekom Labs, TU Berlin
ビナイアガルワル、ドイツテレコム研究所、TUベルリン
Marvin Ammori, Free Press
マービン・アモリ、フリー・プレス
Loa Andersson, Acreo AB
ロア・アンダーソン、Acreo AB
Jari Arkko, Ericsson
ヤリArkko、エリクソン
Alan Arolovitch, PeerApp
アランArolovitch、PeerApp社
Timothy Balcer
ティモシーBalcer
Mary Barnes, Nortel
メアリー・バーンズ、ノーテル
Colby Barth, Cisco Systems
コルビーバース、シスコシステムズ
John Barlett, NetForecast
ジョン・バートレット、ネット予測
Salman Baset, Columbia University
サルマンBASET、コロンビア大学
Chris Bastian, Comcast
クリス・バスティアン、コムキャスト
Matthew Bell, Charter Communications
マシュー・ベル、チャーター・コミュニケーションズ
Donald Bowman, Sandvine Inc.
ドナルド・ボウマン、Sandvine社（株）
Scott Bradner, Harvard University
スコット・ブラッドナー、ハーバード大学
Bob Briscoe, British Telecom
ボブ・ブリスコー、ブリティッシュテレコム
David Bryan, SIPeerior Technologies
デヴィッド・ブライアン、SIPeeriorテクノロジーズ
Rex Bullinger, National Cable & Telecommunications Association
レックスブリンガー、ナショナルケーブル＆テレコミュニケーション協会
Gonzalo Camarillo, Ericsson
ゴンサロ・カマリロ、エリクソン
Mary-Luc Champel, Thomson
メアリー・リュックChampel、トムソン
William Check, NCTA
ウィリアム・チェック、NCTA
Alissa Cooper, Center for Democracy and Technology
アリッサ・クーパー、民主主義と技術のためのセンター
Patrick Crowley, Washington University
パトリック・クローリー、ワシントン大学
Leslie Daigle, Internet Society
レスリーDaigle氏、インターネット協会
Spencer Dawkins
スペンサー・ドーキンス
John Dickinson, Bright House Networks
ジョン・ディキンソン、ブライトハウスネットワークス
Lisa Dusseault, CommerceNet
リサDusseault、CommerceNet
Lars Eggert, Nokia Research Center
ラースエッゲルト、ノキア・リサーチセンター
Joe Godas, Cablevision
ジョー・ビフ、ケーブルビジョン
Vernon Groves, Microsoft
バーノングローブス、マイクロソフト
Daniel Grunberg, Immedia Semiconductor
ダニエルGrunberg、Immediaセミコンダクター
Carmen Guerrero, University Carlos III Madrid
カルメンゲレロ、大学カルロスIIIマドリード
Vijay Gurbani, Bell Laboratories/Alcatel-Lucent
ビジェイGurbani、ベル研究所/アルカテル・ルーセント
William Hawkins III, ITT
ウィリアム・ホーキンスIII、ITT
Volker Hilt, Bell Labs, Alcatel-Lucent
フォルカー柄、ベル研究所、アルカテル・ルーセント
Russell Housley, Vigil Security, LLC
ラッセルHousley氏、ビジルセキュリティ、LLC
Robert Jackson, Camiant
ロバート・ジャクソン、Camiant
Cullen Jennings, Cisco Systems
カレンジェニングス、シスコシステムズ
Paul Jessop, RIAA
ポール・ジェソップ、RIAA
XingFeng Jiang, Huawei
XING F工江は、HU Aは、
Michael Kelsen, Time Warner Cable
マイケル・ケルゼン、タイムワーナーケーブル
Tom Klieber, Comcast
トムKlieber、コムキャスト
Eric Klinker, BitTorrent Inc.
エリック・クリンカー、BitTorrentの株式会社
Umesh Krishnaswamy
Umesh Krishnaswamy
Gregory Lebovitz, Juniper
グレゴリーLebovitz、ジュニパー
Erran Li, Bell-Labs
李はベル研究所、言いました
Jason Livingood, Comcast
ジェイソンLivingood、コムキャスト
Andrew Malis, Verizon
アンドリューMalis、ベライゾン
Enrico Marocco, Telecom Italia Lab
エンリコモロッコ、テレコムイタリアラボ
Marcin Matuszewski, Nokia
マルチンMatuszewski、ノキア
Danny McPherson, Arbor Networks, Inc.
ダニー・マクファーソン、アーバーネットワークス株式会社
Michael Merritt, AT&T
マイケル・メリット、AT＆T
Lyle Moore, Bell Canada
ライル・ムーア、ベル・カナダ
John Morris, Center for Democracy and Technology
ジョン・モリス、民主主義と技術のためのセンター
Jean-Francois Mule, Cablelabs
ジャン=フランソワ・ミュール、CableLabsの
David Oran, Cisco Systems
デビッド・オラン、シスコシステムズ
Reinaldo Penno, Juniper Networks
レイナルドPenno、ジュニパーネットワークス
Jon Peterson, NeuStar
ジョンピーターソン、NeuStar
Howard Pfeffer, Time Warner Cable
ハワードPfefferの、タイムワーナーケーブル
Laird Popkin, Pando Networks
レアードPopkin、パンドネットワークス
Stefano Previdi, Cisco systems
スティーブンは、シスコシステムを予見しました
Satish Putta
少ししていました
Eric Pescorla
エリックPescorla
Benny Rodrig, Avaya
ベニーRodrig、アバイア
Damien Saucez, UCLouvain (UCL)
ダミアンSaucez、UCLouvain（UCL）
Henning Schulzrinne, Columbia University
ヘニングSchulzrinneと、コロンビア大学
Michael Sheehan, Juniper Networks
マイケル・シーハン、ジュニパーネットワークス
Don Shulzrinne, Immedia Semiconductor
ドンShulzrinne、Immediaセミコンダクター
David Sohn, Center for Democracy and Technology
デビッド・孫、民主主義と技術のためのセンター
Martin Stiemerling, NEC
マーティンStiemerling、NEC
Clint Summers, Cox Communications
クリント・サマーズ、コックス・コミュニケーションズ
Robert Topolski
ロバートTopolski
Mark Townsley, Cisco Systems
マークTownsley、シスコシステムズ
Yushun Wang, Microsoft
ゆしゅん わんｇ、 みｃろそｆｔ
Hao Wang, Yale University
H AO王、エール大学
Ye Wang, Yale University
Yエリトリア王、エール大学
David Ward, Cisco
デビッド・ウォード、シスコ
Nicholas Weaver, ICSI
ニコラス・ウィーバー、ICSI
Daniel Weitzner, MIT
ダニエル・ウェイツナー、MIT
Magnus Westerlund, Ericsson
マグヌスウェスター、エリクソン
Thomas Woo, Bell Labs
トーマス・ウー、ベル研究所
Steve Worona, EDUCAUSE
スティーブWoron、EDUCAUSE
Richard Woundy, Comcast
リチャードWoundy、コムキャスト
Haiyong Xie
X IE愛とH
Richard Yang, Yale University
リチャード・ヤン、エール大学
Appendix C. Workshop Agenda
付録C.ワークショップアジェンダ
1. Welcome/Note Well/Intro Slides Cullen Jennings
1.ようこそ/ウェル/イントロスライドカレンジェニングスに注意してください。
2. Service Provider Perspective (Comcast) Rich Woundy and Jason Livingood
2.サービスプロバイダの視点（コムキャスト）リッチWoundyとジェイソンLivingood
3. Application Designer Perspective (BitTorrent) Stanislav Shalunov
3.アプリケーションデザイナの視点（ビットトレント）スタニスラフ・シャルノブ
4. Lightning Talks & General Discussion Robb Topoloski Nick Weaver Leslie Daigle
4.ライトニングトーク＆一般的なディスカッションロブTopoloskiニック・ウィーバーレスリーDaigle氏
5. Localization and Caches Laird Popkin and Haiyong Xie Yu-Shun Wang Vinay Aggrawal
5.ローカライズとキャッシュレアードPopkinとHaiyong謝ゆう旬王ビナイAggrawal
6. New Approaches to Congestion Bob Briscoe Marcin Matuszewski
混雑ボブ・ブリスコーマルチンMatuszewski 6.新しいアプローチ
7. Quality of Service Mary Barnes Henning Schulzrinne
サービスメアリー・バーンズヘニングSchulzrinneとの7.品質
Appendix D. Slides and Position Papers
付録D.スライドとポジションペーパー
Slides and position papers are available at http:// trac.tools.ietf.org/area/rai/trac/wiki/PeerToPeerInfrastructure.
スライドとポジションペーパーは、httpで入手できます：// trac.tools.ietf.org/area/rai/trac/wiki/PeerToPeerInfrastructure。
Position papers:
ポジションペーパー：
Nick Weaver - The case for "Ugly Now" User Fairness
ニック・ウィーバー - 「アグリー今すぐ」ユーザー公平性を考慮した場合
Paul Jessop - Position paper of the RIAA
ポール・ジェソップ - RIAAのポジションペーパー
Nikloaos Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES: Edge Capacity Hosting Overlays of Nano Data Centers
Nikloaos Laotaris、パブロ・ロドリゲス、ローランMassoulie - ECHOES：ナノデータセンターのエッジ容量ホスティングオーバーレイ
Bruce Davie, Stefano Previdi, Jan Medved, Albert Tian - Peer Selection Guidance
ブルース・デイビー、ステファノPrevidi、ヤンMedved、アルバート・ティエン - ピア選択指針
Marie-Jose Montpetit - Community Networks: getting P2P out of prison - the next steps
マリー・ジョゼMontpetit - コミュニティネットワーク：刑務所の外にP2Pを取得 - 次のステップ
D. Bryan, S. Dawkins, B. Lowekamp, E. Shim - Infrastructure-related Attributes of App Scenarios for P2PSIP
D.ブライアン、S.ドーキンス、B. Lowekamp、E.シム - P2PSIPためのアプリケーションシナリオのインフラ関連の属性
Jiang XingFeng - Analysis of the Service Discovery in DHT network
江XingFeng - DHTネットワークにおけるサービス発見の分析
R. Penno - P2P Status and Requirements
R. Penno - P2Pステータスおよび要件
Patrick Crowley and Shakir James - Symbiotic P2P: Resolving the conflict between ISPs and BitTorrent through mutual cooperation
パトリック・クロウリーとShakirジェームズ - 共生P2P：相互の協力により、ISPやBitTorrentの間の紛争を解決します
Robb Topolski - Framing Peer to Peer File Sharing
ロブTopolski - ファイル共有をピアツーピアフレーミング
M. Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network Cooperative Overlay System
M. Stiemerling、S.ニッコリーニ、S.キーセル、J.セードルフ - ネットワーク協調オーバレイシステム
Y. Wang, S. Tan, R. Grove - Traffic Localization with Multi-Layer, Tracker-Based Peer-to-Peer Content Distribution Architecture
Y.王、S.タン、R.グローブ - マルチレイヤでのトラフィックのローカライゼーション、トラッカーベースのピアツーピアコンテンツ配信アーキテクチャ
Haiyong Xie, Y. Richard Yang, Avi Silberschatz, Arvind Krishnamurthy, Laird Popkin - P4P: Provider Portal for P2P Applications
Haiyong謝、Y.リチャード・ヤン、アビSilberschatz、アービンドKrishnamurthy、レアードPopkin - P4P：P2Pアプリケーションのプロバイダポータル
Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly Peer-to-Peer Services
マイケル・メリット、ダグ・パスコ、レアードPopkin - ネットワークにやさしいピア・ツー・ピア・サービス
Camiant (Jackson) - Camiant Submission
Camiant（ジャクソン） - Camiant提出
Jason Livingood, Rich Woundy - Comcast Submission
ジェイソンLivingood、リッチWoundy - Comcastの提出
Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load Impact
ベニーRodrig - エンタープライズIPネットワークとP2Pトラフィック負荷の影響
Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences"
テッドハーディー - ピア・ツー・ピアトラフィックと「無人帰結」
Jiang XingFeng, Ning Zong - Content Replication for Internet P2P
江興鉄NG、NI Zああそのこと - インターネットのP2Pのコンテンツの複製
Applications
アプリケーション
Sandvine (Dundas) - Analysis of Traffic Demographics in Broadband networks
Sandvine社（ダンダス） - ブロードバンドネットワークのトラフィック人口統計の分析
Sandvine (Dundas) - Traffic Management in a World with Network Neutrality
Sandvine社（ダンダス） - ネットワークの中立性と世界のトラフィック管理
Stanislav Shalunov - Users want P2P, we make it work
スタニスラフ・シャルノブ - ユーザーがP2Pをしたい、我々はそれを動作させます
R. Cuevas, A. Cuevas, I. Martinez-Yelmo, C. Guerrero - Internet scale mobility service: a case study on building a DHT based service for ISPs
R.クエバス、A.クエバス、I.マルティネス-Yelmo、C.ゲレロ - インターネット規模のモビリティ・サービス：ISPのためのDHTベースのサービスを構築に関するケーススタディ
M. Barnes, B. McCormick - Peer to Peer Infrastructure Considerations
M.バーンズ、B.マコーミックは - インフラストラクチャに関する検討事項をピアツーピア
Henning Schulzrinne - Encouraging Bandwidth Efficiency for Peer-to-Peer Applications
ヘニングSchulzrinneと - ピアツーピアアプリケーションのための帯域幅の効率を奨励
Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri Papdimitriou - Towards an Open Path Selection Architecture
ダミアンSaucez、ブノワDonnet、オリヴィエ・ボナベンチャー、ディミトリPapdimitriou - オープンパス選択のアーキテクチャに向けて
Eric Rescorla - Notes on P2P Blocking and Evasion
エリックレスコラ - P2Pブロッキングと回避の注意事項
Vinay Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P Systems
ビナイAggrawal、アンジャ・フェルドマン - P2PシステムにおけるISP-支援ネイバーの選択
Enrico Marocco, Vijay K. Gurbani, Volker Hilt, Ivica Rimac, Marco Tomsu - Peer-to-Peer Infrastructure: A Survey of Research on the Application-Layer Traffic Optimization Problem and the Need for Layer Cooperation
エンリコMarocco、ビジェイK. Gurbani、フォルカー柄、イビツァRimac、マルコTomsu - ピアツーピアインフラストラクチャ：アプリケーションレイヤトラフィック最適化問題およびレイヤ協力の必要性に関する研究調査
Tony Moncaster, Bob Briscoe, Louise Burness - Is There a Problem With Peer-to-peer Traffic?
トニーMoncaster、ボブ・ブリスコー、ルイーズBurness - ピア・ツー・ピアトラフィックに問題がありますか？
David Sohn, Alissa Cooper - Peer-to-Peer Infrastructure Considerations
デビッドソン、アリッサ・クーパー - ピアツーピアインフラストラクチャに関する検討事項
Bob Briscoe, Lou Burness, Tony Moncaster, Phil Eardley - Solving this traffic management problem... and the next, and the next
ボブ・ブリスコー、ルーBurness、トニーMoncaster、フィルEardley - ...このトラフィック管理の問題を解決し、次、次
Hannes Tschofenig, Marcin Matuszewski - Dealing with P2P Traffic in an Operator Network
ハンネスTschofenig、マルチンMatuszewski - オペレータネットワークでのP2Pトラフィックへの対処
Jean-Francois Mule - CableLabs submission
ジャン・フランソワ・ミュール - CableLabsの提出
Alan Arolovitch - Peer-to-peer infrastructure: Case for cooperative P2P caching
アランArolovitch - ピア・ツー・ピアのインフラストラクチャ：協同P2Pのキャッシュ用ケース
Leslie Daigle - Defining Success: Questions for the Future of the Internet and Bandwidth-Intensive Activities
レスリーDaigle氏 - 成功の定義：インターネットの未来のための質問と帯域幅を多用する活動
William Check, Rex Bullinger -- NCTA Position Paper
ウィリアム・チェック、レックスブリンガー - NCTAポジションペーパー
Jari Arkko - Incentives and Deployment Considerations for P2PI Solutions
ヤリArkko - P2PIソリューションのためのインセンティブと展開に関する考慮事項
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar USA
ジョン・ピーターソンNeuStar USA
EMail: jon.peterson@neustar.biz
メールアドレス：jon.peterson@neustar.biz
Alissa Cooper Center for Democracy & Technology 1634 Eye St. NW, Suite 1100 Washington, DC 20006 USA
民主主義とテクノロジー1634・アイセントNWのためのアリッサ・クーパーセンター、スイート1100ワシントンD.C. 20006 USA
EMail: acooper@cdt.org
メールアドレス：acooper@cdt.org