过去数年，一直在一些争论中。到底是Segment Routing over SD-WAN，还是SD-WAN over SegmentRouting，接下来把这个议题扩大一点到Overlay。到底是需要SegmentRouting over Overlay还是Overlay over SegmentRouting?前者是Ruta、SR over UDP，后者是SRv6。本质上是应用的视角对应于网络的视角。半个月前，有些网工朋友们跟我吐槽：云原生搞的网工都快失业了，言语中有些悲凉。
每一次的科技变革，你如果不能成为推土机或者压路机，那么你只能成为路的一部分，被推平，被碾压。
孔乙己原来也当过网工，但终于没有考过IE，又不会营生;于是愈过愈穷，弄到将要讨饭了。幸而做的好水晶头，便替人家布线，换一碗饭吃。可惜他又有一样坏脾气，便是好喝懒做。坐不到几天，便连人和网线钳，一齐失踪。如是几次，叫他布线的人也没有了。
…
孔乙己自己知道不能和他们谈天，便只好向孩子说话。有一回对我说道，“你学过网络么?”我略略点一点头。他说，“学过网络，……我便考你一考。网线8根线的线序，怎样排列的?”我想，讨饭一样的人，也配考我么?便回过脸去，不再理会。孔乙己等了许久，很恳切的说道，“不能排罢?……我教给你，记着!这些线序应该记着。将来做网工的时候，打水晶头要用。”我暗想我和网工的等级还很远呢，而且我们网工也从来不做水晶头了;又好笑，又不耐烦，懒懒的答他道，“谁要你教，不是橙白橙绿白蓝蓝白绿棕白棕么?”孔乙己显出极高兴的样子，将两个指头的长指甲敲着柜台，点头说，“对呀对呀!……水晶头有两种做法，你知道么?”我愈不耐烦了，努着嘴走远。
…
自此以后，又长久没有看见孔乙己。到了年关，掌柜取下粉板说，“孔乙己还欠十九个钱呢!”到第二年的端午，又说“孔乙己还欠十九个钱呢!”到中秋可是没有说，再到年关也没有看见他。我到现在终于没有见——大约孔乙己的确死了。
过去三十多年来，网络因为其重资产的特征被几大寡头搞的步履蹒跚，重大的技术失误比比皆是，三十年前的网络诚然很复杂，x.25/FR/ATM,甚至普通用户上网都还需要使用AT指令拨号163、169.网络自然带着它神秘的面纱让应用开发的人望而却步，而即便是《计算机网络》这些入门的书籍对于应用开发者而言都是天书，更不要说那些复杂的路由协议和一不小心就构成的广播风暴或者路由环路了。这些是网工们曾经值得炫耀的技术。而如今到处都是以太网似乎也没有什么太复杂的配置，而网工们瞎搞的SDN伴随着几十年前发明的BGP倒也真闯过不少事故，也难怪应用一出事，报错第一条就是请检查您的网络。
云计算的驱动下，网工的地位越来越低，很多公司云计算资源都被计算团队控制着，网工对于云网络的感知也越来越陌生， 最终逼着应用自己去搞云原生，于是网工就被彻底的碾压在了地上。虽然过去数年网工们也在拼命的学Python搞DevOps，甚至拿Python写BGP这些路由协议，但是离应用越来越远，自然发明的技术越来越难用，所以SDN之死是必然，而下图中两个x都和网络有关。
至于那些做SD-WAN的，似乎连分布式数据库一致性的发展都搞不明白，自然也会在软件复杂度上栽跟头。
Overlay是否需要RDMA?
先来谈一个简单的问题，有人讲RDMA是个宝，AWS也不鸟。本质上这也是网工的思维方式。而背后的逻辑应该是Overlay是否需要RDMA?不知道写这个的人是否读过SRD的driver的code，如果不懂，前面#include总看得懂吧?
RDMA在虚拟机层面实现Kernel bypass有相对良好的生态，这是必然需要考虑的，从这个角度上看SRD和eRDMA本质上是殊途同归的。
渣只是因为看到了DDIO等一系列问题和存算一体化的结构的内存指令扩展以及未来CXL能够很容易操作各种适配器上的内存和I/O隔离控制Jitter，并且在某个400G的项目上遇到了内存瓶颈，因此希望将最后一个DMA的buffer拷贝都省掉，直接通过CXL.cache访问网卡内存来缓解DDIO和PCIe总线带来的jitter，并且为这样的内存操作增加一些向量化的指令集。因此NetDAM构建一个可编程的多机共享的内存抽象层。但是这些的基础还是要给虚机提供一个SMC(Shared Memory Communication),只不过把RDMA原有的QP机制转换为了IP地址+内存地址的寻址操作，并赋予了一些指令集扩展空间，同时使得系统容量可以扩展的更大而已。
那么接下来的一个问题是SRD的简单Hash是否有效?
在标准的Spine-leaf架构下，原有的TCP需要使用flowlet方式转发并且因为保序的要求可能会带来重排和抖动，而SRD有点类似于QUIC，把通信拆分成了更小的block并且不用在传输层保序，这一点是很不错的。
而且很高兴的看到AWS重点强调Jitter而不是延迟，这一点就更赞了。因为Jitter在可靠传输的过程中影响比延迟还大。但是AWS可能也忘了一点，很多数据处理是有明显的链式特征的，借助于RDMA是很难实现如下这种通信的：
这也是nVidia收购卖螺丝后，宁愿在NCCL中将以前的Ring-Allreduce改为Tree-based allreduce，本质上链式反应会扩大Jitter， 每一跳如果都经过了主机的PCIe，jitter会放大的更大：
但是我们不得不意识到如今最快的超算们，大量是使用2D-Torus、3D-Torus、甚至有6D-Torus的拓扑。
本质上这个问题是片网络NOC通过总线连接多机网络的问题，RDMA的QP结构决定了其寻址和链式反应能力是不行的。而NetDAM本质上是借助了Segment-Routing的概念将QP结构去除。同时为互联网终端提供标准的基于UDP的SMC通信，这个会在未来对IoT等场景非常有用。
至于Segment-Routing为啥在这里有用，去看看CHI总线呀， 本质上因为功耗和布线的问题，这些在NOC中存在的问题，同样也存在于数据中心内部。
结论：Overlay和虚机对RDMA的需求来自于SMC和已有的生态下Kernel Bypass，无论eRDMA或者SRD，现阶段的唯一可选。只是底层实现上是否可以有更多的优化，例如内存操作的保序、丢包容忍度、一致性的问题，是否实现事务等。
如果真要对比也是RDMA对比NetDAM，而不是简单的带节奏，而NetDAM本身也要等着CXL慢慢成熟起来，例如Linux中针对CXL的网卡内存、显卡显存的操作驱动逐渐完善，但是这个过程起码也要3~5年的时间, 可能CXL还需要像CHI那样定义一些更加灵活的拓扑结构，如果不懂继续看NetDAM的论文：
https://arxiv.org/abs/2110.14902
拥抱变化，Overlay是否需要SR?
Ruta这样的项目在很多网络团队的评价都是：SRv6不香么?SID太长也可以压缩呀，再搞一套有啥必要?但是他们忘了本质的区别是在Segment Routing放在overlay还是underlay?网络团队为了自己的利益自然会选择一个能够接管overlay的协议。
而找我搞Ruta的大多数都是应用的团队，特别是各个有音视频和CDN业务的团队，还有一些容器网络的团队。在Overlay上搞SR才是必然选择， 因为业务流量的调度，多云互联。
例如在一个混合云的场景中，我们经常为客户部署SD-WAN时遇到很多挑战。例如到AWS后，还要我们自己的SD-WAN路由器和AWS建一个IPSec隧道，而Azure需要专用的一个NVA节点重分布BGP。其它云还面临着VPC本身处于静态路由的时代，例如渣为了某客户上阿里云，还自己写了一个BGP+aliyun-cloud-shell的小程序帮助两边重分发路由。
因此在渣的论文中，VPC内使用Segment Routing构建Transparency VPC比原来的Transit VPC技术更加有效，更加的能够实现cloud-agnostic，因为大量的云原生K8S节点和容器网络本身就是在VPC基础上再构建了一个Overlay。
而网络团队被云原生搞的接近失业的本质不就清楚了么?业务本身也有service-chaining的需求，而这些需求在传统的VPC架构上是很难进行链式触发的，例如在Overlay上实现超算等业务，MPI-RingAllreduce这些低延迟的场景如何搞?是否可以通过协议编码在overlay上降低API-Gateway的负担?这些都是应用需要网络团队帮忙一起解决的问题，可惜网络还抱着自己的Overlay provide by SR做白日梦。
结论：在VPC之上帮应用构建SegmentRouting才是关键，放下SRv6宗教信仰去拥抱变化
IPv4 over SRv6、SR-MPLS
另一个问题是运营商通常遇到的，当你建立好一个SRv6或者SR-MPLS网络后，通常会抱怨业务为啥不切换上来?很显然的一个问题，谁有空那么无聊为了你改代码，还一定要应用程序有Root权限并且又要通过Kernel转发?人家应用好不容易Kernel Bypass做完，又要你去Kernel兜一圈…
特别是那些家庭里的小路由器终端，全国几千万台，为了一个SRv6全部更换值得么?对设备商来看自然有动力，对运营商来看势必不行了。同时还有大量的宽带接入设备升级改造困难时，为什么不想起来一个4over6的技术呢?利用Ruta在接入侧实现Binding-SID的映射将传统网络很容易的导入到SRv6或者SR-MPLS网络中?
技术的轮回
其实很多技术都这样，架构师需要考虑生态、利旧，即便是自己看明白了未来的路在哪里，耐心比信心更加重要，因为你需要一步步的向终端去变更迭代，而不是简单的推倒重来，学会利用生态链中一切可以利用的资源，而不是简单的固步自封。
