BufferBloat：互联网怎么了？
与Vint Cerf、Van Jacobson、Nick Weaver和Jim Gettys的讨论
注意：请务必阅读本文的姊妹篇，Bufferbloat：互联网中的暗缓冲区。- 编者注
互联网延迟现在和恼人一样普遍。这意味着它们最终会像影响我们其他人一样影响系统工程师。当系统工程师感到恼火时，他们通常会去寻找问题的根源。以Jim Gettys为例。他缓慢的家庭网络反复被证明是相当沮丧的根源，因此他着手确定问题所在，甚至为他发现的问题创造了一个术语：bufferbloat（缓冲区膨胀）。
Bufferbloat（缓冲区膨胀）指的是网络内部过度的缓冲，导致高延迟和吞吐量降低。一些缓冲是必要的；它提供了空间来排队等待传输的数据包，从而最大限度地减少数据丢失。过去，内存的高成本使得缓冲区相当小，因此它们很快被填满，并且在链路饱和后不久数据包开始丢弃，向通信协议发出拥塞的存在信号，从而需要进行补偿调整。
由于现在内存比过去便宜得多，因此在各种网络设备中过度使用了缓冲，而没有考虑到后果。制造商们本能地采取行动来防止任何和所有的数据包丢失，这样做却无意中破坏了TCP关键的拥塞检测机制，结果导致拥塞恶化和延迟增加。
既然问题已经被诊断出来，人们正在热火朝天地修复它。本案例研究考虑了缓冲区膨胀问题的程度及其潜在影响。参与指导讨论的是Vint Cerf，他被大众誉为“互联网之父”之一。作为TCP/IP协议的共同设计者，Cerf在1972年至1976年在斯坦福大学以及1976年至1982年在DARPA（美国国防部高级研究计划局）工作期间，确实在开发互联网和相关的分组数据及安全技术方面发挥了关键作用。他目前担任谷歌的首席互联网福音布道师。
Van Jacobson目前是PARC的研究员，在那里他领导网络研究项目，他也是本次讨论的核心人物。Jacobson被认为是TCP领域的世界权威之一，他帮助开发了RED（随机早期检测）队列管理算法，该算法被广泛认为有助于互联网的发展，并在多年来满足了不断增长的吞吐量需求。在加入PARC之前，Jacobson曾担任Cisco Systems的首席科学家，后来在Packet Design Networks担任首席科学家。
参与讨论的还有Nick Weaver，他是ICSI（伯克利国际计算机科学研究所）的研究员，他是开发Netalyzr团队的成员，Netalyzr是一个分析网络连接的工具，在检测缓冲区膨胀和衡量其对整个互联网的影响方面发挥了重要作用。
完成讨论的是Gettys，他编辑了HTTP/1.1规范，并且是X Window System的共同设计者。他现在是Alcatel-Lucent贝尔实验室的技术人员，在那里他专注于系统设计和工程、协议设计以及自由软件开发。
VINT CERF 是什么促使您进行分析，从而得出结论，您的家庭网络存在与中间设备缓冲区相关的问题？
JIM GETTYS 我当时正在贝尔实验室的一个旧IPsec（互联网协议安全）类设备上运行一些带宽测试，并且观察到当设备以最快速度运行时，延迟高达1.2秒。这并没有完全让我感到惊讶，但后来我碰巧在没有IPsec盒子的干扰下运行了相同的测试，结果却相同。1.2秒的延迟伴随着可怕的抖动，我的家庭网络显然需要一些帮助。良好电话服务的经验法则是最多150毫秒的延迟，而我的网络几乎是这个数字的10倍。
我的第一个想法是问题可能与Comcast家庭服务中的一项名为PowerBoost的功能有关。这促使我给Comcast的Rich Woundy发了一张便条，因为他的名字出现在该功能的互联网草案上。他住在我隔壁的镇上，所以我们安排一起吃午饭。在午餐期间，Rich为我提供了几个拼图碎片。首先，他建议我的问题可能与我路径中设备中过度的缓冲有关，而不是与PowerBoost功能有关。他还指出，ICSI有一个很棒的工具叫做Netalyzr，可以帮助你弄清楚你的缓冲情况。另外，令我惊讶的是，他说许多ISP告诉他，他们运行网络时没有任何队列管理——也就是说，他们没有在任何路由器或边缘设备上运行RED。
第二天，我设法获得了一个精彩的跟踪结果。我之前一直难以重现我早先经历的问题，但由于这次我使用的是更新的电缆调制解调器，我有一个简单的单行命令来重现这个问题。由此产生的SmokePing图清楚地显示了问题的严重性，这促使我进行数据包捕获，以便我可以了解到底发生了什么。大约一周后，我在Verizon FiOS [一种通过光纤网络运营的捆绑式家庭通信服务] 上看到了基本相同的特征，这让我感到惊讶。无论如何，很明显，我在家庭网络上经历的事情并非有线调制解调器独有。
VC 我假设您不是唯一一个对这类问题发出抱怨的人？
JG 我一直都在听到类似的抱怨。事实上，大约一年前，Dave Reed [互联网网络架构师，现任SAP Labs] 报告了3G网络中也似乎是由过度缓冲引起的问题。当他公开他的担忧时，他最终被忽视了，但我后来已经能够证实Dave是对的。在他的案例中，他会看到白天每天都有高延迟，但没有太多数据包丢失，然后在晚上随着整个网络流量的下降，延迟又会降下来。
Dave Clark [互联网网络架构师，目前是麻省理工学院的高级研究科学家] 注意到他微型ISP运行的DSLAM（数字用户线路接入复用器）缓冲过多——导致延迟高达六秒。这是他在六年前观察到的，这也导致他警告Rich Woundy可能存在这个问题。
VC 也许这里有一个重要的人生教训，暗示您可能不应该仅仅因为异常值可能是侥幸而将它们抛弃。当异常值出现时，找出原因可能是一个好主意。
NICK WEAVER 但是，在测试这个特定问题时，异常值实际上被证明是良好的网络。
JG 如果没有Netalyzr，我永远不会确定我观察到的现象是否仅仅是几个侥幸。然而，在看到Netalyzr数据后，我可以看到这个问题 realmente 有多普遍。我仍然记得我第一次看到整个互联网的数据被绘制出来的那一天。那真是令人毛骨悚然。
NW 实际上，这是一个非常简单的测试，它允许我们捕获所有这些数据。在ICSI组装Netalyzr时，我们从一个设计理念开始，一位匿名评论员后来很好地概括了这个理念：“这为‘用扳手敲击它’这句话带来了新的含义。” 基本上，我们只是着手敲击一切——除了我们对进行带宽测试不感兴趣，因为那里已经有很多好的测试了。
然而，我记得Nick McKeown和其他人曾咆哮过家庭网络经常被证明是多么令人惊讶地过度缓冲，因此缓冲似乎是一个自然的测试对象。事实证明，这也将给我们带来带宽测试作为副作用。因此，我们开发了一个非常简单的测试。在短短的10秒时间内，它发送一个数据包，然后等待一个数据包返回。然后，每次它收到一个数据包返回时，它会再发送两个数据包。它可以发送大的数据包并接收小的返回数据包，或者发送小的数据包并接收大的返回数据包。在那10秒的最后五秒，它只是测量负载下的延迟与无负载下的延迟的比较。这本质上只是一种简单的方式来压力测试网络。
在发布该工具几个月后，我们才抽出时间分析所有这些数据。然后我们看到的是这些非常漂亮的图表，这些图表让我们有合理的信心，我们刚刚测试过的大部分网络不可能在负载下表现良好。这是一个非常可怕的发现。
JG 我认为，令人毛骨悚然。
NW 对我来说，这并没有那么令人毛骨悚然，因为我已经有效地采取措施来缓解我自己网络上的问题——也就是说，我为我的家庭网络支付了更高等级的服务费用，专门为了在负载下获得更好的表现。您可以这样做，因为缓冲区的大小都是以字节为单位的。因此，如果您为4倍带宽的服务付费，您的缓冲区在延迟方面将小4倍，这最终会成为负载下情况变得多糟糕的边界。并且我已经采取措施来减少其他潜在的问题——例如，通过在我的家中安装多个接入点。
JG 问题在于，下一代设备将配备更大的缓冲区。这就是为什么我最初在使用DOCSIS（有线电缆服务接口规范）3.0调制解调器重现这个问题时遇到麻烦的部分原因。也就是说，因为我拥有的缓冲比以前更加极端，所以需要更长的时间来填满缓冲区并使其开始表现异常。
VC 我认为您刚才概述的是一种衡量好坏的标准，后来证明这完全是错误的做法。起初，设备制造商认为添加更多缓冲区是一件好事，主要是为了处理增加的流量并提供对容量的公平访问。当然，购买一个不带大量内存的芯片也变得越来越困难。
NW 此外，在人们进行任何测试的程度上，他们都在测试延迟或带宽。我们正在讨论的问题是负载下的延迟问题，因此如果您仅测试静态延迟，您将不会注意到它；如果您仅测试带宽，您将永远不会注意到它。除非您专门测试负载下的行为，否则您甚至不会意识到正在发生这种情况。
VAN JACOBSON 我认为存在一个更深层次的问题。我们知道这些大队列的原因是数据堆积在网络中快速到慢速的转换处。这种情况通常发生在从互联网核心到用户的过程中（例如YouTube视频），或者从用户返回到核心的过程中，例如54兆比特的快速家庭网络命中1到2兆比特的慢速互联网连接。
在Jim的案例中，一台Linux机器默认传输大约一百万字节的数据，这相当于在2兆比特线路上的几秒钟延迟。Linux就是这样出厂的，YouTube服务器也是这样开箱即用的。除非这些东西被重新配置，否则它们会发送一百万字节的数据。
所有这些数据都流经网络，直到它堆积在用户链路上。如果某个制造商生产的家用路由器缓冲区非常小，数据将被丢弃，并且该制造商将很快获得制造劣质路由器的声誉。然后，竞争对手肯定会说，“那个路由器的丢包率是90%，所以您应该选择我的盒子，因为它有足够的内存来避免丢失任何东西。” 这就是我们最终面临市场压力，迫使制造商在其设备中放入越来越大的缓冲区的原因。
JG 这不仅仅是宽带边缘的一种现象。在追根溯源以弄清楚为什么我的家用路由器表现如此糟糕的过程中，我发现我们所有的操作系统——Linux、Windows和Macintosh——也都犯了过度缓冲的错误。这种现象渗透到整个路径。您绝对无法在任何单个位置修复它。
VJ 将此视为网络版本的“相互确保摧毁”。除非您能让每个人都合作减少每个设备的缓冲区，否则任何提供商的正确策略都是增加其缓冲区。如果您在Wi-Fi中放入更多缓冲区，您可以使您的Wi-Fi工作得更好。这也是使您的路由器工作得更好并使您的终端系统工作得更好的方法。
JG 我要反驳这一点。您可以在某些非常有限的方式下使事情“更好”。但是，如果您只测量带宽，那么您就看不到您通过助长甚至例行的网络服务（例如IP地址查找）的失败而造成的所有破坏。这些类型的故障现在很常见，部分原因是这些大缓冲区及其造成的长时间延迟与底层协议背道而驰。
VJ 你是在对唱诗班布道，吉姆。
***
过度缓冲在很大程度上破坏了TCP的拥塞避免机制，这些机制依赖于及时的少量数据包丢弃来检测拥塞。通过缓冲，一旦数据包到达瓶颈，它们就开始排队。如果进入的数据包多于可以传输的数据包，则队列会变长。队列中的数据包越多，延迟就越高。最终，数据包被丢弃，从而将拥塞情况通知给通信协议。
缓冲区膨胀允许这些队列增长过长，然后才丢弃任何数据包。结果，缓冲区被数据包淹没，然后需要一段时间才能耗尽，然后才能允许任何额外的数据包进入。最终用户看到的只是响应变慢。需要低延迟的服务（例如网络游戏、VoIP或聊天程序）可能会慢到无法使用的地步。
此外，由于问题的普遍性，人们越来越担心互联网本身的稳定性可能会受到损害。
VC 我们一直在讨论的关键问题是，所有这些过度的缓冲最终会破坏我们网络协议中内置的许多超时机制。这就引出了一个问题，即这个问题到底有多糟糕，以及随着网络边缘的速度继续提高，这个问题可能会变得多糟糕。我假设随着缓冲区开始更快地填满，问题只会变得更糟。
NW 不，实际上，这将使情况变得更好。虽然更大的问题确实与缓冲区太大有关，但如果您从时间而不是容量的角度来看待您自己的情况，并且您可以设法使您的链路性能提高一倍，那么您应该可以将您的延迟减少一半。
VC 说得好。这里的问题似乎围绕着缓冲区需要多长时间才能填满。如果是在慢速线路上，那将需要很长时间，然后缓冲区将容纳所有这些东西并永久损害往返时间。
JG 然而，基本的观察结果更加微妙，因为实际上缓冲区没有一个单一的正确大小。以无线为例，您很容易在带宽上出现两到三个数量级的差异。我们的宽带系统可以运行高达100兆比特或更高，但在低端，它们仅提供10兆比特或更少。这本身就是一个数量级的波动。没有一个静态大小在任何时候都是有意义的。
NW 更糟糕的是，如果您从时间角度考虑——例如，您将缓冲区大小设置为X毫秒而不是X千字节（您可以使用稍微多一点的逻辑来做到这一点）——这仍然不能完全解决问题。它为您提供了90%的解决方案，因为这仍然会在负载下引起一些延迟。它将被限制在最大延迟点——或者如果您仍然希望实现完整的TCP吞吐量，则约为简单队列的负载下最小延迟。
VJ 它甚至不适用于Jim的Wi-Fi示例。移动您的Wi-Fi接收器两英寸，您的吞吐量可能会从100兆比特下降到1兆比特，这意味着您的队列延迟将增加100倍。在这种情况下，根本没有静态缓冲区管理策略——也没有静态缓冲区大小可以工作。
VC 这表明任何有效的方法都必须是动态和适应性强的。但这也引出了一个奇怪的问题，即您网络边缘的设备最终可能会与网络中不同位置的设备进行通信，这些设备具有不同的路径动态。这就引出了一个问题，即您如何观察流量并区分它们。如果我们想要朝着动态调整缓冲区延迟（如果允许我使用这个术语而不是缓冲区大小）的方向发展，以适应您在任何给定时间可能尝试参与的所有各种流量，那么这是否会成为必要的事情？
VJ 不会。您实际上在互联网上移动的是数据包，并且很难分辨哪些数据包构成“流”。然而，我们所知道的是，数据堆积在快速到慢速的转换处，而其他任何地方都不会堆积。该转换的上游端的路由器知道那里有一个巨大的队列正在堆积。如果您可以某种方式在您可以实际看到队列形成的点上缓解队列，或者至少向端点发出关于它们正在创建的队列的信号并告诉它们需要处理这个问题，那么您就不需要进行任何类型的复杂流量分析。
VC 这个队列会出现在网络中的任何地方，而不仅仅是在边缘吗？
VJ 理论上是的。但我认为这个理论上的结论阻碍了该领域的许多工作，因为它导致人们认为这个问题可能存在于任何地方。然而，互联网的经济学倾向于确保一个高带宽的核心，我们在那里聚合来自许多低带宽链路的流量。还要记住，您正在聚合的各个用户是不相关的，因此当您将他们不同的流量流加在一起时，流量往往会变得更平滑。这就是Nick McKeown几年前在谈论核心中过度缓冲时提出的观点。那里真的不需要巨大的缓冲区，因为您正在处理这些巨大的聚合，从而导致流量非常平滑。
NW 关于互联网核心的另一个问题是，一旦您开始谈论10千兆比特以上的链路，缓冲区就会变得非常昂贵。有趣的是，如果您与Internet2的人员交谈，他们对核心路由器的抱怨与缓冲区不足有关，因为他们的测试涉及10千兆比特链路上的单流TCP或少流TCP吞吐量。为此，您实际上确实需要大量的缓冲，但这对于许多核心路由器来说，目前在经济上是不可行的。
VJ 但这也是阻碍这里进展的另一件事——所有旨在最大化超级计算机中心之间带宽的研发。请记住，到目前为止，美国的大部分网络研究都是由NSF（国家科学基金会）资助的，目标是展示学术机构之间非常高的带宽。这对于拥有这些链路的互联网社区的0.01%的人来说很棒，但对于世界上其他拥有2兆比特或更少带宽的10亿人来说，并没有太大的好处。
我们已经在协议、路由器和算法开发方面投入了大量精力，这使得单个TCP有可能饱和40千兆比特的链路，但我们甚至没有投入任何类似的努力来生产可用的手机数据链路、DSL链路或家庭电缆链路。这才是真正困难的问题，因为它要求您开始思考缓冲实际上是如何工作的，以及它是如何转化为延迟的。
VC 我们实际上正在围绕着这样一个事实打转，即由于环境原因，这是一个难题。我们应该讨论我们目前是否正面临危机，如果是，该怎么办。
JG 我们甚至不知道当前的状态是否会保持稳定。当我考虑到仅仅是一个TCP流的痉挛行为，以及大部分时间发生的这些狂野的偏移时，我感到非常紧张。在我看来，我们目前的情况根本不是静态的。
我们正在看到许多新的应用程序——例如流媒体视频和异地系统备份——它们更有可能使链路饱和。所有这些应用程序都开始变得更加日常化，与此同时Windows XP正在退役。这实际上是一个重要的里程碑，因为Windows XP没有实现窗口缩放，因此它往往不像最近发布的任何东西那样使链路饱和。也许我有点偏执，但我真的不喜欢我现在看到的情况。
NW 现在是否存在任何主要的TCP堆栈不进行适当的窗口缩放，因此不会将所有内容饱和到接近千兆比特链路？
JG 我认为它们现在都进行窗口缩放——至少任何比Windows XP更新的东西都是如此。Windows、Mac OS X和Linux都很乐意运行到多千兆比特的速度。
VJ 但数据包输出不是由窗口缩放驱动的。窗口缩放只是为您提供了扩展窗口的空间，但只有当系统默认设置为大窗口时，它才会扩展。多年来，默认窗口的大小被设置为适合当时您通常发现的约100毫秒/1mbps的TCP路径。在过去五六年中的某个时候，人们已经决定，通用路径应该被认为是千兆比特或更高。因此，缓冲区大小已增加到超过一百万字节。
NW 不幸的是，情况几乎完全如此。事实上，如果您看一下我的房子，从我的计算机到文件服务器，我有一个10毫秒以上的千兆链路。
VJ 您是否做过改变窗口大小的实验，然后查看您到文件服务器的吞吐量，作为窗口大小的函数，看看您是否真的需要一百万字节？
NW 不，我没有。
VJ 好吧，我做过，带宽在八个数据包窗口处趋于平稳。我指的是运行最新内核的Linux文件服务器。通常情况下，情况是您处于具有大带宽和非常短延迟的家庭环境中，或者您正在通过互联网出境，在那里您将遇到小带宽和更长的延迟——通常比您在家中拥有的延迟长10倍或更多。您可以选择一个适合互联网的窗口大小——例如100千字节，即10千比特到100毫秒——这对于您的家庭环境也绰绰有余。
但这并不是我们现在看到的。相反，我们发送的是几兆字节，那时您会听到抱怨：“哦，我的上帝，我看到一秒钟的延迟。” 嗯，是的，当然。这就是您的系统配置方式。
JG 更重要的是，您会在几个不同的地方发现这种事情。操作系统本身可能存在问题。如果您查看设备驱动程序，您会发现它们也增加了一些非常大的缓冲区。基本上，无论何时您查看我们当前的任何操作系统内部，您都会发现缓冲区膨胀在多个层中反复出现的主题。
这实际上是问题的一部分：人们将此视为一个层系统，他们不必担心一切实际上是如何工作的，无论是在他们之上还是之下。他们并没有真正考虑清楚他们正在做的事情的所有后果——而且它显示出来了！
***
如果我们真的面临迫在眉睫的危机，该怎么办？缓冲区膨胀提出了一个难题，没有单一的正确解决方案。在缓解当前局势方面取得进展将需要ISP、操作系统实施者、应用程序供应商和设备制造商共同努力。
由于网络硬件显然是主要罪魁祸首，因此似乎减少缓冲区大小应该是真正必要的全部措施。但是缓冲区大小无法在大多数路由器和交换机上配置。缓冲区大小也不能是静态的。它必须是动态调整大小的，这意味着将需要硬件和软件修改。
目前还在研究一些新的队列管理算法。尽管经典的RED队列管理方法可以作为其中一些研究的起点，但它本身并不足以应对当前的挑战。尽管如此，创建RED改进版本的努力已经在进行中。
VC 听起来缓冲区较小的设备肯定有助于防止许多最坏情况的发生，仅仅是因为没有足够的缓冲区空间来造成如此大的问题。我想，另一种可能性是提供一种方法来丢弃备份的数据包，并在您看到队列堆积时向拥塞源发送摘要报告。但这又回到了这个尴尬的问题，即除非您正在监视源/目标对流量或类似的东西，否则您不知道拥塞源可能是什么。鉴于我们现在似乎对问题的性质有所了解，您能否稍微推测一下，如果可以采取任何措施来解决这个问题？
VJ 您刚才描述的方法是RED背后的基本思想：每当您有一个大队列时，您都应该通知一个或多个端点存在问题，以便它们将减小窗口，从而减少队列。这提供了一种替代跟踪流量的方法，而跟踪流量充其量是一个非常占用状态的问题。而且使用IPv6，它可能会变成一个不可能的问题，因为不想被监管的人会只是将流量分散到无数个地址上，并且无法检测到这些是单独的流量还是都来自单个用户。
与其试图推断流量，不如选择一个均匀分布的随机数，当具有该数字的数据包出现时，标记或丢弃它。因此，例如，如果90%的数据包来自一个来源，您将有90%的概率丢弃的数据包来自该来源。
NW Case Western Reserve University 针对远程队列管理提出了一个很酷的小想法。基本上，他们的观察是，如果你位于所有流量都经过的路径上——例如，与线缆调制解调器分离的 NAT（网络地址转换）——你可以跟踪延迟增加。一旦延迟增加超过某个阈值（例如，100 毫秒），你就可以开始使用 RED 方法进行队列管理，或者采取任何你需要做的措施来让流量退避。然而，这个问题在于，它只为电话用户提供了 80% 的解决方案。
VJ 如果我理解那里提出的建议，你是要安装一个设备来测量延迟，但是如果你查看的是聚合流量，你不知道它是如何解聚合的。
NW 这部分解释了为什么这个提议侧重于家庭网关。基本上，在任何时间点，通过你的 NAT 盒的大型流量都不多。
VJ 但是如果你在网关上，你已经有了队列，所以你根本不需要任何状态。队列本身就是状态。
JG 家庭网络甚至考虑队列管理的原因之一是，许多宽带网络根本不提供任何队列管理。我最近读到一篇论文，指出高达 30% 的住宅宽带网络在没有任何队列管理的情况下运行。这使得家庭路由器来处理这个问题。然后，我们又遇到了无线带来的巨大动态范围的复杂性。Van 告诉我，经典的 RED 不能用来解决那个特定的问题。
VC 我正在尝试思考我们如何开始朝着解决方案迈进。似乎至少有三个不同的方面需要考虑。首先，是正在遭受缓冲区膨胀影响的一方，例如，在住宅环境中。然后是服务提供商，我相信他们真的想为客户提供更好的服务质量。最后，是所有那些设备和软件供应商，如果他们认为这样做会让 ISP 和最终用户更满意，他们可能会被说服来解决这个问题。
问题是：在什么条件下我们才能让所有这些参与方合作？或者这是否将主要停留在研究问题上？
NW 嗯，已经有几个案例，应用程序供应商得出结论，他们造成了太多的损害，因此开始做出改变。BitTorrent 就是一个典型的例子。它正在转向基于延迟的拥塞控制，专门为了：（a）对 TCP 更加友好，因为 BitTorrent 携带的大部分数据实际上是较低优先级的；以及（b）缓解“你不能同时运行 BitTorrent 和 Warcraft”的问题。所以，还是有一些希望的。
JG 对。还有许多其他队列管理算法，除了经典的 RED 之外，我们已经准备好开始试验了。Van 正在与 Kathie Nichols [Pollere Inc. 的创始人兼 CEO，专门从事网络架构和性能] 合作开发一种他们称之为 RED Lite 的东西，我们希望很快开始尝试。还有一种名为 SFB（随机公平蓝）的队列管理算法，已经在 Linux 中实现，我们现在正准备试用它。
我们中的许多人现在正在尝试设置 OpenWrt（一个用于嵌入式设备的基于 Linux 的程序），以便我们可以构建，至少作为原理验证，一个表现良好的家庭路由器，甚至可能运行得相当好。
VJ 还有一个独立的方面很重要，需要理解。因为这个问题没有静态的答案，没有适用于所有环境的正确答案，而且任何答案都需要随着时间推移而演变。人们需要一些无需动脑筋、易于使用的测量工具，来说明“你的家庭路由器的延迟变得非常糟糕”。
例如，YouTube 是受缓冲区膨胀问题严重影响的一个群体。它能够观察到住宅链路的上游端的拥塞情况。在他们的服务器上添加工具来测量每个发送出去的视频的缓冲延迟，然后将其与目标 IP 地址关联起来，这将非常简单。可以在个人级别（通过播放器）、前缀级别或网络级别查看，以提供对延迟发生位置的一些了解。
JG 真正重要的问题只发生在带宽转换点。在其他任何地方，过多的缓冲可能根本不重要，除了浪费内存。但在网络的边缘，我们现在肯定受到了相当严重的损害。这适用于操作系统、家庭路由器、人们家中发现的宽带设备，以及安装在 ISP 端的宽带设备。因此，在这四个地方中，我们当然应该专注于开发一些简单的工具，可以帮助人们识别他们的问题来自哪里。
VJ 我家有四个家庭成员。过去我们谁都不在网上看视频，但现在每个人都在网上看视频或玩游戏，或者试图同时做这两件事。只需要一个人在看 YouTube，而另一个人在看 Netflix，就会完全饱和 Internet 到家庭的链路。
这不是 YouTube 或 Netflix 或家庭中任何人的错。这只是人们现在使用 Internet 的方式。这是一个我们需要解决的问题，以便人们可以继续以他们已经习惯的方式使用 Internet。
***
随着对流媒体视频和远程数据备份和存储等互联网密集型活动的需求增长，缓冲区膨胀问题可能会恶化，在线用户体验势必会因此而恶化。这个问题在网络边缘最明显，但在互联网核心、公司网络以及 ISP 之间的边界也可以找到它的踪迹。除了呼吁人们可以使用的简单工具来查找和测量缓冲区膨胀外，所有设备的主动队列管理也是必要的。然而，最适合这项工作的算法仍有待确定。
VC 之前有人提到使用运营商级 NAT 来跟踪延迟增加。但在我看来，即使它们位于可以检测到拥塞的位置，可能仍然存在问题。也就是说，如果你位于拥塞的下游，并且你的设备中有过多的缓冲区，问题仍然会持续存在。这是一个正确的观察吗？
VJ 不，因为你在任何快速到慢速的转换处都会遇到问题，这将在流量从高带宽 Internet 移动到用户链路的任何地方发生。
VC 那么，除非转换发生在你之前的数据流中，否则运营商级 NAT 不一定会有所帮助？
VJ 完全正确。你可以做一些非常复杂的事情来弄清楚这一点，但这真的很难，而且远非 100% 可靠。归根结底，你想要在大型队列所在的任何地方解决问题。
VC 现在可能是提出一个更普遍的问题的好时机，即为什么控制系统除非恰好拥有完全正确的信息（即，与该系统的核心算法最匹配的任何信息）才能良好地工作。我从这次对话中得到的印象是，要获得所有有助于弄清楚在任何时刻合适的缓冲区大小应该是多少的信息，这已被证明是困难的。
VJ 这是真的，我是误传信息的主要贡献者。我帮助人们走上了错误的道路，使用了 RED，它试图从平均队列大小中提取一些信息，但事实证明，从平均队列大小中什么也学不到。
后来有一些关于算法的工作，例如密歇根大学的 BLUE 和爱尔兰汉密尔顿研究所正在开发的后继算法，它们都关注队列高于阈值的时间，这比从队列大小中获得的任何信息都更可靠。
但是有一个问题。你需要大约 100 毫秒的队列才能启动你的连接。你将一个窗口的数据包传递到瓶颈，这暂时创建了一个队列，队列排空到线路中，一切都平稳运行，没有队列。如果你没有那个队列，你将获得可怜的吞吐量和大量的丢包，所以这是好的队列。但是，当你将一秒钟的数据转储到 100 毫秒的路径中，最终得到一秒钟的队列时，它会永远停留在那里。那是坏的队列：它对你没有任何好处；它只是产生延迟。
需要的是一种可以区分好队列和坏队列的算法。这需要动态分析，事实证明这相当容易。队列的时间行为区分了好坏，因为好的队列会消失，而坏的队列不会。如果你只跟踪一段时间内的最小值，那么低于该最小值的所有内容都可以被认为是坏队列，而高于它的所有内容都可以被认为是好队列。
VC 很高兴听到你说你可以应用相当简单的动态分析技术来区分网络中数据速率转换点的好队列和坏队列。至少对于住宅环境而言，设计更具适应性的边缘设备可能是有希望的。
VJ 我对此相当乐观。
VC 让我们为了讨论假设设备制造商认识到存在问题，甚至进一步表示愿意合作，并且 ISP 也表示他们准备购买合适的设备。那么，是否有可能或适当地在这些设备中加入测量能力，以检测任何后续问题，或者至少提供一些关于队列管理算法在部署后运行状况的认识？
VJ 我们肯定希望拥有自测量能力，但它可能不应该驻留在设备中。最终用户才是那些遭受这些问题痛苦的人，他们需要能够查明原因。为最终用户提供工具非常简单。TCP 的正常往返时间测量显示了你的流量正在经历的延迟。如果延迟过高，你可以使用 Netalyzr 或 Pathchar 等工具来确定延迟发生的位置。
JG Steve Bauer [MIT 的] 和我就此与 Speedtest.net 的母公司 Ookla 的 Doug Suttles 进行了对话。我们都同意我们需要最终用户工具来指出路径中缓冲区膨胀的位置。Doug 非常感兴趣，所以希望我们能够在这方面做些什么。
我想提出的另一点是，虽然最严重的问题似乎出现在边缘，但我们知道在其他地方也存在缓冲区膨胀问题，例如各个 ISP 之间的边界，有时你会发现拥塞。我也在 IPsec 隧道终止的任何地方看到问题，我认为许多公司网络现在可能在没有任何队列管理的情况下运行。随着越来越多的在线机器能够轻松地饱和公司网络链路，我们将发现这个问题变得越来越严重。
正在做一些事情，通过允许根据延迟或带宽标准动态调整某些设备的缓冲，而不是仅仅给人们一个静态大小的缓冲区并保持不变，从而在非常短的时间内提供缓解。
例如，有线电视行业甚至现在正在进行一些这方面的更改，以减轻问题的严重性。尽管如此，真正需要的正确解决方案是在任何地方都进行真正的队列管理。
VC 我想知道是否有可能说服设备制造商，改变缓冲区的使用方式符合他们的最佳利益——特别是允许最终用户缓冲区大小的扩展具有更大的动态性。
到目前为止，你所做的是说明了问题的性质以及问题发生的条件，这至少应该作为一个重要的起点。这次讨论清楚地表明这个问题有多么困难。这也是一个重要的问题，因为除非我们找到比现在更好的解决方案，否则人们对网络的体验不太可能最终是愉快的。
喜欢它，讨厌它？请告诉我们
© 2011 1542-7730/11/1000 $10.00
最初发表于 Queue vol. 9, no. 12—
在 数字图书馆 中评论这篇文章
© 保留所有权利。