RFC5693：Application-Layer Traffic Optimization (ALTO) Problem Statement，October 2009
梗概
Internet 上流行的分布式应用程序——例如文件共享、实时通信以及实时和点播媒体流——使用了大量的网络资源。此类应用程序通常通过在分布在 Internet 上的节点之间建立的连接传输大量数据，而对底层网络拓扑知之甚少。一些应用程序被设计成从一个更大的集合中随机选择一个对等体的子集来交换数据。如果没有任何拓扑信息指导此类选择，或者根据从测量和统计中获得的次优或局部信息进行操作，这些应用程序通常会做出不太理想的选择。
本文档讨论与信息共享服务相关的问题，该服务使应用程序能够执行优于随机的对等体选择。
本备忘录的状态
本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。
版权声明
版权所有 (c) 2009 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可证文本，并且不提供 BSD 许可证中所述的保证。
1、 介绍
1.1、 概述
分布式应用程序，包括用于文件共享、实时通信以及实时和点播媒体流的点对点 (peer-to-peer，P2P) 和客户端/服务器，在路由器中使用大量网络容量和 CPU 周期 [WWW .wired.fuel]。与集中式应用程序相比，分布式应用程序访问分布在 Internet 上的文件或媒体中继等资源，并在它们直接与共享此类资源的节点建立的连接中交换大量数据。
高度分布式系统的一个优点是这样的系统提供的资源通常可以通过多个副本获得。然而，应用程序通常没有底层网络的可靠信息，因此必须在提供此类副本的可用对等体中进行选择，这些节点随机或基于它们从部分观察中推导出的信息，在某些情况下，这会导致次优选择。例如，一种对等体选择算法仅基于两个对等体之间初始连接建立期间的测量。由于实际数据传输并未开始，因此该算法仅测量往返时间，无法可靠地推断出对等体之间的实际吞吐量。因此，这种简单地使用往返时间的对等体选择算法可能导致对等体的次优选择。
当今的许多 P2P 系统使用由直接对等体连接组成的overlay网络。此类连接通常不考虑底层网络拓扑。除了性能欠佳之外，此类网络还会导致拥塞并导致严重的低效率。如 [ACM.fear] 中所示，流行的 P2P 应用程序产生的流量经常多次跨越网络边界，使经常受到拥塞影响的链接过载 [ACM.bottleneck]。此外，这种转接除了给用户带来糟糕的体验之外，对于网络运营商来说可能是相当昂贵的。
最近的研究（[ACM.ispp2p]、[WWW.p4p.overview]、[ACM.ono]）显示了这个问题的可能解决方案。互联网服务提供商 (Internet Service Providers，ISP)、网络运营商或第三方可以收集更可靠的网络信息。该信息包括拓扑或链路容量等相关信息。通常，与用于传输层拥塞控制的信息相比，此类信息的更改时间尺度要长得多。将这些信息提供给 P2P 应用程序可以使它们能够针对底层网络拓扑应用比随机更好的对等体选择。因此，有可能提高应用程序性能、减少拥塞并减少跨不同网络的总流量。据推测，应用程序和网络运营商都可以从这些信息中受益。因此，网络运营商有动力直接或通过第三方间接提供此类信息；应用程序有使用这些信息的动机。本文档讨论与信息共享服务相关的问题，该服务使应用程序能够执行优于随机的对等体选择。
第 2 节提供了定义。第 3 节介绍了这个问题。第 4 节描述了一些用例，其中 P2P 应用程序和网络运营商都从此类问题的解决方案中受益。第 5 节描述了设计此类解决方案时要考虑的主要问题。请注意本文档的配套文档“应用层流量优化 (Application-Layer Traffic Optimization，ALTO) 要求”[ALTO-REQS]，详细介绍了这些问题。
1.2、 最先进的
论文 [ACM.ispp2p]、[PATH-SEL] 和 [WWW.p4p.overview] 展示了解决本文档中描述的问题的当代解决方案提案的示例。此外，这些建议具有令人鼓舞的模拟和现场测试结果。这些和类似的、独立的解决方案都包含两个基本部分：
** P2P 应用程序用来寻找可靠信息源的发现机制，以及
** P2P 应用程序用于查询此类源的协议，以检索执行优于随机选择提供所需资源的端点所需的信息。
目前尚不清楚如果在 Internet 上全球部署此类解决方案将如何执行。但是，如果没有就基于开放标准的通用解决方案达成一致，则不太可能广泛采用。
2、 定义
以下术语在应用层流量优化 (ALTO) 问题的定义中具有特殊含义。
Application/应用
一种分布式通信系统（例如文件共享），它使用 ALTO 服务来提高其性能或体验质量，同时改善底层网络基础设施中的资源消耗。应用程序可以使用 P2P 模型来组织自己，使用客户端 - 服务器模型，或者使用两者的混合（即 P2P 模型和客户端 - 服务器模型之间的混合）。
Peer/对等体
应用程序中的特定参与者。通俗地说，对等体是指 P2P 网络或系统中的参与者，这个定义不违反该假设。如果应用程序的基础是客户端-服务器或混合模型，那么术语“客户端”和“服务器”的使用消除了对等体角色的歧义。
P2P
Peer-to-Peer，点对点。
Resource/资源
应用程序可以访问的内容（例如文件或文件块）或服务器进程（例如，中继媒体流或执行计算）。在 ALTO 上下文中，一个资源通常在多个等效副本中可用。此外，不同的对等体通常同时共享这些资源。
Resource Identifier/资源标识符
应用层标识符，用于标识资源，无论存在多少副本。
Resource Provider/资源提供者
对于 P2P 应用程序，资源提供者是提供某些资源的特定对等体。对于客户端-服务器或混合应用程序，提供程序是托管资源的服务器。
Resource Consumer/资源消费者
对于 P2P 应用程序，资源消费者是需要访问资源的特定对等体。对于客户端-服务器或混合应用程序，消费者是需要访问资源的客户端。
Transport Address/传输地址
资源消费者在特定资源提供者处访问所需资源所需的所有地址信息。此信息通常由资源提供者的 IP 地址和可能的其他信息组成，例如传输协议标识符或端口号。
Overlay Network/overlay网络
一个虚拟网络，由另一个网络顶部的直接连接组成，并由一组对等体建立。
Resource Directory/资源目录
在逻辑上与资源消费者分离并帮助资源消费者识别一组资源提供者的实体。一些 P2P 应用程序将资源目录称为 P2P 跟踪器。
ALTO Service/ALTO 服务
多个资源提供者可能能够提供相同的资源。ALTO 服务向资源消费者和/或资源目录提供关于选择哪个资源提供者的指导，以优化客户端的性能或体验质量，同时改善底层网络基础设施中的资源消耗。
ALTO Server/ALTO 服务器
为 ALTO 服务的查询提供接口的逻辑实体。
ALTO Client/ALTO 客户端
发送 ALTO 查询的逻辑实体。根据应用程序的架构，可以将其嵌入到资源使用者和/或资源目录中。
ALTO Query/ ALTO请求
从 ALTO 客户端发送到 ALTO 服务器的消息；它请求 ALTO 服务的指导。
ALTO Response/ALTO 响应
包含来自 ALTO 服务的指导信息作为对 ALTO 查询的答复的消息。
ALTO Transaction/ALTO 事务
由 ALTO 查询和相应的 ALTO 响应组成的事务。
Local Traffic/本地流量
停留在一个 Internet 服务提供商 (ISP) 的网络基础设施内的流量。这种类型的流量通常会使 ISP 的成本最低。
Peering Traffic/对等体流量
由网络直接连接的两个 Internet 服务提供商交换的 Internet 流量。除了基础设施和运营成本外，在对等体协议的合同范围内，对等体流量通常对 ISP 是免费的。
Transit Traffic/传输流量
互联网服务提供商 (ISP) 之间根据经济协议交换的互联网流量。ISP 通常为传输在其网络与 ISP 没有直接连接的远程网络之间流动的流量而向中转提供商支付费用。
Application Protocol/应用程序协议
应用程序用于在对等体之间建立overlay网络并在其上交换数据以及在对等体和资源目录之间交换数据（如果适用）的协议。这些协议在整个 ALTO 架构中发挥着重要作用。但是，定义它们超出了 ALTO WG 的范围。
ALTO Client Protocol/ALTO 客户端协议
用于在 ALTO 客户端和 ALTO 服务器之间发送 ALTO 查询和 ALTO 回复的协议。
Provisioning Protocol/供应协议
用于向 ALTO 服务器填充信息的协议。
图 1：ALTO 元素之间的协议交互概述
图例： === ALTO 客户端协议 *** 应用程序协议（超出范围） ... 配置或初始化（超出范围）
图1显示了 ALTO 客户端协议的范围：对等体或资源目录可以像 ALTO 客户端一样使用这样的协议来查询 ALTO 服务器。拓扑信息到 ALTO 服务的映射以及对等体和资源目录之间的应用程序协议交互超出了 ALTO 客户端协议的范围。
3、 问题
长期以来，网络工程师一直面临流量优化的问题，并设计了 MPLS [RFC3031-MPLS：多协议标签交换架构] 和 Diffserv [RFC3260] 等机制来应对。这些协议解决的问题在于为在特定源地址和目标地址之间传输的数据包寻找（或设置）最佳路由（或路由器中的最佳队列）。解决方案基于低延迟、高可靠性和优先级等要求。此类解决方案通常在链路层和网络层实施，并且往往几乎是透明的。
然而，一般的分布式应用程序，特别是用于例如文件共享的带宽贪婪的 P2P 应用程序，不能直接使用上述技术。通过与了解网络拓扑的外部服务合作，应用程序可以极大地改善它们生成的流量。实际上，当 P2P 应用程序需要建立连接时，逻辑目标不是稳定的主机，而是可以在不同对等体的多个实例中可用的资源（例如，文件或媒体中继）。从重叠拓扑邻近度中选择好的主机对生成的整体流量有很大影响。
请注意，虽然流量考虑很重要，但其他几个因素也会影响分布式应用程序用户体验的性能。这些包括需要避免使单个节点过载，在文件的稀有部分在多个节点可用之前获取文件的稀有部分，等等。然而，关于拓扑条件的更好信息确实在一个重要方面改进了整体选择算法。
优于随机的对等体选择在过程的初始阶段很有帮助。考虑 P2P 协议，其中查询对等体接收资源所在的候选目的地列表。从这个列表中，对等体将派生出一小部分候选者来连接和交换信息。在另一个示例中，流视频客户端可以被提供有目的地列表，它可以从这些目的地流传输内容。在这两种情况下，在早期阶段使用拓扑信息将允许应用程序提高其性能，并将帮助 ISP 更好地利用其网络资源。特别是，ISP 的经济目标是减少域间链接上的传输流量。
解决应用层流量优化 (ALTO) 问题一方面意味着部署 ALTO 服务以向应用程序提供有关底层网络的信息，另一方面，增强应用程序以使用此类信息以更好地执行——与他们建立连接的端点的随机选择。
4、 用例
4.1、 文件共享
文件共享应用程序允许用户搜索其他用户共享的内容并从其他用户下载各自的资源。例如，搜索结果可以由来自多个来源的同一文件（或文件块）的许多实例组成。ALTO 解决方案的目标是帮助节点根据底层网络找到最好的。
在应用程序方面，ALTO 功能的集成可能发生在不同的级别。例如，在完全去中心化的 Gnutella 网络中，最佳资源的选择完全取决于用户。在 BitTorrent 和 eDonkey 等系统中，跟踪器或服务器等中心元素充当中介。因此，在前一种情况下，改进需要在应用程序中进行修改，而在后一种情况下，它可以仅在某些核心要素中实施。
4.2、 缓存/镜像选择
流行内容的提供者，如媒体和软件存储库，通常采用地理分布的缓存和镜像来进行负载平衡。今天，为给定用户选择合适的镜像/缓存是基于不准确的地理定位数据、专有网络定位系统，或者通常委托给用户自己。可以轻松采用 ALTO 解决方案，以自动方式简化此类选择。
4.3、 直播媒体流
用于直播流媒体的 P2P 应用程序允许用户以实时或接近实时的方式接收由一个源生成并针对多个目的地的多媒体内容。这对于不支持多播的用户或网络尤为重要。对等体经常参与内容的分发，充当接收者和发送者。ALTO 解决方案的目标是帮助对等体找到交换媒体内容的有效通信对等体。
4.4、 实时通讯
P2P 实时通信允许用户为实时音频、视频和实时文本通话或进行文本聊天建立直接媒体流。在基本情况下，媒体直接在两个端点之间流动。然而不幸的是，由于 NAT、防火墙或代理，很大一部分用户对 Internet 的访问受到限制。因此，其他元素需要中继媒体。此类媒体中继通过具有公共地址的 Internet 分发。ALTO 解决方案需要帮助对等体找到最佳中继。
4.5、 分布式哈希表
分布式哈希表(Distributed hash tables，DHT) 是一类overlay算法，用于在流行的 P2P 系统中实现查找功能，而不使用集中元素。在这样的系统中，对等体在路由表中维护一组其他参与相同 DHT 的对等体的地址，根据特定标准进行排序。ALTO 解决方案可以为 DHT 算法提供有价值的信息。
5、 问题的层面
本节介绍一些人在第一次开始研究问题空间时可能没有意识到的问题的一些方面。
5.1、 ALTO 服务提供的信息
ALTO服务的目标是为应用程序提供信息，它们可以用来执行优于随机的对等体选择。原则上，有许多类型的信息可以帮助应用程序进行对等体选择。然而，并非所有要传达的信息都适用于类似 ALTO 的服务。更具体地说，可以非常迅速地变化的信息，例如传输层拥塞，超出了 ALTO 服务的范围。此类信息更适合通过传输层的带内技术而不是应用层的类似 ALTO 的带外技术进行传输。用于拥塞的 ALTO 解决方案要么具有过时的信息，要么必须由应用程序过于频繁地联系。最后，应用程序本身可以更准确地测量端到端延迟和可用带宽等信息。
通过带外 ALTO 服务向应用程序传达的有意义的信息类型是应用程序无法轻易获得的任何信息，并且其变化的时间尺度比用于传输层拥塞控制的瞬时信息长得多.此类信息的示例包括运营商的策略、地理位置或网络邻近度（例如，两个对等体之间的拓扑距离）、与向/从对等体发送/接收一定数量数据相关的传输成本，或允许的剩余流量量由同行的运营商（例如，在配额或有限的统一费率定价模型的情况下）。
5.2、 ALTO 服务提供商
至少三种不同类型的实体可以提供 ALTO 服务：
1. 网络运营商。网络运营商通常完全了解他们管理的网络，并了解他们的网络拓扑和策略。
2. 第三方。第三方是独立于网络运营商但可能收集了网络信息或与网络运营商安排了解网络信息的实体。此类实体的示例是 Akamai 等内容交付网络，它控制广泛且高度分布式的基础设施，或代表 ISP 提供 ALTO 服务的公司。
3. 用户社区。用户社区运行分布式算法，例如，用于估计 Internet 的拓扑结构。
5.3、 ALTO服务实施
对于读者来说，重要的是要了解有重要的用户社区期望 ALTO 服务器成为集中式服务。同样，还有其他用户社区期望 ALTO 服务是分布式服务，甚至可能基于或与 P2P 服务集成。
因此，人们可以合理地期望有某种服务发现机制与 ALTO 协议定义一致。
5.4、 用户隐私
一方面，ALTO 客户端可以在其对 ALTO 服务器的查询中提供数据元素，这有助于提高回复的准确度。例如，如果查询客户端指示它正在使用哪种应用程序（例如，实时通信或批量数据传输），服务器将能够在其答复中指示优先级，以适应应用程序将生成的流量的要求.另一方面，应用程序可能会认为此类信息是私密的。此外，一些应用程序可能事先不知道它们将发出什么样的请求。
5.5、 拓扑隐藏
运营商凭借其对网络拓扑的深入了解，可以在解决 ALTO 问题中发挥重要作用。然而，运营商往往认为泄露此类网络信息的细节是保密的。
5.6、 与缓存共存
缓存是一种改善应用程序产生的流量的方法，它需要大量的数据传输。在某些情况下，此类技术已被证明在增强用户体验和节省网络资源方面极为有效。
缓存，明确地或透明地，替换内容源。因此，原则上，缓存必须使用和支持与查询对等体相同的协议。也就是说，如果缓存存储 Web 内容，它必须向 Web 客户端提供 HTTP 接口。给定协议的任何缓存解决方案都需要向客户端呈现相同的协议。换句话说，不同协议的每个缓存解决方案都需要实现该特定协议。出于这个原因，人们只能合理地期望最流行的协议（例如 HTTP 和 BitTorrent）的缓存解决方案。
意识到缓存和 ALTO 是完全正交的非常重要。ALTO，特别是如果它知道缓存，实际上可以将客户端引导到附近的缓存，在那里用户可以获得更好的体验质量。
6、 安全考虑
本文档既不是需求文档，也不是协议规范。但是，我们认为读者必须了解安全和隐私领域，这对于 ALTO 解决方案的设计和实施很重要。此外，诸如数字版权管理之类的问题超出了 ALTO 的范围，因为它们在此级别在技术上是不可强制执行的。
在提供敏感信息之前，ALTO 的某些环境和用例可能需要客户端或服务器身份验证。为了以互操作方式支持这些环境，ALTO 要求文档 [ALTO-REQS] 概述了最低到实现的身份验证和其他安全要求。
应用程序可以决定依赖 ALTO 服务器提供的信息来增强对等体选择过程。原则上，这使得提供此类信息的 ALTO 服务能够影响应用程序的行为，基本上让第三方——ALTO 服务提供者——在以前没有参与的分布式系统中发挥重要作用。
例如，在由 ISP 部署和运行的 ALTO 服务器的情况下，P2P 社区可能认为这样的服务器是敌对的，因为运营商可以：
** 使用 ALTO 来防止内容分发和强制执行版权；
** 将应用程序重定向到提供恶意内容的损坏中介；
** 跟踪连接以执行内容检查或记录；
** 根据网络效率以外的标准应用策略。例如，服务提供商可能会从用户的角度建议次优路线，以避免受不方便的经济协议监管的对等体。
需要注意的是，P2P 应用程序没有要求 ALTO 的协议机制。如果由于某种原因，ALTO 无法提高 P2P 应用程序的性能，则 ALTO 将不会流行，P2P 社区也不会使用它。
在撰写本文时，第 5.4 节中描述的隐私问题与 ALTO 解决方案相关。用户可能不愿意向 ALTO 服务器披露敏感信息。另一方面，运营商可能不希望披露会暴露其内部拓扑细节的信息。在详细探索解决方案空间时，需要考虑这些问题，以便 ALTO 协议不会假定客户端或服务器必须强制披露信息。
7、 贡献者
本文档最初由 Enrico Marocco 和 Vijay Gurbani 编辑。作为工作组主席，他们继续为当前作者提供重要的编辑和意见。
8、 致谢
Vinay Aggarwal 和 P4P 工作组进行了在 IETF 之外完成的研究工作。Emil Ivov、Rohan Mahy、Anthony Bryan、Stanislav Shalunov、Laird Popkin、Stefano Previdi、Reinaldo Penno、Dimitri Papadimitriou、Sebastian Kiesel、Greg DePriest 和许多其他人提供了有见地的讨论、具体评论和急需的更正。
Jan Seedorf 和 Sebastian Kiesel 得到了 NAPA-WINE 项目（Network-Aware P2P-TV Application over Wise Networks，http://www.napa-wine.org）的部分支持，该研究项目由欧盟委员会根据其第 7框架计划（合同号 214412）。此处包含的观点和结论是作者的观点和结论，不应被解释为必然代表 NAPA-WINE 项目或欧盟委员会的官方政策或认可，无论明示或暗示。
特别感谢 Richard Yang 的几篇评论。
9、 参考资料
[ACM.bottleneck] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM, October 2003. [ACM.fear] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should ISPs fear Peer-Assisted Content Distribution?", ACM USENIX IMC, Berkeley 2005. [ACM.ispp2p] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved performance?", ACM SIGCOMM Computer Communications Review (CCR), 37:3, pp. 29-40. [ACM.ono] Choffnes, D. and F. Bustamante, "Taming the Torrent: A practical approach to reducing cross-ISP traffic in P2P systems", Proceedings of ACM SIGCOMM, August 2008. [ALTO-REQS] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", Work in Progress, April 2009. [PATH-SEL] Saucez, D. and B. Donnet, "The case for an informed path selection service", Work in Progress, February 2008. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [WWW.p4p.overview] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, "P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers", <http://www.dcia.info/documents/P4P_Overview.pdf>.
[WWW.wired.fuel] Glasner, J., "P2P Fuels Global Bandwidth Binge", April 2005, <http://www.wired.com>.
