第21屆HotNets于2022年11月14日-11月15日在美國得克薩斯州奧斯汀召開。本次會議共收到104篇投稿，接收32篇論文，錄取率為30.77%。

廈門大學(xué)SNG的同學(xué)們按照會議日程對論文內(nèi)容進(jìn)行了分期評述，本期介紹session2的論文。

Session2： Rethinking the Internet

The Case for an Internet Primitive for Fault Localization

William Sussman （MIT）; Emily Marx （UC Berkeley）; Venkat Arun （MIT）; Akshay Narayan （UC Berkeley）， Mohammad Alizadeh， Hari Balakrishnan （MIT）; Aurojit Panda （New York University）; Scott Shenker （ICSI and UC Berkeley）

＞背景

現(xiàn)代分布式應(yīng)用程序基本都部署運行在云數(shù)據(jù)中心中的眾多微服務(wù)和組件上，使用共享的云服務(wù)進(jìn)行計算和存儲。一個分布式服務(wù)可能需要多個分布式應(yīng)用、各種網(wǎng)絡(luò)交換傳輸設(shè)備、以及不同網(wǎng)絡(luò)層上的網(wǎng)絡(luò)協(xié)議共同協(xié)作來完成。而今天的大規(guī)模應(yīng)用程序是由數(shù)千個軟件組件組成的，通常作為微服務(wù)運行。這些微服務(wù)運行在云數(shù)據(jù)中心的虛擬機(jī)中，并通過虛擬交換機(jī)和網(wǎng)絡(luò)功能使用物理網(wǎng)絡(luò)。應(yīng)用程序組件可以分布在全球不同的數(shù)據(jù)中心和云提供商之間，并在邊緣位置和客戶端端點上使用在內(nèi)容分發(fā)網(wǎng)絡(luò)（CDNs）中運行的組件。這也是為什么當(dāng)觀察到一個網(wǎng)絡(luò)問題時，很難識別哪個組件有故障。在這些組件中的任何一個環(huán)節(jié)都有可能出現(xiàn)錯誤導(dǎo)致網(wǎng)絡(luò)問題：比如無數(shù)的交換機(jī)、防火墻、網(wǎng)絡(luò)路由器和連接它們的鏈路故障。本文提出了一種具有簡單、標(biāo)準(zhǔn)化的互聯(lián)網(wǎng)信息接口的跨層、跨域、跨應(yīng)用的故障定位原語WTF來實現(xiàn)網(wǎng)絡(luò)事故的檢測定位。

＞W(wǎng)TF核心設(shè)計

利用health bits作為原語來表示網(wǎng)絡(luò)組件自身的網(wǎng)絡(luò)狀態(tài)，里面攜帶的是有關(guān)網(wǎng)絡(luò)故障的信息，網(wǎng)絡(luò)事故可以通過追溯一系列的health bits來進(jìn)行錯誤定位。

把網(wǎng)絡(luò)系統(tǒng)看作一個（巨大的）圖，圖上最小的單位是元素，每個元素可以是影響分布式應(yīng)用程序的觀察行為的任何組件、系統(tǒng)服務(wù)、網(wǎng)絡(luò)功能或設(shè)備。而一個圖上的節(jié)點指在其中運行一個或多個元素的服務(wù)器或虛擬機(jī)。

圖上的邊表示元素間的交互關(guān)系，所以每個節(jié)點（包含多個元素）只知道自己域內(nèi)的組件狀態(tài)和相連的鄰居節(jié)點的某些元素狀態(tài)，即每個節(jié)點只有局部視圖。

節(jié)點只能定義自身的health bits的語義和鄰居節(jié)點的health bits狀態(tài)而不知道鄰居節(jié)點的具體語義，但通過這些觀測到的狀態(tài)就可以定位錯誤。

考慮到各種網(wǎng)絡(luò)組件的差異性（包括軟硬件復(fù)雜程度、性能情況），WTF不指定health bits該如何定義以及如何維護(hù)及利用，只提供了一種health bits可以傳輸用于錯誤定位的機(jī)制來探討跨協(xié)議跨域跨應(yīng)用的網(wǎng)絡(luò)事故檢測方法。

＞W(wǎng)TF用例

考慮下圖的例子，這是一個多人游戲應(yīng)用程序，有兩個玩家（player 1和player 2），且需將他們的游戲直播給觀眾。Player 1在一個由云游戲服務(wù)提供的實例上運行游戲，而Player 2則在本地運行游戲。兩個玩家都被連接到一個多人游戲服務(wù)器。玩家1的云游戲?qū)嵗策B接到流媒體服務(wù)器，流媒體服務(wù)器為用戶轉(zhuǎn)換游戲視頻和音頻。如果玩家在執(zhí)行一個動作和其效果對其他玩家可見之間有明顯的延遲，玩家可能會報告網(wǎng)絡(luò)問題。如果視頻流滯后或質(zhì)量較低，觀眾可能會報告網(wǎng)絡(luò)問題。如例子中，觀眾報告了視頻卡頓的問題，于是相應(yīng)的網(wǎng)絡(luò)組件（元素）開始收集屬于視頻流區(qū)域的元素的health bits（子圖c），之后進(jìn)一步分析這些組件的網(wǎng)絡(luò)狀態(tài)來定位錯誤，快速返回給開發(fā)者（子圖e）。

＞個人觀點

任何網(wǎng)絡(luò)運行都可以抽象成一個連通圖，如本文所述，圖上節(jié)點是網(wǎng)絡(luò)組件，節(jié)點/鏈路的故障情況會導(dǎo)致圖的某些屬性違反（比如連通性、min-cut、和最大最小流性質(zhì)），這些性質(zhì)的改變就是產(chǎn)生網(wǎng)絡(luò)事故的原因。傳統(tǒng)的網(wǎng)絡(luò)事故診斷更像是在故障顯示起點（如延遲過大的客戶端）開展廣度優(yōu)先遍歷來找根因節(jié)點/鏈路（因為不知道全局視圖，即未知除了自己外的任一節(jié)點/鏈路是否有錯），而health bits的做法好比是運行時周期性地讓各個域維護(hù)自己的錯誤性狀態(tài)并讓鄰居也知道，雖然仍不知全局視圖，但這樣在事故發(fā)生時可以提供一些先驗知識來深度優(yōu)先遍歷網(wǎng)絡(luò)圖從而找到最可能導(dǎo)致錯誤的子樹。

Tango or Square Dance？ How Tightly Should we Integrate Network Functionality in Browsers？

A. Davidson（Brave Software） M. Frei（ETH Zurich） M. Gartner（OVGU Magdeburg） H. Haddadi（Imperial College London） A. Perrig（ETH Zurich） J. Subirà Nieto（ETH Zurich） P. Winter（Brave Software） F. Wirz（ETH Zurich）

隨著路徑感知網(wǎng)絡(luò)（PAN）的出現(xiàn)，應(yīng)用程序如何利用新的網(wǎng)絡(luò)特性的問題也隨之出現(xiàn)。傳統(tǒng)上，網(wǎng)絡(luò)功能要么放在核心網(wǎng)絡(luò)、中間件中，要么放在操作系統(tǒng)中。在新興的路徑感知網(wǎng)絡(luò)技術(shù)的背景下，出現(xiàn)了一個有趣的問題：哪一層應(yīng)該處理新的特性？本文作者認(rèn)為，瀏覽器正在成為網(wǎng)絡(luò)創(chuàng)新的強(qiáng)大平臺，它可以承載各種復(fù)雜的服務(wù)，即使這些服務(wù)與具體業(yè)務(wù)高度相關(guān)。基于這樣的想法，作者基于SCION路徑感知網(wǎng)絡(luò)體系結(jié)構(gòu)實現(xiàn)了一個瀏覽器擴(kuò)展原型，在不引入任何顯著性能開銷的情況下，證明了地理隔離瀏覽的可行性。

＞背景

SCION是一種自2009年開發(fā)的面向安全和路徑感知的網(wǎng)絡(luò)架構(gòu)。SCION提供了對兩個端點之間的多個路徑轉(zhuǎn)發(fā)的支持以及安全性的保障?；赟CION網(wǎng)絡(luò)架構(gòu)的特性以及其提供的服務(wù)，我們可以選擇不同的路徑進(jìn)行數(shù)據(jù)傳輸，比如延遲最低路徑、帶寬最高路徑、丟包率最低路徑等等。也就是說，這些路徑可以是不同屬性要求下的最優(yōu)路徑，同時，我們也可以利用SCION的路徑感知能力提供地理隔離等服務(wù)。本文針對SCION所提供的能力應(yīng)該在哪一層進(jìn)行應(yīng)用進(jìn)行了討論，首先分析了路徑感知能力在不同載體上（操作系統(tǒng)，App，用戶）的使用針對不同指標(biāo)的合適程度，如下圖所示：

＞創(chuàng)新

瀏覽器是人們與Internet交互的主要媒介。2021年，有50億人將網(wǎng)絡(luò)瀏覽器作為桌面或移動的使用的一部分，其中32億人使用Google Chrome，瀏覽器在PC端和手機(jī)端有著巨大使用規(guī)模，所以作者認(rèn)為，在瀏覽器中使用SCION的路徑感知能力是一個很自然的想法。作者認(rèn)為：在Web瀏覽器中部署新技術(shù)可以最大限度地減少新手用戶所需的配置和安裝工作量。出于這種想法，作者在Brave瀏覽器中實現(xiàn)了一個基于路徑感知網(wǎng)絡(luò)的路徑選擇插件原型。

＞實現(xiàn)

如下圖所示，在本文中，插件的設(shè)計可以同時支持BGP/IP網(wǎng)絡(luò)和SCION網(wǎng)絡(luò)。在用戶使用BGP/IP網(wǎng)絡(luò)時，瀏覽器插件不對用戶請求進(jìn)行攔截，當(dāng)用戶使用SCION網(wǎng)絡(luò)時，則瀏覽器插件將請求轉(zhuǎn)至一個輕量級的QUIC代理進(jìn)行發(fā)送。

由于SCION網(wǎng)絡(luò)并沒有廣泛部署，當(dāng)用戶開啟了SCION網(wǎng)絡(luò)選項時，如果用戶同時開啟了嚴(yán)格模式，則所有請求將通過SCION網(wǎng)絡(luò)進(jìn)行傳輸，如果目標(biāo)地不支持該模式，則瀏覽器不加載該資源。在非嚴(yán)格模式下，不支持SCION網(wǎng)絡(luò)的資源將會通過BGP/IP網(wǎng)絡(luò)進(jìn)行加載。

＞ 評估

從評估結(jié)果中可以看出，當(dāng)添加拓展后，即使使用SCION網(wǎng)絡(luò)進(jìn)行網(wǎng)絡(luò)資源的加載，也只額外消耗了很少的時間（大約30ms），但是卻獲得了路徑選擇的權(quán)利。

＞個人觀點

利用瀏覽器使用路徑感知網(wǎng)絡(luò)的特性是一個有趣的嘗試，雖然對用戶來說，更加在意的一般都是延遲和帶寬，但對于ISP和網(wǎng)頁提供者來說，利用路徑感知，路徑選擇，地理隔離等相關(guān)功能可能會產(chǎn)生許多好處（環(huán)保、經(jīng)濟(jì)價值）。值得一提的是，路徑感知網(wǎng)絡(luò)中的各項指標(biāo)測量可能并不準(zhǔn)確，但這并不妨礙它存在的價值和意義。

Sidecar： In-Network Performance Enhancements in the Age of Paranoid Transport Protocols

Gina Yuan（Stanford University）， David K.Zhang（Stanford University）， Matthew Sotoudeh（Stanford University）， Michael Welzl（University of Oslo）， Keith Winstein（Stanford University）

＞背景

對于高延遲衛(wèi)星鏈路、具有大量ACK和頻繁重新排序的Wi-Fi或蜂窩WWAn的路徑，重復(fù)使用有線網(wǎng)絡(luò)的超時重傳或擁塞控制方案并不理想。許多網(wǎng)絡(luò)通過在部署性能增強(qiáng)代理（PEP）加速TCP連接。在TCP連接的中間加入PEP可以更改特定子路徑上的網(wǎng)絡(luò)行為。然而，如QUIC這樣的傳輸協(xié)議需要加密、驗證報頭和有效載荷，對中間件不透明，使得性能增強(qiáng)代理（PEP）無法提供與以前相同的幫助。

本文提出一種與現(xiàn)有底層協(xié)議松耦合的sidecar協(xié)議，適用于QUIC這樣對中間件不透明的協(xié)議。sidecar協(xié)議的關(guān)鍵挑戰(zhàn)是如何有效地表示底層連接的數(shù)據(jù)包，同時避免PEP存在的協(xié)議僵化問題。本文采用一種簡明的數(shù)字表示——quACK（快速ACK），用于有效解碼sidecar協(xié)議接收到的隨機(jī)加密數(shù)據(jù)包標(biāo)識符。文章實現(xiàn)了quACK，并討論了quACK的三個應(yīng)用：擁塞控制拆分、ACK減少以及在有損子路徑上PEP到PEP的重傳。

＞quACK設(shè)計

發(fā)送方發(fā)送集合（集合中的每個元素為數(shù)據(jù)包的標(biāo)識符）到接收方，接收方收到集合，。接收方通過構(gòu)造quACK，發(fā)送方解碼quACK推斷出，即丟失包的標(biāo)識符。文章使用 straggler identification方法，將quACK的解碼問題轉(zhuǎn)換為冪和多項式求解。

＞應(yīng)用

1）擁塞控制拆分

將端到端連接拆分為多個段使得PEP能夠更好地調(diào)整其發(fā)送速率或在每個段上實施不同類型的擁塞控制方案。然而，PEP無法應(yīng)用于端到端加密協(xié)議。quACK使得即使是端到端加密協(xié)議，也可以通過sidecar協(xié)議執(zhí)行如PEP的連接拆分以進(jìn)行擁塞控制。

客戶端向代理發(fā)送quACK，代理向服務(wù)器發(fā)送quACK，每個段上以固定間隔（例如每RTT一次）發(fā)送quACK。每個段上的發(fā)送方能夠準(zhǔn)確地確定自上次quACK以來尚未接收到哪些數(shù)據(jù)包。Sidecar協(xié)議使用從quACK解碼出的信息來調(diào)整下游段上的發(fā)送速率。例如，如果代理檢測到大量數(shù)據(jù)包尚未接收，則可以以較慢的速率發(fā)送緩沖區(qū)中未轉(zhuǎn)發(fā)的QUIC數(shù)據(jù)包。

2）ACK減少

使用quACK可以為端到端加密協(xié)議提供累計序列號ACK的功能，quACK不知道協(xié)議級別的序列號，但可以簡潔地表示接收到的數(shù)據(jù)包。sidecar協(xié)議將quACK視為客戶端ACK。代理不需要讀取或修改QUIC包內(nèi)容，客戶端也無需參與sidecar協(xié)議。該協(xié)議可以使服務(wù)器更快地向前移動其發(fā)送窗口，而不是等待來自客戶端的ACK。客戶端還可以使用QUIC中提出的ACK頻率擴(kuò)展來發(fā)送更少的ACK，從而減少網(wǎng)絡(luò)擁塞。

盡管這些quACK通常取代來自客戶端的ACK，但端到端ACK具有sidecar協(xié)議無法實現(xiàn)的某些特殊功能。例如，端到端ACK可以傳送顯式擁塞通知（ECN）信息。此外，quACK不會反饋從代理發(fā)送到客戶端過程中丟失的數(shù)據(jù)包。因此，服務(wù)器在大多數(shù)情況下仍然可以依賴quACK，并在需要重傳時使用不太頻繁的端到端ACK。

3）網(wǎng)內(nèi)重傳

兩個路由器上的sidecar實例被靜態(tài)配置為在它們之間的路徑段上發(fā)生數(shù)據(jù)包丟失的情況下重新發(fā)送數(shù)據(jù)包。當(dāng)兩個路由器之間的RTT顯著小于端到端RTT時，網(wǎng)絡(luò)內(nèi)重傳可能是有益的。左側(cè)的接收方代理向右側(cè)的發(fā)送方代理發(fā)送quACK。發(fā)送方代理不需要讀取或修改數(shù)據(jù)包內(nèi)容，只需將數(shù)據(jù)包緩存在緩沖區(qū)中，以防需要重傳。接收方代理生成和發(fā)送quACK的間隔是靈活的，理想情況下取決于丟包率。

＞評估

在一個quACK表示1000個已發(fā)送數(shù)據(jù)包的情況下，最多丟失20個數(shù)據(jù)包。其中，每個數(shù)據(jù)包使用32位標(biāo)識符表示，一個quACK大小為82B，需要106us來構(gòu)造，61us來解碼。使用32位標(biāo)識符時，數(shù)據(jù)包具有0.000023%的沖突概率（一個標(biāo)識符映射到多個數(shù)據(jù)包的概率）。

＞個人觀點

當(dāng)前網(wǎng)絡(luò)中以加密流量為主，加密協(xié)議QUIC是HTTP3協(xié)議中的重要協(xié)議之一，傳統(tǒng)PEP不適用于加密場景。文章提出的sidecar協(xié)議解決了加密流量傳輸?shù)男阅茉鰪?qiáng)問題，所提出的quACK構(gòu)造和解碼方法對加密數(shù)據(jù)包的識別具有啟發(fā)性。quACK方法可以有效識別丟失數(shù)據(jù)包卻不能完全替代ACK，協(xié)議不可知情況下是否還有可用于性能增強(qiáng)的其他信息值得進(jìn)一步探索。

DIP:Unifying Network Layer Innovatios using Shared L3 Core Functions

Ziqiang Wang（Southeast University）， Zhuotao Liu（Tsinghua University and Zhongguancun Laboratory）， Xiaoliang Wang（Capital Normal University）， Songtao Fu（Tsinghua University）， Ke Xu（Tsinghua University and Zhongguancun Laboratory）

＞背景

IP協(xié)議為互聯(lián)網(wǎng)的發(fā)展做出了巨大貢獻(xiàn)，但是IP協(xié)議的固定分組處理阻礙了互聯(lián)網(wǎng)的功能擴(kuò)展。IP協(xié)議的廣泛應(yīng)用導(dǎo)致了目前的互聯(lián)網(wǎng)架構(gòu)單一且固定（只能使用IP協(xié)議），無法適應(yīng)核心機(jī)制的創(chuàng)新，例如無法動態(tài)部署更適合移動場景的尋址模型（移動場景更適合非IP的尋址模式）。為了解決互聯(lián)網(wǎng)的協(xié)議僵化問題，網(wǎng)絡(luò)社區(qū)提出了各種新的L3協(xié)議，以更好地支持網(wǎng)絡(luò)層的各種網(wǎng)絡(luò)功能。本文提出了一種新L3協(xié)議DIP（Dynamic Internet Protocol，動態(tài)互聯(lián)網(wǎng)協(xié)議）。DIP基于新L3功能原語Field Operation（FN），構(gòu)建L3協(xié)議共享的通用網(wǎng)絡(luò)功能核心。每個獨立的L3協(xié)議可以被分解為多個FN的組合，同時可以組合各種FN來實現(xiàn)新的L3協(xié)議。

＞設(shè)計

DIP的基本頭由四個字段組成：NextHdr、FN_Num、HopL和Packet Parameter。FN_Num表示數(shù)據(jù)包中定義的FN數(shù)量。每個FN由包頭中的三個字段指定：FieldLoc、FieldLen和Operation_Key。FN讀取和寫入的實際數(shù)據(jù)包位置定義為 FN Locations（FieldLoc，F(xiàn)ieldLoc：FieldLen）。Operation_Key表示需要對FN Locations進(jìn)行的操作。

＞評估

本文在 Barefoot Tofino可編程交換機(jī)上實現(xiàn)了DIP原型，并對IP、NDN、OPT和NDN +OPT協(xié)議數(shù)據(jù)包的處理時間和開銷進(jìn)行了評估。

1）包處理時間

對于IP、NDN、OPT和NDN +OPT協(xié)議數(shù)據(jù)包，在包大小為128字節(jié)、768字節(jié)和1500字節(jié)三種情況下測試處理時間。以IPv4和IPv6報文的轉(zhuǎn)發(fā)時間為基準(zhǔn)。評估結(jié)果如下圖所示。結(jié)果表明，DIP報文的處理時間接近于基線。由于MAC操作比較昂貴，所以O(shè)PT和NDN+OPT包需要更多的處理時間。

2）包頭大小開銷

DIP包頭開銷略大于基準(zhǔn)協(xié)議， 如下圖所示

＞個人觀點

DIP利用網(wǎng)絡(luò)可編程設(shè)備的發(fā)展，為網(wǎng)絡(luò)功能的使用和定制提供了新的設(shè)計空間。這種思想就好像面向?qū)ο缶幊讨械某橄箢悾瑘箢^規(guī)定了字段和字段處理函數(shù)的抽象。需要實現(xiàn)具體的協(xié)議時，就將字段和字段處理函數(shù)實例化，大大增加了網(wǎng)絡(luò)協(xié)議的靈活性。

審核編輯 ：李倩