7.1 Datacenters (DCTCP, On-Ramp)
在数据中心环境下优化 TCP 的多个尝试中， Data Center TCP（DCTCP） 是最初的尝试之一。数据中心环境包括以下特点，使得其需要采取与传统 TCP 不同的拥塞控制方法。
数据中心内部的 RTT 时间很短
数据中心交换机的缓存通常较小
所有的交换机都受统一的管控，因此可能可以满足特定的标准
很多流量都有低延时的需求
低延时的流量需要与高带宽的数据流竞争
应该注意的是，DCTCP 不仅仅是 TCP 的一个版本，而是一个系统设计，它改变了交换机在发生拥塞时的行为以及端到端主机对从交换机接收到的拥塞信息的响应。
DCTCP 的核心出发点是：仅使用丢包作为数据中心环境中拥塞的主要信号是不够的。一个反例是：当交换机队列积累到足以溢出时，延时会增加，从而使得不能满足低延时流量的要求，进而对数据中心应用整体性能有负面影响。因此，DCTCP使用ECN的一个版本来作为即将发生拥塞的信号。
与原始ECN的设计将ECN标记等同于丢包并将拥塞窗口减半不同，DCTCP采取了更精细的方法。DCTCP并不是简单的做出非 0 即 1 的判断来决定是否存在拥塞，而是试图估算遇到拥塞的字节比例，然后基于这个估算来调整拥塞窗口大小。如果真的丢包了，标准TCP算法仍将介入。通过这种可以尽早对拥塞做出反应以保持网络设备队列较短，同时又不过度反应到使得队列空闲并牺牲吞吐量。
在这种方法中的主要挑战是估算遇到拥塞的字节比例。交换机的行为比较简单，如果数据包到达并且交换机看到队列长度（K）高于某个阈值；例如，
其中C是链路速率，单位是packet per second。那么，交换机将IP头部的CE位设置为1。这里不需要引入复杂如RED这样的机制。
接收方为每个数据流维护一个布尔变量，我们将其称为 DCTCP.CE，它最初会被设置为false。在发送ACK时，只有当 DCTCP.CE 为true时，接收方才在ACK 对应的 TCP 头中设置ECE（Echo Congestion Experienced）标志。DCTCP 还实现了以下状态机以响应每个接收到的数据包：
如果CE位为1，且
DCTCP.CE为false，将DCTCP.CE设置为true，并立刻回复ACK如果CE位为0，且
DCTCP.CE为true，将DCTCP.CE设置为false，并立刻回复ACK否则，忽略CE位
在上面第三种情况“否则”中，有一个不太容易察觉的效果：只要接收端持续收到固定的CE值的数据流，那么它每隔n个包才会发送一个延迟ACK。延迟ACK已经被证明对维持高性能来说很重要。
在每个观测窗口结束时（观察窗口通常约等于RTT），发送方计算在该窗口期间遇到拥塞的字节比例，即用CE标记的字节数除以传输总字节数。DCTCP增长拥塞窗口的方式与标准算法相同，区别是它会根据上一个观测窗口期间遇到拥塞的字节数比例来减小窗口大小。
具体来说，一个名为 DCTCP.Alpha 的新变量被初始化为 1，并在观察窗口结束时，按以下方式更新：
M 是带有CE标记的字节比例，g 是预估增益，这是一个由具体实现定义的常量，用于确定 DCTCP.Alpha 对数据包CE标记反应变化的速度。当存在持续的拥塞时，DCTCP.Alpha 接近 1；当拥塞不持续时，DCTCP.Alpha 会衰减至零。这导致对新出现的拥塞反应温和，而对持续拥塞反应更为严格。对应的拥塞窗口的计算如下：
总结一下，在DCTCP中，CE标记用于指示早期和频繁发生的拥塞，但对此类标记的反应比标准TCP中的更为谨慎，以避免过度反应导致队列一直为空。
描述了DCTCP的论文获得了SIGCOMM“经久不衰”奖，论文中介绍了数据中心流量特征，并基于该流量特征设计了 DCTCP，以及全部的论证过程。
更多阅读：M. Alizadeh, et al. Data Center TCP (DCTCP). ACM SIGCOMM, August 2010.
自 DCTCP 以来，为了优化数据中心的 TCP ，已经进行了大量研究。这些研究通常采取的方法是引入来自网络的更加复杂的信号，并使得发送方利用这些信号来管理拥塞。我们之后将重点介绍最近的一项努力——On-Ramp，因为它关注的是所有拥塞控制算法面临的一个基本挑战：如何在，让长期流量达到稳定平衡状态和处理瞬时突发流量之间，做出取舍。On-Ramp 采用模块化设计，直接解决了这个挑战，而且无需依赖网络的额外反馈。
On-Ramp 的主要思想是，当一个拥塞控制算法达到平衡状态后，如果遇到了严重拥塞并大幅减少其窗口（或速率）时，它必须决定是否记住其之前的平衡状态。这是一个困难的选择，因为这取决于拥塞持续的时间，而这又很难预测。如果拥塞是短暂的，算法应该记住其之前的状态，以便一旦突发结束，它可以迅速恢复旧的平衡状态，以确保网络被充分利用。如果拥塞是持续的，例如是由于一个或多个新数据流的到来引起的拥塞，算法应该忘记其之前的状态，以便它可以迅速找到一个新的平衡状态。
这里的方法是将拥塞控制机制拆分为两个部分：传统的 TCP 拥塞控制算法和 On-Ramp，它们分别关注流量的平衡和突发特性。具体来说，On-Ramp 被实现为一个shim层，位于传统的 TCP 拥塞控制算法下方，如图41所示。当测量到 One-Way Delay（OWD）大于某个阈值时，表明当前有突发流量，On-Ramp会通过临时将数据包保留在发送端，来尽快减少因为队列堆积带来的延时。On-Ramp shim与现有的拥塞控制算法配合工作，后者继续让长期数据流达到平衡。已经证明 On-Ramp 能够与多种现有的拥塞控制算法一起工作，包括 DCTCP。
On-Ramp 的关键在于，两个控制决策独立，并各自按自己的时间尺度进行。但要使其正常工作，shim 需要准确测量 OWD，这又依赖于发送方和接收方之间的时钟同步。由于数据中心内延迟可能少于几十微秒，发送方和接收方的时钟必须同步到几微秒之内。这种高精度的时钟同步通常需要特定的硬件支持，但 On-Ramp 利用了一种新方法，通过一些合作的节点，实现了纳秒级别的时钟同步，从而不需要特殊硬件，进而使得 On-Ramp 易于部署。
更多阅读：S. Liu, et al. Breaking the Transience-Equilibrium Nexus: A New Approach to Datacenter Packet Transport. Usenix NSDI ‘21. April 2021.
Y. Geng, et al. Exploiting a Natural Network Effect for Scalable, Fine-grained Clock Synchronization. Usenix NSDI ‘18, April 2018.
Last updated
