无损网络和有损网络

无损网络近来越来越多被提到，无损网络似乎是 RDMA 的必须，为了减轻主机侧的负载(这是 RDMA 的目标之一)，网络就要承担复杂，因此，RoCE 为 RDMA 承诺了一个无损链路层，这样 RDMA 就不必再实现丢包重传那些东西了。可靠传输是在底层保证的，而不是在传输层保证的。
但物理链路不可能无损，这就好像交通事故一定会发生一样，所有无损网络链路层均需要提供可靠传输，它们本质上就是一个可靠传输承载协议。可靠传输一定要应对并解决丢包，乱序问题，而方法就是 ARQ，FEC 此类，go-back-n，sack 只是例子。
另一方面，几乎所有可靠传输协议无一例外都避不开 TCP 的影响，至少任何一个新协议都要保持 TCP 友好，对 TCP 公平。所有可靠传输都要高效且公平，于是大家纷纷学 TCP 的样子来做。可 TCP 的存在正是因为底层链路不可靠的缘故，而不是它必须存在。
如果底层是一个无损网络，谁还会用 TCP。如何做一个可靠传输协议应该关注底层可靠性，而不是学 TCP。
即使底层不是一个完全的无损网络，只要它足够可靠，传输层协议也会大有不同。在目前的数据中心以及广域骨干链路这种足够可靠几乎无损的环境，假设我们忘掉 TCP，类 TCP 的可靠传输协议有多大概率会被重新引入。
在重新引入类 TCP 协议前，不得不重新评估它自身的负担。整个互联网超过一半的流量是 TCP 流量，其中又有几乎 1/4 到 1/3 的流量是 pure ACK，而 ACK 仅仅为了提供一个滑动窗口时钟并辅助测量，这已经是非常大的负担。 TCP 才是问题本身，而不是解决方案。
在丢包率不足 0.01% 的网络如何应对丢包和丢包率超过 10% 的网络应对丢包的策略完全不同。为万里挑一的丢包引入源源不断的 pure ACK 时钟仅为指示丢包非常不划算，pure ACK 传递的永远是有效信息，比如拥塞指示，吞吐反馈，以及其它变化量，pure ACK 应边沿触发而非水平触发。
丢包率极低的准可靠网络环境，无论 go-back-n，sack，rto 等 ARQ 还是 FEC 都不划算，都不如应用程序发现问题主动请求重传。传输层将大大简化。目前数据中心网络 transport 都在陆续走上这条路，丢包是 app-aware，而不是 transport-aware。
但 TCP 诞生的 1970 年代，底层信道质量远非可靠，主机资源有限，TCP 就是最优解。TCP 随后的迭代始终保持着该基因，即底层信道是不可靠的，无论 fast retransmit，sack，rack 都在基于此认同上进行优化。因为 TCP 太成功了，以至于几乎成了唯一解，即使链路信道质量已经好到不再需要像 TCP 那般谨慎了，甚至可靠传输本身已经廉价到可由应用程序自己负责了，几乎所有的新传输协议还是无法摆脱 TCP 的影子。
再往底层说，数据中心网络链路信道已经如此可靠，RoCE 却像极了一个链路层的 TCP，go-back-n，ECN…总之还是 TCP 那一套，以至于这些底层协议依然假定，信道是会发生丢包的，丢包需要被应对，这和 TCP 基因里的假设没有任何区别。
首先，可靠传输不仅仅只是 TCP，go-back-n，ECN 也不仅仅属于 TCP，它们是任何可靠传输的选项。其次我们再来看丢包。丢包分误码丢包和拥塞丢包，现如今的误码丢包已经非常罕见，但拥塞丢包大多数还是自找的。
拥塞丢包，简单说就是发的太多了，为了应对这种情况，需要拥塞控制。拥塞控制分分布式和集中式两类。早期关于互联网设计哲学的辩论，倾向于将互联网设计成了胖端瘦网的分布式结构，几乎于此同时，以太网成功占领了互联网的枝端，而以太网本身也是分布式控制网络，它和互联网基本是一回事。
和互联网交换机 buffer 溢出丢包一样，以太网在重试次数超过一定阈值后会放弃重试而丢包，而最大重试次数表示的就是一个有最大值限制的最大等待时间，以太网丢包策略几乎就是一个完备的 RED。无论交换机还是以太网，都没有中心控制器对拥塞源进行抑制，需要指示拥塞并付出了丢包代价时，拥塞肯定已经发生了，这是互联网和以太网的基因，它们都是有损网络。
将传输协议和网络结合，要么像 RoCE 在有损网络上提供无损链路层，要么像 TCP 在有损网络上提供无损传输层，二者是一回事，区别在于 RoCE 卸载了 CPU 的负担，而 TCP 必须由 CPU 处理。
整体回顾，我们发现 TCP 也好，RoCE 也好，它们与互联网以及以太网是契合的。互联网和以太网提供了一个有损网络，这也是上层协议的唯一假设。
真正的无损网络必须引入中心控制，彻底摆脱由于拥塞导致的丢包，可参考 infiniband，ATM 等实现，而不是在以太网上打 patch，以太网再打 1000 个 patch 也还是修修补补，改变不了基因，就像打地鼠一样，这边打下去那边冒头，PFC 用延时换溢出，总之还是拥塞不顺畅，这其实可以看成是 pause 帧的细化，还要解决死锁问题，越来越复杂。这是由于以太网分布式本质造成的。就算你想出再新式的 “算法”，无一例外都很以太网，INT，带内逆向捎带 ECN，都改变不了。
本文两个层面说问题，丢包分两类，信道误码丢包和拥塞丢包。第一种情况，信道质量越好，应用程序自行检测的成本越低，越倾向于传输协议不实现可靠传输，第二种情况，分布式端到端拥塞控制本质上只是转移等待时间(重传延时，排队延时等)，无法彻底避免拥塞，丢包一定会发生，因此拥塞丢包必须处理。愿景是，当带宽足够大，大到分布式网络上跑满了 application-limited 自限性流量依然跑不满带宽时，分布式拥塞就彻底避免了，否则，引入一套中心控制机制终究还是不雅。

今天想到一个例子，打电话不会拥塞，没有排队延时，但会造成主叫长时间等待，打电话和互联网通信是两个极端，但改变不了的是总等待时间，不同的只是这段总时间的分布。很多人并不明白这一点，总以为用 buffer 兜住数据而不丢包就是无损网络的一切，实际上该损还得损，问题不在这里就在那里，最终都是时间，等待时间，CPU 时间，这一切都是守恒的。

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