＞背景與問(wèn)題 在當(dāng)今最廣泛部署的網(wǎng)絡(luò)堆棧中，專(zhuān)用的、緊密集成的和靜態(tài)的數(shù)據(jù)包處理管道使網(wǎng)絡(luò)堆棧無(wú)法充分利用現(xiàn)代硬件的能力。如圖1(a)所示，當(dāng)今Linux網(wǎng)絡(luò)堆棧結(jié)構(gòu)存在以下特點(diǎn)：專(zhuān)用管道：每個(gè)應(yīng)用程序和/或線程將數(shù)據(jù)提交到專(zhuān)用管道的一端（發(fā)送端），網(wǎng)絡(luò)棧嘗試將數(shù)據(jù)傳遞到專(zhuān)用管道的另一端（接收端）；緊密集成的包處理管道：每個(gè)管道都有自己的socket，有自己獨(dú)立的傳輸層操作（擁塞控制、行控制等），并由網(wǎng)絡(luò)子系統(tǒng)完全獨(dú)立于其他共存的管道進(jìn)行操作；靜態(tài)管道：整個(gè)數(shù)據(jù)包處理管道（數(shù)據(jù)庫(kù)、協(xié)議處理、主機(jī)資源配置等）在管道創(chuàng)建時(shí)確定，并在管道生命周期期間保持不變，同樣，獨(dú)立于其他管道和主機(jī)上的動(dòng)態(tài)資源可用性。 這種專(zhuān)用的、緊密集成的和靜態(tài)的管道非常適合因特網(wǎng)和早期一代的數(shù)據(jù)中心網(wǎng)絡(luò)——因?yàn)樾阅芷款i主要位于網(wǎng)絡(luò)核心，需要仔細(xì)分配主機(jī)資源(計(jì)算、緩存、NIC隊(duì)列等)。然而，鏈路帶寬的快速增加，加上其他主機(jī)資源相對(duì)停滯的技術(shù)趨勢(shì)，現(xiàn)在已經(jīng)將瓶頸推到了主機(jī)上：（1）主機(jī)上的處理綁定到單個(gè)CPU core，無(wú)法處理快速的網(wǎng)絡(luò)傳過(guò)來(lái)的包，（2）當(dāng)網(wǎng)絡(luò)層處理成為短消息(例如，RPCs)的瓶頸時(shí)，靜態(tài)和專(zhuān)用包處理管道也阻止Linux動(dòng)態(tài)縮放連接數(shù)量。（3）當(dāng)延遲敏感和吞吐量綁定應(yīng)用程序co-located時(shí)，數(shù)據(jù)包處理管道的緊密集成特性會(huì)導(dǎo)致較差的性能隔離。因此對(duì)于這個(gè)新的機(jī)制，專(zhuān)用的、緊密集成的和靜態(tài)管道現(xiàn)在限制了今天的網(wǎng)絡(luò)堆棧，不能充分利用現(xiàn)代硬件的能力，不能支持us-scale的延遲和千兆比特的帶寬。因此，現(xiàn)有的網(wǎng)絡(luò)堆棧已經(jīng)處于崩潰的邊緣，而特兆比特以太網(wǎng)的出現(xiàn)將不可避免地需要重新構(gòu)建網(wǎng)絡(luò)堆棧。 ?＞設(shè)計(jì) 如圖1(b)所示，NetChannel將今天的網(wǎng)絡(luò)堆棧中緊密集成的包處理管道分解為三個(gè)松散耦合的層。虛擬網(wǎng)絡(luò)系統(tǒng)(VNS)：應(yīng)用程序與提供標(biāo)準(zhǔn)化接口的VNS層交互。VNS層支持應(yīng)用程序和內(nèi)核程序之間的數(shù)據(jù)傳輸，同時(shí)確保接口語(yǔ)義的正確性（例如，流接口的有序傳遞）。NetChannel的核心是NetDriver層：它使用channel抽象將網(wǎng)絡(luò)和遠(yuǎn)程服務(wù)器抽象為一個(gè)多隊(duì)列設(shè)備。特別是，NetDriver層將包處理從單個(gè)應(yīng)用程序和core解耦：一個(gè)core上的應(yīng)用程序讀取/寫(xiě)入的數(shù)據(jù)可以映射到一個(gè)或多個(gè)channel，而不破壞應(yīng)用程序語(yǔ)義。每個(gè)通道都實(shí)現(xiàn)了協(xié)議規(guī)范功能獨(dú)立，可以動(dòng)態(tài)映射到一個(gè)底層硬件隊(duì)列，和任何一對(duì)服務(wù)器之間的通道的數(shù)量可以擴(kuò)展獨(dú)立于這些服務(wù)器上運(yùn)行的應(yīng)用程序的數(shù)量和個(gè)人應(yīng)用程序使用的核心的數(shù)量。網(wǎng)絡(luò)調(diào)度器：它將延遲敏感的應(yīng)用程序與吞吐量綁定的應(yīng)用程序隔離：網(wǎng)絡(luò)通道使延遲敏感的應(yīng)用程序能夠?qū)崿F(xiàn)微秒規(guī)模的尾部延遲，同時(shí)允許帶寬密集型的應(yīng)用程序幾乎完美地使用剩余帶寬。 NetChannel優(yōu)勢(shì)在于簡(jiǎn)單，容易實(shí)現(xiàn)，同時(shí)能夠提升當(dāng)前網(wǎng)絡(luò)堆棧的性能，且獨(dú)立于網(wǎng)絡(luò)堆棧的位置——內(nèi)核、用戶空間或硬件，可以在微內(nèi)核風(fēng)格的用戶空間堆棧上實(shí)現(xiàn)其設(shè)計(jì)。作者選擇Linux內(nèi)核只是因?yàn)樗某墒?、穩(wěn)定性和廣泛的部署。＞性能

• 使單個(gè)應(yīng)用程序線程飽和數(shù)百千兆訪問(wèn)鏈路帶寬；

• 支持具有核數(shù)的小消息處理的近線性可伸縮性，獨(dú)立于應(yīng)用程序線程數(shù)；

• 支持隔離對(duì)延遲敏感的應(yīng)用程序，允許它們即使在與以近線速率運(yùn)行的吞吐量綁定的應(yīng)用程序競(jìng)爭(zhēng)時(shí)也能保持us-scale的尾延遲。

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

• 優(yōu)點(diǎn)

作者對(duì)于host network stack積累深厚，見(jiàn)解獨(dú)到，能夠具體分析出當(dāng)前Linux netowrk stack的限制性并由此提出重新設(shè)計(jì)當(dāng)前網(wǎng)絡(luò)棧的結(jié)構(gòu)。本文有意思的地方在于增加了虛擬隊(duì)列來(lái)實(shí)現(xiàn)應(yīng)用程序與資源之間的解耦，提高資源的利用率。

• 不足

作者在evaluation時(shí)，使用Redis來(lái)驗(yàn)證本文創(chuàng)新的Netchannel所具備的實(shí)踐性，不過(guò)Redis本身的性能就很高，作者還使用8個(gè)線程來(lái)做實(shí)驗(yàn)，那性能自然也不會(huì)低。這點(diǎn)或許有點(diǎn)取巧。第二，增加了虛擬隊(duì)列，實(shí)現(xiàn)資源共享后會(huì)存在諸多問(wèn)題，例如鎖的爭(zhēng)用和維護(hù)等帶來(lái)的開(kāi)銷(xiāo)，尤其是在大型數(shù)據(jù)中心里，隊(duì)列數(shù)目眾多，那開(kāi)銷(xiāo)會(huì)更大，但是作者并沒(méi)有提及該問(wèn)題和相應(yīng)的解決方案。 ?

SPRIGHT: Extracting the Server from Serverless Computing High-Performance eBPF-based Event-driven, Shared-Memory Processing

Shixiong Qi, Leslie Monis, Ziteng Zeng, Ian-chin Wang, K. K. Ramakrishnan (University of California, Riverside)

＞背景與問(wèn)題 這篇文章來(lái)自California的研究者。它設(shè)計(jì)了一個(gè)一種輕量級(jí)、高性能、響應(yīng)式無(wú)服務(wù)器(Serverless)框架——SPRIGHT。無(wú)服務(wù)器計(jì)算越來(lái)越受歡迎，因?yàn)橛脩糁恍枰_(kāi)發(fā)他們的應(yīng)用程序，而無(wú)需關(guān)心底層操作系統(tǒng)和硬件基礎(chǔ)設(shè)施。但是對(duì)于云服務(wù)提供商來(lái)說(shuō)，如何確保滿足服務(wù)質(zhì)量要求(SLO)是一項(xiàng)復(fù)雜的工作。其中出現(xiàn)的困難主要有兩個(gè)：（1）重型的無(wú)服務(wù)器組件：為了實(shí)現(xiàn)具有廣泛功能支持的跨功能服務(wù)網(wǎng)格層（例如指標(biāo)收集和緩沖，促進(jìn)無(wú)服務(wù)器網(wǎng)絡(luò)和編配等），每個(gè)函數(shù)倉(cāng)（function pod）都會(huì)有一個(gè)專(zhuān)用的sidecar代理組件來(lái)幫助建立。但是該組件是重型的，需要持續(xù)運(yùn)行并產(chǎn)生過(guò)多的開(kāi)銷(xiāo)。并且對(duì)于非常見(jiàn)的協(xié)議（例如MQTT, CoAP等），也需要額外的重型組件來(lái)適配，也會(huì)導(dǎo)致大量資源開(kāi)銷(xiāo)。(2)?函數(shù)鏈的數(shù)據(jù)平面性能較差：現(xiàn)代的云架構(gòu)為了提高靈活性，借助獨(dú)立于平臺(tái)的通信技術(shù)(如HTTP/REST API)，將單個(gè)應(yīng)用程序分解為多個(gè)松耦合、鏈接的函數(shù)。但是，這涉及到上下文切換、序列化和反序列化以及數(shù)據(jù)復(fù)制開(kāi)銷(xiāo)。目前的設(shè)計(jì)還嚴(yán)重依賴于內(nèi)核協(xié)議棧來(lái)處理路由和在功能艙之間轉(zhuǎn)發(fā)網(wǎng)絡(luò)數(shù)據(jù)包，所有這些都會(huì)影響性能。雖然靈活性提升了，但是性能開(kāi)銷(xiāo)卻仍是一個(gè)負(fù)擔(dān)。函數(shù)間產(chǎn)生的復(fù)雜數(shù)據(jù)管道為函數(shù)鏈增加了更多的網(wǎng)絡(luò)通信。所有這些都會(huì)導(dǎo)致數(shù)據(jù)平面性能較差(吞吐量較低，延遲較高)，影響服務(wù)水平目標(biāo)(SLOs)。 下圖為作者研究了幾個(gè)專(zhuān)有和開(kāi)源的無(wú)服務(wù)器平臺(tái)的設(shè)計(jì)后，開(kāi)發(fā)的一個(gè)通用抽象模型。當(dāng)客戶端發(fā)送消息時(shí)，在經(jīng)過(guò)網(wǎng)關(guān)后（①），在前端代理/消息代理中排隊(duì)（②）。代理會(huì)將消息發(fā)送到第一個(gè)函數(shù)倉(cāng)，但是會(huì)先經(jīng)過(guò)sidecar代理（③）。第一個(gè)函數(shù)處理完成后，會(huì)發(fā)往代理排隊(duì)進(jìn)入下一個(gè)函數(shù)倉(cāng)，但還是要先經(jīng)過(guò)sidecar代理（④）。轉(zhuǎn)交到下個(gè)函數(shù)倉(cāng)，按③④的步驟，沿著函數(shù)鏈反復(fù)執(zhí)行下去（⑤）。由此圖就可以看出，無(wú)服務(wù)器函數(shù)鏈產(chǎn)生的額外開(kāi)銷(xiāo)是非常巨大的（除函數(shù)倉(cāng)的user container外都是）。 ?＞設(shè)計(jì) 作者以開(kāi)源項(xiàng)目Knative作為基礎(chǔ)平臺(tái)開(kāi)始。使用事件驅(qū)動(dòng)處理和共享內(nèi)存來(lái)提升性能，并廣泛使用eBPF進(jìn)行聯(lián)網(wǎng)和監(jiān)控。eBPF是一個(gè)內(nèi)核內(nèi)的輕量級(jí)虛擬機(jī)，它可以插入/從內(nèi)核中插入，具有相當(dāng)?shù)撵`活性、效率和可配置性。 下圖顯示了SPRIGHT的總體架構(gòu)。主要包括以下幾個(gè)內(nèi)容： SPRIGHT控制器用來(lái)協(xié)調(diào)與編配引擎(即K8s和Knative)協(xié)同工作的函數(shù)的控制平面。在K8s主節(jié)點(diǎn)中運(yùn)行，與k8s運(yùn)作在每個(gè)worker節(jié)點(diǎn)上的進(jìn)程合作，對(duì)函數(shù)倉(cāng)的生命周期進(jìn)行管理。此外，與k8s的調(diào)度器一起工作，以確定函數(shù)鏈的規(guī)模和函數(shù)鏈在適當(dāng)?shù)墓ぷ鞴?jié)點(diǎn)上的放置位置。給定一個(gè)來(lái)自用戶的函數(shù)鏈創(chuàng)建請(qǐng)求，SPRIGHT控制器為函數(shù)鏈創(chuàng)建并分配必要的控制和數(shù)據(jù)平面組件，包括共享內(nèi)存管理器和SPRIGHT網(wǎng)關(guān)，并根據(jù)用戶配置啟動(dòng)函數(shù)鏈中的函數(shù)。 SPRIGHT網(wǎng)關(guān)是為了靈活管理SPRIGHT中函數(shù)鏈的進(jìn)出流量，避免在函數(shù)鏈中重復(fù)處理協(xié)議。充當(dāng)了函數(shù)鏈的反向代理，以合并協(xié)議處理。它攔截對(duì)函數(shù)鏈的傳入請(qǐng)求，并將有效負(fù)載復(fù)制到共享內(nèi)存區(qū)域。這允許在鏈內(nèi)進(jìn)行零拷貝處理，避免不必要的序列化/反序列化和協(xié)議棧處理。SPRIGHT網(wǎng)關(guān)是一個(gè)輕量級(jí)組件，內(nèi)存占用相對(duì)較小，CPU消耗也不是一個(gè)重要的問(wèn)題。 為了消除額外的網(wǎng)絡(luò)組件對(duì)函數(shù)鏈的影響，作者設(shè)計(jì)了直接功能路由(DFR)。DFR利用共享內(nèi)存并利用eBPF映射提供的可配置性。DFR允許動(dòng)態(tài)更新路由規(guī)則，并使用共享內(nèi)存直接在函數(shù)之間傳遞數(shù)據(jù)。 設(shè)計(jì)了一個(gè)輕量級(jí)的、事件驅(qū)動(dòng)的代理(EPROXY和SPROXY)，它使用eBPF來(lái)構(gòu)造服務(wù)網(wǎng)格，而不是像Knative那樣使用與每個(gè)函數(shù)實(shí)例關(guān)聯(lián)的連續(xù)運(yùn)行的隊(duì)列代理。因此，我們減少了大量的處理開(kāi)銷(xiāo)。＞性能 與Knative相比，SPRIGHT通過(guò)大量使用基于ebp的事件驅(qū)動(dòng)能力以及高性能的共享內(nèi)存處理，實(shí)現(xiàn)了高達(dá)5倍的吞吐量提高，53倍的延遲減少，以及27倍的CPU使用節(jié)省。 與使用DPDK提供共享內(nèi)存和零拷貝交付的環(huán)境相比，SPRIGHT實(shí)現(xiàn)了具有競(jìng)爭(zhēng)力的吞吐量和延遲，同時(shí)消耗的CPU資源減少了11倍。 此外，對(duì)于物聯(lián)網(wǎng)應(yīng)用中常見(jiàn)的間歇請(qǐng)求到達(dá)，與Knative使用“預(yù)熱”功能相比，SPRIGHT仍然將平均延遲提高了16%，同時(shí)減少了41%的CPU周期。＞個(gè)人觀點(diǎn) SPRIGHT是一個(gè)無(wú)服務(wù)器函數(shù)鏈框架，通過(guò)對(duì)零拷貝、基于eBPF代理和共享內(nèi)存的系統(tǒng)優(yōu)化的良好組合，相對(duì)于現(xiàn)有的開(kāi)源無(wú)服務(wù)器框架，它提供了大量的CPU、延遲和啟動(dòng)時(shí)間改進(jìn)。此外，本文貢獻(xiàn)了eBPF中高性能軟件數(shù)據(jù)路徑的設(shè)計(jì)和實(shí)現(xiàn)，該路徑非常適合跨節(jié)點(diǎn)中運(yùn)行的函數(shù)鏈處理請(qǐng)求調(diào)用的路由和轉(zhuǎn)發(fā)。

NeuroScaler: neural video enhancement at scale

Hyunho Yeo, Hwijoon Lim, Jaehong Kim, Youngmok Jung, Juncheol Ye, Dongsu Han (KAIST)

這篇文章來(lái)自KAIST的研究者。本文主要解決的內(nèi)容是在直播視頻流傳輸?shù)膱?chǎng)景下，采用傳統(tǒng)的神經(jīng)增強(qiáng)方法（Neural enhancement）實(shí)現(xiàn)高分辨率的視頻流傳輸時(shí)，神經(jīng)超分辨率（Neural super-resolution）計(jì)算開(kāi)銷(xiāo)過(guò)大，無(wú)法滿足實(shí)時(shí)直播需求的問(wèn)題。本文的是通過(guò)提供恰當(dāng)?shù)某直媛蕩?jì)算方案與服務(wù)端的編碼方案，優(yōu)化整體傳輸性能與視頻質(zhì)量。＞背景與問(wèn)題 當(dāng)今視頻流的傳輸過(guò)程中，人們對(duì)于高分辨率的視頻需求日益增長(zhǎng)。而隨著網(wǎng)絡(luò)技術(shù)的迭代，人們對(duì)于直播視頻流的質(zhì)量有了更多的期待。但是，高清視頻的傳輸很大程度上依賴于上行帶寬，因此，傳統(tǒng)的技術(shù)多采用DNN技術(shù)，從較低的分辨率圖像中獲取較高的分辨率。當(dāng)前的技術(shù)具有以下幾個(gè)特點(diǎn)：上行帶寬較低：視頻流需要從上行帶寬中傳輸?shù)矫襟w服務(wù)器，并分發(fā)給其他接收者。但由于上行帶寬較低，往往無(wú)法提供較高的視頻流質(zhì)量。超分辨率技術(shù)：超分辨率技術(shù)是指將低分辨率對(duì)應(yīng)物生成高分辨率圖像的技術(shù)?，F(xiàn)有的超分辨率技術(shù)大多使用深度神經(jīng)網(wǎng)絡(luò) (DNN)，學(xué)習(xí)低分辨率到高分辨率低映射。錨幀選取：錨幀是指應(yīng)用超分辨率技術(shù)的幀。因?yàn)閷?duì)幀進(jìn)行超分辨率推理帶來(lái)極大的開(kāi)銷(xiāo)，因此我們無(wú)法對(duì)每一個(gè)幀進(jìn)行推理。所以，從視頻流的一系列幀中選取錨幀，利用錨幀重建高分辨率視頻圖像是一種合理的方式。 因?yàn)樯闲袔捿^低，所以我們需要采用超分辨率技術(shù)進(jìn)行視頻流質(zhì)量的提升。但是，超分辨率技術(shù)帶來(lái)巨大的計(jì)算開(kāi)銷(xiāo)，因此，我們不能對(duì)每一個(gè)流進(jìn)行推理，而是應(yīng)該選擇錨幀進(jìn)行輔助重建。這也就帶來(lái)了一系列的問(wèn)題：1）錨幀的選取很大程度上影響著視頻流的質(zhì)量，不合理的錨幀會(huì)導(dǎo)致重建后的視頻質(zhì)量較低，因此，合適的實(shí)時(shí)錨幀選擇方式能極大改善系統(tǒng)的質(zhì)量。2）錨幀的計(jì)算開(kāi)銷(xiāo)是異構(gòu)的，這也意味著如果對(duì)于錨幀計(jì)算資源分配不恰當(dāng)，會(huì)導(dǎo)致整體性能的降低。3）媒體服務(wù)器上對(duì)幀的編碼也會(huì)帶來(lái)極大的計(jì)算開(kāi)銷(xiāo)。＞設(shè)計(jì) 本文作者認(rèn)為，合適的錨幀選擇可以提高視頻重建的質(zhì)量，而視頻流的編碼則是制約整體性能的重要瓶頸。當(dāng)前的設(shè)計(jì)面臨著三個(gè)主要的挑戰(zhàn)：1）圖像增強(qiáng)的高計(jì)算開(kāi)銷(xiāo)。2）編碼帶來(lái)的額外時(shí)延。3）在計(jì)算資源上的分配失效，無(wú)法帶來(lái)滿意的表現(xiàn)。此作者提出了三個(gè)部分的改進(jìn)，分別是1）錨幀的調(diào)度，即選取合適的錨幀，利用該錨幀可以獲取更好的視頻重建表現(xiàn)。2）為錨幀有效地分配計(jì)算資源。3）以及錨幀的增強(qiáng)設(shè)計(jì)，即使用合適的方法，在超分辨率編碼階段降低計(jì)算開(kāi)銷(xiāo)。其整體的架構(gòu)如下圖所示： ?無(wú)推斷錨幀選取：錨幀的增益可以不經(jīng)過(guò)實(shí)際的神經(jīng)推理即可獲取。當(dāng)我們不斷使用超分辨率進(jìn)行圖像的重建，因?yàn)閳D像之間的殘差，導(dǎo)致重建后的質(zhì)量損失。另一方面，文章觀察到增益和殘差具有一定的相關(guān)性，因此，文章通過(guò)殘差的計(jì)算，選取合適的錨幀，而不需要進(jìn)行具有極大計(jì)算開(kāi)銷(xiāo)都神經(jīng)推理。錨幀計(jì)算資源分配：錨幀的計(jì)算開(kāi)銷(xiāo)和增益都是異構(gòu)并會(huì)隨著時(shí)間變化的，因此，簡(jiǎn)單的平均分配并不能帶來(lái)優(yōu)秀的表現(xiàn)。因此，計(jì)算資源的調(diào)度應(yīng)該從錨幀的角度思考。本文提出了一個(gè)錨幀的選取算法，即從之前計(jì)算獲得的錨幀集合中，按照順序盡可能多的選取一部分錨幀，同時(shí)這些錨幀的推理時(shí)延需求要滿足一定的限制。在此之后，將錨幀進(jìn)行分組，并對(duì)每組分配計(jì)算資源。編碼開(kāi)銷(xiāo)限制：文章指出，非錨幀在接收端仍能以較低的計(jì)算開(kāi)銷(xiāo)進(jìn)行重建，因此，在媒體服務(wù)端，沒(méi)必要對(duì)非錨幀進(jìn)行編碼，而錨幀所占比例較低，這極大降低了編碼的開(kāi)銷(xiāo)。而在解碼端，該方法只引入了18% 的額外計(jì)算開(kāi)銷(xiāo)，這與編碼開(kāi)銷(xiāo)的降低相比，是可以接受的。GPU上下文切換：除了上述設(shè)計(jì)之外，文章還針對(duì)推理框架的切換帶來(lái)的開(kāi)銷(xiāo)，引入了模型預(yù)優(yōu)化與內(nèi)存預(yù)分配，提高了整體的性能表現(xiàn)。＞性能端對(duì)端吞吐量：如下圖所示，NeuroScaler overview相對(duì)于每一幀推斷以及其他選取的對(duì)比，吞吐量提高了10x和2x-5x。 ?資源開(kāi)銷(xiāo):如以下兩幅圖所示，NeuroScaler的資源開(kāi)銷(xiāo)，相較于其他的方案都較為低廉，能夠很好地滿足性能的需求。 ?＞個(gè)人觀點(diǎn) 本文作者主要解決的是當(dāng)前直播視頻流傳輸遇到的主要問(wèn)題。在計(jì)算資源與傳輸資源緊張的情況下，通過(guò)選取合適的計(jì)算方法與編碼思路，可以極大減輕計(jì)算與傳輸負(fù)載。本文便采用恰當(dāng)?shù)腻^幀選取算法，以較小的計(jì)算資源獲得較為優(yōu)異的表現(xiàn)。同時(shí)，本文以接收端的解碼時(shí)間為代價(jià)，犧牲了一部分接收端的解碼速度，極大增強(qiáng)了媒體服務(wù)器的速度，即將整體負(fù)載分散到多個(gè)獨(dú)立的運(yùn)算端上，從而獲得整體性能的提升。

LiveNet: a low-latency video transport network for large-scale live streaming

Jinyang Li, Zhenyu Li (ICT, CAS), Ri Lu, Kai Xiao, Songlin Li, Jufeng Chen, Jingyu Yang, Chunli Zong, Aiyun Chen (Alibaba Group), Qinghua Wu (ICT, CAS), Chen Sun (Alibaba Group), Gareth Tyson (Queen Mary University of London), Hongqiang Harry Liu (Alibaba Group)

本文來(lái)自阿里巴巴和中科院計(jì)算所等機(jī)構(gòu)的研究者，主要報(bào)道了作者在阿里云的直播服務(wù)LiveNet的建設(shè)和運(yùn)營(yíng)方面所做的工作。＞背景與問(wèn)題 隨著新冠肺炎疫情在全球范圍內(nèi)蔓延，直播已經(jīng)成為日常生活的必需品。隨著新的低延遲直播用例的出現(xiàn)(如電子商務(wù)、工作、娛樂(lè)游戲)，用戶數(shù)量顯著增長(zhǎng)。隨著用戶期望的增長(zhǎng)，底層傳輸系統(tǒng)的靈活性和可擴(kuò)展性受到了挑戰(zhàn)。 ? 作為全球主要的CDN提供商之一，阿里巴巴的CDN擁有眾多的直播應(yīng)用(如淘寶的電商直播)。多年來(lái)，這些應(yīng)用程序在很大程度上得到了阿里巴巴第一代分層視頻傳輸網(wǎng)絡(luò)的支持(見(jiàn)下圖)。在該網(wǎng)絡(luò)中，流被傳輸?shù)揭粋€(gè)中央系統(tǒng)進(jìn)行視頻加工，然后分配到邊緣節(jié)點(diǎn)，這些節(jié)點(diǎn)隨后與觀眾連接。通常，這些CDN節(jié)點(diǎn)使用例如應(yīng)用層組播和緩存等，形成一個(gè)(多層)覆蓋樹(shù)，葉子節(jié)點(diǎn)服務(wù)客戶端和內(nèi)部節(jié)點(diǎn)傳播內(nèi)容到葉子。然而，這對(duì)中央處理系統(tǒng)和內(nèi)部節(jié)點(diǎn)造成了巨大的壓力，它們必須根據(jù)流的數(shù)量進(jìn)行伸縮。這對(duì)于有嚴(yán)格延遲約束的直播流來(lái)說(shuō)尤其具有挑戰(zhàn)性，因?yàn)榱餍枰獌纱伪闅v傳遞樹(shù)的深度。事實(shí)上，樹(shù)形結(jié)構(gòu)覆蓋沒(méi)有達(dá)到低延遲直播服務(wù)對(duì)CDN延遲的嚴(yán)格要求。 ?＞設(shè)計(jì) LiveNet——阿里巴巴基于扁平CDN結(jié)構(gòu)的集中協(xié)調(diào)低延遲視頻網(wǎng)絡(luò)。下面介紹了基于作者之前的操作經(jīng)驗(yàn)的三個(gè)主要設(shè)計(jì)選擇： ? 為了擺脫僵化的覆蓋拓?fù)浠蚬?jié)點(diǎn)的預(yù)先分配角色，LiveNet建立在一個(gè)平面CDN上。它的核心是一組靈活的節(jié)點(diǎn)(每個(gè)節(jié)點(diǎn)都是一組機(jī)器)，它們可以服務(wù)于多個(gè)動(dòng)態(tài)分配的角色:生產(chǎn)者(接收和處理廣播者的流)，消費(fèi)者(接收客戶端的請(qǐng)求并對(duì)流進(jìn)行精細(xì)控制)，以及中繼器(將消費(fèi)者和生產(chǎn)者以任意覆蓋的拓?fù)浣Y(jié)構(gòu)連接起來(lái)，提供轉(zhuǎn)發(fā)和緩存等服務(wù))。通過(guò)將各個(gè)節(jié)點(diǎn)與任何特定角色解耦，就可以在每個(gè)應(yīng)用程序的基礎(chǔ)上組成最合適的覆蓋拓?fù)洌⑵骄峙湄?fù)載，避免了之前的中心熱點(diǎn)。 ? 這種靈活性自然伴隨著許多資源分配和管理挑戰(zhàn)，特別是在大規(guī)模操作時(shí)。因此，第二個(gè)設(shè)計(jì)選擇借鑒了軟件定義網(wǎng)絡(luò)(SDN): 作者沒(méi)有在每個(gè)節(jié)點(diǎn)中嵌入控制邏輯，而是設(shè)計(jì)了一個(gè)邏輯集中的CDN控制器(流大腦)，負(fù)責(zé)為節(jié)點(diǎn)指定角色，計(jì)算它們之間的疊加路徑，并為消費(fèi)節(jié)點(diǎn)選擇路徑。通過(guò)在邏輯上集中管理功能，可以輕松地試驗(yàn)新的拓?fù)浜团渲茫岳@過(guò)有問(wèn)題的節(jié)點(diǎn)或?qū)崿F(xiàn)每個(gè)應(yīng)用程序的策略。前兩個(gè)設(shè)計(jì)可以參考下圖。 ? 盡管上述架構(gòu)允許在每一跳（例如，緩存、轉(zhuǎn)碼等）靈活地組合新的覆蓋拓?fù)浜颓度胧椒?wù)，但它也引入了具有挑戰(zhàn)性的開(kāi)銷(xiāo)。這是因?yàn)閿?shù)據(jù)包必須遍歷多個(gè)軟件棧，給直播客戶帶來(lái)了不必要的延遲。為了緩解這種情況，第三種設(shè)計(jì)選擇使用了一種新穎的流轉(zhuǎn)發(fā)機(jī)制，目的是最小化端到端延遲。它基于每個(gè)節(jié)點(diǎn)內(nèi)的兩條并行包處理路徑——一條快路和一條慢路，實(shí)現(xiàn)了不同協(xié)議堆棧層提供的不同功能。在該模型中，每個(gè)節(jié)點(diǎn)在接收到RTP數(shù)據(jù)包后，立即將其轉(zhuǎn)發(fā)到覆蓋層的下一跳，而無(wú)需執(zhí)行傳統(tǒng)的控制功能，如丟失檢測(cè)或擁塞控制(快速路徑)。并行地，數(shù)據(jù)包的一個(gè)副本被復(fù)制到慢路徑上，這引入了擁塞控制和在快速路徑發(fā)生丟失時(shí)的丟失恢復(fù)，并在每個(gè)節(jié)點(diǎn)上實(shí)現(xiàn)GoP (Group of Pictures)緩存。這優(yōu)化了LiveNet的延遲——快速路徑以盡可能快的速度交付數(shù)據(jù)包，而慢路徑提供了可靠的傳輸和內(nèi)容緩存，這對(duì)快速啟動(dòng)和恢復(fù)至關(guān)重要。流程可參考下圖。 ? ?＞性能 ? 3年來(lái)，LiveNet一直是阿里巴巴低延遲流媒體技術(shù)的基礎(chǔ)。與之前的分層CDN相比，LiveNet將平均傳輸路徑長(zhǎng)度(即覆蓋跳數(shù))從4壓縮到2，并將CDN的入口和出口點(diǎn)之間的延遲減少了50%以上。它還顯著提高了用戶可感知的體驗(yàn):95%的視圖的啟動(dòng)延遲小于1秒，98%的視圖沒(méi)有檔位。LiveNet的設(shè)計(jì)選擇和經(jīng)驗(yàn)教訓(xùn)可以廣泛應(yīng)用于其他大型流媒體場(chǎng)景，如視頻會(huì)議和在線教育。＞個(gè)人觀點(diǎn) 這篇文章描述了一個(gè)名為L(zhǎng)iveNet的新型直播傳輸網(wǎng)絡(luò)，它已經(jīng)在阿里巴巴運(yùn)營(yíng)了幾年，旨在實(shí)現(xiàn)低延遲的同時(shí)播放高質(zhì)量的視頻這兩者的平衡。此外，作為一篇經(jīng)驗(yàn)論文，從部署和操作LiveNet中學(xué)到的經(jīng)驗(yàn)教訓(xùn)對(duì)學(xué)術(shù)界很有價(jià)值。論文對(duì)低延遲直播的關(guān)注對(duì)下一代在線媒體服務(wù)具有重要意義，并將激發(fā)社區(qū)在這一重要領(lǐng)域的更多研究。

GSO-simulcast: global stream orchestration in simulcast video conferencing systems

Xianshang Lin, Yunfei Ma, Junshao Zhang, Yao Cui, Jing Li, Shi Bai, Ziyue Zhang, Dennis Cai, Hongqiang Harry Liu, Ming Zhang (Alibaba Group)

本文來(lái)自于阿里巴巴的研究者，主要研究的是大規(guī)模視頻會(huì)議系統(tǒng)下，傳統(tǒng)的方法無(wú)法同時(shí)提供1. 較好的視頻質(zhì)量；2. 改善較慢參與者的表現(xiàn)；3.應(yīng)用于任何可接入會(huì)議的設(shè)備；的問(wèn)題，并嘗試使用聯(lián)播 (Simulcast) 的方式，提供一個(gè)可以任意設(shè)備接入的，具有較好的會(huì)議質(zhì)量，同時(shí)不會(huì)因?yàn)檩^慢參與者而導(dǎo)致整體表現(xiàn)不佳的系統(tǒng)。＞背景與問(wèn)題 這個(gè)時(shí)代，在線視頻會(huì)議已經(jīng)成為了一個(gè)日常生活的重要組成部分，在線會(huì)議，遠(yuǎn)程授課等場(chǎng)景十分常見(jiàn)。而這種大規(guī)模的多方在線會(huì)議，帶來(lái)了兩個(gè)問(wèn)題：1）不同的參與者，網(wǎng)絡(luò)狀態(tài)是不同的。2）參與者間的訂閱關(guān)系是復(fù)雜的。傳統(tǒng)的設(shè)計(jì)主要集中于以下三個(gè)方案：代碼轉(zhuǎn)換：代碼轉(zhuǎn)換(transcoding)可以給下游網(wǎng)絡(luò)路徑提供適配的視頻流，但在大規(guī)模場(chǎng)景中，對(duì)服務(wù)器的性能具有較高的需求，在昂貴的花銷(xiāo)上是不合算的。SVC：SVC可以把一個(gè)流適配到多種比特率上，但SVC的問(wèn)題是它嚴(yán)重依賴于編解碼方案，而部分終端不具備對(duì)于SVC的編解碼能力。聯(lián)播：聯(lián)播 (Simulcast) 可以將視頻流編碼成多種比特率，并且并行發(fā)送。但是，傳統(tǒng)的聯(lián)播方法，沒(méi)有對(duì)于鏈路間和參與者的協(xié)調(diào)，流策略也不夠靈活，導(dǎo)致視頻和網(wǎng)絡(luò)之間的失配，以及大規(guī)模網(wǎng)絡(luò)下的低可管理性。 在傳統(tǒng)的設(shè)計(jì)下，聯(lián)播無(wú)法滿足大規(guī)模多方會(huì)議的需求，那么，就需要全局的信息進(jìn)行參與者的協(xié)調(diào)與流策略的設(shè)置，這就帶來(lái)了以下幾個(gè)挑戰(zhàn)：1）如何實(shí)現(xiàn)實(shí)時(shí)的控制。2）如何對(duì)不同的流進(jìn)行優(yōu)先級(jí)的管理。3）如何獲取全局的信息。4）可以利用現(xiàn)有的架構(gòu)進(jìn)行實(shí)現(xiàn)。＞設(shè)計(jì) 本文認(rèn)為，是全局信息的缺失與流策略的僵硬，導(dǎo)致聯(lián)播方式的較差表現(xiàn)。因此，本文提出了GSO-Simulcast，通過(guò)全局信息進(jìn)行流策略管理。從而滿足以下三個(gè)目標(biāo)，即1）更低的鏈路擁塞。2）更少的視頻和網(wǎng)絡(luò)失配狀況。3）更好的流策略。為此，本文提出了一個(gè)三層的網(wǎng)絡(luò)架構(gòu)，如下圖所示： ?控制算法：本文將問(wèn)題設(shè)置為一個(gè)優(yōu)化問(wèn)題，并以三部分作為限制條件，分別是：1）帶寬的限制。2）編解碼能力的限制。3）訂閱的限制。而這三部分，則是對(duì)應(yīng)背包，合并，規(guī)約三部分算法。控制算法通過(guò)多次迭代計(jì)算，從而快速得到對(duì)應(yīng)的解。獲取全局信息：為了實(shí)現(xiàn)中心化的方案，本文從多個(gè)方面獲取不同的全局信息：1）訂閱信息的收集可以通過(guò)信號(hào)信道進(jìn)行傳播。2）編解碼信息則是在SDP協(xié)商時(shí)發(fā)送的，這包括了一些附加信息，用來(lái)收集分辨率和比特率。3）在發(fā)送端可以直接獲取帶寬信息，而在接受端則利用RTCP進(jìn)行帶寬計(jì)算。反饋控制：當(dāng)控制器找到了新的解決方案，則會(huì)想?yún)⑴c者發(fā)送控制反饋以配置流。配置流的信息是在TMMBR中攜帶的，并以TMMBN作為接受反饋。以這種帶內(nèi)的方法來(lái)提高反饋的及時(shí)性。管理流：1）對(duì)于流的優(yōu)先級(jí)，我們可以給一些流更高的QoE優(yōu)先級(jí)，從而確保該流能被分配盡可能多的帶寬。2）對(duì)于同一個(gè)發(fā)送者的多個(gè)流，我們可以重用控制算法的第一部分，將其作為兩個(gè)獨(dú)立的流，在后續(xù)部分合并，進(jìn)行統(tǒng)一的調(diào)度分配。＞性能 GSO-Simulacst獲得了較好的性能表現(xiàn)。如下圖所示，(a)表示GSO-Simulcast方法具有較好的性能表現(xiàn)，而線性的增長(zhǎng)表示大規(guī)模的參與者場(chǎng)景也具有較好的表現(xiàn)。(b)則表示在不同比特率下， 該方面都有較好的表現(xiàn)。(c)則表示，隨著比特率或者參與者的線性增長(zhǎng)，整體的時(shí)間也是在線性增長(zhǎng)的，也就是體現(xiàn)了較好的可擴(kuò)展性。其中，元組被表示為(#放映者，#參與者，#比特率)。＞個(gè)人觀點(diǎn) 本文主要解決的問(wèn)題是在多方視頻會(huì)議下表現(xiàn)較差的問(wèn)題。為了設(shè)備的兼容性，本文采用了聯(lián)播的方式進(jìn)行設(shè)計(jì)，并通過(guò)多層的網(wǎng)絡(luò)架構(gòu)與集中式的調(diào)度器進(jìn)行流策略的管理。而通過(guò)不改變網(wǎng)絡(luò)本身的架構(gòu)，該系統(tǒng)得到了較好的表現(xiàn)。但是，本文的整體設(shè)計(jì)主要依賴于集中式的控制器，而將其推廣到分布式的設(shè)計(jì)也是一個(gè)可行的思路。