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

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

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

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

＞個人觀點(diǎn)

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

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

• 不足

作者在evaluation時，使用Redis來驗證本文創(chuàng)新的Netchannel所具備的實踐性，不過Redis本身的性能就很高，作者還使用8個線程來做實驗，那性能自然也不會低。這點(diǎn)或許有點(diǎn)取巧。第二，增加了虛擬隊列，實現(xiàn)資源共享后會存在諸多問題，例如鎖的爭用和維護(hù)等帶來的開銷，尤其是在大型數(shù)據(jù)中心里，隊列數(shù)目眾多，那開銷會更大，但是作者并沒有提及該問題和相應(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)

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

NeuroScaler: neural video enhancement at scale

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

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

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

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