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

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

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

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

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

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

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

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

＞W(wǎng)TF用例

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

＞個(gè)人觀點(diǎn)

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

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)了一個(gè)有趣的問題：哪一層應(yīng)該處理新的特性？本文作者認(rèn)為，瀏覽器正在成為網(wǎng)絡(luò)創(chuàng)新的強(qiáng)大平臺(tái)，它可以承載各種復(fù)雜的服務(wù)，即使這些服務(wù)與具體業(yè)務(wù)高度相關(guān)。基于這樣的想法，作者基于SCION路徑感知網(wǎng)絡(luò)體系結(jié)構(gòu)實(shí)現(xiàn)了一個(gè)瀏覽器擴(kuò)展原型，在不引入任何顯著性能開銷的情況下，證明了地理隔離瀏覽的可行性。

＞背景

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

＞創(chuàng)新

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

＞實(shí)現(xiàn)

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

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

＞ 評(píng)估

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

＞個(gè)人觀點(diǎn)

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

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）

＞背景

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

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

＞quACK設(shè)計(jì)

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

＞應(yīng)用

1）擁塞控制拆分

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

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

2）ACK減少

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

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

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

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

＞評(píng)估

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

＞個(gè)人觀點(diǎn)

當(dāng)前網(wǎng)絡(luò)中以加密流量為主，加密協(xié)議QUIC是HTTP3協(xié)議中的重要協(xié)議之一，傳統(tǒng)PEP不適用于加密場(chǎng)景。文章提出的sidecar協(xié)議解決了加密流量傳輸?shù)男阅茉鰪?qiáng)問題，所提出的quACK構(gòu)造和解碼方法對(duì)加密數(shù)據(jù)包的識(shí)別具有啟發(fā)性。quACK方法可以有效識(shí)別丟失數(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é)議），無(wú)法適應(yīng)核心機(jī)制的創(chuàng)新，例如無(wú)法動(dòng)態(tài)部署更適合移動(dòng)場(chǎng)景的尋址模型（移動(dòng)場(chǎng)景更適合非IP的尋址模式）。為了解決互聯(lián)網(wǎng)的協(xié)議僵化問題，網(wǎng)絡(luò)社區(qū)提出了各種新的L3協(xié)議，以更好地支持網(wǎng)絡(luò)層的各種網(wǎng)絡(luò)功能。本文提出了一種新L3協(xié)議DIP（Dynamic Internet Protocol，動(dòng)態(tài)互聯(lián)網(wǎng)協(xié)議）。DIP基于新L3功能原語(yǔ)Field Operation（FN），構(gòu)建L3協(xié)議共享的通用網(wǎng)絡(luò)功能核心。每個(gè)獨(dú)立的L3協(xié)議可以被分解為多個(gè)FN的組合，同時(shí)可以組合各種FN來(lái)實(shí)現(xiàn)新的L3協(xié)議。

＞設(shè)計(jì)

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

＞評(píng)估

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

1）包處理時(shí)間

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

2）包頭大小開銷

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

＞個(gè)人觀點(diǎn)

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

審核編輯 ：李倩