基于DPDK的包级别ICN视频传输

霍玲玲 李萌萌 王 远

1(吉林工商学院外国语学院 吉林 长春 130507) 2(兰州大学信息科学与工程学院 甘肃 兰州 730000)

0 引 言

与IP网络不同，信息中心网络(ICN)摈弃了传统的细腰结构，侧重于命名数据的缓存和分发，是典型的未来互联网范式之一[1]。独特的网内缓存特性使ICN备受关注，也使其具有更广泛的应用价值，如车载网、无线卫星网络、移动社交网络等。然而，与此同时越来越多的媒体应用和视频服务商层出不穷，如YouTube、NetFlix、腾讯等，这就要求ICN必须能够兼容这些应用，即支持高效的视频传输。虽然一些服务商(如CDN)同样支持大型视频的高效传输，但是它们的叶子节点比较高，很难以较低的价格开销下沉到局域网。相比之下，ICN天然地支持网内缓存，能够部署到局域网以及更靠近用户的地方，且路由器部署的缓存大小比较灵活，这就使得当前的视频传输业务对ICN部署的需求较大。

随着云计算、物联网、5G等技术的发展，现在网内传输的视频不再是以MB来论，往往都是以多少GB来论。如果再沿用传统ICN对内容的内容级别或者块级别的缓存，那么将会引起两个严重的问题。(1)内容路由器的大小是受限的(它不可能无限制地放大，这是由缓存价值所决定的)，它通常没有能力去容纳多个不同的完整视频数据，这就导致缓存不断地替换，最终使得网络性能大幅度下降。(2)对于同一个视频，并不是所有的用户对这个整的视频数据都感兴趣；相反，大部分用户只对视频的某个片段感兴趣(即热点片段，例如文献[2]指出83%的观看时间仅仅集中在1%的视频，这说明整个视频仅仅有一小段是流行的，而剩余的那些片段往往是无人关注的)，这种情况就会导致缓存的利用率不高，不利于整体网络性能的提升和用户体验质量的改善。

基于上述的分析和讨论，包级的缓存应该被提出，一方面是为了提高视频的传输性能，另一方面是为了更好地兼容IP网络。除此之外，本文还引入数据平面开发套件(DPDK)[3]来保障视频的有效传输，主要体现着两个方面：(1)采用特有的函数库来确保除最后一个包之外的每个包的大小是一致的(这不同于IP层的切包和网卡切包，因为ICN本身不具备这种能力)；(2)绕过内核，加大视频数据在端侧的传输能力。

1 相关工作

近年来，国内外的研究学者就ICN的视频传输已经开展了一些相关工作，并且取得了一定的成效。文献[4]利用流映射代理来监管内容路由器之间的信息连接情况，在此基础上提出无缝的视频传输方案用于解决节点的移动性问题。文献[5]借鉴供应链管理中的库存模型来模拟视频传输的过程，使视频流在离散状态下自组织地传输。文献[6]提出了基于继电器的多点视频传输方案，利用无线感知环境设计了一个低复杂度的算法去选择继电器。文献[7]提出基于软件定义网络的视频传输方案，充分利用软件定义网络的集中控制能力和具有全局视图的能力来主导视频的传输。文献[8]在理论上给出了一个视频传输分析模型，能够处理多路径下的多个视频流的请求。文献[9]启发于自然界中的蚂蚁行为，提出一种分布式并行的视频传输方案，整个视频的传输过程都是以自组织自适应的方式进行的。文献[10]集成有状态的数据转发构建了一个多播树，并给出一种划分算法将多播树分解成多个区域，继而针对不同的区域来传输视频。文献[11]提出了一种基于网络编码的视频传输方案，主要用于提升缓存命中率和网络吞吐。文献[12]在无线接入网上构建了一个视频传输机制的测试床，具有很好的支撑效果。

虽然以上相关视频传输方案具有不错的性能，但在缓存命中率、传输时延、网络负载等方面仍有提升的空间。此外，不同于现有的工作，本文首次提出基于包级别缓存的视频传输，并通过DPDK给予保障，这最大程度地减少视频传输的流量和加快视频传输的速度。

2 包级别的视频传输方案

2.1 思想孵化

就传统的ICN视频传输方案而言，一段视频总是要从视频提供商出发一直被分发到用户请求者。然而事实上，如果本地能够通过某种手段知晓下游有该视频片段的缓存，那么本地大可不必再传输这个视频段，取而代之的是只传输这段视频的标识，这样一来就大幅度节省了传输的视频流量。对此，给出一个事例进行说明，如图1所示。

图1中有四个内容路由器，分别是I、J、K和L。在初始状态下(如图1(a)所示)，I、J和L缓存有packet-x而K没有缓存packet-x。在user1和user2都请求packet-x的情况下，根据传统的ICN视频传输方案，packet-x的传输路径分别是I->K->L->user1和J-K-L->user2。可以看出packet-x在局部路径K->L上进行了重复的传输。由于一个视频会有若干个包构成，多次如此重复传输，势必严重影响整体网络的性能。

(a) (b)图1 思想孵化说明

正如上述所讲，如果I和J知道它们的下游L有packet-x，那么它们不需要再向下传输packet-x，取而代之可以在局部路径上仅仅传输packet-x的包头。即如图1(b)所示，局部路径I->K->L和J->K-L只需传输packet-x的包头，这是因为L已经缓存有packet-x；而packet-x只需在局部路径L->user1和L->user2上传输即可。

根据这个事例，本文将要设计的包级别的视频传输方案的核心思想总结为以下两点：1)如果本地判断下游有缓存，本地仅向下游传输包头；2)如果本地接到的是上游发来的包头而下游又没有缓存，本地需要重新构造这个包。通过核心思想，可以看出有两个问题需要细究：1)本地如何判断下游是否有缓存；2)详细的视频传输方案是如何设计的。

2.2 下游缓存判断

就经典的ICN而言，内容路由器通常包含有三个用于兴趣路由以及视频传输的表结构，分别是用于存储视频的内容存储表(Content Store，CS)、用于检测兴趣是否转发成功情况的未决兴趣表(Pending Interest Table，PIT)和用于引导兴趣准确转发的转发信息表(Forwarding Information Base，FIB)。显然，这三个表难以实现对下游是否有缓存的判断。为此，本文为内容路由器增设一个新的表结构，即包传输表(Packet Transmission Table,PTT)用于记录包往下游传输的情况，如表1所示。

表1 新增的PTT结构

可以看出PTT由两个字段组成，即包的标识ID和定时器Timer。其中ID是包头的一个字段，由视频供应商统一编写，即应用层的实现；Timer是由系统产生的定时器，用于记录对应包转发的剩余时间。具体地讲，PTT的一个表项要表达的意思是：某个包已经向下游发生了传输动作并且下游缓存的存在时间是Timer对应的数值。

针对PTT，需要指出的有三点：(1)如果内容路由器需要向下传输相同的包，那么对应表项的Timer归置到初始值；(2)如果内容路由器需要向下传输新的包，那么PTT需要新增一个表项并置Timer为初始值；(3)如果某个表项的Timer变为0，这说明该ID对应的包这个时间段没有通过该内容路由器传输，因此要清除该表项。这样一来，就能够根据PTT来判断下游是否有缓存了，即如果在PTT中查到有对应的ID，那么就意味着下游一定有缓存。

通过上述描述，虽然PTT能够判断下游是否有缓存，但于整个系统而言仍需要CS的配合，这是由Timer的协调所决定的。为此，本文改进CS如表2所示，其中改进CS的一个表项要表达的意思是：某个包从上游过来且它的存储时间是Timer对应的数值。特别地，表2中的Timer值要与PTT中的Timer值相对应。

表2 改进的CS结构

2.3 传输方案设计

根据2.1节孵化的两点核心思想和2.2节设计的两个表结构，整个视频传输方案总结如下：

1)检查PTT，如果发现下游有某个包，那么这个包被“拆开”，只保留对应的ID在包头中，并将它传输到下游去。

2)检查PTT，如果发现下游没有要传输的包，并且如果本地从上游接到的是整个包，则向下传输该包；如果本地从上游接到的是包头所带的ID，那么需要对包头进行“拼接”操作，即检查CS、寻找该ID对应的数据段，然后将其“拼接”到包头的后面，最后才能向下游传输。

考虑packet-x由ID-x和payload-x组成，它从任意的内容路由器I直接到内容路由器J进行传输，整个过程的伪代码描述如算法1所示。

算法1视频传输方案

输入：packet-x，I，J。

输出：NULL。

1.I解析接收到的包；

2.ifI接到的是ID-x+payload-x，then

3.ifI的CS缓存有packet-x，then

4.ifI的TPP有匹配的ID-x，then

5. 拆开packet-x并传输ID-x到J；

6.else

7. 传输packet-x到J；

8.else

9. 缓存packet-x并操作4至7行；

10.else

11.ifI的PTT有匹配的ID-x，then

12. 传输ID-x到J；

13.else

14.ifI的CS缓存有packet-x，then

15. 拼接payload-x到ID-x并传输到J；

16.else

17. 丢掉ID-x；

特别地，对于算法的最后一行，它的意思是当内容路由器I和内容路由器J的CS都没有匹配的packet-x时，ID-x不必向上回溯而是要丢弃。

2.4 定量分析

假设一段视频有N个包需要传输，下游的缓存命中率为rhit，采用本文设计的传输方案时任意包所经过内容路由器的数量为ni，不采用本文设计的传输方案时任意包所经过内容路由器的数量为uni。基于此，本文的视频传输流量和非本文的视频传输流量分别为：

(1)

(2)

式中：headersize和payloadsize分别是包头的大小和包容纳视频数据的大小。用srate代表流量的节省率，则有：

(3)

考虑一个视频大小为3 GB左右，N=1 610 612，payloadsize=2 000 B，headersize=10 B，ni=1.6，uni=3，rhit=35%。将它们代入式(3)，可以得到srate=65.5%，这说明本文设计的视频传输方案能够节省大量的传输数据，对性能优化起到重要的推动作用。

3 DPDK的效用分析

正如前文所述，DPDK的引入一方面是确保视频传输方案中除最后一个包外的每个包的大小一致，另一方面是利用它绕内核的特性来加速视频数据的传输。为了实现以上两个效用，本文重点使用DPDK的三个基础模块，即DPDK Generic Segmentation Offload(GSO)、DPDK send和DPDK receive。其中，第二和第三个模块用于实现DPDK的第二个效用，即加速视频数据的传输：DPDK send用于发包，DPDK receive用于收包，分别可以调用内置的DPDK函数来完成各自的发包和收包，即rte_tx_burst和rte_rx_burst函数。

对于DPDK的第一个效用，需要由DPDK GSO来实现。虽然基于GSO的包切片是一个工程实现，但是它仅仅处理标准的包，即TCP header、IP header、以太header，而不能直接用于本文带ID的视频传输方案。为此本文改进GSO来确保包大小的一致性，描述如下：

1)为要传输的整个视频段添加标准的包头。

2)调用内置函数rte_gso_segment来做切包，其中每个包由标准的包头和对应的视频片段组成。

3)插入ID到标准包头的后面，从而形成新的带ID的包头。特别地，ID和对应的视频片段在逻辑上是相邻的但在物理上是不相邻的，这通过指针来实现。

4)把形成的多个包逐次放到DPDK缓冲队列中准备发送。

上述过程的伪代码描述如算法2所示。其中：videombuf用于承载整个视频段；segmbuf用于承载切好的标准包；outmbuf用于承载重新组合带ID的包；p_size是规定包的大小；no_segs是每次最大允许的切包个数。

算法2基于DPDK GSO的切包

输入：结构体*mbuf_pool，*videombuf，*segmbuf，

*sheadermbuf，*IDmbuf。

输出：结构体*outmbuf。

1.rte_eal_init(argc,argv)；

2.mbuf_pool=rte_pktmbuf_pool_create()；

3.将整个视频段放到videombuf；

4.rte_pktmbuf_chain(sheadermbuf,videombuf)；

5.rte_gso_segment(videombuf,p_size,segmbuf,no_segs)；

6.for切好的每个包，do

7. *p=包的header；

8. *q=包的payload；

9. rte_pktmbuf_chain(p,IDmbuf)；

10. rte_pktmbuf_chain(IDmbuf,q)；

11.endfor

12.outmbuf=segmbuf；

4 实 验

4.1 仿真设置

本文的仿真细节如下：

1)仿真硬件环境设置为Intel(R)Core(TM-2)Quad CPU@ 2.86 GHz，3.99 GB内存，且操作系统为Ubuntu 14.04.5 LTS 64 bit。

2)仿真软件环境为NS3，通过C++语言进行编程。

3)仿真数据集来自于校园网测试的真实YouTube数据集[13]，包括18 751个兴趣请求、13 764个视频和2 377个用户。

4)仿真实验拓扑是Oteglobe网络拓扑，包括61个节点和69条边，如图2所示。

图2 Oteglobe网络拓扑

5)对比基准为文献[7]和文献[11]，它们分别呈现了基于软件定义网络的方法和基于网络编码的方法。

6)实验评价的指标是平均缓存命中率、平均传输时延和平均网络负载。

7)将18 751个兴趣请求按时隙平均分为5个阶段，每个阶段取400个兴趣请求，即测试5组实验。

仿真参数设置如表3所示。

表3 仿真参数设置

4.2 缓存命中率

三个视频传输方案的平均缓存命中率如图3所示。可以看出本文提出的视频传输方案具有最高的平均缓存命中率，其次是文献[11]，最后是文献[7]，这是因为包级别的缓存能使内容路由器缓存数量更多并且种类更丰富的包。对于文献[7]和文献[11]，后者有更高的平均缓存命中率是因为两个方面：(1)文献[11]充分利用了网内缓存的能力去放置更多的视频块在内容路由器中，这有效提高了缓存的利用率；(2)文献[11]采用分布式协作缓存的方式去挖掘缓存的可能性，而文献[7]仅仅通过集中式的方式来调度缓存的视频块，缓存灵活性不够高。

图3 平均缓存命中率

4.3 传输时延

三个视频传输方案的平均传输时延如图4所示。可以看出本文提出的视频传输方案能以最短的时间将视频从视频服务商传输到用户，主要基于三方面的原因：(1)包级别的缓存促使较高的缓存命中率，同时使整体兴趣请求的平均路由跳数变小，因此视频传输过程中不需要再经历那么长的路径；(2)得益于设计的轻载型视频传输方案，当判断下游有某个视频段时，该视频段不必再往下传输，这大大地减少了传输的视频数据，使传输效率大幅度地增加；(3)受益于DPDK绕内核的方式，它通过DPDK send和DPDK receive两个模块来加速端侧视频流的发送和接收，在双核的促使下几乎能使吞吐量达到网络设置的带宽。

图4 平均传输时延

进一步地，还可以看出与文献[11]相比，文献[7]执行较短的平均传输时延，这是因为文献[7]只采用了软件定义网络的思想而未涉及到复杂的计算。与之相反，文献[11]采用了网络编码的思想，虽然能够提升缓存的命中率，但却因为其编码的时间复杂度较高而大大牺牲了传输时延。

4.4 网络负载

三个视频传输方案的平均网络负载如图5所示。可以看出本文提出的视频传输方案在平均网络负载方面具有绝对的优势，这是因为在视频传输的过程中，有大部分的包未曾向下传输，取而代之的是仅仅传输与之相对应的包头。正如2.4节中定量分析的那样，整个传输的过程中，本文的视频传输方案规避了巨大的流量传输。而对于文献[7]和文献[11]，后者是一种分布式的方案，它能够将视频流分散到网络各处，使网络中的内容路由器均摊流量压力。此外，后者采用了网络编码，取得了高的平均缓存命中率，这意味着它有更高的能力去快速地处理网络中的视频流量。综上两点，可以说明文献[11]较文献[7]具有较低的平均网络负载。

图5 平均网络负载

4.5 统计性测试

为了使本文的实验结果更有说服力，本节给出基于Wilcoxon的统计性测试[14]，其中置信水平设为0.01。本节只呈现第一组实验关于缓存命中率、传输时延、网络负载的统计性测试结果，结果如表4所示。其中：R+对应的数字表示前者的实验结果值大于后者实验结果的次数；R-则相反。

表4 第一组实验的统计性测试结果

可以看出，所有的p值都等于0，这说明本文提出的视频传输方案在缓存命中率、传输时延和网络负载三个方面的整体性能要好于两个对比机制。

5 结 语

与IP网络不同，ICN具有非常典型的网内缓存特征。然而当前针对缓存的研究，其粒度往往都是内容级别的或者块级别的。此外，针对ICN的视频传输应用，仅仅靠天然的网络缓存来支撑视频的高效传输也是远远不够的。鉴于此，本文提出一种包级别缓存的理念，并以此设计了轻载的视频传输方案，即尽可能多地向下游传输包头而非整个包。除此之外，为了进一步提高视频传输的效率和保障包级别的传输，又引入DPDK来进行端侧加速和完成切包。基于真实的数据集在Oteglobe网络拓扑上进行仿真，并基于Wilcoxon进行统计性测试，实验验证了本文提出的视频传输方案是可行且有效的。

然而作为一个新的视频传输方案，本文方案仍然存在一些挑战，其中最为突出的就是一致性问题的解决，即上游判断下游有缓存可能存在不一致的情况(由于下游内容频繁地替换造成的)。如果要设计关于内容的路由通告协议，那么当网络规模变大，网内的路由通告信息会呈现指数增长，致使网络性能下降，显然不是最科学的解决方案。为此，可以设计平滑过渡的方案来解决这一问题，其主要的核心思想有两点：(1)为下游内容路由器设置一个缓存阈值(可以通过实验来确定合适的值)，当达到这个阈值时，触发一个向上通告信息告诉下游缓存已满，上游不必再缓存转发信息(即不存在关于后续信息的一致性判断问题)；(2)借鉴内容分发网络的思想，如果下游替换频率比较高且达到一定的水平，这说明突发性流量到来，内容比较集中，此时下游再进行缓存也没有意义，故可以暂时关闭上游缓存转发信息的能力和下游缓存内容信息的能力。未来将围绕平滑过渡方案展开详细的研究，并基于多个大规模网络拓扑给予实验说明。