Network Working Group J. Peterson
Request for Comments: 5594 NeuStar
Category: Informational A. Cooper
Center for Democracy & Technology
July 2009
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
IETF对等（P2P）基础设施研讨会报告，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实时应用和基础设施领域主管组织的研讨会的结果，讨论了因对等（P2P）通信量增加而导致的网络延迟和拥塞问题。研讨会于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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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中。研讨会议程可在附录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
研讨会展示了IETF社区对P2P和其他高容量应用程序对整个互联网的影响的认识。与会者欢迎有机会讨论潜在的标准化工作，网络运营商、应用程序提供商和最终用户都会发现这些工作是互利的。两个与传输相关的工作项目获得了显著的进展：为延迟容忍应用程序设计一个非常不同的端到端拥塞控制协议，以及生成一个关于应用程序同时打开多个传输连接的原因和效果的信息文档。研讨会上出现的另一个感兴趣的领域是通过
networks make more information available to applications. Finally, presenters also covered traditional approaches to multiple service-tier queuing such as Diffserv.
网络为应用程序提供了更多信息。最后，演示者还介绍了多服务层排队的传统方法，如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）研讨会的起源在很大程度上源于互联网服务提供商由于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引起的拥塞的看法，Jason Livingood和Rich Woundy概述了康卡斯特的网络和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）体系结构[DOCSIS]中，可能有一个电缆调制解调器终端系统（CMTS），为数百或数千个住宅电缆客户提供服务。每个CMT有多个
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域，每个域通常具有单个下游链路和多个上游链路。每个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.
在上行方向上，连接到CMT的任何电缆调制解调器都可以向CMT发出发送请求，并且请求被随机化以最小化冲突。由于许多电缆调制解调器同时发出请求，请求可能会发生冲突，导致延迟。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队列的前端，在交互式但不太密集的上游应用程序之前。例如，如果CMT大约每1到3毫秒批准一次请求，则为VoIP之类的服务传输数据的电缆调制解调器（打包延迟为20-30毫秒）可能会与同一CMT上的另一个调制解调器发生竞争，该调制解调器不断地向上游传输并承载每个新请求。这也许可以解释为什么大量的上游用户最终会主导管道而不是更多的交互式应用程序。因此，对问题空间和潜在解决方案的评估必须注意特定的第二层网络可能对互联网流量行为产生的影响，特别是在考虑缓解接入网络中的拥塞时。
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流公平性如何应用于向CMT发送的上游请求是一个开放的问题。CMTS可以看到许多服务流，每个服务流可以是单个TCP流或多个TCP流（或UDP）。CMTS在数据包已经向上游传输之前不知道数据包的源IP地址或目的IP地址，因此不能使用这些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
特定的电缆调制解调器可以定义多个服务流。例如，作为VoIP端点的调制解调器可以为VoIP提供服务流，该服务流将允许VoIP通信避免到cmt的上游请求过程（从而避免争用）
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.
使用其他调制解调器）。服务流将为其配置上游容量。调制解调器将有一个单独的服务流，以尽最大努力传输数据。一些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客户开始越来越多地抱怨延迟敏感流量（VoIP和游戏）的性能，部分原因是上述DOCSIS体系结构引起的问题。与此同时，互联网服务提供商发现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.
拥堵管理可以采取多种形式；Jason和Rich解释了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概述了BitTorrent对P2P流量增加的影响和潜在缓解措施的看法。这里描述了影响；他提出的解决方案（包括他的大部分演讲）将在第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），这是不常见的）。这可能导致秒级延迟，对应用程序性能造成灾难性影响。在邻居之间共享容量的电缆系统上，一个邻居可能会使缓冲区饱和，并影响另一个邻居的通信延迟。即使是拥有专用带宽的用户也会遇到延迟，因为他们自己的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
研讨会之前收到的意见涵盖了一系列广泛的工作，涉及P2P流量的具体方面和其他相关问题。解决方案建议通常分为一种
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.
或以上三个主题领域：改进对等选择、拥塞控制新方法和服务质量机制。各领域的研讨会讨论和成果如下所述。
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
虽然本地化有可能改善同行选择，但对信息交流双方的激励是复杂的。ISP可能希望将流量移出自己的网络，这可能会促使他们向对等方提供与对等方预期相反的信息。同样，同龄人希望利用他们收到的信息来提高绩效；否则，他们就没有动力在选择对等点之前咨询网络。即使双方都认为信息共享是有益的，用户
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.
根据所提供信息的范围和同伴的位置，体验不一定是统一的。本地化信息可能构成对等选择决策的一个组成部分，但可能需要与其他因素进行平衡。
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提供的一组特定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.
对四种最流行的BitTorrent Torrent进行了案例研究，以确定本地化到AS的效果。洪流的群大小分别为9984、3944、2561和2023，其大小分布似乎是多项式的。由于单个AS中有20多个对等点，AS中的对等点只能相互交易，从而避免域间通信。在这四个群体中，超过一半（57%）的同龄人处于这样的ASE中。因此，在这些情况下，连接到AS内的对等点可以减少至少57%的公交流量。但是，如果ASE具有不对称的上传和下载链接，那么最终的用户体验可能会恶化，因为每个对等方的下载速度都会受到较慢上传速度的限制。
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，两个对等点位于同一个邻居中的概率太低，因此不值得定位到邻居级别。作为第一步，尝试一个简单的本地化方案，如上述的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
P2P应用程序提供商门户（P4P）项目[P4P]旨在设计一个框架，以实现提供商和应用程序（包括P2P）之间的合作，其中“提供商”可能是ISP、内容提供商
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.
分发网络或缓存服务。在这种架构中，每个提供者都可以通过称为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.
在这个框架的测试中，创建了两个平行的群集，它们拥有大约相同数量的客户端和相似的地理和网络分布，都共享相同的文件。其中一个群集使用P4P框架，ISP的网络拓扑图作为iTracker的输入，另一个群集使用传统的对等选择。没有P4P的swarm与ISP外部的对等方之间的通信量占98%，而有P4P的swarm则占50%。启用P4P的swarm的下载完成时间平均提高了约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.
这种架构中的一个挑战是确定“本地”对跟踪器、种子和对等体意味着什么。局部性可能取决于流量条件、负载平衡、静态拓扑、策略或其他度量。这些同样的考虑对于在混合网络中确定适当的缓存位置也至关重要。
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托管的“oracle”组成。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的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服务的主要挑战是可伸缩性。如果对等方需要向oracle通信他们知道的每个对等方的IP地址，oracle请求的大小可能会非常大。此外，今天最大的群集接近10000个对等点，并且随着每个对等点请求一个排序列表，oracle请求量将膨胀。随着依赖P2P分发内容的商业模式的增长，未来的蜂群可能会更大，这进一步加剧了问题。潜在的缓解措施包括让跟踪器而不是对等方发出oracle请求，并使用其他对等方的排序列表作为输入，而不是总是使用未排序的列表。
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知道特定内容可能位于何处，也不要求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 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.
研讨会上讨论的潜在工作项目清单如下所示。讲习班学员对进一步研究前三个项目特别感兴趣。
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客户端想要确定AS编号时，它们目前依赖于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.
随着追踪器、iTracker、oracles或其他机制的部署，这些机制提供了特定于节点位置的一些信息，节点将需要找到这些资源的方法。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订户受到网络使用策略或基于卷的配额的约束时，采用标准的方式传达订户的当前使用状态可能会很有用。这类似于用户计费周期中剩余的手机通话时间。应用程序可以使用这些信息来决定何时以及如何传输数据。实施这样一个标准的一个挑战是支持可能无限不同的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服务器为类似目的建立自己的镜像信息索引，尽管这些索引没有标准化。如果这两个问题空间足够相似，则可能有空间跨这两个空间标准化格式。
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客户端实现更好的拥塞控制，使瓶颈保持完整，同时让竞争流量的延迟保持较低。这种算法已经在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的简单扩展在主机上实现（尽管操作系统之间的共识对于可移植性是必要的）。通过加权拥塞控制，控制权属于主机，而即使有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.
符合这些标准的一个指标是危害（成本）指标，其中成本等于未送达目的地的数据量。使用此指标，当流量峰值最大时，成本最高。它允许在拥塞期间不发送太多数据的策略，而不指定确切的数据量。成本指标既可以用于区分服务方法，也可以用于加权拥塞控制。
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
研讨会上关于P2P拥塞的讨论引发了关于开放多个TCP连接的应用程序（P2P或其他）的相关讨论。由于多个用户共享一条链路，TCP流公平性为具有多个开放连接的用户提供了更大比例的带宽。由于某些P2P协议使用多个开放连接进行单个文件传输，并且用户经常同时进行多个传输，因此这可能会导致P2P用户一次拥有比同一链路上的其他用户更多的开放连接。对于打开多个应用程序的其他应用程序的用户也是如此
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.
连接。具有多个开放连接的单个用户表面上不一定是个问题，但公平性是由每个流而不是每个用户决定的这一事实给人留下了这样的印象。研讨会参与者认为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和他们的订阅者所经历的那样——IETF在考虑P2P流量问题时应该考虑到这一点。
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.
一方面，带宽成本可能很高，即使与拥塞问题分开来看也是如此。据估计，1GB的总运输成本在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.
讲习班与会者认为，这里强调的问题可能是国际研究工作队工作的有用素材。
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.
研讨会结束后以及随后的几天里，人们清楚地认识到，人们最感兴趣的领域分为两类：与交通有关的问题和改进的同行选择。
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要感谢主办研讨会的麻省理工学院，以及所有在麻省理工学院和其他地方协助组织和后勤研讨会的人。
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还要感谢斯宾塞·道金斯（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：应用程序提供商门户”，2008年8月<http://uwnews.org/relatedcontent/2008/August/ rc\u parentID43281\u 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 24751998年12月。
Dave Clark, MIT
戴夫·克拉克，麻省理工
Lars Eggert, TSV AD
拉尔斯·艾格特，TSV广告
Cullen Jennings, RAI AD
库伦·詹宁斯，拉伊广告公司
John Morris, Center for Democracy and Technology
约翰·莫里斯，民主与技术中心
Jon Peterson, RAI AD
乔恩·彼得森
Danny Weitzner, MIT
丹尼·魏茨纳，麻省理工
Vinay Aggarwal, Deutsche Telekom Labs, TU Berlin
Vinay Aggarwal，德国电信实验室，柏林
Marvin Ammori, Free Press
马文·阿莫里，自由新闻社
Loa Andersson, Acreo AB
安徒生律师事务所
Jari Arkko, Ericsson
爱立信雅丽阿尔科
Alan Arolovitch, PeerApp
艾伦·阿罗洛维奇，佩拉普
Timothy Balcer
蒂莫西·巴尔瑟
Mary Barnes, Nortel
玛丽·巴恩斯，北电
Colby Barth, Cisco Systems
Colby Barth，思科系统公司
John Barlett, NetForecast
约翰·巴利特，NetForecast
Salman Baset, Columbia University
萨尔曼·巴塞特，哥伦比亚大学
Chris Bastian, Comcast
克里斯·巴斯蒂安，康卡斯特
Matthew Bell, Charter Communications
Matthew Bell，特许通信公司
Donald Bowman, Sandvine Inc.
唐纳德·鲍曼，桑德文公司。
Scott Bradner, Harvard University
斯科特·布拉德纳，哈佛大学
Bob Briscoe, British Telecom
鲍勃·布里斯科，英国电信公司
David Bryan, SIPeerior Technologies
David Bryan，Sipecior 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
Alissa Cooper，民主与技术中心
Patrick Crowley, Washington University
帕特里克·克劳利，华盛顿大学
Leslie Daigle, Internet Society
Leslie Daigle，互联网协会
Spencer Dawkins
斯宾塞·道金斯
John Dickinson, Bright House Networks
约翰·迪金森，光明之家网络公司
Lisa Dusseault, CommerceNet
Lisa Dusseault，商业网
Lars Eggert, Nokia Research Center
拉尔斯·艾格特，诺基亚研究中心
Joe Godas, Cablevision
乔·戈达斯，有线电视
Vernon Groves, Microsoft
弗农·格罗夫斯，微软
Daniel Grunberg, Immedia Semiconductor
丹尼尔·格伦伯格，伊梅迪亚半导体公司
Carmen Guerrero, University Carlos III Madrid
卡门·格雷罗，马德里卡洛斯三世大学
Vijay Gurbani, Bell Laboratories/Alcatel-Lucent
Vijay Gurbani，贝尔实验室/阿尔卡特朗讯
William Hawkins III, ITT
威廉·霍金斯三世，ITT
Volker Hilt, Bell Labs, Alcatel-Lucent
沃尔克希尔特，贝尔实验室，阿尔卡特朗讯
Russell Housley, Vigil Security, LLC
Russell Housley，维吉尔安全有限责任公司
Robert Jackson, Camiant
罗伯特·杰克逊，卡米安特
Cullen Jennings, Cisco Systems
库伦·詹宁斯，思科系统公司
Paul Jessop, RIAA
保罗·杰索普，里娅
XingFeng Jiang, Huawei
江兴峰，华为
Michael Kelsen, Time Warner Cable
迈克尔·凯尔森，时代华纳有线电视公司
Tom Klieber, Comcast
汤姆·克莱伯，康卡斯特
Eric Klinker, BitTorrent Inc.
Eric Klinger，BitTorrent公司。
Umesh Krishnaswamy
乌梅什·克里希纳斯瓦米
Gregory Lebovitz, Juniper
Gregory Lebovitz，Juniper
Erran Li, Bell-Labs
贝尔实验室
Jason Livingood, Comcast
杰森·利文戈德，康卡斯特
Andrew Malis, Verizon
安德鲁·马利斯，Verizon
Enrico Marocco, Telecom Italia Lab
Enrico Marocco，意大利电信实验室
Marcin Matuszewski, Nokia
Marcin Matuszewski，诺基亚
Danny McPherson, Arbor Networks, Inc.
丹尼·麦克弗森，阿伯网络公司。
Michael Merritt, AT&T
迈克尔·梅里特，美国电话电报公司
Lyle Moore, Bell Canada
莱尔·摩尔，加拿大贝尔
John Morris, Center for Democracy and Technology
约翰·莫里斯，民主与技术中心
Jean-Francois Mule, Cablelabs
让·弗朗索瓦·穆尔，有线实验室
David Oran, Cisco Systems
David Oran，思科系统公司
Reinaldo Penno, Juniper Networks
雷纳尔多·佩诺，Juniper Networks
Jon Peterson, NeuStar
乔恩·彼得森，纽斯塔
Howard Pfeffer, Time Warner Cable
Howard Pfeffer时代华纳有线电视公司
Laird Popkin, Pando Networks
莱尔德·波普金，潘多网络公司
Stefano Previdi, Cisco systems
思科系统公司Stefano Previdi
Satish Putta
萨提什推杆
Eric Pescorla
埃里克·佩斯科拉
Benny Rodrig, Avaya
本尼·罗德里格，阿瓦亚
Damien Saucez, UCLouvain (UCL)
达米恩·索塞兹，乌鲁万（UCL）
Henning Schulzrinne, Columbia University
Henning Schulzrinne，哥伦比亚大学
Michael Sheehan, Juniper Networks
迈克尔·希恩，Juniper Networks
Don Shulzrinne, Immedia Semiconductor
伊梅迪亚半导体公司Don Shulzrinne
David Sohn, Center for Democracy and Technology
大卫·孙，民主与技术中心
Martin Stiemerling, NEC
马丁斯蒂梅林，NEC
Clint Summers, Cox Communications
克林特·萨默斯，考克斯通讯公司
Robert Topolski
罗伯特·托波尔斯基
Mark Townsley, Cisco Systems
马克·汤斯利，思科系统公司
Yushun Wang, Microsoft
Yushun Wang, Microsofttranslate error, please retry
Hao Wang, Yale University
王浩，耶鲁大学
Ye Wang, Yale University
叶旺，耶鲁大学
David Ward, Cisco
大卫·沃德，思科
Nicholas Weaver, ICSI
尼古拉斯·韦弗，ICSI
Daniel Weitzner, MIT
丹尼尔·魏茨纳，麻省理工
Magnus Westerlund, Ericsson
爱立信马格努斯·韦斯特隆德
Thomas Woo, Bell Labs
Thomas Woo，贝尔实验室
Steve Worona, EDUCAUSE
史蒂夫·沃罗纳，教育事业
Richard Woundy, Comcast
理查德·沃迪，康卡斯特
Haiyong Xie
谢海永
Richard Yang, Yale University
理查德·杨，耶鲁大学
1. Welcome/Note Well/Intro Slides Cullen Jennings
1. 欢迎/注好/介绍幻灯片Cullen Jennings
2. Service Provider Perspective (Comcast) Rich Woundy and Jason Livingood
2. 服务提供商透视（Comcast）Rich Woundy和Jason Livingood
3. Application Designer Perspective (BitTorrent) Stanislav Shalunov
3. 应用程序设计器透视图（BitTorrent）Stanislav Shalunov
4. Lightning Talks & General Discussion Robb Topoloski Nick Weaver Leslie Daigle
4. 闪电会谈和一般性讨论Robb Topoloski Nick Weaver Leslie Daigle
5. Localization and Caches Laird Popkin and Haiyong Xie Yu-Shun Wang Vinay Aggrawal
5. 莱尔德·波普金和海永·谢玉顺·王维奈·瓦勒的本地化和缓存
6. New Approaches to Congestion Bob Briscoe Marcin Matuszewski
6. 解决拥塞的新方法Bob Briscoe Marcin Matuszewski
7. Quality of Service Mary Barnes Henning Schulzrinne
7. 服务质量Mary Barnes Henning Schulzrinne
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
Paul Jessop-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
Bruce Davie、Stefano Previdi、Jan Medved、Albert Tian-同伴选择指导
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
蒋兴峰——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
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
谢海勇，Y.杨，Avi Silberschatz，Arvind Krishnamurthy，Laird Popkin-P4P：P2P应用程序提供商门户
Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly Peer-to-Peer Services
Michael Merritt，Doug Pasko，Laird Popkin-网络友好型点对点服务
Camiant (Jackson) - Camiant Submission
卡米安特（杰克逊）-卡米安特提交
Jason Livingood, Rich Woundy - Comcast Submission
Jason Livingood，Rich Woundy-康卡斯特提交
Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load Impact
Benny Rodrig-企业IP网络和P2P流量负载影响
Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences"
Ted Hardie-点对点流量和“无人看管的后果”
Jiang XingFeng, Ning Zong - Content Replication for Internet P2P
蒋兴峰，宁宗-互联网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-互联网规模移动服务：为ISP构建基于DHT的服务的案例研究
M. Barnes, B. McCormick - Peer to Peer Infrastructure Considerations
M.Barnes，B.McCormick-对等基础设施考虑因素
Henning Schulzrinne - Encouraging Bandwidth Efficiency for Peer-to-Peer Applications
Henning Schulzrinne-鼓励对等应用程序的带宽效率
Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri Papdimitriou - Towards an Open Path Selection Architecture
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 Agrawal，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
Leslie Daigle-定义成功：互联网和带宽密集型活动的未来问题
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
美国乔恩·彼得森纽斯塔尔酒店
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz
Alissa Cooper Center for Democracy & Technology 1634 Eye St. NW, Suite 1100 Washington, DC 20006 USA
Alissa Cooper民主与技术中心美国华盛顿特区西北眼街1634号1100室，邮编：20006
EMail: acooper@cdt.org
EMail: acooper@cdt.org