NDNlive：命名數據網絡下的視頻直播系統*

王麗婧，MOISEENKO Ilya，何文博，汪東升

1.清華大學 計算機科學與技術系，北京 100084

2.清華大學 清華信息科學與技術國家實驗室，北京 100084

3.加州大學 洛杉磯分校 計算機系，美國 洛杉磯 90095

4.清華大學 電子工程系，北京 100084

NDNlive：命名數據網絡下的視頻直播系統*

王麗婧1,2，MOISEENKO Ilya3，何文博4，汪東升2+

1.清華大學 計算機科學與技術系，北京 100084

2.清華大學 清華信息科學與技術國家實驗室，北京 100084

3.加州大學 洛杉磯分校 計算機系，美國 洛杉磯 90095

4.清華大學 電子工程系，北京 100084

+Corresponding autho author:r:E-mail:wds@tsinghua.edu.cn

WANG Lijing,MOISEENKO Ilya,HEWenbo,et al.NDNlive:live video stream ing system in nam ed data networking.Journalof Frontiersof Com puter Science and Technology,2017,11(7)：1033-1043.

命名數據網絡（named data networking，NDN）通過將IP網絡中以地理位置驅動的信息交互方式轉變成為以數據為中心的信息交互模式，為內容分發應用例如視頻播放提供了更好的支持。通過利用NDN的命名機制與數據獲取模式，設計并實現了基于NDN的視頻直播系統（NDNlive），將實時捕捉的視頻傳輸給多用戶。與傳統的定長切片技術不同，NDNlive將視頻流按照應用數據單元（幀）進行切分與獲取。同時對于音頻、視頻和元數據信息，依照其數據屬性和生成模式采用不同的數據獲取方法。由于幀獲取流水線策略提供的靈活性，NDNlive可以容忍小的網絡問題。NDNlive被部署在NDN全球測試平臺中，實驗結果表明，NDNlive可以在全球跨11個時區提供流暢和同步的視頻直播流。

命名數據網絡；視頻流；消費者/生產者編程接口

1 引言

伴隨著移動應用、信息密集型商務和數字化內容傳播的快速增長，互聯網已經從一個以通信為主要目的網絡進化成一個以內容分發為核心的網絡，例如現在網絡上流動的大部分數據為多媒體、電子商務與社交信息等。命名數據網絡（named data networking，NDN）[1-3]作為一種典型的信息中心網絡（information-centric networking，ICN）架構，使用數據名稱而不是IP地址來傳輸數據，從而使數據本身而不是它的容器（網絡連接）成為網絡層中的核心成員。

視頻直播系統作為目前流行的社交方式已經得到了迅速的推廣與普及。作為一種新型的網絡架構，NDN為此類視頻播放等內容分發應用提供了新的設計思路以及良好的應用前景[4-5]。通過使路由器緩存數據包，NDN減少了網絡流量[6]：如果多個用戶請求相同的視頻文件，路由器可以轉發相同的數據包給它們，而不是要求視頻發布者每次生成新的數據包。然而NDN處于開發初期，仍需要對此類應用程序進行有效的設計、開發與驗證。

NDN應用程序與應用數據單元（application data unit，ADU）協同工作，其中ADU被認為是信息單元最適合的表現形式[7]，例如在視頻數據中，ADU即幀。這些ADU最初由NDN的生產者根據設計好的命名空間以Data包的形式發布。NDN的消費者發送含有應用層數據單元名稱的Interest包來請求ADU，Data包能夠沿著Interest建立的路徑的相反方向返回到數據消費者。一些技術部分采用了ADU設計原則。MPEG-DASH（dynam ic adaptive streaming over HTTP）[8]將多路復用或非多路復用的內容拆分為具有相等持續時間的小文件段序列，這些數據隨后可以通過HTTP從原始媒體服務器或中間緩存服務器對外提供服務。然而，因為與單獨的視頻幀和音頻幀相比文件段的粒度更大，所以用戶仍然會經歷媒體質量波動或中斷。

因此，本文提出了NDNlive，旨在提供一個研究案例來探索如何設計、實現以及測量能夠充分利用ADU概念的NDN網絡環境下的視頻直播系統，以驗證NDN對此類內容分發應用的支持。NDNlive能夠將攝像機捕獲的實時視頻流傳輸到多個播放器。針對音頻、視頻內容和元數據采用不同的數據獲取策略，以匹配不同的數據屬性和數據生成模式。通過應用自適應的幀流水線獲取策略，NDNlive可以容忍小的網絡問題。NDNlive已經在全球范圍的NDN測試平臺中成功部署和測試。這項工作作為整個NDN項目的一個核心應用，與NDN的發源地加州大學洛杉磯分校（University of California，LosAngeles，UCLA）網絡研究實驗室（InternetResearch Lab，IRL）合作開發。

2 消費者/生產者編程接口

NDN通信協議和架構模塊的通用編程接口由消費者/生產者編程接口（Consumer/Producer API）[9]提供。在消費者方面，API將NDN名稱前綴與各種策略（例如數據獲取、傳輸和內容驗證）相關聯，以整合Interest包和Data包的處理。在生產者方面，API將NDN名稱前綴與各種策略（例如分包、緩存、基于內容的安全性和命名空間注冊）相關聯，以集成對數據包的處理。

NDNlive中，分別生成視頻幀和音頻幀的多個數據生成者共同構成了視頻發布方。相應的視頻播放方由多個發送Interest包的數據消費者組成。視頻發布方和播放方的邏輯在Consumer/Producer API的幫助下都得到了簡化。因為視頻的一幀通常非常大以至于無法放進單獨的一個Data包中，所以視頻流的發布方需要完成一個內容分段的步驟，將一整塊視頻數據切分到多個Data包中。Producer API通過提供數據自動分段功能來解決這個問題。相應的，因為單個Interest包不能獲取到完整的視頻幀，Consumer API背后的一些協議可以自動地管理Interest包的并行發送，并解決與應用程序幀內數據獲取相關的其他任務，如Interest包的超時重傳等。

3 設計目標

NDNlive的設計目標如下：

（1）基于任意視頻流位置的播放。由于視頻幀率（fr_rate）固定，播放時間（pb_time）與幀號（fr_num）之間的關系是一定的，參見公式：

（2）視頻音頻的同步播放。直播視頻流被組織成為兩個系列的多媒體幀，分別為音頻和視頻。由于每個幀在被生產出來時已經被裝載了時間戳信息，Gstreamer媒體處理庫可以自動同步它們。

（3）無連接和無會話的數據流。NDN架構自然地支持這一目標。直播播放方不嘗試與視頻發布者建立任何持續性會話或連接。視頻幀可以從轉發器的高速緩存、生產者的高速緩存或者網絡內的永久存儲設備中獲取。

（4）內容驗證和溯源。作為NDN的一個核心特征，每個Data包必須用原始發布者的非對稱密鑰簽名，以便認證發布內容的真實性與可靠性。但是視頻發布方需要輸出如此多的Data包，以致NDN支持庫的安全組件由于其有限的簽名速度成為瓶頸。為了實現所需的簽名吞吐量，所有生產者API都使用FAST_SIGNING選項。

通過使用新的數據包格式、新的轉發器和新的應用程序庫，NDNlive已經實現了上述目標。這項工作是第一次與全新的為NDN量身定制的API進行合作，為NDN應用開發人員提供了更加完整的示例來學習和使用Consumer/ProducerAPI。

4 設計與實現

圖1展示了NDNlive的數據流。發布者將從攝像頭捕獲的視頻傳入Gstreamer進行視頻編碼，并將視頻與音頻分離成為單獨的視頻幀與音頻幀，接著這些幀在生產者API的幫助下被發布到NDN網絡中；視頻消費者使用恰當的數據獲取策略生成用于獲取視頻幀與音頻幀的Interest包，被獲取的數據接著傳入Gstreamer進行解碼和播放。與傳統的基于TCP/IP網絡的視頻播放系統對視頻流采用定長切片技術不同，NDNlive將視頻幀與音頻單獨按照ADU（即視頻幀或音頻幀）進行切分、發布與獲取，并且采用消費者主動發送視頻或音頻的Interest包對Data包進行獲取的pull模型，而非TCP/IP網絡下的push模型。

Fig.1 Data flow of NDNlive圖1 NDNlive數據流

圖2展示了NDNlive的代碼結構，主要包括生產者（Producer）、消費者（Consumer）以及測量監控模塊（Measurement）。下文會分別對其中的命名規則（nam ing conventions）、生產者否定應答（negative ac-know ledgement，NACK）、消費者數據獲取策略（data retrieval）以及幀流水線獲取策略（pipelining strategy）進行具體介紹。

Fig.2 Code structureof NDNlive圖2 NDNlive代碼結構

4.1 命名規則

數據命名是NDN應用程序設計的關鍵一步。一方面，NDN轉發器需要使用名字來進行路由；另一方面，名字中的組件能夠攜帶一些用于應用程序間交互的重要信息。合理的命名空間能夠為高效的應用程序設計帶來很大的貢獻。NDNlive將直播流分離成視頻流與音頻流單獨進行處理，每種流都包含多個幀，其中每個幀可能包含多個段。下面是一個來自NDNlive視頻幀的Interest包或Data包的名稱示例：

/ndn/NDNlive/s-1/video/content/8/\%00\%00

（1）可被路由的名稱前綴：/ndn/NDNlive是NDN轉發器需要參照的將Interest包轉發給相應的數據發布者的命名前綴。

（2）流編號：/s-1是用來區分不同實時數據流的標識符。

（3）視頻或音頻標識位：/video是用來區分視頻幀與音頻幀的標識組件。

（4）內容或者元數據：所有的在/content前綴下的數據都是視頻幀或音頻幀，直播流的元數據信息需要在/info的前綴下。

（5）幀號：/8用來辨識每個單獨的視頻幀或音頻幀的序號信息。

（6）段號：/%00%00段號信息來識別同一個幀中的不同段，因為通常視頻幀都比較大，以致一個Data包無法承載，必須要分段到不同的Data包中。

由于是視頻直播系統，視頻播放者希望獲取最新的視頻內容。因此作為初始化的一個步驟，視頻消費者必須獲取包含當前幀號以及視頻的解碼信息等元數據來建立多媒體播放流水線。這類元數據信息需要視頻發布者實時更新到最新的版本，每一個版本都有一個不同的名字（在名字最后附上當前的時間戳）。下面是一個典型的包含元數據信息的直播流名稱：

/ndn/NDNlive/s-1/video/info/1428725107049

4.2 生產者需要處理的問題

在視頻發布者方面，有兩個內容生產者通過不斷遞增幀號來持續發布視頻幀和音頻幀。兩個流信息/元數據生產者持續發布最新的有關幀號、幀率、視頻尺寸以及編碼格式等元數據信息（或者回復幀號查詢請求）。需要注意的是，有時視頻流生產者無法立刻滿足Interest包的請求，這也是pull網絡模型需要面對的一種比較普遍的問題。針對這一問題，提出了兩種利用否定應答信息進行處理的方案，分別舉例闡述。

例1一個消費者可能誤計算幀請求的發送頻率，例如視頻生成方還沒有生成此幀。生產者可以通過使用Producer API提供的nack()函數并設置好RETRY_AFTER標志，將數據預計可以上線的時間通知給消費者。但在最新版的設計中，此類NACK被移除了。因為經過反復的實驗與測試證明，保持一些未被滿足的Interest包更適合來均衡消費者和生產者之間的認知遲延。在最新版NDNlive中，如果數據流生產者遇到Interest包請求還沒有被生成的幀，它只會簡單地無視這些包，因為這些數據在稍后被生成時可以直接用來滿足這些Interest包。

例2消費者往往在生產者之后加入網絡，并且作為實時視頻流的生產者往往只會存儲有限的最近產生的視頻幀，導致一些消費者可能會請求一些已經在網絡上失效的數據包。在這種情況下，生產者可以通過調用nack()函數并設置NO-DATA標識符，回復給Interest包這個數據已經不再存在。

4.3 消費者的數據獲取策略

對于視頻和音頻、內容和元數據，視頻流消費者/播放器端采取了不同的數據獲取策略。

4.3.1 內容獲取

在視頻直播中，為了能夠匹配視頻的產生速率，消費者需要不間斷地發出獲取視頻幀與音頻幀的請求。同一個幀內的數據段需要盡快地被獲取完整，并且即使當前幀內有數據段丟失，該幀的獲取進程也不應該阻塞后續幀的獲取。

NDNlive音頻內容消費者使用簡單數據獲取（simple data retrieval，SDR）模式發送數據請求。在這種模式下，一次請求只發送一個Interest包，并且不支持超時重傳，是最簡單的數據請求模式。這種屬性剛好符合音頻幀的特性，因為音頻幀數據量很小足夠放在一個Data包內。然而對于視頻內容，消費者需要使用非可靠數據獲取（unreliable data retrieval，UDR）模式進行獲取。UDR并行地發送Interest包，但不負責進行幀內排序。由于一些數據段可能會以亂序抵達，視頻播放方的開發者需要自行處理幀內Data包段重組以及舍棄掉某些不完整的幀。但是經過多次實驗與思考，針對視頻幀的獲取最終采用可靠數據獲取（reliable data retrieval，RDR）模式來取代UDR模式，原因如下：

（1）一個視頻幀通常包含許多段，然而僅僅一個段的遺失就會導致整個幀的無效化。如果不對此數據段進行重新請求，此幀內已經獲取的數據段就被浪費了。同時，關鍵幀（key frame）的丟失會對視頻畫面產生十分嚴重的影響。由于跨地域的數據請求，段遺失情況并不罕見，需要超時重傳的支持。

（2）如果使用UDR，幀內的數據重新排序與重組需要消費者自己來完成，而RDR可以幫助完成此項功能。

這并不意味著UDR沒有用途，只是RDR更加適合此類情況。設計方案中仍然保留了原始的設計描述以提供一個完整的開發曲線，同時希望這項工作能夠給其他NDN應用程序開發者一些靈感。值得注意的是，無論采取哪一種數據獲取策略，在必要的情況下程序都可以自由地丟棄任意幀，因為數據獲取過程是每一幀獨立的。

4.3.2 元數據獲取

直播流的元數據信息需要被生產者實時更新，這意味著每次要有一個新的Data包被生成（新的時間戳將會作為名字的最后一個組件）。然而嘗試加入直播流網絡的消費者并不知道這個獨特的名稱，不能夠使用UDR或者RDR策略，因為這兩類策略沒有假設此類信息。一個簡單的解決方案是使用SDR策略，將Right_Most_Child選項設置為真，該選項保證每次獲取的命名前綴下的元數據信息都是最新的。同時，SDR也被用來獲取幀號和播放時間的映射關系。

4.3.3 幀間流水線獲取策略

正如上文討論的那樣，RDR策略可以幫助處理幀內的數據段。然而消費者需要自行控制幀與幀之間的發送速度，這種關系更加難以處理：如果消費者發送幀間Interest包速度太快，而數據還未被產生，那么播放器就可能崩潰；另一方面，如果消費者發送Interest包太慢，播放可能就會落后于視頻生成速率。NDNlive使用固定幀率，因此對于一個視頻幀率為fr_rate=30（每秒鐘幀數為30）的直播流，幀之間的時間間隔則為33ms，參見公式：

如果下一幀無法在33ms內到達，播放就會被阻塞。然而NDN測試平臺上兩個節點間典型的I-D（Interest-Data）包的交換往返時延（round trip time，RTT）至少為50ms。因此如果采用阻塞式的幀間數據獲取策略（即只有當前幀獲取成功后再獲取下一幀），將無法在指定時間間隔內獲取足夠的視頻幀。

（1）流水線窗口與動態調整算法。為了達到視頻的流暢播放，必須有多個連續幀被同時請求。據此，提出了流水線窗口（pipelinew indow，pip_win），其等于在同一時刻被同時請求的幀的總和，并且該窗口可以依據實時的RTT進行自適應的調整。為了更加清楚地描述幀間流水線獲取策略，圖3展示了一個例子，其中幀間間隔（fr_int）為33ms，幀間往返時延（fr_rtt）為50ms，流水線窗口（pip_win）為2，Tn為：

Fig.3 Frame fetching pipelining strategy圖3 幀流水線獲取策略

初始時，播放器同時發送兩組Interest包，分別請求幀0與幀1，這兩組請求會先于幀生成的時間抵達視頻發布者，這段時間被稱作預熱階段（warm_period），即圖3中的時間段（1）。在此階段之后的T0時間點，幀0的Interest包可以被滿足，由于傳輸延遲的存在，可以得到一定會有的播放時延如下：

其中，fr_rtt代表每幀的平均獲取時間。只要播放器收到幀0的Data包，就會接著發送幀2的Interest包請求，此舉將流水線窗口從{0,1}滑動到了{1,2}。可以觀察得到，設置恰當的流水線窗口能夠使新生成的幀立即被轉發到播放器方，以此保證視頻播放的流暢度。流水線窗口計算公式如下：

通過對流水線窗口的動態調整進行流量控制，此部分偽代碼如算法1所示。首先，將pip_win設置為一個較大的初始值，然后依照當前的fr_rtt以及fr_rate逐漸減小。為了避免頻繁的變動，pip_win只有當幀數量聚集到pip_win/2時才會重新計算，并且每次只能增加或收縮1。此外，對于幀生成速率固定且消費者知情的情況下，可以直接采用fr_rate來計算fr_int，如果該值并不固定，則需要通過實時測量幀吞吐量來取代fr_rate對fr_int進行計算。

算法1流水線窗口動態調整

fr_cnt++

rtts←rtts+fr.fr_rtt

iffr_cnt≥pip_win/2 then//如果幀累積到一定數量

fr_rtt←rtts/fr_cnt

//計算該時間段內的平均fr_rtt

ifnew_win＞pip_winthen

//如果新窗口值大于舊窗口值則加1

pip_win++

else ifnew_win＜pip_winthen

//如果新窗口值小于舊窗口值則減1

pip_win??

end if

fr_cnt←0

rtts←0

end if

end function

（2）超時重傳參數。另外一個需要注意的參數是Interest包的超時重傳（Timeout），同樣也是與網絡實時的RTT相關。如圖3所示，只有在warm_period+fr_int時間之后，幀1的請求才會被滿足。因此在此期間，Interest包不能失效，否則必須重新發出一次幀1的請求，這將會導致播放器延遲加劇。流水線窗口的最后一幀往往會遭遇最久的等待時間，最長可達(pip_win-1)×fr_int。幀的超時重傳（fr_to）應該滿足如下公式：

為了更簡潔一些，設置warm_period≈fr_int，可以得到式（7）：

Fr_to不能夠被設置得太久，因為當網絡不穩定時，太長時間的Timeout會導致更久的重傳等待時間，進而影響整個的數據獲取進程。總結一下，通過自動調整流水線窗口（pip_win）與超時重傳數值（fr_ro）來控制幀間數據請求的速率。這也是NDN或者其他ICN網絡中的另一個關鍵問題。

（3）關鍵（key）幀與增量（delta）幀。同樣都是視頻幀，關鍵幀與增量幀的大小存在巨大差異，關鍵幀包含超過10個段，而增量幀只含有1到2個段。為了能夠適應這種容量差異，幀內數據獲取策略總是會首先發出一條請求來獲取本幀最后一個段的段號。在獲取了這個信息之后，API會同時發出幀內剩下所有段的請求。對于幾乎所有的增量幀，數據獲取能夠在一個I-D交換時間內完成，對于關鍵幀和一小部分的增量幀，數據請求需要花費兩個I-D交換時間。

5 實驗結果

NDNlive開發使用Consumer/ProducerAPI（C++）與Gstreamer1.4.3庫。NDN轉發守護進程（NDN forwarding daemon，NFD）[10]被用來轉發Interest包到適合的生產者以及回復Data包給消費者。支持的平臺為Mac OSX和Linux Ubuntu。更多有關該項目早期的實驗細節與偽代碼可以在此技術報告中獲取[11]，但如第4.2節與第4.3.2小節提及的，本項目開發在此報告之后經過多次版本迭代，例如NACK策略的更改、RDR策略替換UDR策略等；同時后期更新了幀間流水線獲取策略（第4.3.3小節）；底層消費者/生產者API在不斷改進中，其接口與使用方式也在不斷調整，因此NDNlive也需不斷更新代碼以適配最新底層庫；進行了更加完整的遍布全球的測試；推廣NDN-live到更多的應用場景，例如一個基于NDNlive設計與開發的人臉識別系統也正在測試與部署中。

整個命名數據網絡架構還在非常初級的階段，并且還沒有硬件支持，因此NDNlive在性能上無法與TCP/IP網絡進行直接的橫向比較，該項工作更多的是一種功能性測試和開發示例。本章首先介紹實驗環境，接著展示實驗結果。

5.1 實驗設置

與模擬實驗不同，選擇將NDNlive直接部署在世界范圍的NDN測試平臺上，以此提供更加真實的結果，同時驗證設計的正確性和靈活性。在進行實驗的時間段內，該公共測試平臺包含32個節點、87個鏈路，同時在該平臺上還運行著許多其他的真實有效的應用程序。其中13個節點在北美洲，1個節點在南美洲，10個節點在歐洲，8個節點在亞洲，幾乎遍布全球。從跨越0個節點（消費者和生產者在局域網內直連）到跨越6個節點（NDN測試平臺的最長路徑）依次對NDNlive進行了測試，每個測試時長24小時。

數據發布者與播放者分別運行在兩臺Macbook上，均位于加州大學洛杉磯分校校園內，并且同時接入NDN測試平臺中。需要特別強調的是，NDNlive使用該平臺傳輸Interest和Data包，而不是直接將應用程序運行在該平臺上。因此文中提到的跳（hop）通常指視頻發布者與播放者跨越的位于平臺之中的節點個數，真實的跳數應該加1。同樣，計算的路徑花費（cost）也不包括邊界節點到發布者與播放者之間的距離。實際實驗中，使用了其中25個節點，考慮到有5個節點沒有正常工作和2個節點在當時還沒有搭建完成。為了方便對比，視頻發布者總是接入到UCLA節點，只改變視頻播放者的接入點。總體上，在美國境內共計13個節點，最長跳數小于等于4，NDN 路由協議（NDN link state routing protocol，NLSR）[12]花費少于50，節點間NLSR花費由路由協議根據距離自動生成。在其他地域的節點NLSR花費均大于95，其中位于歐洲（7對節點，大于等于4跳）的節點平均花費要略微高于亞洲（5對節點，大于等于3跳）的花費。

5.2 幀RTT測量

Fig.4 Frame RTT across testbed圖4 測試平臺中的幀往返時延

圖4顯示了在整個NDN測試平臺中，視頻與音頻的幀平均往返時延（fr_rtt）。可以看出，視頻的fr_rtt總是比音頻的要長一點，這是合理的，因為很多視頻幀中有多個段而音頻幀中只有一個段。總體的趨勢為幀RTT伴隨著距離（NLSR花費）的增加而增長，并且存在一些波動（RTT突變，共計7處），原因在于：

（1）一些NLSR花費不夠準確。例如通過路徑UCLA-CSU-M ICH-NIST的視頻fr_rtt大概是1 000，該數值遠遠高于路徑UCLA-CSU-M ICH-UM(fr_rtt≈600)，雖然它們的NLSR花費其實是一樣多的，都是44。測量結果顯示，盡管M ICH-NIST段與M ICHUM段NLSR花費相同，都是13，具體的Interest-Data交換時延前者卻高很多。這也解釋了在TONGJI節點處的第一次RTT突變，該NLSR花費為96，其位于中國，相較NLSR花費更高的位于日本的WASEDA節點而言，其網絡狀況更差，因此雖然NLSR花費更低，但RTT卻比周圍節點都高出很多。

（2）總是存在一些繁忙節點。盡管希望能在全平臺空閑時（例如凌晨）運行測試程序，但這幾乎是不可能的，因為美國與其他大陸存在時差（最長可達11小時）；此外，由于測試平臺是公共的，無法控制其他應用程序的行為，例如在KISTI（跨越3跳，NLSR花費100）節點中，總是有一個應用程序在運行并占用大量計算資源，導致其RTT相較圖中周圍NLSR花費相近的節點明顯增大（突變）。

（3）連接在跨洋時會變得十分不穩定。因此實驗最終去除了5個節點：BUPT，位于亞洲；SYSTEMX、ORANGE、BASEL、URJC位于歐洲，這些節點總會經歷相當長的延時與更加顯著的性能波動。作為結果，即使是在十分低畫質的情況下，它們的丟包率（大于50%，其他節點小于25%）太高而無法實現流暢的傳輸。剩下的5次RTT突變就發生在該5個節點處。

5.3 流水線窗口與幀超時重傳

在具體實現中，流水線窗口通常被設置為一個很大的數值，然后慢慢依據實時的fr_rtt不斷縮小直至穩定在一個固定數值左右。圖5顯示了視頻以及音頻的流水線窗口穩定值。

Fig.5 Pipelinew indow across testbed圖5 測試平臺中的流水線窗口

可以看出流水線窗口（pip_win）隨著NLSR花費的變化而改變，其趨勢與幀往返時延（fr_rtt）相似，即圖4。圖5中已經剔除了上文提到的5個跨洋節點。據觀察所得，自適應的幀流水線獲取策略的確能夠帶來至多跨11個時區直播的流暢播放。在多次實驗后，總結發現對于流水線窗口最好比計算值，即式（5），大1。因為更大的窗口能夠忍受輕微的幀往返時延抖動，例如當網絡不穩定時。這點對于幀超時重傳（fr_to）也是一樣的，在實際中fr_to通常被設置成為兩倍的fr_rtt，fr_to并不像pip_win一樣敏感。

5.4 幀間流水線獲取策略驗證

為了驗證自適應幀流水線獲取策略的彈性，記錄了當有臨時的網絡擁塞發生時，流水線窗口的變化曲線，如圖6所示。本實驗在使用兩臺Macbook同時接入UCLA節點，即跨越1跳的情況下完成。為了簡潔性，圖中只顯示了視頻的情況，沒有音頻。

Fig.6 Pipelinew indow and frame RTT of video across onehopwhen network congestion occurs圖6 網絡擁塞發生時的視頻流水線窗口與幀往返時延

從圖6中可以看出，流水線窗口被初始化為10，接著參照幀往返時延逐漸降低，然后維持在6一段時間。為了避免頻繁的變動，pip_win只有當幀數量聚集到pip_win/2時才會重新計算，并且每次只能增加或收縮1。例如，初始時，窗口大小為10，則只有當過去了10/2×33.3≈167ms時，它才會從10下降到9，因此下降速度是與pip_win的大小成正比的。在第2秒時，網絡擁塞發生（有另一個應用程序不間斷地向UCLA節點發送Interest請求）。可以看到fr_rtt立刻增加，pip_win也隨之慢慢增加，然后維持在9，停留了1 s。在網絡恢復正常后（第3秒），fr_rtt逐漸下降回6。在測試過程中，除了無法避免的初始化播放延遲，以及由于被延長的Interest-Data交換延遲，視頻流只在網絡擁塞發生之初出現了卡頓（少于100ms），其余過程中視頻流均能維持流暢和同步播放。

6 相關工作

加州大學洛杉磯分校REMAP（Center for Research in Engineering,Media and Performance）實驗小組曾經在搭建NDNVideo[13]系統上做出很多的努力，這也是第一個在NDN上證實視頻播放軟件可行的應用。之后數據包格式以及新的轉發器的研發導致了這個視頻流已經不再可用。NDNlive是清華大學以及加州大學洛杉磯分校IRL實驗室共同研發的具有相似功能的，但能夠與現在新的數據包格式、轉發器以及應用支撐庫適配的新的視頻直播系統。同時，此項工作對于NDN應用開發者也提供了更加完整的參考示例。

NDNlive和NDNVideo的主要區別在于視頻內容和音頻內容的組織方式上。在NDNVideo中，視頻和音頻流被切分成定長的段，因此需要在真實的播放時間與段號之間建立映射關系來保證視頻和音頻的同步，同時以此來支持查找功能。定長切分破壞了幀之間界限，這種內部相關性會導致和TCP/IP中同樣的問題，例如線頭阻塞問題（head-of-line，HOL）。與此相反，在NDNlive中，兩組直播流都被按照幀進行組織，幀內可能包含多個段。由于幀內分段對于應用程序而言是透明的，NDNlive開發可以集中關注在幀這一層面。因為每個幀都有一個獨特的名字，并且是和其他幀獨立的，所以單獨某一幀的丟失不會影響到其他幀的獲取，對于視頻流尤其是實時視頻流帶來了很大的靈活性。

NDN-RTC[14-15]是一個實時會議庫，用來提供類似Skype視頻通話的功能。與NDNlive類似，NDN-RTC也將視頻和音頻按幀分割，但是NDNlive在設計上更加簡潔。

（1）關鍵幀和增量幀在NDN-RTC中采用的是不同的命名空間，然而NDNlive在命名空間上不區分這兩種幀。首先，消費者/生產者API可以幫助獲取一個幀內的多段數據，并且任意幀（無論該幀可能多大）的獲取都可以控制在兩輪幀往返延遲之內，如此限制了兩種幀之間的區別。其次，自適應流水線窗口策略能夠容忍不同幀獲取時間的差異，因為幀往返時延總是在累積到一定幀數后才會被重新計算（流水線窗口的一半）。

（2）NDNlive使用消費者/生產者API來處理生產者的數據幀分段，與消費者的幀內數據段重傳和重組。NDN-RTC則完全由應用程序來處理這些工作，邏輯更為復雜。這也是消費者/生產者API能夠帶來的一個顯著優勢。

表1描述了3個項目其他的主要不同點，例如依賴庫、媒體處理工具以及編程語言等。除此之外，NDNlive還具備更加完整的跨越整個世界范圍的NDN測試平臺的實驗與測試。

7 結論與展望

本文提出了NDNlive，一個基于命名數據網絡的視頻直播系統。NDNlive將視頻與音頻流組織成為連續的幀，使視頻播放方可以更加靈活地處理獲取的數據。NDNlive針對音頻、視頻內容以及元數據采用不同的數據獲取策略以適應不同的數據屬性與數據生成模式。同時通過應用自適應的幀流水線獲取策略，NDNlive能夠忍受輕微的網絡問題。實驗結果顯示，NDNlive確實是一個靈活有效的、能夠運行在全球范圍的NDN測試平臺上的直播系統，驗證了命名數據網絡對此類應用的支持。本文針對NDN以及其他內容中心網絡中存在的問題，給出了一些通用的解決方案，例如NACK。該項工作還可以被當作命名數據網絡中一個較為完整的設計、實驗與測量應用程序的示例。

Table1 Comparisonw ith NDNVideo and NDN-RTC表1 與NDNVideo和NDN-RTC的比較

[1]Jacobson V,Smetters D K,Thornton JD,etal.Networking named content[C]//Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies,Rome,Italy,Dec 1-4,2009.New York:ACM,2009:1-12.

[2]Zhang Lixia,Estrin D,Burke J,etal.Named data networking(NDN)project[J].Transportation Research Record Journal of the Transportation Research Board,2014,1892(1):227-234.

[3]Zhang Lixia,A fanasyev A,Burke J,et al.Named data networking[J].ACM SIGCOMM Computer Communication Review,2014,44(3):66-73.

[4]Burke J,Gasti P,Nathan N,etal.Secure sensing over named data networking[C]//Proceedings of the 13th International Symposium on Network Computing and Applications,Cambridge,USA,Aug 21-23,2014.Washington:IEEEComputer Society,2014:175-180.

[5]Fan Chenyu,ShannigrahiS,Dibenedetto S,etal.Managing scientific data w ith named data networking[C]//Proceedings of the 5th InternationalWorkshop on Network-Aware Data Management,Austin,USA,Nov 15,2015.New York:ACM,2015:1.

[6]YiCheng,Afanasyev A,Wang Lan,etal.Adaptive forwarding in Named Data Networking[J].ACM SIGCOMM Computer Communication Review,2012,42(3):62-67.

[7]ClarkD D,Tennenhouse D L.Architectural considerations for a new generation of protocols[J].ACM SIGCOMM Computer Communication Review,1984,20(4):200-208.

[8]Stockhammer T.Dynam ic adaptive stream ing over HTTP--:standards and design principles[C]//Proceedings of the 2nd Annual ACM Conference on Multimedia Systems,Santa Clara,USA,Feb 23-25,2011.New York:ACM,2011:133-144.

[9]Moiseenko I,Wang Lijing,Zhang Lixia.Consumer/producer communication w ith application level framing in named data networking[C]//Proceedings of the 2nd International Conference on Information-Centric Networking,San Francisco,USA,Sep 30-Oct2,2015.New York:ACM,2015:99-108.

[10]Afanasyev A,Shi Junxia,Zhang Beichuan,et al.NFD developer'sguide,NDN-002[R].2014.

[11]Wang Lijing,Moiseenko I,Zhang Lixia.NDNlive and NDN-tube:live and prerecorded video streaming over NDN,NDN-0031[R].2015.

[12]Hoque A K M M,Amin SO,Alyyan A,etal.NLSR:nameddata link state routing protocol[C]//Proceedings of the 3rd ACM SIGCOMM Workshop on Information-Centric Networking,Hong Kong,China,Aug 12,2013,New York:ACM,2013:15-20.

[13]Kulinski D,Burke J.NDNVideo:random-access live and pre-recorded stream ing using NDN,NDN-0007[R].2012.

[14]Gusev P,Burke J.NDN-RTC:real-time videoconferencing over named data networking[C]//Proceedingsof the 2nd International Conference on Information-Centric Networking,San Francisco,USA,Sep 30-Oct2,2015.New York:ACM,2015:117-126.

[15]Gusev P,Wang Zhehao,Burke J,etal.Real-time streaming data delivery over named data networking[J].IEICE Transactionson Communications,2016,99(5):974-991.

WANG Lijing was born in 1988.She is a Ph.D.candidate atDepartmentof Computer Science and Technology,Tsinghua University.Her research interests include distributed system and named datanetworking.

王麗婧（1988—），女，山東威海人，清華大學計算機科學與技術系博士研究生，主要研究領域為分布式系統，命名數據網絡。

MOISEENKO Ilyawas born in 1988.He received the Ph.D.degree from University of California,Los Angeles in 2015.Now he isa research softwareengineeratCisco.His research interest isnetwork architecture.

MOISEENKO Ilya（1988—），男，俄羅斯人，2015年于美國加州大學洛杉磯分校獲得博士學位，現為思科公司研發工程師，主要研究領域為網絡架構。

HEWenbo was born in 1996.He is a studentat Departmentof Electronic Engineering,Tsinghua University.His research interests includemachine learning and distributed computing.

何文博（1996—），男，河北保定人，清華大學電子工程系學生，主要研究領域為機器學習，分布式計算。

WANG Dongsheng was born in 1966.He received the Ph.D.degree from Harbin Institute of Technology in 1995.Now he is a professor at Department of Computer Science and Technology,Tsinghua University,and the senior memberof CCF.His research interests include computerarchitecture and high performance computing.

汪東升（1966—），男，黑龍江哈爾濱人，1995年于哈爾濱工業大學獲得博士學位，現為清華大學計算機科學與技術系教授，CCF高級會員，主要研究領域為計算機體系結構，高性能計算。

NDNlive:Live Video Stream ing System in Named Data Networking*

WANG Lijing1,2,MOISEENKO Ilya3,HEWenbo4,WANGDongsheng2+
1.Departmentof Computer Scienceand Technology,Tsinghua University,Beijing 100084,China
2.Tsinghua National Laboratory for Information Scienceand Technology,Tsinghua University,Beijing 100084,China
3.Computer Science Department,University of California,LosAngeles90095,USA
4.Departmentof Electronic Engineering,Tsinghua University,Beijing 100084,China

By adopting a data-centric information exchange pattern instead of the IPnetworks'location-driven pattern,named data networking(NDN)offers better support for contentdistribution applications such as video streaming application.This paper proposes NDNlive,exploiting NDN features such as nam ing conventions and data retrieval pattern to stream live video tomultiple players.Instead of fixed-size segmentation,NDNlive chops video stream into frameswhich are the application data units(ADU).For the audio,video content and themediametadata,NDNlive uses differentdata retrieval strategies according to their data properties and differentdata generation patterns.NDN-live can tolerate small network problems thanks to the flexibility provided by the frame fetch pipelining strategy.It has been deployed over theworld-w ide NDN Testbed.The experiments show that NDNlive can provide fluentandsynchronized video stream ing across11 time zones in theworldw ide.

named datanetworking;video stream ing;Consumer/ProducerAPI

on

Frame(Framefr)

A

：TP302.1

*The National Natural Science Foundation of China under GrantNo.61373025(國家自然科學基金);the National Key Research and DevelopmentPlan of ChinaunderGrantNo.2016YFB1000303(國家重點研發計劃).

Received 2017-03,Accepted 2017-05.

CNKI網絡優先出版:2017-05-22,http://kns.cnki.net/kcms/detail/11.5602.TP.20170522.1058.004.htm l