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