[要約] 要約： RFC 5594は、2008年5月28日に開催されたIETFワークショップでのピア・ツー・ピア（P2P）インフラストラクチャに関する報告書です。目的： このRFCの目的は、P2Pインフラストラクチャに関するワークショップの成果をまとめ、関係者に提供することです。
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）インフラストラクチャに関するIETFワークショップからのレポート、2008年5月28日
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.
このドキュメントは、IETFのリアルタイムアプリケーションとIETFのインフラストラクチャエリアディレクターによって組織されたワークショップの結果を報告し、ピアツーピア（P2P）のトラフィック量の増加に起因するネットワークの遅延と渋滞の問題について説明します。このワークショップは、2008年5月28日に米国マサチューセッツ州ケンブリッジのMITで開催されました。ワークショップの目標は2つありました。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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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トラフィックの問題に遭遇しています。インターネット上のノード間の静的な遅延耐性データの転送はよく理解されている問題ですが、輸送レベルでの公平性の従来の管理は、最高のエンドユーザー転送率を達成するために設計されたアプリケーションからの緊張にさらされています。ピーク時に、これにより絶対容量に近いネットワークが実行され、すべてのトラフィックが遅延が発生します。この追加のレイテンシの矢面に立つアプリケーションは、Voice over 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.
ワークショップの目標は2つありました。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に添付されています。ワークショップのアジェンダは、付録Cにあります。ワークショップで記載されているプレゼンテーションへのリンクと、ワークショップの前に提出されたポジションペーパーは、付録Dにあります。
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.
このワークショップでは、IETFコミュニティがP2Pおよびその他の大量のアプリケーションがインターネット全体での影響を認識していることを紹介しました。参加者は、ネットワークオペレーター、アプリケーションプロバイダー、エンドユーザーがすべて相互に有益だと思う潜在的な標準化作業について議論する機会を歓迎しました。2つの輸送関連の作業項目が大幅な牽引力を獲得しました。遅延耐性アプリケーションの非常に延期されるエンドツーエンドの混雑制御のプロトコルの設計、および複数の輸送接続を一度に開くアプリケーションの背後にある理由と影響に関する情報文書を作成します。ワークショップで登場した独立した関心分野は、ネットワークにアプリケーションでより多くの情報を利用できるようにすることで、ピア選択の改善に焦点を当てました。最後に、プレゼンターは、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がより一般的な問題の空間に近づくべきであると感じていました。
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誘発性輻輳の特定のネットワークオペレーターの見解をより詳細に理解できるようにするために、Jason LivingoodとRich Woundyは、Comcastのネットワークの概要とP2Pトラフィックの管理へのアプローチを提供しました。
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 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）アーキテクチャ[DOCSIS]を介したデータには、数百または数千の住宅用ケーブルの顧客にサービスを提供する単一のケーブルモデム終端システム（CMT）がある場合があります。各CMTには複数のDOCSISドメインがあり、それぞれには通常、単一のダウンストリームリンクと多数のアップストリームリンクがあります。各CMTは、ハイブリッドファイバーコキシアル（HFC）ネットワークを介して、加入者のケーブルモデムに接続されています。
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ミリ秒ごとにリクエストを許可している場合、20〜30ミリ秒のパケット化遅延を持つVOIPのようなサービスのケーブルモデム送信データは、常に同じCMTで別のモデムと競合する可能性があります。アップストリームを送信し、新しいリクエストごとにピギーバックします。これは、より重い上流のユーザーが、よりインタラクティブなアプリケーションよりも最終的にパイプを支配する方法を説明するかもしれません。その結果、問題の空間と潜在的な解決策の評価は、特にアクセスネットワークでの混雑の緩和を考慮する場合、特定のレイヤー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.
CMTSへの上流のリクエストにTCPフローの公平性がどのように適用されるかは、未解決の問題です。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トラフィックがCMTへの上流要求プロセスを回避できるようにするVoIPのサービスフローをプロビジョニングできます（それにより、他のモデムとの競合を回避します）。サービスフローには、上流の容量がプロビジョニングされます。モデムには、最良の努力のために別のサービスフローがあります。一部のISPは、独自のVoIP製品にそのようなフローを提供しています。他の人は、加入者が追加の支払いを行うことを許可して、プロビジョニングされたサービスフローに特定のトラフィックを割り当てます。
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.
混雑管理は多くの形をとることができます。ジェイソンとリッチは、Comcastが現在裁判にかけている新しいプロトコルに依存しないアプローチを説明しました。これらの試験の前に、すべてのトラフィックは「最善の努力」としてマークされていました。試験中、すべてのトラフィックは「優先度」として再分類されます。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.
トラフィックが再マ化されている加入者は、「長期間のバルク消費状態」に一時的に入力したかどうかを判断することにより選択されます。この状態は、一定の期間にわたって一定量の帯域幅を消費することによって達成されます（両方とも、試験中に調査される微調整可能なパラメーターです）。これらのしきい値は、サブスクライバーのサービス層に依存します。これは、より多くの帯域幅を支払うサブスクライバーがより高いしきい値を持っています。再マッキングでは、同じサブスクライバー接続の複数のユーザーを区別しないため、ある家族の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.
Stanislav Shalunovは、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の使用が成長するにつれて、エンドユーザーの遅延も増加しています。たとえば、アップリンク容量が250〜500 kbpsであり、モデムバッファが32〜64 kbpsの容量を持っているユーザーは、モデムが適応キュー管理（AQM）を使用しない限り、これは珍しいことです）。これにより、アプリケーションのパフォーマンスに悲惨な影響を与える秒程度の遅延が発生する可能性があります。近隣の間で共有容量を持つケーブルシステムでは、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つのトピック領域の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クライアントまたはトラッカーが利用できるようにします。この情報は、地域の何らかのメトリックに基づいてトラフィックをローカライズしたり、提供されたネットワーク情報に基づいてピア選択の決定を変更するために使用できます（以下、単に「ローカリゼーション」と呼ばれます）。この種のアプローチの特別なケースの1つは、ピアが求めているコンテンツを含むキャッシュを見つけるのに役立ちます。
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は、トラフィックを自分のネットワークから移動させたい場合があります。同様に、ピアは、受信した情報を使用してパフォーマンスの改善をもたらすことを望んでいます。それ以外の場合、ピアを選択する前にネットワークに相談するインセンティブはありません。両当事者が情報共有が有益であると判断した場合でも、ユーザーエクスペリエンスは、提供された情報の範囲とピアの場所に応じて、必ずしも均一ではありません。ローカリゼーション情報は、ピア選択決定の1つのコンポーネントを形成する可能性がありますが、他の要因とバランスをとる必要があるでしょう。
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）内でピアを好むことができる簡単な方法の1つです。潜在的な改善の程度を判断するためには、より多くのデータが必要ですが、一部のネットワークでは同じ速度と同じようなピア間の転送が必要です。たとえば、モバイルネットワークでは、AS数のユーティリティは地理的位置と相関していないため、制限されています。また、ピアは、ISPが提供する特定のASEまたは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.
4つの最も人気のあるBitTorrent Torrentsでケーススタディが実施され、Asへのローカライズの効果がどのようなものかを判断しました。急流の群れサイズは9984、3944、2561、および2023で、サイズ分布は多項式であると思われました。20人以上のピアが1つのASで、AS内の仲間が互いにしか交換できず、ドメイン間トラフィックを避けます。4つの群れの仲間の半分以上（57％）がこのようなASEにいました。したがって、これらの場合、AS内の仲間に接続すると、輸送トラフィックを少なくとも57％減らすことができます。ただし、ASESが非対称のアップロードおよびダウンロードリンクを持っている場合、各ピアのダウンロード速度がより遅いアップロード速度によって制限されるため、結果のユーザーエクスペリエンスが悪化する可能性があります。
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]は、プロバイダーとアプリケーション（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.
このフレームワークのテストでは、ほぼ同じ数のクライアントと同様の地理的およびネットワーク分布で2つの並列群れが作成され、どちらも同じファイルを共有しています。群れの1つはP4Pフレームワークを使用し、ISPのネットワークトポロジマップはItrackerへの入力として、もう1つは従来のピア選択を使用しました。P4Pのない群れは、ISPの外部の仲間との間のトラフィックの98％を見ましたが、P4Pではその数は50％でした。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を必要とする可能性があるため、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がホストする「オラクル」で構成されています。Oracleは、ネットワークノードからIPアドレスのリストを受信し、独自の機密基準に従ってリストをソートし、ソートされたリストをノードに返します。Oracleが提供するピアランキングは、前のセクションで説明されている仮想コストインターフェイスの特別なケースと見なすことができます。
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サービスとして実行できます（おそらくBindに似ています）。
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の数に基づいてランキングを行うことができます。別のオプションは、複数の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サービスの実装における主な課題は、スケーラビリティです。ピアがOracleに知っているすべてのピアのIPアドレスをOracleに通信する必要がある場合、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キャッシュに関する2つの主な懸念は、ネットワーク能力と法的責任に関連しています。キャッシュが有用であるためには、おそらく大規模である必要があるでしょう（1つのTBキャッシュが1つの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メカニズム全体を標準化することが可能かもしれませんが、出発点として、標準化のためにコア管理可能なコンポーネントを選ぶ方が理にかなっています。標準化が役に立たないため、1つの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は他のISPSネットワークの接続コストが何であるかを知らない場合がありますが、複数の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.
P2Pクライアントは現在、数字を決定したい場合、IPからマッピングテーブルに依存しています。クライアントがこの情報を取得するための標準的で簡単な方法を提供することは、特定のネットワークでピア選択をより効率的にするのに役立ちます。
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.
ノードのローカリティに固有の情報を提供するトラッカー、Itracker、Oracles、またはその他のメカニズムの展開により、ノードはこれらのリソースを見つける方法が必要です。IETFの1つのタスクは、既存のディスカバリープロトコル（DNS、DHCP、Anycastなど）を活用することにより、発見を行う方法を探求することです。発見するリソースに応じて、ディスカバリーは単純な検索のみを必要とするか、リクエストを発行するノードにどのリソースが「最も近い」かをより複雑な決定が必要になる場合があります。
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.
マルチレイヤートラッカーアプローチは、グローバルトラッカーからローカルトラッカーに再ダイレクトするための標準トラッカー形式によって支援される可能性があります。既存のトラッカーが他のトラッカーと喜んで相談する範囲は不明ですが、再方向形式は別のコンテキストでアナログを持っている可能性があります。標準化されていません。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）秒単位で」問題を解決する1つのアプローチは、P2Pクライアントがより良い混雑制御を実装し、競合するトラフィックの遅延を低く保つためにボトルネックをいっぱいに保つことです。このようなアルゴリズムは、一元配置遅延を継続的にサンプリングし（伝播をキューイング遅延から分離）、小さなキューイング遅延値をターゲットにすることにより、BitTorrentのクライアントに実装されています。これは、基本的に、バルク、弾力性のあるトラフィックを混雑の下で競合他社に降伏させることにより、エンドツーエンドの混雑制御メカニズムのスカベンジャーサービスクラスに近似します。
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とは異なり、ソケットAPIの単純な拡張機能を持つホストに加重混雑制御を実装できます（ただし、移植性にはOS間のコンセンサスが必要です）。加重混雑制御により、コントロールはホストに存在しますが、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がユーザーの決定をarbitrarily意的に無効にすべきではないことを意味します（ただし、これは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の重要な制限の1つは、他の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が追求するための潜在的な手段の1つは、混雑の問題全般と提案された迅速な修正の長期的な影響を評価するための長期設計チームを設立することです。これらの問題は必ずしも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）の取り決めは、長期的にはより適している場合があります。輻輳時に特定のクラスのトラフィックを区別する1つのアプローチは、セクション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またはその他）に関する関連する議論に拍車をかけました。複数のユーザーが1つのリンクを共有しているため、TCP Flow Fiarnessは、複数のオープン接続を持つユーザーに帯域幅のより大きな割合を提供します。一部の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.
ワークショップの参加者は、ISPが経験したように、さらに、サブスクライバーが経験したように、データを転送するコストがP2Pトラフィックの問題を考慮するIETFを考慮すべきであることについて、さまざまな意見を表明しました。
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.
一方では、混雑の問題から単独で見られる場合でも、帯域幅のコストは重要な場合があります。一部の推定では、1 GBの出荷の総費用が0.10ドルから2ドルの間に置かれました。加入者が定額料金を請求される市場での輸送帯域幅のコストは、平準化されているように見え、もはや安くなっていない可能性があります。したがって、渋滞を制御し、収益を増やす手段として、より多くのサービスプロバイダーがボリュームベースの価格設定（まだ行っていない場合）に移行することを期待することは合理的かもしれません。これは、帯域幅の消費がエンドユーザーに見える場合にのみ実現可能です。これは、クォータと使用をアプリケーションにさらすメカニズムを主張しています。ただし、コスト情報の表現は、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は、輻輳を緩和するために支払っていると見なされる可能性があります。または、サブスクライバーがネットワークの混雑に対して請求された場合、コストと混雑はまったく同じと見なされる可能性があります。したがって、それらの区別は人工的な場合があります。
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).
2つの主要な輸送関連の作業項目がワークショップから進化しました。1つ目は、P2Pクライアントなどのアプリケーションが共有リンクで使用するインタラクティブアプリケーションへの影響を減らすために使用できる標準化された遅延ベースのエンドツーエンドの混雑制御メカニズムの作成でした（セクション5.2で説明されています。1）。2つ目は、複数の輸送接続を開く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は、ワークショップ中に議事録を熱心に録音したScribes、Spencer Dawkins、Alissa Cooperにも感謝したいと思います。
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/仕様20.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] Xie、H.、Yang、Y.、Krishnamurthy、A。、およびA. Silberschatz、「P4P：アプリケーションのプロバイダーポータル」、<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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
Dave Clark, MIT
デイブ・クラーク、MIT
Lars Eggert, TSV AD
Lars Eggert、TSV AD
Cullen Jennings, RAI AD
カレン・ジェニングス、ライド
John Morris, Center for Democracy and Technology
ジョン・モリス、民主主義技術センター
Jon Peterson, RAI AD
ジョン・ピーターソン、ライド
Danny Weitzner, MIT
ダニー・ワイツナー、MIT
Vinay Aggarwal, Deutsche Telekom Labs, TU Berlin
Vinay Aggarwal、Deutsche Telekom Labs、Tu Berlin
Marvin Ammori, Free Press
Marvin Ammori、Free Press
Loa Andersson, Acreo AB
Loa Andersson、Acreo AB
Jari Arkko, Ericsson
ジャリ・アークコ、エリクソン
Alan Arolovitch, PeerApp
アラン・アロヴィッチ、ピアラップ
Timothy Balcer
ティモシー・バルサー
Mary Barnes, Nortel
メアリー・バーンズ、ノルテル
Colby Barth, Cisco Systems
コルビーバース、シスコシステム
John Barlett, NetForecast
ジョン・バーレット、netforecast
Salman Baset, Columbia University
コロンビア大学サルマンベース
Chris Bastian, Comcast
クリス・バスチャン、Comcast
Matthew Bell, Charter Communications
マシュー・ベル、チャーターコミュニケーションズ
Donald Bowman, Sandvine Inc.
ドナルド・ボウマン、サンドバイン社
Scott Bradner, Harvard University
ハーバード大学スコット・ブラッドナー
Bob Briscoe, British Telecom
ボブ・ブリスコ、イギリスの通信
David Bryan, SIPeerior Technologies Rex Bullinger, National Cable & Telecommunications Association
David Bryan、Sipeerior Technologies Rex Bullinger、National Cable＆Telecommunications Association
Gonzalo Camarillo, Ericsson
ゴンザロ・カマリロ、エリクソン
Mary-Luc Champel, Thomson
メアリー・ルック・チャンペル、トムソン
William Check, NCTA
ウィリアムチェック、NCTA
Alissa Cooper, Center for Democracy and Technology
アリッサクーパー、民主主義技術センター
Patrick Crowley, Washington University
ワシントン大学のパトリック・クローリー
Leslie Daigle, Internet Society
レスリー・デイグル、インターネット社会
Spencer Dawkins
スペンサー・ドーキンス
John Dickinson, Bright House Networks
ジョン・ディキンソン、ブライトハウスネットワーク
Lisa Dusseault, CommerceNet
Lisa Dusseault、Commercenet
Lars Eggert, Nokia Research Center
ノキア研究センターのラース・エガート
Joe Godas, Cablevision
ジョー・ゴダス、ケーブルビジョン
Vernon Groves, Microsoft
Vernon Groves、Microsoft
Daniel Grunberg, Immedia Semiconductor
Daniel Grunberg、Immedia Semiconductor
Carmen Guerrero, University Carlos III Madrid
カルメンゲレロ、カルロスIIIマドリード大学
Vijay Gurbani, Bell Laboratories/Alcatel-Lucent
Vijay Gurbani、Bell Laboratories/Alcatel-Lucent
William Hawkins III, ITT
ウィリアム・ホーキンスIII、ITT
Volker Hilt, Bell Labs, Alcatel-Lucent
Volker Hilt、Bell Labs、Alcatel-Lucent
Russell Housley, Vigil Security, LLC
Russell Housley、Vigil Security、LLC
Robert Jackson, Camiant
ロバート・ジャクソン、カミアント
Cullen Jennings, Cisco Systems
Cullen Jennings、Cisco Systems
Paul Jessop, RIAA
ポール・ジェソップ、リアア
XingFeng Jiang, Huawei
Xingfeng Jiang、Huawei
Michael Kelsen, Time Warner Cable Tom Klieber, Comcast
マイケル・ケルセン、タイム・ワーナーケーブルトム・クリーバー、Comcast
Eric Klinker, BitTorrent Inc.
Eric Klinker、Bittorrent Inc.
Umesh Krishnaswamy
Umesh Krishnaswamy
Gregory Lebovitz, Juniper
ジュニパー、グレゴリー・レボビッツ
Erran Li, Bell-Labs
Erran Li、ベルラブ
Jason Livingood, Comcast
ジェイソンリビングウッド、コムキャスト
Andrew Malis, Verizon
アンドリュー・マリス、ベライゾン
Enrico Marocco, Telecom Italia Lab
Enrico Marocco、Telecom Italia Lab
Marcin Matuszewski, Nokia
ノキアのマーシン・マツシェフスキー
Danny McPherson, Arbor Networks, Inc.
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
Jean-Francois Mule、CableLabs
David Oran, Cisco Systems
デビッド・オラン、シスコ・システム
Reinaldo Penno, Juniper Networks
Reinaldo Penno、ジュニパーネットワーク
Jon Peterson, NeuStar
ジョン・ピーターソン、ノイスター
Howard Pfeffer, Time Warner Cable
Howard Pfeffer、タイムワーナーケーブル
Laird Popkin, Pando Networks
Laird Popkin、Pando Networks
Stefano Previdi, Cisco systems
Cisco Systems、Stefano Previdi
Satish Putta
サティシュパッタ
Eric Pescorla
エリック・ペスコルラ
Benny Rodrig, Avaya
ベニー・ロドリグ、アヴァヤ
Damien Saucez, UCLouvain (UCL) Henning Schulzrinne, Columbia University
ダミアンソース、Uclouvain（UCL）Henning Schulzrinne、コロンビア大学
Michael Sheehan, Juniper Networks
マイケル・シーハン、ジュニパーネットワーク
Don Shulzrinne, Immedia Semiconductor
Don Shulzrinne、Immedia Semiconductor
David Sohn, Center for Democracy and Technology
デビッド・ソーン、民主主義技術センター
Martin Stiemerling, NEC
Martin Stiemerling、Nec
Clint Summers, Cox Communications
Clint Summers、Cox Communications
Robert Topolski
ロバート・トポルスキー
Mark Townsley, Cisco Systems
マークタウンズリー、シスコシステム
Yushun Wang, Microsoft
Yushun Wang、Microsoft
Hao Wang, Yale University
イェール大学のハオ・ワン
Ye Wang, Yale University
イェール大学、イェワン
David Ward, Cisco
デイビッド・ウォード、シスコ
Nicholas Weaver, ICSI
ニコラス・ウィーバー、ICSI
Daniel Weitzner, MIT
ダニエル・ワイツナー、MIT
Magnus Westerlund, Ericsson
エリクソン、マグナス・ウェスターランド
Thomas Woo, Bell Labs
トーマス・ウー、ベルラボ
Steve Worona, EDUCAUSE
スティーブ・ウォーナ、教育
Richard Woundy, Comcast
リチャード・ウッキング、コムキャスト
Haiyong Xie
haiyong xie
Richard Yang, Yale University
イェール大学リチャード・ヤン
1. Welcome/Note Well/Intro Slides Cullen Jennings
1. ウェルカム/メモウェル/イントロスライドカレンジェニングス
2. Service Provider Perspective (Comcast) Rich Woundy and Jason Livingood
2. サービスプロバイダーの視点（Comcast）豊富な傷とジェイソンリビングウッド
3. Application Designer Perspective (BitTorrent) Stanislav Shalunov
3. アプリケーションデザイナーの視点（Bittorrent）Stanislav Shalunov
4. Lightning Talks & General Discussion Robb Topoloski Nick Weaver Leslie Daigle
4. ライトニングトークと一般的な議論ロブトポロスキーニックウィーバーレスリーデイグル
5. Localization and Caches Laird Popkin and Haiyong Xie Yu-Shun Wang Vinay Aggrawal
5. ローカリゼーションとキャッシュレアードポップキンとハイヨンXie Yu-Shun Wang Vinay Aggrawal
6. New Approaches to Congestion Bob Briscoe Marcin Matuszewski
6. 混雑するための新しいアプローチ
7. Quality of Service Mary Barnes Henning Schulzrinne
7. サービス品質メアリーバーンズヘニングシュルツリンヌ
8. Conclusions & Wrap-Up
8. 結論とまとめ
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
ポールジェソップ - リアアの位置
Nikloaos Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES: Edge Capacity Hosting Overlays of Nano Data Centers
Nikloaos Laotaris、Pablo Rodriguez、Laurent Massoulie-エコー：ナノデータセンターのエッジ容量ホスティングオーバーレイ
Bruce Davie, Stefano Previdi, Jan Medved, Albert Tian - Peer Selection Guidance
ブルース・デイビー、ステファノ・プレビディ、ヤン・メドベッド、アルバート・ティアン - ピア選択ガイダンス
Marie-Jose Montpetit - Community Networks: getting P2P out of prison - the next steps
Marie -Jose Montpetit-コミュニティネットワーク：P2Pを刑務所から追い出す - 次のステップ
D. Bryan, S. Dawkins, B. Lowekamp, E. Shim - Infrastructure-related Attributes of App Scenarios for P2PSIP
D. Bryan、S。Dawkins、B。Lowekamp、E。Shim-P2PSIPのアプリシナリオのインフラストラクチャ関連属性
Jiang XingFeng - Analysis of the Service Discovery in DHT network R. Penno - P2P Status and Requirements
Jiang Xingfeng- DHTネットワークでのサービス発見の分析R. Penno -P2Pステータスと要件
Patrick Crowley and Shakir James - Symbiotic P2P: Resolving the conflict between ISPs and BitTorrent through mutual cooperation
Patrick CrowleyとShakir James-共生P2P：相互協力を通じてISPとBitTorrentの間の対立を解決する
Robb Topolski - Framing Peer to Peer File Sharing
Robb Topolski-ピアからピアファイル共有のフレーミング
M. Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network Cooperative Overlay System
M. Stiemerling、S。Niccolini、S。Kiesel、J。Seedorf-ネットワーク協同組合オーバーレイシステム
Y. Wang, S. Tan, R. Grove - Traffic Localization with Multi-Layer, Tracker-Based Peer-to-Peer Content Distribution Architecture
Y. Wang、S。Tan、R。Grove-マルチレイヤーによる交通ローカリゼーション、トラッカーベースのピアツーピアコンテンツ配信アーキテクチャ
Haiyong Xie, Y. Richard Yang, Avi Silberschatz, Arvind Krishnamurthy, Laird Popkin - P4P: Provider Portal for P2P Applications
Haiyong Xie、Y。RichardYang、Avi Silberschatz、Arvind Krishnamurthy、Laird Popkin -P4P：P2Pアプリケーション用のプロバイダーポータル
Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly Peer-to-Peer Services
マイケル・メリット、ダグ・パスコ、レアード・ポップキン - ネットワークに優しいピアツーピアサービス
Camiant (Jackson) - Camiant Submission
Camiant（Jackson） - Camiant Submission
Jason Livingood, Rich Woundy - Comcast Submission
ジェイソンリビングウッド、リッチネスティウ - コムキャストの提出
Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load Impact
Benny Rodrig-エンタープライズIPネットワークとP2Pトラフィック負荷の影響
Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences"
テッドハーディ - ピアツーピアトラフィックと「無人の結果」
Jiang XingFeng, Ning Zong - Content Replication for Internet P2P
Jiang Xingfeng、Ning Zong-インターネットP2Pのコンテンツレプリケーション
Applications
アプリケーション
Sandvine (Dundas) - Analysis of Traffic Demographics in Broadband networks
Sandvine（Dundas） - ブロードバンドネットワークにおける交通人口統計の分析
Sandvine (Dundas) - Traffic Management in a World with Network Neutrality
Sandvine（Dundas） - ネットワークの中立性を持つ世界の交通管理
Stanislav Shalunov - Users want P2P, we make it work
Stanislav Shalunov-ユーザーは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. Cuevas、A。Cuevas、I。Martinez -Yelmo、C。Guerrero-インターネットスケールモビリティサービス：ISPSのDHTベースのサービスの構築に関する事例研究
M. Barnes, B. McCormick - Peer to Peer Infrastructure Considerations
M.バーンズ、B。マコーミック - ピアツーピアインフラストラクチャの考慮事項
Henning Schulzrinne - Encouraging Bandwidth Efficiency for Peer-to-Peer Applications Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri Papdimitriou - Towards an Open Path Selection Architecture
Henning Schulzrinne-ピアツーピアアプリケーションの帯域幅効率の奨励Damien Saucez、Benoit Donnet、Olivier Bonaventure、Dimitri Papdimitriou-オープンパス選択アーキテクチャに向けて
Eric Rescorla - Notes on P2P Blocking and Evasion
Eric Rescorla- P2Pブロッキングと回避に関するメモ
Vinay Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P Systems
Vinay Aggrawal、Anja Feldmann-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
Enrico Marocco、Vijay K. Gurbani、Volker Hilt、Ivica Rimac、Marco Tomsu-ピアツーピアインフラストラクチャ：アプリケーション層の交通最適化問題と層協力の必要性に関する研究の調査
Tony Moncaster, Bob Briscoe, Louise Burness - Is There a Problem With Peer-to-peer Traffic?
トニー・モンカスター、ボブ・ブリスコ、ルイーズ・バーネス - ピアツーピアトラフィックに問題はありますか？
David Sohn, Alissa Cooper - Peer-to-Peer Infrastructure Considerations
David Sohn、Alissa Cooper-ピアツーピアインフラストラクチャの考慮事項
Bob Briscoe, Lou Burness, Tony Moncaster, Phil Eardley - Solving this traffic management problem... and the next, and the next
ボブ・ブリスコ、ルー・バーネス、トニー・モンカスター、フィル・アードリー - この交通管理の問題を解決する...そして次のものと次の
Hannes Tschofenig, Marcin Matuszewski - Dealing with P2P Traffic in an Operator Network
Hannes Tschofenig、Marcin Matuszewski-オペレーターネットワークでのP2Pトラフィックを扱う
Jean-Francois Mule - CableLabs submission
Jean -Francois Mule -CableLabsの提出
Alan Arolovitch - Peer-to-peer infrastructure: Case for cooperative P2P caching
Alan Arolovitch-ピアツーピアインフラストラクチャ：協力的なP2Pキャッシングのケース
Leslie Daigle - Defining Success: Questions for the Future of the Internet and Bandwidth-Intensive Activities
レスリー・デイグル - 成功の定義：インターネットの将来と帯域幅を集中的に活動するための質問
William Check, Rex Bullinger -- NCTA Position Paper
ウィリアムチェック、レックスブリンジャー-NCTAポジションペーパー
Jari Arkko - Incentives and Deployment Considerations for P2PI Solutions
Jari Arkko- P2PIソリューションのインセンティブと展開の考慮事項
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar USA
ジョン・ピーターソン・ノイスター・USA
EMail: jon.peterson@neustar.biz
Alissa Cooper Center for Democracy & Technology 1634 Eye St. NW, Suite 1100 Washington, DC 20006 USA
アリッサクーパー民主主義技術センター1634 Eye St. NW、Suite 1100 Washington、DC 20006 USA
EMail: acooper@cdt.org