過(guò)去數(shù)年，一直在一些爭(zhēng)論中。到底是Segment Routing over SD-WAN，還是SD-WAN over SegmentRouting，接下來(lái)把這個(gè)議題擴(kuò)大一點(diǎn)到Overlay。到底是需要SegmentRouting over Overlay還是Overlay over SegmentRouting?前者是Ruta、SR over UDP，后者是SRv6。本質(zhì)上是應(yīng)用的視角對(duì)應(yīng)于網(wǎng)絡(luò)的視角。半個(gè)月前，有些網(wǎng)工朋友們跟我吐槽：云原生搞的網(wǎng)工都快失業(yè)了，言語(yǔ)中有些悲涼。

每一次的科技變革，你如果不能成為推土機(jī)或者壓路機(jī)，那么你只能成為路的一部分，被推平，被碾壓。

孔乙己原來(lái)也當(dāng)過(guò)網(wǎng)工，但終于沒(méi)有考過(guò)IE，又不會(huì)營(yíng)生;于是愈過(guò)愈窮，弄到將要討飯了。幸而做的好水晶頭，便替人家布線，換一碗飯吃。可惜他又有一樣壞脾氣，便是好喝懶做。坐不到幾天，便連人和網(wǎng)線鉗，一齊失蹤。如是幾次，叫他布線的人也沒(méi)有了。

…

孔乙己自己知道不能和他們談天，便只好向孩子說(shuō)話(huà)。有一回對(duì)我說(shuō)道，“你學(xué)過(guò)網(wǎng)絡(luò)么?”我略略點(diǎn)一點(diǎn)頭。他說(shuō)，“學(xué)過(guò)網(wǎng)絡(luò)，……我便考你一考。網(wǎng)線8根線的線序，怎樣排列的?”我想，討飯一樣的人，也配考我么?便回過(guò)臉去，不再理會(huì)。孔乙己等了許久，很懇切的說(shuō)道，“不能排罷?……我教給你，記著!這些線序應(yīng)該記著。將來(lái)做網(wǎng)工的時(shí)候，打水晶頭要用。”我暗想我和網(wǎng)工的等級(jí)還很遠(yuǎn)呢，而且我們網(wǎng)工也從來(lái)不做水晶頭了;又好笑，又不耐煩，懶懶的答他道，“誰(shuí)要你教，不是橙白橙綠白藍(lán)藍(lán)白綠棕白棕么?”孔乙己顯出極高興的樣子，將兩個(gè)指頭的長(zhǎng)指甲敲著柜臺(tái)，點(diǎn)頭說(shuō)，“對(duì)呀對(duì)呀!……水晶頭有兩種做法，你知道么?”我愈不耐煩了，努著嘴走遠(yuǎn)。

…

自此以后，又長(zhǎng)久沒(méi)有看見(jiàn)孔乙己。到了年關(guān)，掌柜取下粉板說(shuō)，“孔乙己還欠十九個(gè)錢(qián)呢!”到第二年的端午，又說(shuō)“孔乙己還欠十九個(gè)錢(qián)呢!”到中秋可是沒(méi)有說(shuō)，再到年關(guān)也沒(méi)有看見(jiàn)他。我到現(xiàn)在終于沒(méi)有見(jiàn)——大約孔乙己的確死了。

過(guò)去三十多年來(lái)，網(wǎng)絡(luò)因?yàn)槠渲刭Y產(chǎn)的特征被幾大寡頭搞的步履蹣跚，重大的技術(shù)失誤比比皆是，三十年前的網(wǎng)絡(luò)誠(chéng)然很復(fù)雜，x.25/FR/ATM,甚至普通用戶(hù)上網(wǎng)都還需要使用AT指令撥號(hào)163、169.網(wǎng)絡(luò)自然帶著它神秘的面紗讓?xiě)?yīng)用開(kāi)發(fā)的人望而卻步，而即便是《計(jì)算機(jī)網(wǎng)絡(luò)》這些入門(mén)的書(shū)籍對(duì)于應(yīng)用開(kāi)發(fā)者而言都是天書(shū)，更不要說(shuō)那些復(fù)雜的路由協(xié)議和一不小心就構(gòu)成的廣播風(fēng)暴或者路由環(huán)路了。這些是網(wǎng)工們?cè)?jīng)值得炫耀的技術(shù)。而如今到處都是以太網(wǎng)似乎也沒(méi)有什么太復(fù)雜的配置，而網(wǎng)工們瞎搞的SDN伴隨著幾十年前發(fā)明的BGP倒也真闖過(guò)不少事故，也難怪應(yīng)用一出事，報(bào)錯(cuò)第一條就是請(qǐng)檢查您的網(wǎng)絡(luò)。

云計(jì)算的驅(qū)動(dòng)下，網(wǎng)工的地位越來(lái)越低，很多公司云計(jì)算資源都被計(jì)算團(tuán)隊(duì)控制著，網(wǎng)工對(duì)于云網(wǎng)絡(luò)的感知也越來(lái)越陌生， 最終逼著應(yīng)用自己去搞云原生，于是網(wǎng)工就被徹底的碾壓在了地上。雖然過(guò)去數(shù)年網(wǎng)工們也在拼命的學(xué)Python搞DevOps，甚至拿Python寫(xiě)B(tài)GP這些路由協(xié)議，但是離應(yīng)用越來(lái)越遠(yuǎn)，自然發(fā)明的技術(shù)越來(lái)越難用，所以SDN之死是必然，而下圖中兩個(gè)x都和網(wǎng)絡(luò)有關(guān)。

至于那些做SD-WAN的，似乎連分布式數(shù)據(jù)庫(kù)一致性的發(fā)展都搞不明白，自然也會(huì)在軟件復(fù)雜度上栽跟頭。

Overlay是否需要RDMA?

先來(lái)談一個(gè)簡(jiǎn)單的問(wèn)題，有人講RDMA是個(gè)寶，AWS也不鳥(niǎo)。本質(zhì)上這也是網(wǎng)工的思維方式。而背后的邏輯應(yīng)該是Overlay是否需要RDMA?不知道寫(xiě)這個(gè)的人是否讀過(guò)SRD的driver的code，如果不懂，前面#include總看得懂吧?

RDMA在虛擬機(jī)層面實(shí)現(xiàn)Kernel bypass有相對(duì)良好的生態(tài)，這是必然需要考慮的，從這個(gè)角度上看SRD和eRDMA本質(zhì)上是殊途同歸的。

渣只是因?yàn)榭吹搅薉DIO等一系列問(wèn)題和存算一體化的結(jié)構(gòu)的內(nèi)存指令擴(kuò)展以及未來(lái)CXL能夠很容易操作各種適配器上的內(nèi)存和I/O隔離控制Jitter，并且在某個(gè)400G的項(xiàng)目上遇到了內(nèi)存瓶頸，因此希望將最后一個(gè)DMA的buffer拷貝都省掉，直接通過(guò)CXL.cache訪問(wèn)網(wǎng)卡內(nèi)存來(lái)緩解DDIO和PCIe總線帶來(lái)的jitter，并且為這樣的內(nèi)存操作增加一些向量化的指令集。因此NetDAM構(gòu)建一個(gè)可編程的多機(jī)共享的內(nèi)存抽象層。但是這些的基礎(chǔ)還是要給虛機(jī)提供一個(gè)SMC(Shared Memory Communication),只不過(guò)把RDMA原有的QP機(jī)制轉(zhuǎn)換為了IP地址+內(nèi)存地址的尋址操作，并賦予了一些指令集擴(kuò)展空間，同時(shí)使得系統(tǒng)容量可以擴(kuò)展的更大而已。

那么接下來(lái)的一個(gè)問(wèn)題是SRD的簡(jiǎn)單Hash是否有效?

在標(biāo)準(zhǔn)的Spine-leaf架構(gòu)下，原有的TCP需要使用flowlet方式轉(zhuǎn)發(fā)并且因?yàn)楸Ｐ虻囊罂赡軙?huì)帶來(lái)重排和抖動(dòng)，而SRD有點(diǎn)類(lèi)似于QUIC，把通信拆分成了更小的block并且不用在傳輸層保序，這一點(diǎn)是很不錯(cuò)的。

而且很高興的看到AWS重點(diǎn)強(qiáng)調(diào)Jitter而不是延遲，這一點(diǎn)就更贊了。因?yàn)镴itter在可靠傳輸?shù)倪^(guò)程中影響比延遲還大。但是AWS可能也忘了一點(diǎn)，很多數(shù)據(jù)處理是有明顯的鏈?zhǔn)教卣鞯模柚赗DMA是很難實(shí)現(xiàn)如下這種通信的：

這也是nVidia收購(gòu)賣(mài)螺絲后，寧愿在NCCL中將以前的Ring-Allreduce改為T(mén)ree-based allreduce，本質(zhì)上鏈?zhǔn)椒磻?yīng)會(huì)擴(kuò)大Jitter， 每一跳如果都經(jīng)過(guò)了主機(jī)的PCIe，jitter會(huì)放大的更大：

但是我們不得不意識(shí)到如今最快的超算們，大量是使用2D-Torus、3D-Torus、甚至有6D-Torus的拓?fù)洹?/p>

本質(zhì)上這個(gè)問(wèn)題是片網(wǎng)絡(luò)NOC通過(guò)總線連接多機(jī)網(wǎng)絡(luò)的問(wèn)題，RDMA的QP結(jié)構(gòu)決定了其尋址和鏈?zhǔn)椒磻?yīng)能力是不行的。而NetDAM本質(zhì)上是借助了Segment-Routing的概念將QP結(jié)構(gòu)去除。同時(shí)為互聯(lián)網(wǎng)終端提供標(biāo)準(zhǔn)的基于UDP的SMC通信，這個(gè)會(huì)在未來(lái)對(duì)IoT等場(chǎng)景非常有用。

至于Segment-Routing為啥在這里有用，去看看CHI總線呀， 本質(zhì)上因?yàn)楣暮筒季€的問(wèn)題，這些在NOC中存在的問(wèn)題，同樣也存在于數(shù)據(jù)中心內(nèi)部。

結(jié)論：Overlay和虛機(jī)對(duì)RDMA的需求來(lái)自于SMC和已有的生態(tài)下Kernel Bypass，無(wú)論eRDMA或者SRD，現(xiàn)階段的唯一可選。只是底層實(shí)現(xiàn)上是否可以有更多的優(yōu)化，例如內(nèi)存操作的保序、丟包容忍度、一致性的問(wèn)題，是否實(shí)現(xiàn)事務(wù)等。

如果真要對(duì)比也是RDMA對(duì)比NetDAM，而不是簡(jiǎn)單的帶節(jié)奏，而NetDAM本身也要等著CXL慢慢成熟起來(lái)，例如Linux中針對(duì)CXL的網(wǎng)卡內(nèi)存、顯卡顯存的操作驅(qū)動(dòng)逐漸完善，但是這個(gè)過(guò)程起碼也要3~5年的時(shí)間, 可能CXL還需要像CHI那樣定義一些更加靈活的拓?fù)浣Y(jié)構(gòu)，如果不懂繼續(xù)看NetDAM的論文：

https://arxiv.org/abs/2110.14902

擁抱變化，Overlay是否需要SR?

Ruta這樣的項(xiàng)目在很多網(wǎng)絡(luò)團(tuán)隊(duì)的評(píng)價(jià)都是：SRv6不香么?SID太長(zhǎng)也可以壓縮呀，再搞一套有啥必要?但是他們忘了本質(zhì)的區(qū)別是在Segment Routing放在overlay還是underlay?網(wǎng)絡(luò)團(tuán)隊(duì)為了自己的利益自然會(huì)選擇一個(gè)能夠接管overlay的協(xié)議。

而找我搞Ruta的大多數(shù)都是應(yīng)用的團(tuán)隊(duì)，特別是各個(gè)有音視頻和CDN業(yè)務(wù)的團(tuán)隊(duì)，還有一些容器網(wǎng)絡(luò)的團(tuán)隊(duì)。在Overlay上搞SR才是必然選擇， 因?yàn)闃I(yè)務(wù)流量的調(diào)度，多云互聯(lián)。

例如在一個(gè)混合云的場(chǎng)景中，我們經(jīng)常為客戶(hù)部署SD-WAN時(shí)遇到很多挑戰(zhàn)。例如到AWS后，還要我們自己的SD-WAN路由器和AWS建一個(gè)IPSec隧道，而Azure需要專(zhuān)用的一個(gè)NVA節(jié)點(diǎn)重分布BGP。其它云還面臨著VPC本身處于靜態(tài)路由的時(shí)代，例如渣為了某客戶(hù)上阿里云，還自己寫(xiě)了一個(gè)BGP+aliyun-cloud-shell的小程序幫助兩邊重分發(fā)路由。

因此在渣的論文中，VPC內(nèi)使用Segment Routing構(gòu)建Transparency VPC比原來(lái)的Transit VPC技術(shù)更加有效，更加的能夠?qū)崿F(xiàn)cloud-agnostic，因?yàn)榇罅康脑圃鶮8S節(jié)點(diǎn)和容器網(wǎng)絡(luò)本身就是在VPC基礎(chǔ)上再構(gòu)建了一個(gè)Overlay。

而網(wǎng)絡(luò)團(tuán)隊(duì)被云原生搞的接近失業(yè)的本質(zhì)不就清楚了么?業(yè)務(wù)本身也有service-chaining的需求，而這些需求在傳統(tǒng)的VPC架構(gòu)上是很難進(jìn)行鏈?zhǔn)接|發(fā)的，例如在Overlay上實(shí)現(xiàn)超算等業(yè)務(wù)，MPI-RingAllreduce這些低延遲的場(chǎng)景如何搞?是否可以通過(guò)協(xié)議編碼在overlay上降低API-Gateway的負(fù)擔(dān)?這些都是應(yīng)用需要網(wǎng)絡(luò)團(tuán)隊(duì)幫忙一起解決的問(wèn)題，可惜網(wǎng)絡(luò)還抱著自己的Overlay provide by SR做白日夢(mèng)。

結(jié)論：在VPC之上幫應(yīng)用構(gòu)建SegmentRouting才是關(guān)鍵，放下SRv6宗教信仰去擁抱變化

IPv4 over SRv6、SR-MPLS

另一個(gè)問(wèn)題是運(yùn)營(yíng)商通常遇到的，當(dāng)你建立好一個(gè)SRv6或者SR-MPLS網(wǎng)絡(luò)后，通常會(huì)抱怨業(yè)務(wù)為啥不切換上來(lái)?很顯然的一個(gè)問(wèn)題，誰(shuí)有空那么無(wú)聊為了你改代碼，還一定要應(yīng)用程序有Root權(quán)限并且又要通過(guò)Kernel轉(zhuǎn)發(fā)?人家應(yīng)用好不容易Kernel Bypass做完，又要你去Kernel兜一圈…

特別是那些家庭里的小路由器終端，全國(guó)幾千萬(wàn)臺(tái)，為了一個(gè)SRv6全部更換值得么?對(duì)設(shè)備商來(lái)看自然有動(dòng)力，對(duì)運(yùn)營(yíng)商來(lái)看勢(shì)必不行了。同時(shí)還有大量的寬帶接入設(shè)備升級(jí)改造困難時(shí)，為什么不想起來(lái)一個(gè)4over6的技術(shù)呢?利用Ruta在接入側(cè)實(shí)現(xiàn)Binding-SID的映射將傳統(tǒng)網(wǎng)絡(luò)很容易的導(dǎo)入到SRv6或者SR-MPLS網(wǎng)絡(luò)中?

技術(shù)的輪回

其實(shí)很多技術(shù)都這樣，架構(gòu)師需要考慮生態(tài)、利舊，即便是自己看明白了未來(lái)的路在哪里，耐心比信心更加重要，因?yàn)槟阈枰徊讲降南蚪K端去變更迭代，而不是簡(jiǎn)單的推倒重來(lái)，學(xué)會(huì)利用生態(tài)鏈中一切可以利用的資源，而不是簡(jiǎn)單的固步自封。