Congestion control in DC-CSDN博客

DC 网络与 Internet 拥塞控制不同。DC 网络属相对确定的网络，捕捉流量特征成为可能。针对这些明确的特征做明确的定制传输策略是高尚的。

按照对传统拥塞控制的理解，DC 网络的不同在于：

• RTT 极短。
• 带宽极高。
• 交换机 Buffer 很小。
• 误码丢包率极低。

另一方面，DC 网络的流量特征与 Internet 流量也不同：

• 极低的传输延时倾向于高频率短连接，短消息。
• 费用成本自决倾向于自研 transport 等非 TCP/QUIC 标准。
• 多在最后一跳 tor 上受微突发影响而丢包，可规避。
• 少数在第一跳 tor 由于 host 大突发而丢包，可改进。

与 Internet 长肥管道建连，传输巨大的 overhead 不同，DC 网络的时间开销很小。

结合以上 DC 网络的特征以及 DC 网络内流量的特征，对大多数的短消息，包括 Aeolus，Homa 等 transport 的思路是高尚的：

• 挂在 tor 下的 host 以线速 pacing 突发一个或少数几个 BDP 的数据。

这看起来实属赌博，但赢的概率很大。

采用慢启动探测耽搁的时间大于发送时间本身，不如赌一把，如果发生拥塞丢包，下一个 RTT 重传不会耽搁太久，若采用慢启动探测，时间亦无法压缩，如果没发生拥塞，大部分短消息都可在一个或几个 RTT 内完成传输。平均 FTC 不变甚至更低。

若属 incast 流量，则退避随机值突发，见 彻底解决 IDC Incast

以上短消息的处理，属赢率很大的一锤子赌博，不会继续押注。

对无法在几个 RTT 无法完成的长消息，前几个 RTT 数据亦可重复上述短消息策略，对后面的消息，与 “长肥管道” 相对，逆着做就行，可轻易总结出 DC 网络拥塞控制的解法：

• 路径短，随机丢包概率低，不怕 cwnd 涨不上去。
• RTT 极短，不怕 cwnd 由于拥塞控制下降后涨得慢。

因此 AIMD 是高尚的，别的都太花哨。事实也确实，DC 拥塞控制基本都是 AIMD-Based。AIMD，本来是做 Internet 拥塞控制的，结果却更加适合 DC 网络，对于 Internet 拥塞控制，Rate-Based 正风靡。

说下费用成本自决。

与 Internet 按流量收费使用基础设施不同，DC 基础设施属固定资产投资， 定制何种设备需要满足哪些需求，这笔预算是最开始决定的，后面仅剩物尽所用：

• 端到端可定制，发送端与接收端均属自己的资产。
• 网络可定制，交换机属于自己的资产。

基础设施可为 transport 提供尽可能多的信息用于优化传输效率。DC 网络无需遵循 TCP/IP 这种分布式协议标准。

发送端为实施拥塞控制需要的信息，可向接收端甚至交换机索要，而不必像 TCP 那般基于少数几个量启发猜测。

确定性的 DC 网络让事情变得高尚这件事简单了很多。

最后，讲个故事。

我一直都希望有个 traceswitch 工具，类似 traceroute/mtr ，追踪源和目标之间所有的交换机(而不仅仅是路由器)，用于 DC 网络的传输特征探测。我需要这个工具的理由很简单：

• 如果能观察到某个交换机的实时状态，就可以区分丢包是因为发送端突发太大还是受到其它流量微突发的影响。

这个工具可以将发送端确定为凶手或者受害者。

但很多人不知道我在说什么。有人让我用 traceroute，我说 traceroute 看不到二层设备，只能看到路由器，接着我就被怼，对方告诉我 DC 内没有二层设备，都是三层… 我无语，抛出一个 “难题” ：192.168.100.16/24 和 192.168.100.17/24，192.168.100.18/24 这三台机器用线缆连在一起的吗？它们接的那个交换机里面把三条线打个结？

显然这人并不清楚三层设备和三层逻辑。当个笑话得了。

很幸运，我从专业人士那里讨要到了一个可以满足需求的替代工具，很棒。

DC 网络的拥塞控制让人觉得清爽但却感觉未尽所用，不妨简单说说 DC 网络的拥塞控制。

浙江温州皮鞋湿，下雨进水不会胖。