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

廈門大學SNG的同學們按照會議日程對論文內容進行了分期評述，本期介紹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）

＞背景

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

＞WTF核心設計

利用health bits作為原語來表示網絡組件自身的網絡狀態，里面攜帶的是有關網絡故障的信息，網絡事故可以通過追溯一系列的health bits來進行錯誤定位。

把網絡系統看作一個（巨大的）圖，圖上最小的單位是元素，每個元素可以是影響分布式應用程序的觀察行為的任何組件、系統服務、網絡功能或設備。而一個圖上的節點指在其中運行一個或多個元素的服務器或虛擬機。

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

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

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

＞WTF用例

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

＞個人觀點

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

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）

隨著路徑感知網絡（PAN）的出現，應用程序如何利用新的網絡特性的問題也隨之出現。傳統上，網絡功能要么放在核心網絡、中間件中，要么放在操作系統中。在新興的路徑感知網絡技術的背景下，出現了一個有趣的問題：哪一層應該處理新的特性？本文作者認為，瀏覽器正在成為網絡創新的強大平臺，它可以承載各種復雜的服務，即使這些服務與具體業務高度相關?；谶@樣的想法，作者基于SCION路徑感知網絡體系結構實現了一個瀏覽器擴展原型，在不引入任何顯著性能開銷的情況下，證明了地理隔離瀏覽的可行性。

＞背景

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

＞創新

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

＞實現

如下圖所示，在本文中，插件的設計可以同時支持BGP/IP網絡和SCION網絡。在用戶使用BGP/IP網絡時，瀏覽器插件不對用戶請求進行攔截，當用戶使用SCION網絡時，則瀏覽器插件將請求轉至一個輕量級的QUIC代理進行發送。

由于SCION網絡并沒有廣泛部署，當用戶開啟了SCION網絡選項時，如果用戶同時開啟了嚴格模式，則所有請求將通過SCION網絡進行傳輸，如果目標地不支持該模式，則瀏覽器不加載該資源。在非嚴格模式下，不支持SCION網絡的資源將會通過BGP/IP網絡進行加載。

＞ 評估

從評估結果中可以看出，當添加拓展后，即使使用SCION網絡進行網絡資源的加載，也只額外消耗了很少的時間（大約30ms），但是卻獲得了路徑選擇的權利。

＞個人觀點

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

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）

＞背景

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

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

＞quACK設計

發送方發送集合（集合中的每個元素為數據包的標識符）到接收方，接收方收到集合，。接收方通過構造quACK，發送方解碼quACK推斷出，即丟失包的標識符。文章使用 straggler identification方法，將quACK的解碼問題轉換為冪和多項式求解。

＞應用

1）擁塞控制拆分

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

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

2）ACK減少

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

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

3）網內重傳

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

＞評估

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

＞個人觀點

當前網絡中以加密流量為主，加密協議QUIC是HTTP3協議中的重要協議之一，傳統PEP不適用于加密場景。文章提出的sidecar協議解決了加密流量傳輸的性能增強問題，所提出的quACK構造和解碼方法對加密數據包的識別具有啟發性。quACK方法可以有效識別丟失數據包卻不能完全替代ACK，協議不可知情況下是否還有可用于性能增強的其他信息值得進一步探索。

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協議為互聯網的發展做出了巨大貢獻，但是IP協議的固定分組處理阻礙了互聯網的功能擴展。IP協議的廣泛應用導致了目前的互聯網架構單一且固定（只能使用IP協議），無法適應核心機制的創新，例如無法動態部署更適合移動場景的尋址模型（移動場景更適合非IP的尋址模式）。為了解決互聯網的協議僵化問題，網絡社區提出了各種新的L3協議，以更好地支持網絡層的各種網絡功能。本文提出了一種新L3協議DIP（Dynamic Internet Protocol，動態互聯網協議）。DIP基于新L3功能原語Field Operation（FN），構建L3協議共享的通用網絡功能核心。每個獨立的L3協議可以被分解為多個FN的組合，同時可以組合各種FN來實現新的L3協議。

＞設計

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

＞評估

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

1）包處理時間

對于IP、NDN、OPT和NDN +OPT協議數據包，在包大小為128字節、768字節和1500字節三種情況下測試處理時間。以IPv4和IPv6報文的轉發時間為基準。評估結果如下圖所示。結果表明，DIP報文的處理時間接近于基線。由于MAC操作比較昂貴，所以OPT和NDN+OPT包需要更多的處理時間。

2）包頭大小開銷

DIP包頭開銷略大于基準協議， 如下圖所示

＞個人觀點

DIP利用網絡可編程設備的發展，為網絡功能的使用和定制提供了新的設計空間。這種思想就好像面向對象編程中的抽象類，報頭規定了字段和字段處理函數的抽象。需要實現具體的協議時，就將字段和字段處理函數實例化，大大增加了網絡協議的靈活性。

審核編輯 ：李倩