王麗婧,MOISEENKO Ilya,何文博,汪東升
1.清華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系,北京 100084
2.清華大學(xué) 清華信息科學(xué)與技術(shù)國(guó)家實(shí)驗(yàn)室,北京 100084
3.加州大學(xué) 洛杉磯分校 計(jì)算機(jī)系,美國(guó) 洛杉磯 90095
4.清華大學(xué) 電子工程系,北京 100084
NDNlive:命名數(shù)據(jù)網(wǎng)絡(luò)下的視頻直播系統(tǒng)*
王麗婧1,2,MOISEENKO Ilya3,何文博4,汪東升2+
1.清華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系,北京 100084
2.清華大學(xué) 清華信息科學(xué)與技術(shù)國(guó)家實(shí)驗(yàn)室,北京 100084
3.加州大學(xué) 洛杉磯分校 計(jì)算機(jī)系,美國(guó) 洛杉磯 90095
4.清華大學(xué) 電子工程系,北京 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.
命名數(shù)據(jù)網(wǎng)絡(luò)(named data networking,NDN)通過(guò)將IP網(wǎng)絡(luò)中以地理位置驅(qū)動(dòng)的信息交互方式轉(zhuǎn)變成為以數(shù)據(jù)為中心的信息交互模式,為內(nèi)容分發(fā)應(yīng)用例如視頻播放提供了更好的支持。通過(guò)利用NDN的命名機(jī)制與數(shù)據(jù)獲取模式,設(shè)計(jì)并實(shí)現(xiàn)了基于NDN的視頻直播系統(tǒng)(NDNlive),將實(shí)時(shí)捕捉的視頻傳輸給多用戶。與傳統(tǒng)的定長(zhǎng)切片技術(shù)不同,NDNlive將視頻流按照應(yīng)用數(shù)據(jù)單元(幀)進(jìn)行切分與獲取。同時(shí)對(duì)于音頻、視頻和元數(shù)據(jù)信息,依照其數(shù)據(jù)屬性和生成模式采用不同的數(shù)據(jù)獲取方法。由于幀獲取流水線策略提供的靈活性,NDNlive可以容忍小的網(wǎng)絡(luò)問(wèn)題。NDNlive被部署在NDN全球測(cè)試平臺(tái)中,實(shí)驗(yàn)結(jié)果表明,NDNlive可以在全球跨11個(gè)時(shí)區(qū)提供流暢和同步的視頻直播流。
命名數(shù)據(jù)網(wǎng)絡(luò);視頻流;消費(fèi)者/生產(chǎn)者編程接口
伴隨著移動(dòng)應(yīng)用、信息密集型商務(wù)和數(shù)字化內(nèi)容傳播的快速增長(zhǎng),互聯(lián)網(wǎng)已經(jīng)從一個(gè)以通信為主要目的網(wǎng)絡(luò)進(jìn)化成一個(gè)以內(nèi)容分發(fā)為核心的網(wǎng)絡(luò),例如現(xiàn)在網(wǎng)絡(luò)上流動(dòng)的大部分?jǐn)?shù)據(jù)為多媒體、電子商務(wù)與社交信息等。命名數(shù)據(jù)網(wǎng)絡(luò)(named data networking,NDN)[1-3]作為一種典型的信息中心網(wǎng)絡(luò)(information-centric networking,ICN)架構(gòu),使用數(shù)據(jù)名稱而不是IP地址來(lái)傳輸數(shù)據(jù),從而使數(shù)據(jù)本身而不是它的容器(網(wǎng)絡(luò)連接)成為網(wǎng)絡(luò)層中的核心成員。
視頻直播系統(tǒng)作為目前流行的社交方式已經(jīng)得到了迅速的推廣與普及。作為一種新型的網(wǎng)絡(luò)架構(gòu),NDN為此類視頻播放等內(nèi)容分發(fā)應(yīng)用提供了新的設(shè)計(jì)思路以及良好的應(yīng)用前景[4-5]。通過(guò)使路由器緩存數(shù)據(jù)包,NDN減少了網(wǎng)絡(luò)流量[6]:如果多個(gè)用戶請(qǐng)求相同的視頻文件,路由器可以轉(zhuǎn)發(fā)相同的數(shù)據(jù)包給它們,而不是要求視頻發(fā)布者每次生成新的數(shù)據(jù)包。然而NDN處于開發(fā)初期,仍需要對(duì)此類應(yīng)用程序進(jìn)行有效的設(shè)計(jì)、開發(fā)與驗(yàn)證。
NDN應(yīng)用程序與應(yīng)用數(shù)據(jù)單元(application data unit,ADU)協(xié)同工作,其中ADU被認(rèn)為是信息單元最適合的表現(xiàn)形式[7],例如在視頻數(shù)據(jù)中,ADU即幀。這些ADU最初由NDN的生產(chǎn)者根據(jù)設(shè)計(jì)好的命名空間以Data包的形式發(fā)布。NDN的消費(fèi)者發(fā)送含有應(yīng)用層數(shù)據(jù)單元名稱的Interest包來(lái)請(qǐng)求ADU,Data包能夠沿著Interest建立的路徑的相反方向返回到數(shù)據(jù)消費(fèi)者。一些技術(shù)部分采用了ADU設(shè)計(jì)原則。MPEG-DASH(dynam ic adaptive streaming over HTTP)[8]將多路復(fù)用或非多路復(fù)用的內(nèi)容拆分為具有相等持續(xù)時(shí)間的小文件段序列,這些數(shù)據(jù)隨后可以通過(guò)HTTP從原始媒體服務(wù)器或中間緩存服務(wù)器對(duì)外提供服務(wù)。然而,因?yàn)榕c單獨(dú)的視頻幀和音頻幀相比文件段的粒度更大,所以用戶仍然會(huì)經(jīng)歷媒體質(zhì)量波動(dòng)或中斷。
因此,本文提出了NDNlive,旨在提供一個(gè)研究案例來(lái)探索如何設(shè)計(jì)、實(shí)現(xiàn)以及測(cè)量能夠充分利用ADU概念的NDN網(wǎng)絡(luò)環(huán)境下的視頻直播系統(tǒng),以驗(yàn)證NDN對(duì)此類內(nèi)容分發(fā)應(yīng)用的支持。NDNlive能夠?qū)z像機(jī)捕獲的實(shí)時(shí)視頻流傳輸?shù)蕉鄠€(gè)播放器。針對(duì)音頻、視頻內(nèi)容和元數(shù)據(jù)采用不同的數(shù)據(jù)獲取策略,以匹配不同的數(shù)據(jù)屬性和數(shù)據(jù)生成模式。通過(guò)應(yīng)用自適應(yīng)的幀流水線獲取策略,NDNlive可以容忍小的網(wǎng)絡(luò)問(wèn)題。NDNlive已經(jīng)在全球范圍的NDN測(cè)試平臺(tái)中成功部署和測(cè)試。這項(xiàng)工作作為整個(gè)NDN項(xiàng)目的一個(gè)核心應(yīng)用,與NDN的發(fā)源地加州大學(xué)洛杉磯分校(University of California,LosAngeles,UCLA)網(wǎng)絡(luò)研究實(shí)驗(yàn)室(InternetResearch Lab,IRL)合作開發(fā)。
NDN通信協(xié)議和架構(gòu)模塊的通用編程接口由消費(fèi)者/生產(chǎn)者編程接口(Consumer/Producer API)[9]提供。在消費(fèi)者方面,API將NDN名稱前綴與各種策略(例如數(shù)據(jù)獲取、傳輸和內(nèi)容驗(yàn)證)相關(guān)聯(lián),以整合Interest包和Data包的處理。在生產(chǎn)者方面,API將NDN名稱前綴與各種策略(例如分包、緩存、基于內(nèi)容的安全性和命名空間注冊(cè))相關(guān)聯(lián),以集成對(duì)數(shù)據(jù)包的處理。
NDNlive中,分別生成視頻幀和音頻幀的多個(gè)數(shù)據(jù)生成者共同構(gòu)成了視頻發(fā)布方。相應(yīng)的視頻播放方由多個(gè)發(fā)送Interest包的數(shù)據(jù)消費(fèi)者組成。視頻發(fā)布方和播放方的邏輯在Consumer/Producer API的幫助下都得到了簡(jiǎn)化。因?yàn)橐曨l的一幀通常非常大以至于無(wú)法放進(jìn)單獨(dú)的一個(gè)Data包中,所以視頻流的發(fā)布方需要完成一個(gè)內(nèi)容分段的步驟,將一整塊視頻數(shù)據(jù)切分到多個(gè)Data包中。Producer API通過(guò)提供數(shù)據(jù)自動(dòng)分段功能來(lái)解決這個(gè)問(wèn)題。相應(yīng)的,因?yàn)閱蝹€(gè)Interest包不能獲取到完整的視頻幀,Consumer API背后的一些協(xié)議可以自動(dòng)地管理Interest包的并行發(fā)送,并解決與應(yīng)用程序幀內(nèi)數(shù)據(jù)獲取相關(guān)的其他任務(wù),如Interest包的超時(shí)重傳等。
NDNlive的設(shè)計(jì)目標(biāo)如下:
(1)基于任意視頻流位置的播放。由于視頻幀率(fr_rate)固定,播放時(shí)間(pb_time)與幀號(hào)(fr_num)之間的關(guān)系是一定的,參見公式:
(2)視頻音頻的同步播放。直播視頻流被組織成為兩個(gè)系列的多媒體幀,分別為音頻和視頻。由于每個(gè)幀在被生產(chǎn)出來(lái)時(shí)已經(jīng)被裝載了時(shí)間戳信息,Gstreamer媒體處理庫(kù)可以自動(dòng)同步它們。
(3)無(wú)連接和無(wú)會(huì)話的數(shù)據(jù)流。NDN架構(gòu)自然地支持這一目標(biāo)。直播播放方不嘗試與視頻發(fā)布者建立任何持續(xù)性會(huì)話或連接。視頻幀可以從轉(zhuǎn)發(fā)器的高速緩存、生產(chǎn)者的高速緩存或者網(wǎng)絡(luò)內(nèi)的永久存儲(chǔ)設(shè)備中獲取。
(4)內(nèi)容驗(yàn)證和溯源。作為NDN的一個(gè)核心特征,每個(gè)Data包必須用原始發(fā)布者的非對(duì)稱密鑰簽名,以便認(rèn)證發(fā)布內(nèi)容的真實(shí)性與可靠性。但是視頻發(fā)布方需要輸出如此多的Data包,以致NDN支持庫(kù)的安全組件由于其有限的簽名速度成為瓶頸。為了實(shí)現(xiàn)所需的簽名吞吐量,所有生產(chǎn)者API都使用FAST_SIGNING選項(xiàng)。
通過(guò)使用新的數(shù)據(jù)包格式、新的轉(zhuǎn)發(fā)器和新的應(yīng)用程序庫(kù),NDNlive已經(jīng)實(shí)現(xiàn)了上述目標(biāo)。這項(xiàng)工作是第一次與全新的為NDN量身定制的API進(jìn)行合作,為NDN應(yīng)用開發(fā)人員提供了更加完整的示例來(lái)學(xué)習(xí)和使用Consumer/ProducerAPI。
圖1展示了NDNlive的數(shù)據(jù)流。發(fā)布者將從攝像頭捕獲的視頻傳入Gstreamer進(jìn)行視頻編碼,并將視頻與音頻分離成為單獨(dú)的視頻幀與音頻幀,接著這些幀在生產(chǎn)者API的幫助下被發(fā)布到NDN網(wǎng)絡(luò)中;視頻消費(fèi)者使用恰當(dāng)?shù)臄?shù)據(jù)獲取策略生成用于獲取視頻幀與音頻幀的Interest包,被獲取的數(shù)據(jù)接著傳入Gstreamer進(jìn)行解碼和播放。與傳統(tǒng)的基于TCP/IP網(wǎng)絡(luò)的視頻播放系統(tǒng)對(duì)視頻流采用定長(zhǎng)切片技術(shù)不同,NDNlive將視頻幀與音頻單獨(dú)按照ADU(即視頻幀或音頻幀)進(jìn)行切分、發(fā)布與獲取,并且采用消費(fèi)者主動(dòng)發(fā)送視頻或音頻的Interest包對(duì)Data包進(jìn)行獲取的pull模型,而非TCP/IP網(wǎng)絡(luò)下的push模型。
Fig.1 Data flow of NDNlive圖1 NDNlive數(shù)據(jù)流
圖2展示了NDNlive的代碼結(jié)構(gòu),主要包括生產(chǎn)者(Producer)、消費(fèi)者(Consumer)以及測(cè)量監(jiān)控模塊(Measurement)。下文會(huì)分別對(duì)其中的命名規(guī)則(nam ing conventions)、生產(chǎn)者否定應(yīng)答(negative ac-know ledgement,NACK)、消費(fèi)者數(shù)據(jù)獲取策略(data retrieval)以及幀流水線獲取策略(pipelining strategy)進(jìn)行具體介紹。
Fig.2 Code structureof NDNlive圖2 NDNlive代碼結(jié)構(gòu)
4.1 命名規(guī)則
數(shù)據(jù)命名是NDN應(yīng)用程序設(shè)計(jì)的關(guān)鍵一步。一方面,NDN轉(zhuǎn)發(fā)器需要使用名字來(lái)進(jìn)行路由;另一方面,名字中的組件能夠攜帶一些用于應(yīng)用程序間交互的重要信息。合理的命名空間能夠?yàn)楦咝У膽?yīng)用程序設(shè)計(jì)帶來(lái)很大的貢獻(xiàn)。NDNlive將直播流分離成視頻流與音頻流單獨(dú)進(jìn)行處理,每種流都包含多個(gè)幀,其中每個(gè)幀可能包含多個(gè)段。下面是一個(gè)來(lái)自NDNlive視頻幀的Interest包或Data包的名稱示例:
/ndn/NDNlive/s-1/video/content/8/\%00\%00
(1)可被路由的名稱前綴:/ndn/NDNlive是NDN轉(zhuǎn)發(fā)器需要參照的將Interest包轉(zhuǎn)發(fā)給相應(yīng)的數(shù)據(jù)發(fā)布者的命名前綴。
(2)流編號(hào):/s-1是用來(lái)區(qū)分不同實(shí)時(shí)數(shù)據(jù)流的標(biāo)識(shí)符。
(3)視頻或音頻標(biāo)識(shí)位:/video是用來(lái)區(qū)分視頻幀與音頻幀的標(biāo)識(shí)組件。
(4)內(nèi)容或者元數(shù)據(jù):所有的在/content前綴下的數(shù)據(jù)都是視頻幀或音頻幀,直播流的元數(shù)據(jù)信息需要在/info的前綴下。
(5)幀號(hào):/8用來(lái)辨識(shí)每個(gè)單獨(dú)的視頻幀或音頻幀的序號(hào)信息。
(6)段號(hào):/%00%00段號(hào)信息來(lái)識(shí)別同一個(gè)幀中的不同段,因?yàn)橥ǔR曨l幀都比較大,以致一個(gè)Data包無(wú)法承載,必須要分段到不同的Data包中。
由于是視頻直播系統(tǒng),視頻播放者希望獲取最新的視頻內(nèi)容。因此作為初始化的一個(gè)步驟,視頻消費(fèi)者必須獲取包含當(dāng)前幀號(hào)以及視頻的解碼信息等元數(shù)據(jù)來(lái)建立多媒體播放流水線。這類元數(shù)據(jù)信息需要視頻發(fā)布者實(shí)時(shí)更新到最新的版本,每一個(gè)版本都有一個(gè)不同的名字(在名字最后附上當(dāng)前的時(shí)間戳)。下面是一個(gè)典型的包含元數(shù)據(jù)信息的直播流名稱:
/ndn/NDNlive/s-1/video/info/1428725107049
4.2 生產(chǎn)者需要處理的問(wèn)題
在視頻發(fā)布者方面,有兩個(gè)內(nèi)容生產(chǎn)者通過(guò)不斷遞增幀號(hào)來(lái)持續(xù)發(fā)布視頻幀和音頻幀。兩個(gè)流信息/元數(shù)據(jù)生產(chǎn)者持續(xù)發(fā)布最新的有關(guān)幀號(hào)、幀率、視頻尺寸以及編碼格式等元數(shù)據(jù)信息(或者回復(fù)幀號(hào)查詢請(qǐng)求)。需要注意的是,有時(shí)視頻流生產(chǎn)者無(wú)法立刻滿足Interest包的請(qǐng)求,這也是pull網(wǎng)絡(luò)模型需要面對(duì)的一種比較普遍的問(wèn)題。針對(duì)這一問(wèn)題,提出了兩種利用否定應(yīng)答信息進(jìn)行處理的方案,分別舉例闡述。
例1一個(gè)消費(fèi)者可能誤計(jì)算幀請(qǐng)求的發(fā)送頻率,例如視頻生成方還沒有生成此幀。生產(chǎn)者可以通過(guò)使用Producer API提供的nack()函數(shù)并設(shè)置好RETRY_AFTER標(biāo)志,將數(shù)據(jù)預(yù)計(jì)可以上線的時(shí)間通知給消費(fèi)者。但在最新版的設(shè)計(jì)中,此類NACK被移除了。因?yàn)榻?jīng)過(guò)反復(fù)的實(shí)驗(yàn)與測(cè)試證明,保持一些未被滿足的Interest包更適合來(lái)均衡消費(fèi)者和生產(chǎn)者之間的認(rèn)知遲延。在最新版NDNlive中,如果數(shù)據(jù)流生產(chǎn)者遇到Interest包請(qǐng)求還沒有被生成的幀,它只會(huì)簡(jiǎn)單地?zé)o視這些包,因?yàn)檫@些數(shù)據(jù)在稍后被生成時(shí)可以直接用來(lái)滿足這些Interest包。
例2消費(fèi)者往往在生產(chǎn)者之后加入網(wǎng)絡(luò),并且作為實(shí)時(shí)視頻流的生產(chǎn)者往往只會(huì)存儲(chǔ)有限的最近產(chǎn)生的視頻幀,導(dǎo)致一些消費(fèi)者可能會(huì)請(qǐng)求一些已經(jīng)在網(wǎng)絡(luò)上失效的數(shù)據(jù)包。在這種情況下,生產(chǎn)者可以通過(guò)調(diào)用nack()函數(shù)并設(shè)置NO-DATA標(biāo)識(shí)符,回復(fù)給Interest包這個(gè)數(shù)據(jù)已經(jīng)不再存在。
4.3 消費(fèi)者的數(shù)據(jù)獲取策略
對(duì)于視頻和音頻、內(nèi)容和元數(shù)據(jù),視頻流消費(fèi)者/播放器端采取了不同的數(shù)據(jù)獲取策略。
4.3.1 內(nèi)容獲取
在視頻直播中,為了能夠匹配視頻的產(chǎn)生速率,消費(fèi)者需要不間斷地發(fā)出獲取視頻幀與音頻幀的請(qǐng)求。同一個(gè)幀內(nèi)的數(shù)據(jù)段需要盡快地被獲取完整,并且即使當(dāng)前幀內(nèi)有數(shù)據(jù)段丟失,該幀的獲取進(jìn)程也不應(yīng)該阻塞后續(xù)幀的獲取。
NDNlive音頻內(nèi)容消費(fèi)者使用簡(jiǎn)單數(shù)據(jù)獲?。╯imple data retrieval,SDR)模式發(fā)送數(shù)據(jù)請(qǐng)求。在這種模式下,一次請(qǐng)求只發(fā)送一個(gè)Interest包,并且不支持超時(shí)重傳,是最簡(jiǎn)單的數(shù)據(jù)請(qǐng)求模式。這種屬性剛好符合音頻幀的特性,因?yàn)橐纛l幀數(shù)據(jù)量很小足夠放在一個(gè)Data包內(nèi)。然而對(duì)于視頻內(nèi)容,消費(fèi)者需要使用非可靠數(shù)據(jù)獲?。╱nreliable data retrieval,UDR)模式進(jìn)行獲取。UDR并行地發(fā)送Interest包,但不負(fù)責(zé)進(jìn)行幀內(nèi)排序。由于一些數(shù)據(jù)段可能會(huì)以亂序抵達(dá),視頻播放方的開發(fā)者需要自行處理幀內(nèi)Data包段重組以及舍棄掉某些不完整的幀。但是經(jīng)過(guò)多次實(shí)驗(yàn)與思考,針對(duì)視頻幀的獲取最終采用可靠數(shù)據(jù)獲?。╮eliable data retrieval,RDR)模式來(lái)取代UDR模式,原因如下:
(1)一個(gè)視頻幀通常包含許多段,然而僅僅一個(gè)段的遺失就會(huì)導(dǎo)致整個(gè)幀的無(wú)效化。如果不對(duì)此數(shù)據(jù)段進(jìn)行重新請(qǐng)求,此幀內(nèi)已經(jīng)獲取的數(shù)據(jù)段就被浪費(fèi)了。同時(shí),關(guān)鍵幀(key frame)的丟失會(huì)對(duì)視頻畫面產(chǎn)生十分嚴(yán)重的影響。由于跨地域的數(shù)據(jù)請(qǐng)求,段遺失情況并不罕見,需要超時(shí)重傳的支持。
(2)如果使用UDR,幀內(nèi)的數(shù)據(jù)重新排序與重組需要消費(fèi)者自己來(lái)完成,而RDR可以幫助完成此項(xiàng)功能。
這并不意味著UDR沒有用途,只是RDR更加適合此類情況。設(shè)計(jì)方案中仍然保留了原始的設(shè)計(jì)描述以提供一個(gè)完整的開發(fā)曲線,同時(shí)希望這項(xiàng)工作能夠給其他NDN應(yīng)用程序開發(fā)者一些靈感。值得注意的是,無(wú)論采取哪一種數(shù)據(jù)獲取策略,在必要的情況下程序都可以自由地丟棄任意幀,因?yàn)閿?shù)據(jù)獲取過(guò)程是每一幀獨(dú)立的。
4.3.2 元數(shù)據(jù)獲取
直播流的元數(shù)據(jù)信息需要被生產(chǎn)者實(shí)時(shí)更新,這意味著每次要有一個(gè)新的Data包被生成(新的時(shí)間戳將會(huì)作為名字的最后一個(gè)組件)。然而嘗試加入直播流網(wǎng)絡(luò)的消費(fèi)者并不知道這個(gè)獨(dú)特的名稱,不能夠使用UDR或者RDR策略,因?yàn)檫@兩類策略沒有假設(shè)此類信息。一個(gè)簡(jiǎn)單的解決方案是使用SDR策略,將Right_Most_Child選項(xiàng)設(shè)置為真,該選項(xiàng)保證每次獲取的命名前綴下的元數(shù)據(jù)信息都是最新的。同時(shí),SDR也被用來(lái)獲取幀號(hào)和播放時(shí)間的映射關(guān)系。
4.3.3 幀間流水線獲取策略
正如上文討論的那樣,RDR策略可以幫助處理幀內(nèi)的數(shù)據(jù)段。然而消費(fèi)者需要自行控制幀與幀之間的發(fā)送速度,這種關(guān)系更加難以處理:如果消費(fèi)者發(fā)送幀間Interest包速度太快,而數(shù)據(jù)還未被產(chǎn)生,那么播放器就可能崩潰;另一方面,如果消費(fèi)者發(fā)送Interest包太慢,播放可能就會(huì)落后于視頻生成速率。NDNlive使用固定幀率,因此對(duì)于一個(gè)視頻幀率為fr_rate=30(每秒鐘幀數(shù)為30)的直播流,幀之間的時(shí)間間隔則為33ms,參見公式:
如果下一幀無(wú)法在33ms內(nèi)到達(dá),播放就會(huì)被阻塞。然而NDN測(cè)試平臺(tái)上兩個(gè)節(jié)點(diǎn)間典型的I-D(Interest-Data)包的交換往返時(shí)延(round trip time,RTT)至少為50ms。因此如果采用阻塞式的幀間數(shù)據(jù)獲取策略(即只有當(dāng)前幀獲取成功后再獲取下一幀),將無(wú)法在指定時(shí)間間隔內(nèi)獲取足夠的視頻幀。
(1)流水線窗口與動(dòng)態(tài)調(diào)整算法。為了達(dá)到視頻的流暢播放,必須有多個(gè)連續(xù)幀被同時(shí)請(qǐng)求。據(jù)此,提出了流水線窗口(pipelinew indow,pip_win),其等于在同一時(shí)刻被同時(shí)請(qǐng)求的幀的總和,并且該窗口可以依據(jù)實(shí)時(shí)的RTT進(jìn)行自適應(yīng)的調(diào)整。為了更加清楚地描述幀間流水線獲取策略,圖3展示了一個(gè)例子,其中幀間間隔(fr_int)為33ms,幀間往返時(shí)延(fr_rtt)為50ms,流水線窗口(pip_win)為2,Tn為:
Fig.3 Frame fetching pipelining strategy圖3 幀流水線獲取策略
初始時(shí),播放器同時(shí)發(fā)送兩組Interest包,分別請(qǐng)求幀0與幀1,這兩組請(qǐng)求會(huì)先于幀生成的時(shí)間抵達(dá)視頻發(fā)布者,這段時(shí)間被稱作預(yù)熱階段(warm_period),即圖3中的時(shí)間段(1)。在此階段之后的T0時(shí)間點(diǎn),幀0的Interest包可以被滿足,由于傳輸延遲的存在,可以得到一定會(huì)有的播放時(shí)延如下:
其中,fr_rtt代表每幀的平均獲取時(shí)間。只要播放器收到幀0的Data包,就會(huì)接著發(fā)送幀2的Interest包請(qǐng)求,此舉將流水線窗口從{0,1}滑動(dòng)到了{(lán)1,2}??梢杂^察得到,設(shè)置恰當(dāng)?shù)牧魉€窗口能夠使新生成的幀立即被轉(zhuǎn)發(fā)到播放器方,以此保證視頻播放的流暢度。流水線窗口計(jì)算公式如下:
通過(guò)對(duì)流水線窗口的動(dòng)態(tài)調(diào)整進(jìn)行流量控制,此部分偽代碼如算法1所示。首先,將pip_win設(shè)置為一個(gè)較大的初始值,然后依照當(dāng)前的fr_rtt以及fr_rate逐漸減小。為了避免頻繁的變動(dòng),pip_win只有當(dāng)幀數(shù)量聚集到pip_win/2時(shí)才會(huì)重新計(jì)算,并且每次只能增加或收縮1。此外,對(duì)于幀生成速率固定且消費(fèi)者知情的情況下,可以直接采用fr_rate來(lái)計(jì)算fr_int,如果該值并不固定,則需要通過(guò)實(shí)時(shí)測(cè)量幀吞吐量來(lái)取代fr_rate對(duì)fr_int進(jìn)行計(jì)算。
算法1流水線窗口動(dòng)態(tài)調(diào)整
fr_cnt++
rtts←rtts+fr.fr_rtt
iffr_cnt≥pip_win/2 then//如果幀累積到一定數(shù)量
fr_rtt←rtts/fr_cnt
//計(jì)算該時(shí)間段內(nèi)的平均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)超時(shí)重傳參數(shù)。另外一個(gè)需要注意的參數(shù)是Interest包的超時(shí)重傳(Timeout),同樣也是與網(wǎng)絡(luò)實(shí)時(shí)的RTT相關(guān)。如圖3所示,只有在warm_period+fr_int時(shí)間之后,幀1的請(qǐng)求才會(huì)被滿足。因此在此期間,Interest包不能失效,否則必須重新發(fā)出一次幀1的請(qǐng)求,這將會(huì)導(dǎo)致播放器延遲加劇。流水線窗口的最后一幀往往會(huì)遭遇最久的等待時(shí)間,最長(zhǎng)可達(dá)(pip_win-1)×fr_int。幀的超時(shí)重傳(fr_to)應(yīng)該滿足如下公式:
為了更簡(jiǎn)潔一些,設(shè)置warm_period≈fr_int,可以得到式(7):
Fr_to不能夠被設(shè)置得太久,因?yàn)楫?dāng)網(wǎng)絡(luò)不穩(wěn)定時(shí),太長(zhǎng)時(shí)間的Timeout會(huì)導(dǎo)致更久的重傳等待時(shí)間,進(jìn)而影響整個(gè)的數(shù)據(jù)獲取進(jìn)程??偨Y(jié)一下,通過(guò)自動(dòng)調(diào)整流水線窗口(pip_win)與超時(shí)重傳數(shù)值(fr_ro)來(lái)控制幀間數(shù)據(jù)請(qǐng)求的速率。這也是NDN或者其他ICN網(wǎng)絡(luò)中的另一個(gè)關(guān)鍵問(wèn)題。
(3)關(guān)鍵(key)幀與增量(delta)幀。同樣都是視頻幀,關(guān)鍵幀與增量幀的大小存在巨大差異,關(guān)鍵幀包含超過(guò)10個(gè)段,而增量幀只含有1到2個(gè)段。為了能夠適應(yīng)這種容量差異,幀內(nèi)數(shù)據(jù)獲取策略總是會(huì)首先發(fā)出一條請(qǐng)求來(lái)獲取本幀最后一個(gè)段的段號(hào)。在獲取了這個(gè)信息之后,API會(huì)同時(shí)發(fā)出幀內(nèi)剩下所有段的請(qǐng)求。對(duì)于幾乎所有的增量幀,數(shù)據(jù)獲取能夠在一個(gè)I-D交換時(shí)間內(nèi)完成,對(duì)于關(guān)鍵幀和一小部分的增量幀,數(shù)據(jù)請(qǐng)求需要花費(fèi)兩個(gè)I-D交換時(shí)間。
NDNlive開發(fā)使用Consumer/ProducerAPI(C++)與Gstreamer1.4.3庫(kù)。NDN轉(zhuǎn)發(fā)守護(hù)進(jìn)程(NDN forwarding daemon,NFD)[10]被用來(lái)轉(zhuǎn)發(fā)Interest包到適合的生產(chǎn)者以及回復(fù)Data包給消費(fèi)者。支持的平臺(tái)為Mac OSX和Linux Ubuntu。更多有關(guān)該項(xiàng)目早期的實(shí)驗(yàn)細(xì)節(jié)與偽代碼可以在此技術(shù)報(bào)告中獲取[11],但如第4.2節(jié)與第4.3.2小節(jié)提及的,本項(xiàng)目開發(fā)在此報(bào)告之后經(jīng)過(guò)多次版本迭代,例如NACK策略的更改、RDR策略替換UDR策略等;同時(shí)后期更新了幀間流水線獲取策略(第4.3.3小節(jié));底層消費(fèi)者/生產(chǎn)者API在不斷改進(jìn)中,其接口與使用方式也在不斷調(diào)整,因此NDNlive也需不斷更新代碼以適配最新底層庫(kù);進(jìn)行了更加完整的遍布全球的測(cè)試;推廣NDN-live到更多的應(yīng)用場(chǎng)景,例如一個(gè)基于NDNlive設(shè)計(jì)與開發(fā)的人臉識(shí)別系統(tǒng)也正在測(cè)試與部署中。
整個(gè)命名數(shù)據(jù)網(wǎng)絡(luò)架構(gòu)還在非常初級(jí)的階段,并且還沒有硬件支持,因此NDNlive在性能上無(wú)法與TCP/IP網(wǎng)絡(luò)進(jìn)行直接的橫向比較,該項(xiàng)工作更多的是一種功能性測(cè)試和開發(fā)示例。本章首先介紹實(shí)驗(yàn)環(huán)境,接著展示實(shí)驗(yàn)結(jié)果。
5.1 實(shí)驗(yàn)設(shè)置
與模擬實(shí)驗(yàn)不同,選擇將NDNlive直接部署在世界范圍的NDN測(cè)試平臺(tái)上,以此提供更加真實(shí)的結(jié)果,同時(shí)驗(yàn)證設(shè)計(jì)的正確性和靈活性。在進(jìn)行實(shí)驗(yàn)的時(shí)間段內(nèi),該公共測(cè)試平臺(tái)包含32個(gè)節(jié)點(diǎn)、87個(gè)鏈路,同時(shí)在該平臺(tái)上還運(yùn)行著許多其他的真實(shí)有效的應(yīng)用程序。其中13個(gè)節(jié)點(diǎn)在北美洲,1個(gè)節(jié)點(diǎn)在南美洲,10個(gè)節(jié)點(diǎn)在歐洲,8個(gè)節(jié)點(diǎn)在亞洲,幾乎遍布全球。從跨越0個(gè)節(jié)點(diǎn)(消費(fèi)者和生產(chǎn)者在局域網(wǎng)內(nèi)直連)到跨越6個(gè)節(jié)點(diǎn)(NDN測(cè)試平臺(tái)的最長(zhǎng)路徑)依次對(duì)NDNlive進(jìn)行了測(cè)試,每個(gè)測(cè)試時(shí)長(zhǎng)24小時(shí)。
數(shù)據(jù)發(fā)布者與播放者分別運(yùn)行在兩臺(tái)Macbook上,均位于加州大學(xué)洛杉磯分校校園內(nèi),并且同時(shí)接入NDN測(cè)試平臺(tái)中。需要特別強(qiáng)調(diào)的是,NDNlive使用該平臺(tái)傳輸Interest和Data包,而不是直接將應(yīng)用程序運(yùn)行在該平臺(tái)上。因此文中提到的跳(hop)通常指視頻發(fā)布者與播放者跨越的位于平臺(tái)之中的節(jié)點(diǎn)個(gè)數(shù),真實(shí)的跳數(shù)應(yīng)該加1。同樣,計(jì)算的路徑花費(fèi)(cost)也不包括邊界節(jié)點(diǎn)到發(fā)布者與播放者之間的距離。實(shí)際實(shí)驗(yàn)中,使用了其中25個(gè)節(jié)點(diǎn),考慮到有5個(gè)節(jié)點(diǎn)沒有正常工作和2個(gè)節(jié)點(diǎn)在當(dāng)時(shí)還沒有搭建完成。為了方便對(duì)比,視頻發(fā)布者總是接入到UCLA節(jié)點(diǎn),只改變視頻播放者的接入點(diǎn)??傮w上,在美國(guó)境內(nèi)共計(jì)13個(gè)節(jié)點(diǎn),最長(zhǎng)跳數(shù)小于等于4,NDN 路由協(xié)議(NDN link state routing protocol,NLSR)[12]花費(fèi)少于50,節(jié)點(diǎn)間NLSR花費(fèi)由路由協(xié)議根據(jù)距離自動(dòng)生成。在其他地域的節(jié)點(diǎn)NLSR花費(fèi)均大于95,其中位于歐洲(7對(duì)節(jié)點(diǎn),大于等于4跳)的節(jié)點(diǎn)平均花費(fèi)要略微高于亞洲(5對(duì)節(jié)點(diǎn),大于等于3跳)的花費(fèi)。
5.2 幀RTT測(cè)量
Fig.4 Frame RTT across testbed圖4 測(cè)試平臺(tái)中的幀往返時(shí)延
圖4顯示了在整個(gè)NDN測(cè)試平臺(tái)中,視頻與音頻的幀平均往返時(shí)延(fr_rtt)??梢钥闯觯曨l的fr_rtt總是比音頻的要長(zhǎng)一點(diǎn),這是合理的,因?yàn)楹芏嘁曨l幀中有多個(gè)段而音頻幀中只有一個(gè)段??傮w的趨勢(shì)為幀RTT伴隨著距離(NLSR花費(fèi))的增加而增長(zhǎng),并且存在一些波動(dòng)(RTT突變,共計(jì)7處),原因在于:
(1)一些NLSR花費(fèi)不夠準(zhǔn)確。例如通過(guò)路徑UCLA-CSU-M ICH-NIST的視頻fr_rtt大概是1 000,該數(shù)值遠(yuǎn)遠(yuǎn)高于路徑UCLA-CSU-M ICH-UM(fr_rtt≈600),雖然它們的NLSR花費(fèi)其實(shí)是一樣多的,都是44。測(cè)量結(jié)果顯示,盡管M ICH-NIST段與M ICHUM段NLSR花費(fèi)相同,都是13,具體的Interest-Data交換時(shí)延前者卻高很多。這也解釋了在TONGJI節(jié)點(diǎn)處的第一次RTT突變,該NLSR花費(fèi)為96,其位于中國(guó),相較NLSR花費(fèi)更高的位于日本的WASEDA節(jié)點(diǎn)而言,其網(wǎng)絡(luò)狀況更差,因此雖然NLSR花費(fèi)更低,但RTT卻比周圍節(jié)點(diǎn)都高出很多。
(2)總是存在一些繁忙節(jié)點(diǎn)。盡管希望能在全平臺(tái)空閑時(shí)(例如凌晨)運(yùn)行測(cè)試程序,但這幾乎是不可能的,因?yàn)槊绹?guó)與其他大陸存在時(shí)差(最長(zhǎng)可達(dá)11小時(shí));此外,由于測(cè)試平臺(tái)是公共的,無(wú)法控制其他應(yīng)用程序的行為,例如在KISTI(跨越3跳,NLSR花費(fèi)100)節(jié)點(diǎn)中,總是有一個(gè)應(yīng)用程序在運(yùn)行并占用大量計(jì)算資源,導(dǎo)致其RTT相較圖中周圍NLSR花費(fèi)相近的節(jié)點(diǎn)明顯增大(突變)。
(3)連接在跨洋時(shí)會(huì)變得十分不穩(wěn)定。因此實(shí)驗(yàn)最終去除了5個(gè)節(jié)點(diǎn):BUPT,位于亞洲;SYSTEMX、ORANGE、BASEL、URJC位于歐洲,這些節(jié)點(diǎn)總會(huì)經(jīng)歷相當(dāng)長(zhǎng)的延時(shí)與更加顯著的性能波動(dòng)。作為結(jié)果,即使是在十分低畫質(zhì)的情況下,它們的丟包率(大于50%,其他節(jié)點(diǎn)小于25%)太高而無(wú)法實(shí)現(xiàn)流暢的傳輸。剩下的5次RTT突變就發(fā)生在該5個(gè)節(jié)點(diǎn)處。
5.3 流水線窗口與幀超時(shí)重傳
在具體實(shí)現(xiàn)中,流水線窗口通常被設(shè)置為一個(gè)很大的數(shù)值,然后慢慢依據(jù)實(shí)時(shí)的fr_rtt不斷縮小直至穩(wěn)定在一個(gè)固定數(shù)值左右。圖5顯示了視頻以及音頻的流水線窗口穩(wěn)定值。
Fig.5 Pipelinew indow across testbed圖5 測(cè)試平臺(tái)中的流水線窗口
可以看出流水線窗口(pip_win)隨著NLSR花費(fèi)的變化而改變,其趨勢(shì)與幀往返時(shí)延(fr_rtt)相似,即圖4。圖5中已經(jīng)剔除了上文提到的5個(gè)跨洋節(jié)點(diǎn)。據(jù)觀察所得,自適應(yīng)的幀流水線獲取策略的確能夠帶來(lái)至多跨11個(gè)時(shí)區(qū)直播的流暢播放。在多次實(shí)驗(yàn)后,總結(jié)發(fā)現(xiàn)對(duì)于流水線窗口最好比計(jì)算值,即式(5),大1。因?yàn)楦蟮拇翱谀軌蛉淌茌p微的幀往返時(shí)延抖動(dòng),例如當(dāng)網(wǎng)絡(luò)不穩(wěn)定時(shí)。這點(diǎn)對(duì)于幀超時(shí)重傳(fr_to)也是一樣的,在實(shí)際中fr_to通常被設(shè)置成為兩倍的fr_rtt,fr_to并不像pip_win一樣敏感。
5.4 幀間流水線獲取策略驗(yàn)證
為了驗(yàn)證自適應(yīng)幀流水線獲取策略的彈性,記錄了當(dāng)有臨時(shí)的網(wǎng)絡(luò)擁塞發(fā)生時(shí),流水線窗口的變化曲線,如圖6所示。本實(shí)驗(yàn)在使用兩臺(tái)Macbook同時(shí)接入U(xiǎn)CLA節(jié)點(diǎn),即跨越1跳的情況下完成。為了簡(jiǎn)潔性,圖中只顯示了視頻的情況,沒有音頻。
Fig.6 Pipelinew indow and frame RTT of video across onehopwhen network congestion occurs圖6 網(wǎng)絡(luò)擁塞發(fā)生時(shí)的視頻流水線窗口與幀往返時(shí)延
從圖6中可以看出,流水線窗口被初始化為10,接著參照幀往返時(shí)延逐漸降低,然后維持在6一段時(shí)間。為了避免頻繁的變動(dòng),pip_win只有當(dāng)幀數(shù)量聚集到pip_win/2時(shí)才會(huì)重新計(jì)算,并且每次只能增加或收縮1。例如,初始時(shí),窗口大小為10,則只有當(dāng)過(guò)去了10/2×33.3≈167ms時(shí),它才會(huì)從10下降到9,因此下降速度是與pip_win的大小成正比的。在第2秒時(shí),網(wǎng)絡(luò)擁塞發(fā)生(有另一個(gè)應(yīng)用程序不間斷地向UCLA節(jié)點(diǎn)發(fā)送Interest請(qǐng)求)??梢钥吹絝r_rtt立刻增加,pip_win也隨之慢慢增加,然后維持在9,停留了1 s。在網(wǎng)絡(luò)恢復(fù)正常后(第3秒),fr_rtt逐漸下降回6。在測(cè)試過(guò)程中,除了無(wú)法避免的初始化播放延遲,以及由于被延長(zhǎng)的Interest-Data交換延遲,視頻流只在網(wǎng)絡(luò)擁塞發(fā)生之初出現(xiàn)了卡頓(少于100ms),其余過(guò)程中視頻流均能維持流暢和同步播放。
加州大學(xué)洛杉磯分校REMAP(Center for Research in Engineering,Media and Performance)實(shí)驗(yàn)小組曾經(jīng)在搭建NDNVideo[13]系統(tǒng)上做出很多的努力,這也是第一個(gè)在NDN上證實(shí)視頻播放軟件可行的應(yīng)用。之后數(shù)據(jù)包格式以及新的轉(zhuǎn)發(fā)器的研發(fā)導(dǎo)致了這個(gè)視頻流已經(jīng)不再可用。NDNlive是清華大學(xué)以及加州大學(xué)洛杉磯分校IRL實(shí)驗(yàn)室共同研發(fā)的具有相似功能的,但能夠與現(xiàn)在新的數(shù)據(jù)包格式、轉(zhuǎn)發(fā)器以及應(yīng)用支撐庫(kù)適配的新的視頻直播系統(tǒng)。同時(shí),此項(xiàng)工作對(duì)于NDN應(yīng)用開發(fā)者也提供了更加完整的參考示例。
NDNlive和NDNVideo的主要區(qū)別在于視頻內(nèi)容和音頻內(nèi)容的組織方式上。在NDNVideo中,視頻和音頻流被切分成定長(zhǎng)的段,因此需要在真實(shí)的播放時(shí)間與段號(hào)之間建立映射關(guān)系來(lái)保證視頻和音頻的同步,同時(shí)以此來(lái)支持查找功能。定長(zhǎng)切分破壞了幀之間界限,這種內(nèi)部相關(guān)性會(huì)導(dǎo)致和TCP/IP中同樣的問(wèn)題,例如線頭阻塞問(wèn)題(head-of-line,HOL)。與此相反,在NDNlive中,兩組直播流都被按照幀進(jìn)行組織,幀內(nèi)可能包含多個(gè)段。由于幀內(nèi)分段對(duì)于應(yīng)用程序而言是透明的,NDNlive開發(fā)可以集中關(guān)注在幀這一層面。因?yàn)槊總€(gè)幀都有一個(gè)獨(dú)特的名字,并且是和其他幀獨(dú)立的,所以單獨(dú)某一幀的丟失不會(huì)影響到其他幀的獲取,對(duì)于視頻流尤其是實(shí)時(shí)視頻流帶來(lái)了很大的靈活性。
NDN-RTC[14-15]是一個(gè)實(shí)時(shí)會(huì)議庫(kù),用來(lái)提供類似Skype視頻通話的功能。與NDNlive類似,NDN-RTC也將視頻和音頻按幀分割,但是NDNlive在設(shè)計(jì)上更加簡(jiǎn)潔。
(1)關(guān)鍵幀和增量幀在NDN-RTC中采用的是不同的命名空間,然而NDNlive在命名空間上不區(qū)分這兩種幀。首先,消費(fèi)者/生產(chǎn)者API可以幫助獲取一個(gè)幀內(nèi)的多段數(shù)據(jù),并且任意幀(無(wú)論該幀可能多大)的獲取都可以控制在兩輪幀往返延遲之內(nèi),如此限制了兩種幀之間的區(qū)別。其次,自適應(yīng)流水線窗口策略能夠容忍不同幀獲取時(shí)間的差異,因?yàn)閹禃r(shí)延總是在累積到一定幀數(shù)后才會(huì)被重新計(jì)算(流水線窗口的一半)。
(2)NDNlive使用消費(fèi)者/生產(chǎn)者API來(lái)處理生產(chǎn)者的數(shù)據(jù)幀分段,與消費(fèi)者的幀內(nèi)數(shù)據(jù)段重傳和重組。NDN-RTC則完全由應(yīng)用程序來(lái)處理這些工作,邏輯更為復(fù)雜。這也是消費(fèi)者/生產(chǎn)者API能夠帶來(lái)的一個(gè)顯著優(yōu)勢(shì)。
表1描述了3個(gè)項(xiàng)目其他的主要不同點(diǎn),例如依賴庫(kù)、媒體處理工具以及編程語(yǔ)言等。除此之外,NDNlive還具備更加完整的跨越整個(gè)世界范圍的NDN測(cè)試平臺(tái)的實(shí)驗(yàn)與測(cè)試。
本文提出了NDNlive,一個(gè)基于命名數(shù)據(jù)網(wǎng)絡(luò)的視頻直播系統(tǒng)。NDNlive將視頻與音頻流組織成為連續(xù)的幀,使視頻播放方可以更加靈活地處理獲取的數(shù)據(jù)。NDNlive針對(duì)音頻、視頻內(nèi)容以及元數(shù)據(jù)采用不同的數(shù)據(jù)獲取策略以適應(yīng)不同的數(shù)據(jù)屬性與數(shù)據(jù)生成模式。同時(shí)通過(guò)應(yīng)用自適應(yīng)的幀流水線獲取策略,NDNlive能夠忍受輕微的網(wǎng)絡(luò)問(wèn)題。實(shí)驗(yàn)結(jié)果顯示,NDNlive確實(shí)是一個(gè)靈活有效的、能夠運(yùn)行在全球范圍的NDN測(cè)試平臺(tái)上的直播系統(tǒng),驗(yàn)證了命名數(shù)據(jù)網(wǎng)絡(luò)對(duì)此類應(yīng)用的支持。本文針對(duì)NDN以及其他內(nèi)容中心網(wǎng)絡(luò)中存在的問(wèn)題,給出了一些通用的解決方案,例如NACK。該項(xiàng)工作還可以被當(dāng)作命名數(shù)據(jù)網(wǎng)絡(luò)中一個(gè)較為完整的設(shè)計(jì)、實(shí)驗(yàn)與測(cè)量應(yīng)用程序的示例。
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—),女,山東威海人,清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系博士研究生,主要研究領(lǐng)域?yàn)榉植际较到y(tǒng),命名數(shù)據(jù)網(wǎng)絡(luò)。
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年于美國(guó)加州大學(xué)洛杉磯分校獲得博士學(xué)位,現(xiàn)為思科公司研發(fā)工程師,主要研究領(lǐng)域?yàn)榫W(wǎng)絡(luò)架構(gòu)。
HEWenbo was born in 1996.He is a studentat Departmentof Electronic Engineering,Tsinghua University.His research interests includemachine learning and distributed computing.
何文博(1996—),男,河北保定人,清華大學(xué)電子工程系學(xué)生,主要研究領(lǐng)域?yàn)闄C(jī)器學(xué)習(xí),分布式計(jì)算。
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年于哈爾濱工業(yè)大學(xué)獲得博士學(xué)位,現(xiàn)為清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系教授,CCF高級(jí)會(huì)員,主要研究領(lǐng)域?yàn)橛?jì)算機(jī)體系結(jié)構(gòu),高性能計(jì)算。
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(國(guó)家自然科學(xué)基金);the National Key Research and DevelopmentPlan of ChinaunderGrantNo.2016YFB1000303(國(guó)家重點(diǎn)研發(fā)計(jì)劃).
Received 2017-03,Accepted 2017-05.
CNKI網(wǎng)絡(luò)優(yōu)先出版:2017-05-22,http://kns.cnki.net/kcms/detail/11.5602.TP.20170522.1058.004.htm l