過去數年，一直在一些爭論中。到底是Segment Routing over SD-WAN，還是SD-WAN over SegmentRouting，接下來把這個議題擴大一點到Overlay。到底是需要SegmentRouting over Overlay還是Overlay over SegmentRouting?前者是Ruta、SR over UDP，后者是SRv6。本質上是應用的視角對應于網絡的視角。半個月前，有些網工朋友們跟我吐槽：云原生搞的網工都快失業了，言語中有些悲涼。
每一次的科技變革，你如果不能成為推土機或者壓路機，那么你只能成為路的一部分，被推平，被碾壓。
孔乙己原來也當過網工，但終于沒有考過IE，又不會營生;于是愈過愈窮，弄到將要討飯了。幸而做的好水晶頭，便替人家布線，換一碗飯吃?？上钟幸粯訅钠猓闶呛煤葢凶?。坐不到幾天，便連人和網線鉗，一齊失蹤。如是幾次，叫他布線的人也沒有了。
…
孔乙己自己知道不能和他們談天，便只好向孩子說話。有一回對我說道，“你學過網絡么?”我略略點一點頭。他說，“學過網絡，……我便考你一考。網線8根線的線序，怎樣排列的?”我想，討飯一樣的人，也配考我么?便回過臉去，不再理會?？滓壹旱攘嗽S久，很懇切的說道，“不能排罷?……我教給你，記著!這些線序應該記著。將來做網工的時候，打水晶頭要用?！蔽野迪胛液途W工的等級還很遠呢，而且我們網工也從來不做水晶頭了;又好笑，又不耐煩，懶懶的答他道，“誰要你教，不是橙白橙綠白藍藍白綠棕白棕么?”孔乙己顯出極高興的樣子，將兩個指頭的長指甲敲著柜臺，點頭說，“對呀對呀!……水晶頭有兩種做法，你知道么?”我愈不耐煩了，努著嘴走遠。
…
自此以后，又長久沒有看見孔乙己。到了年關，掌柜取下粉板說，“孔乙己還欠十九個錢呢!”到第二年的端午，又說“孔乙己還欠十九個錢呢!”到中秋可是沒有說，再到年關也沒有看見他。我到現在終于沒有見——大約孔乙己的確死了。
過去三十多年來，網絡因為其重資產的特征被幾大寡頭搞的步履蹣跚，重大的技術失誤比比皆是，三十年前的網絡誠然很復雜，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網絡中?
技術的輪回
其實很多技術都這樣，架構師需要考慮生態、利舊，即便是自己看明白了未來的路在哪里，耐心比信心更加重要，因為你需要一步步的向終端去變更迭代，而不是簡單的推倒重來，學會利用生態鏈中一切可以利用的資源，而不是簡單的固步自封。
