原文: https://www.compiralabs.com/ultimate-guide-congestion-control
指南上半部分：链接
TCP 的基于模型与无模型替代方案
如果您打算为最后一英里网络等环境设计新的拥塞控制算法，则很难完全表征该算法将遇到的所有网络条件。在这种情况下，拥塞控制算法设计者必须决定他们可以合理地假设网络什么，以及他们可以从观察中自信地推断出哪些参数。
TCP 的替代方案主要有两种类型：基于模型的算法和无模型算法。它们之间的根本区别在于它们是否基于有关网络及其行为方式的假设。
基于网络模型的算法依赖于网络环境的表示，即网络的模型。该模型基于假设和观察到的网络动态的推论。该算法使用模型来预测网络动态如何演变以及不同的发送速率将如何影响性能。
无网络模型算法将网络视为无法精确建模的黑匣子。在没有任何预测基础的情况下，无模型算法会观察不同发送速率产生的性能，并根据经验寻找速率和性能之间的“良好”映射。
这两类算法具有不同的优势。如果您确信您的假设和推论是正确的，那么基于模型的算法将为您带来比无模型算法的实验方法快得多的有效发送速率。但如果您的假设有误，您在尝试为模糊网络找到最佳发送速率时会遇到很多挫败感。
想象一下总带宽为 100 Mbps 的链路上的单个连接。最佳发送速率为 100 Mbps。具有准确模型的基于模型的算法将以 100 Mbps 开始，因此几乎立即达到最佳发送速率。但这只有在拥有准确的模型时才会发生。如果由于带宽实际上是 200 Mbps 或者发送者在链路上并不孤单而导致模型不正确怎么办？该算法要么无法充分利用链路，要么发送流量过快并导致数据包丢失。相比之下，无模型方法可能会花费宝贵的时间探索不同发送速率对性能的影响。但是，如果基于模型的方法有错误的模型，则无模型算法可能会优于基于模型的算法，因为它不需要纠正错误的现实模型。
基于模型的方法非常适合可预测的网络，可以从准确的网络模型开始。其中一些例子是 Google、Facebook 和 Amazon 等大型组织内的私有内部网。这些网络稳定且表现良好；网络的所有基础设施都处于集中控制之下。
无模型方法最适合难以准确建模的复杂网络环境，并且在动态条件下本质上更加稳健。在互联网的最后一英里，条件不断变化（正如我们上面讨论的），因此无模型算法通常更合适。
我们将更深入地研究两种拥塞控制选项。BBR 是典型的白盒、基于模型的方法，最初由 Google 为其内部网络开发。PCC 是黑盒、无模型方法的范例，也是 Compira Labs 解决方案的基础。
BBR - 一种白盒、基于模型的拥塞控制方法
BBR是瓶颈带宽和 RTT 的缩写，是 TCP 最著名的替代方案之一。BBR 是一种用于传输 YouTube 流量的拥塞控制算法。它也被 Netflix 和其他一些重要的播放器所采用。
简单之美
BBR 本质上非常简单。这是该算法的基本结构。
想象一下，一个发送者正在向另一个通信端点发送数据。沿着路线的某个地方，数据遇到了瓶颈链路。虽然流量可能穿越一个非常复杂的网络，其中有多个网段和不同的竞争，但对 BBR 来说重要的是路径最窄点的带宽。我们不知道是什么导致了瓶颈；这可能是来自其他流量、低带宽或多个其他问题的竞争加剧。BBR 通过将整个旅程简化为单个链路（即瓶颈的宽度）来对整个网络进行建模。它探测网络以推断瓶颈带宽，然后调整其发送速率以匹配该带宽。我们在下面解释 BBR 如何做到这一点。
BBR 是如何工作的？
为了确定瓶颈链路带宽，BBR 不断检查其发送速率相对于数据包到达接收器的速率。考虑带宽为 100 Mbps 的链路上单独的发送者。现在，假设链路没有拥塞。在这种情况下，数据包到达端点的速率应与离开发送方的速率大致相同；这意味着 ACK 也将以大致相同的速率到达发送方。在我们的示例中，如果发送速率为 50 Mbps，ACK 也应以 50 Mbps 到达。但是，如果发送速率超过带宽并且链路饱和，则流量将以与带宽相同的速率到达接收器，因为这是链路可以支持的最快速率。ACK 也应该以大致该速率到达发送方，在我们的示例中为 100 Mbps。如果发送速率保持高于带宽，则随着数据包排队等待传送，队列将开始形成。通过比较发送速率和ACK到达速率，BBR可以判断其速率是否超过了链路带宽，并估计该带宽是多少。BBR估计的瓶颈带宽是BBR的最佳工作点。它充分利用链路而不超出带宽，因此损失和延迟保持在最低限度。
要了解 BBR 如何选择何时以及如何增加/减少其发送速率，让我们继续使用 100 Mbps 链路上的单个发送者的简单示例。与 TCP 一样，BBR 以慢启动模式开始，每个 RTT 的速率加倍。这种情况一直持续到发送速率超过估计的瓶颈带宽。当这种情况发生时，BBR 会降低其速率以匹配估计的带宽并进入拥塞避免模式。BBR定期将速率提高25%，以检查瓶颈带宽是否发生变化。如果接收速率同步上升，BBR 知道它可以继续保持更高的速率。如果接收速率没有随着发送速率的增加而增加，则数据包的发送速率显然高于网络可以支持的速率。这意味着缓冲区中有一行数据包正在等待，这可能会导致数据包丢失或过度延迟。为了解决这个问题，BBR 会定期将发送速率降低到低于之前标准的 25%，从而排空队列，这样缓冲的数据包就可以发送，而不会再堆积。如果我们在示例中绘制 BBR 发送方的发送速率图表，它将如下所示：
尽管我们的示例是由单个链路组成的网络路径，但 BBR 会将整个路径建模为单个链路，无论实际有多少链路组成该路径。因此，BBR 在每种场景下都使用相同的过程来估计带宽。当多个持久的 BBR 连接通过同一链路发送流量时，实验表明它们通常都会获得公平的带宽份额。
BBR 与 TCP
BBR 与 TCP 的区别主要有两点：
BBR调整的是发送速率，而不是拥塞窗口。我们已经解释过 TCP 改变的是拥塞窗口而不是实际的发送速率。对于 BBR，决策是根据流量速度（以 Mbps 为单位）做出的。
BBR 收集有意义的统计数据。与 TCP 不同，BBR 不规定对数据包级事件的硬连线反应。相反，它尝试主要通过 ACK 接收速率来推断有关网络的有意义的统计数据，并以此为基础来指导其速率选择。
在大多数情况下，BBR 的性能优于广泛使用的 TCP 变体，例如 TCP Cubic。通过明确针对瓶颈带宽，BBR 实现了更好的吞吐量和更低的延迟。此外，BBR 本质上对非拥塞相关的丢失具有更强的弹性，因为与 TCP 不同，它不会将数据包丢失视为拥塞信号。
也就是说，BBR 确实有缺点。
什么时候 BBR 不适合？
BBR 依赖于其以易于处理且对决策有用的方式对复杂网络进行建模的能力。毫不奇怪，这并不总是可能的，尤其是在混乱的最后一英里。
尽管 BBR 似乎对情况有一个很好的模型，但网络仍然可以包含惊喜。竞争交通流突然进入和离开；基本路线可能会改变；不同的发送者可以与采用不同拥塞控制算法的连接共享链路；用户移动性可能会导致意外的丢包和带宽波动；和更多。
当 BBR 模型偏离现实太远时，BBR 就会做出不明智的决策。
另一个严重的缺点是 BBR 不是一个“公平”的拥塞控制解决方案。BBR 通常与使用相同协议的流量源配合良好。但当 BBR 与其他流量控制协议发生冲突时，它就表现不佳。BBR 可能会非常激进地攻击其他流量，从而接管所有有限的可用带宽。
PCC - 黑盒、无模型方法
PCC是“面向性能的拥塞控制”的缩写，由耶路撒冷希伯来大学和伊利诺伊大学香槟分校 (UIUC) 的研究人员联合开发。与 TCP 一样，但与 BBR 不同，PCC 是拥塞控制算法的通用框架。所有 PCC 变体都是使用相同的效用函数和在线速率选择的通用架构构建的，我们将在下面更详细地讨论。PCC 变体的不同之处在于拥塞控制算法中内置的效用函数和在线速率选择方案的具体选择。
“无模型”的重要性
正如我们所解释的，BBR 是一种基于模型的白盒方法，它利用网络统计数据来推断网络状况。PCC则截然相反。它将网络视为一个无法理解的黑匣子。PCC 发送方从不尝试推断网络参数，例如瓶颈带宽或数据包丢失的根本原因。
相反，PCC 将数据传输视为一系列“微观实验”。在每个此类微实验中，发送方都会量化当前发送速率的性能水平。它使用此信息随时间调整其发送速率。
PCC如何运作？
PCC 有两个主要组成部分：
实用功能
在线费率选择算法
效用函数（或效用框架）获取所选发送速率产生的统计数据，并将其转换为性能分数或效用值。该效用值表示以该速率发送所达到的性能水平。在线速率选择算法根据先前选择的发送速率观察到的效用值来决定接下来选择什么速率。
PCC 实用程序框架：灵活性的优点
当 PCC 发送方开始以一定速率发送数据包时，它会在 RTT 后开始接收 ACK。这些 ACK 可以揭示信息，包括丢失的数据包比例、数据包延迟的上升或下降等。PCC 发送方收集此信息并将其聚合为效用值或性能分数。
让我们考虑这样一种场景，其中特定发送速率的性能被测量为安全到达目的地的流量部分。想象一下，发送方以 50 Mbps 的速度发送数据包的简化连接，其中 30% 的数据包（即每发送 100 个数据包中的 30 个）在途中丢失；这意味着 70% 已到达。当使用这个简单的效用函数来量化性能时，导出的效用值等于 35，即 50 Mbps 的 70%。
该效用函数可以用以下等式表示
U = X(1-L)
X 是发送速率
L 是数据包丢失的比例；例如，L=0表示没有丢包，L=0.1表示有10%的丢包；L=0.5表示50%的数据包丢失；L=1表示所有数据包丢失等。
U 是性能分数
例如，如果没有数据包丢失，则 X 和 U 相同，因为所有数据包均到达目的地。如果一半数据包丢失，则 U=X/2。
这种效用函数的具体选择过于简单而无效。原因如下：
如果以 100 Mbps 的速度发送且没有任何数据包丢失，则 U 将等于 100。
如果您以 200 Mbps 的速率发送并看到 50% 的数据包丢失，则 U 仍然等于 100。
U 在两种情况下都是相同的，尽管没有数据包丢失显然比丢失一半数据包要好，但在吞吐量方面却没有任何收获。
本例中的效用函数完全忽略了延迟。它仅在网络缓冲区耗尽且数据包丢失时对拥塞做出反应，而不是对拥塞的发生做出响应。
幸运的是，我们可以通过设置数据包延迟和数据包丢失的惩罚来创建更好的效用函数，以产生所需的属性。分组延迟的惩罚表示为p D ，分组丢失的惩罚表示为p L 。此类效用函数具有以下一般形式：
U = X - p D X - p L X
与之前一样，X 是发送速率，L 是数据包丢失比例，U 是性能分数。随着延迟和丢失的增加，对数据包延迟和数据包丢失的惩罚也应增加。因此，p L和p D可以采用多种不同的形式。例如，当设置 p L =100L 时，丢包对发送方效用值的负面影响比设置 p L =L 时高 100 倍。观察到，当我们设置 p D =0 时，数据包延迟不会受到惩罚，并且 p D =L，我们得到
U = X - L x X = X(1-L)
这正是我们之前的简单效用函数。
现在该方程包括三个需要考虑的因素：
发送速率 (X)，我们希望将其推得尽可能高
数据包延迟（受到 p D惩罚），我们希望保持尽可能低的延迟
数据包丢失（受到 p L惩罚），我们也希望将其保持尽可能低
确定实用函数的良好选择可能很微妙，因为实用函数有两个重要作用：
- 灵活地为不同应用程序定制性能
正如我们上面提到的，不同的应用程序有不同的需求。其中一些对延迟敏感，例如 Zoom，而另一些则对带宽要求很高，例如 Netflix。可以调整实用功能以满足每个应用程序的需求。例如，当将 PCC 用于 Zoom 时，我们可以将数据包延迟的惩罚设置为高于将 PCC 用于 Netflix 时的惩罚。这将导致更倾向于最大限度地减少延迟的行为，正如 Zoom 所青睐的那样，即使这是以降低带宽利用率为代价的，而这对 Netflix 来说更为重要。
- 确保连接之间的公平性
我们已经讨论了公平性对于拥塞控制解决方案的重要性。通过PCC，每个发送者都专注于根据其效用函数优化自己的发送速率。因此，存在一个发送者可能垄断所有带宽、导致其他连接匮乏的风险。他们达到公平均衡的原因取决于博弈论。只要PCC用户是同质的，并且都使用某个系列的实用功能，就可以保证他们公平地共享带宽。在其他重要场景下也能保证理想的带宽分配。
例如，这可以通过将一类实用功能用于主要的、时间敏感的流量（例如视频会议）和另一类用于“清道夫”流量（例如软件更新）来实现。
PCC在线速率选择
在效用函数之后，PCC的第二个组成部分是在线速率选择算法。PCC 发送方需要根据其观察到的先前选择的速率的效用值来决定下一步使用什么发送速率。这就是PCC在线速率选择算法的作用。
这是它的工作原理。就像 TCP 和 BBR 一样，PCC 以慢启动模式开始，并且每个 RTT 的速率加倍。这种情况一直持续到效用分数停止上升为止；这表明 PCC 提高了太多速率，从而导致性能下降。此时，PCC进入拥塞避免模式。
现在，假设 PCC 以某个速率 r 发送。确定是否应该增加或减少其速率的简单方法如下。PCC 可以以略高的速率（高于 r 2%）发送并检查导出的效用值，然后以略低的速率（低于 r 2%）发送，并再次检查导出的效用值。在评估以较高和较低的速率发送如何影响性能（即效用值）后，PCC 可以切换到较低或较高的速率，具体取决于哪个速率产生最高的性能分数。
无需逆向工程
PCC 的最早变体（称为PCC Allegro）使用了这种调整发送速率的算法。虽然相当简单，但它避免了 TCP 的一些缺陷。考虑发送方遇到与拥塞无关的数据包丢失的情况。例如，假设无论发送数据的速度有多快，每 100 个数据包中有 1 个被丢弃。在这里，提高发送速率不会增加丢失数据包的比例，但会导致更多数据包到达接收器并获得更好的性能分数。因此，PCC Allegro 将选择提高费率。相反，如果发送方因拥塞而丢失数据包，则提高速率只会导致更多数据包丢失，而无法获得更多流量，从而导致性能变差。因此，PCC Allegro 将选择降低费率。回想一下，无论数据包丢失的原因如何，TCP 都会降低其发送速率，如第 5 节中所讨论的。如您所见，PCC Allegro 能够有效地区分数据包丢失的两种不同原因，并以不同的方式做出反应。
与 BBR 不同，PCC 算法不会尝试确定为什么较高的速率比较低的速率更好，反之亦然。发送方不会尝试对网络条件进行逆向工程，例如明确推理造成数据包丢失的可能原因。相反，发送方将网络视为黑匣子，只是尝试了解当前速率的哪些变化会带来最佳性能。
相对于 PCC Allegro 的改进
尽管 PCC Allegro 的简单算法很有效，但它仍然存在一些缺陷。主要困难在于它总是以固定的步长改变其速率。在我们的示例中，该比例为 2%。正如我们将在下面讨论的，在某些情况下，此步长会太大，而在其他情况下，此步长会太小。
例如，下面的图 15 显示了以 1% 的小步长降低发送速率的 PCC 算法。假设发送方最初以 r 的速率发送，该速率远高于网络带宽 R。由于发送速率明显高于网络可以支持的速率，因此会出现大量数据包丢失和/或数据包延迟。这些丢失和延迟将持续下去，同时速率以微小的增量缓慢下降，直到再次达到带宽阈值。或者，如果当前发送速率远低于可用带宽，则每次将发送速率提高 1% 可能需要很长时间才能达到适当的带宽利用率。
另一方面，图 16 显示了如果步长固定为太高的值（例如 30%）会发生什么情况。首先考虑图 16(a) 中描述的场景，其中连接以 r1 的速率在链路上发送，该速率远低于可用带宽 R。这会导致网络利用率较差，因此 PCC 算法将增加其比率。由于步长很大，发送方将在一次巨大的跳跃中增加其速率，并且可能会大大超出网络容量，如图所示。然后，为了从这个错误中恢复，它将把它的速率降低到太低，如图 16(b) 所示，然后再次增加它，依此类推。
更先进的 PCC 速率控制方案建立在机器学习和博弈论方面丰富的文献基础上来解决这个问题。PCC Vivace 是一种方案的示例，它比 PCC Allegro 对网络变化的响应能力更强，并且具有更好的收敛速度。
无模型方法的好处
正如我们上面所讨论的，依赖于网络强假设的拥塞控制解决方案（例如 TCP 和 BBR）在网络模型偏离现实时很容易导致性能不佳。由于其无模型方法避免了做出任何假设，PCC 在响应网络条件的意外变化方面更加稳健。这些变化是现实世界环境中的一个事实，尤其是在最后一英里。
在一个简单的对照实验中，我们在反映最后一英里混乱的不可预测变化的情况下比较了 BBR 和 PCC。我们的延迟、可用带宽和数据包丢失每秒都在变化。下图显示了对 PCC 和 BBR 的影响，以及理想的带宽利用率。
总结
拥塞控制令人兴奋的未来
正如您现在所了解的，拥塞控制几十年来一直是一个挑战。试图解决这个问题的计算机科学家需要克服许多障碍，包括阴暗、不断变化的最后一英里条件；来自其他连接的持续竞争；需要平衡带宽利用率与最小的数据包丢失和延迟；以及连接之间公平的要求；除其他问题外。
这是互联网数据传输的激动人心的时刻，新的解决方案触手可及。很长一段时间以来，TCP 范式第一次受到争议，并且其他方案（例如 BBR 和 PCC）已经得到部署。随着我们越来越多的人生活在网上，对高质量和公平的网络访问的需求只会增长。我们已经看到企业和消费者对流媒体视频、视频会议、电子竞技、实时在线宗教服务、社交距离合唱团等应用程序的需求日益增长。今天，我们需要更有效的方法来提高互联网体验质量。拥塞控制是服务提供商需要考虑的关键因素。
172
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
