0 概述

视频传输在当今网络流量组成中占据相当大的比例, 根据Cisco^[1]的预测, IP视频流量占所有消费者网络流量的百分比将从2016年的37%提升到2021年的82%。届时, 每秒钟都将有近百万分钟的视频内容在网络上传输, 如此大规模的需求会使网络带宽资源迅速饱和, 从而导致延迟、抖动和丢包等一系列问题。在此情况下, 视频服务提供商很难保证终端用户的服务质量(Quality of Service, QoS)和体验质量(Quality of Experience, QoE)。

视频热度的倾斜度服从帕累托准则^[2-3], 即20%的视频对象覆盖了80%的访问量, 而多次访问同一视频会产生相当多的流量冗余。IP组播可以在一次发送中将数据推送给一组感兴趣的接收者, 但组播只支持同步视频播放而不支持视频点播(Video on Demand, VoD)这类个性化差异服务, 总体而言仍无法减少流量冗余。另一种思路是通过应用层优化来提高视频内容的传输效率, 如在传统网络协议栈上部署内容分发网络(Content Distribution Network, CDN) ^[4]。但CDN只是一个覆盖在稀疏代理服务器网络上的逻辑网络, 不能降低终端用户和选定代理服务器之间的冗余。而且, 如果CDN服务器位于自治系统(Autonomous System, AS)之外, 则会引发大量的跨域冗余流量, 且部署大规模的CDN服务器成本过高^[5]。

随着网络功能虚拟化(Network Function Virtualiza-tion, NFV)技术的普及, 网络中的路由节点可以支持内容缓存, 即网内缓存^[6]。由于缓存磁盘被集成在网络节点上, 而非CDN的存储服务器上, 因此可实现网络层的内容缓存和分发, 使其尽可能贴近用户, 从而减少边缘网络的冗余, 同时能避免将过多视频请求重定向到ISP网络之外的代理服务器上。

尽管NFV可减少设备开销, 缩短设备开发周期, 提高可扩展性、灵活性和敏捷性, 但要从现有静态、无弹性的传统网络迁移到基于NFV的新型网络架构仍面临较多挑战。软件定义网络(Software-Defined Network, SDN)^[7]提供了一个可扩展的智能框架, 能在虚拟或物理基础设施上动态部署基于NFV的网络功能^[8]。OpenFlow^[9]是首个实现SDN原理的平台, 提供了相应的接口来使能控制平面和数据平面之间的交互。

在此基础上, 本文设计一个支持网内缓存且可完成高效视频内容分发的软件定义VoD系统, 能实现从距离用户最近的网络节点完成内容交付, 以降低传输时延及流量冗余, 并提高QoS和QoE。

1 相关工作 1.1 基于NFV的CDN和网内缓存

通过NFV可以改进传统CDN服务。文献[10]在CDN场景下, 设计基于NFV和云计算的虚拟节点和应用, 从而通过较小的代价实现有效的内容分发。文献[11]利用OpenStack设计多媒体传输框架, 基于NFV构建CDN来提高服务质量。上述研究虽然取得了一定的优化效果, 但是终端用户和代理服务器之间的冗余流量仍未被消除。

网内缓存技术可减少重复流量。文献[12]在网内缓存场景下引入资源管理的概念, 在减少冗余的同时可使资源得到更有效的利用。文献[13]利用CCN/NDN网络的网内缓存能力, 根据特定的内容缓存策略来预缓存MPEG-DASH编码的视频片段。上述研究较传统基于代理服务器的缓存架构有明显的性能改善, 但仍较难实现有效的全局管控, 因此需引入SDN技术做进一步性能优化。

1.2 支持SDN的视频流化和缓存管理

文献[14]利用SDN实现分层组播视频会议系统, 提高异构终端接收可伸缩视频编码(Scalable Video Coding, SVC)视频流质量, 降低时延。文献[15]提出基于SDN的DASH路由规划和码率调节联合算法来提升视频分发效率。文献[16]在SDN背景下考虑了视频多媒体服务的接入控制和路由优化算法。然而, 以上方案未将网内缓存和SDN相结合。文献[17]提出OpenCache框架以提升缓存分发效率, 但OpenCache节点部署在网络边缘的独立服务器上, 而本文提出的网内缓存是集成在OpenFlow交换机中, 视频流传输不需要遵循端对端原则。

1.3 缓存置换策略

传统缓存系统有许多经典的内容置换算法, 如最近最少使用(Least Recently Used, LRU)算法和最低频率使用(Least Frequently Used, LFU)算法均得到广泛应用^[18]。文献[19]提出一种在线学习缓存置换方法, 学习视频随时间变化的流行度并预测其变化趋势。以上算法尽管都在不同程度上达到性能改善的目的, 但都需要缓存整个视频文件, 且视频流行度预测准确度有待提高。

文献[20]考虑利用最近的用户行为信息预测将来的视频片段请求, 提出不同匹配度水平下的2种视频片段缓存策略, 以提高缓存命中率和降低带宽消耗。文献[21]扩展了文献[22]中为处理多媒体服务系统中混合负载而提出的间隔缓存策略, 本文在此基础上提出针对支持网内缓存的SDN视频流化系统, 设计变长间隔缓存策略, 以降低冗余流量和提高资源利用率。

2 SDN多媒体流化构架 2.1 系统构架

如图 1所示, 本文多媒体流化系统针对内容提供商在ISP的小规模边缘网络上部署服务的场景进行设计。该系统由OpenFlow控制器、多媒体流化服务器(Media Streaming Server, MSS)、管理服务器(Management Server, MS)、OpenFlow交换机和终端组成。图 1中带箭头虚线表示从流媒体服务器发出的源视频流，而带箭头实线表示从节点缓存中流化出的缓存视频流。由于SDN具有中心控制管理、信息收集及状态监测能力, 且可以支持网络节点和上层应用之间的协作, 因此本文系统基于SDN架构进行设计。支持缓存的软件定义多媒体流化系统架构如图 2所示。

在MSS上有全部视频内容, 还部署了视频服务应用来接收用户请求并为每个会话产生实时传输协议(Real-time Transport Protocol, RTP)视频流。其基本功能是提供VoD服务(视频内容管理和RTP流化)。相应地, 终端上会有视频播放器触发请求, 接收视频流并解码播放。MS像整个系统的大脑, 从交换机获得拓扑、缓存分布和连接状态信息, 并运行特定的缓存策略, 指导数据缓存和视频流化。OpenFlow控制器负责根据MS的决策控制交换机动作。路由管理模块和事件管理模块使得MS能控制交换机来推送、缓存和流化视频。Cache是集成在交换机内的网内缓存。交换机可以进行文件管理和内容传输, 具备本地缓存管理、链路状态监测、RTP数据处理的能力。LCM支持基本的文件操作来缓存视频流, 并提供关于链路状态及缓存分布的信息作为事件周期性地上传到OpenFlow控制器, 再交给MS分析处理。部署在交换机中的RTP^[23]工具支持RTP数据缓存、读取输出和发送RTP流到终端。为使得OpenFlow控制器能实现网内缓存管理和内容传输的功能, 本文分别定义了新的与存储管理和视频流化相关的事件来扩展OpenFlow协议。位于传输路径上的交换机可以复制和缓存相应的RTP视频, 使得被请求过的高热度内容能够遍布全网。当后续的用户发起相同的内容请求, 可以直接从网络节点上获取内容, 间接降低了MSS的负载。为高效地利用缓存, 需要一个有效的针对SDN网络场景视频流化服务的缓存管理策略。本文将采用间隔缓存技术优化视频流的网内缓存, 而非缓存整个视频对象。

2.2 变长间隔缓存技术

变长间隔缓存策略中的数学符号如表 1所示。交换机中的缓存由MS中的全局缓存管理模块控制, 由其发出缓存特定视频流的指令后, 交换机会创建一个本地文件缓存RTP数据包。变长间隔缓存窗口作为缓存的基本单元, 其机制如图 3所示, 其中, R_{i, j}表示第i个视频的第j个请求，L_{i, j}表示第i个视频的第j个窗口的长度。

整个视频文件被当作一个固定长度的时间轴, 被交换机缓存的部分则是在视频时间轴上滑动的一定长度的窗口。由于窗口尺寸调整的粒度为GoP, 比窗口长度的典型值小多个数量级, 因此可忽略视频编码带来的影响, 而合理地假定窗口长度仅取决于视频请求的到达模式, 即到达时间的概率分布。同一窗口中的视频请求会重复利用上游交换机中的同一个视频流, 即在时间域上聚集冗余的视频流量。此外, 值得注意的是间隔缓存技术仅缓存窗口中的视频流量。

MS中的全局缓存管理模块控制交换机中的缓存。基于图 4所示的链表和STL图动态地维护存储的组织结构。

图 4包含视频对象和窗口的匹配关系。视频对象列表包括若干C_i, 一个对象C_i与一个包含W_{i, j}的窗口列表相关, 而W_{i, j}与不同的交换机相关。一个W_{i, j}包含一个请求列表R_{i, j}^k, k=1, 2, …, K_{i, j}, K_{i, j}为窗口的请求总数。每个窗口有一个记录, 包含Window ID、Content ID、交换机标识(DPID)等。此外, 开始时间、长度、请求数量和平均到达间隔时间都是窗口对象的属性。

2.3 基本操作流程

用户触发一个视频请求, MSS解析后提取用户的IP地址、视频ID和到达时间发送给MS。MS的用户管理模块基于与IP地址相关的用户ID鉴定用户, 并授权对视频服务的接入。对授权用户, MS使用OpenFlow控制器的链路状态与全局缓存管理模块的缓存分布信息共同确定最优的内容传输路径。一旦确定, MS将把所有的行动映射为交换机中可执行的指令, 更新全局的缓存信息。交换机接到指令后会开启新进程传输RTP包, 除非缓存未命中, 此时继续由MSS提供内容。

在被请求视频的传输路径的节点上对其进行缓存, 并根据本地热度相应地自适应调整缓存长度。如果有新的用户请求相同的内容, 则优先在最近的网络节点上查找是否有相应的缓存。如果有, 则直接从该节点取回视频内容, 实现同一份视频缓存的异步复用, 提高缓存资源利用率; 如果没有, 则继续从源服务器取回内容。

3 基于变长间隔窗口的网内缓存策略 3.1 状态机

假定一个如图 5所示初始长度为T的缓存窗口W_{i, j}中有n个请求到达, R_{i, j}ⁿ为最后一个到达的请求。定义I_{i, j}^k为第k个(连续2个到达的请求之间)的间隔时间。

$ I_{i, j}^{k}=\left\{\begin{array}{l}{\infty, k=n=1} \\ {T_{i, j}^{k+1}-T_{i, j}^{k}, 1<k<n} \\ {T+T_{i, j}^{1}-T_{i, j}^{n}, k=n>1}\end{array}\right. $

(1)

如果n=1, 则I_{i, j}¹被指定为∞, 即没有间隔存在。最后一个请求到达时间和时间区间结束点之间的间距被称为等待时间, 即为等待下一个请求的时间。另外, 定义$ \overline{I}_{i, j}$为缓存窗口W_{i, j}的平均到达间隔:

$ {{\bar I}_{i, j}} = \left\{ {\begin{array}{*{20}{l}} {\infty , n = 1}\\ {\sum\limits_{k = 1}^{n - 1} {I_{i, j}^k} /(n - 1), n > 1} \end{array}} \right. $

(2)

如果在时间区间T中只有一个请求到达, 则不存在平均间隔时间, 设置为∞。$ \overline{I}_{i, j}$越小意味着对视频的访问越频繁, 所以I_{i, j}^k序列或$ \overline{I}_{i, j}$序列刻画了视频的流行度和当前的用户请求模式。

本文用状态机来描述一个缓存窗口的生命周期。如图 5所示, 定义缓存窗口的3个状态:1)Building态。一旦有一个请求到达, 如果没有包含需要的缓存片段的缓存窗口存在, 则会初始化一个长度为T的初始缓存窗口, 其大小在“冻住”以前可调。“冻住”是指该窗口不再接收新的视频请求。在缓存窗口“冻住”以前的状态称为Building态。如果被请求的对象没有缓存窗口, 则分配第1个下标为1的缓存窗口, 后续创建的缓存窗口下标依次增加。2)Moving态。在缓存窗口冻住后, 进入Moving态。缓存窗口随着视频对象的流化进程在时间轴上移动。需注意Moving态下缓存窗口的大小只会在提前终止或类VCR操作^[24](暂停、前进、后退等)发生时发生改变。3)Releasing态。当对应缓存窗口中第1个请求的视频会话进行到视频流的终点时, 缓存窗口进入Releasing态。

3.2 变长间隔网内缓存策略

一个缓存窗口的所有请求会被分派到同一个交换机中以重复利用缓存中的同一个数据块, 从而降低冗余的网络流量。当第i个对象的用户请求到达时, 如果包含所求视频片段的缓存窗口在Building态, 且相应的交换机有输出视频流的可用带宽, 则该请求就被安排到最优的交换机中, 从而得到最短的传输路径。传输路径上的每一个没有该缓存内容的交换机都要创建一个初始长度为T的新的缓存窗口; 否则, 该请求就被安排到MSS中建立新的RTP会话。同样地, 此时传输路径上的每个交换机也都会创建一个长度为T的新的缓存窗口。

下文讨论缓存窗口大小的调整。在创建一个缓存窗口时, 会分配一个初始的长度T并开始一个三阶段的生命周期。在这些阶段中, 缓存窗口长度会根据以下规则进行调整, 如图 6所示。

为防止缓存窗口过大, 缓存窗口的尺寸由一个上界T_max限定。会话结束也可能导致缓存大小的调整, 包括2种不同类型的进程结束, 完成后结束和提前结束。完成后结束时会话在视频流末端结束, 可以根据Releasing态结束进行处理。对于提前结束的情形, 后来的请求可能比前面的请求结束得还早, 此时缓存窗口大小的调整就需要特殊的处理机制。不失一般性, 本文仅讨论Moving态的缓存窗口调整规则, 其他2个状态可以进行类似推导。

考虑处在Moving态的缓存窗口W_{i, j}有连续的请求R_{i, j}¹, R_{i, j}², …, R_{i, j}ⁿ, 如果请求R_{i, j}^k(1≤k≤n)的会话先于其他会话结束, 则缓存窗口的大小调整遵循以下原则:1)如果R_{i, j}^k处于缓存窗口的中间, 即1 < k < n, 在同一个缓存窗口中有前后请求, 则缓存窗口保持目前状态并移除R_{i, j}^k。2)如果R_{i, j}^k处于缓存窗口的头部, 即k=1, 则移除R_{i, j}¹; 如果该请求是缓存窗口中的唯一请求, 则删除该请求后该缓存窗口也被销毁; 否则该窗口的头部会收缩到R_{i, j}², 且R_{i, j}¹和R²_{i, j}之间的区间会被移除; 3)如果R_{i, j}^k处于缓存窗口的尾部, 即k=n, 从请求队列中删除R_{i, j}ⁿ, 且缓存窗口的尾部收缩, R_{i, j}^n－1成为最后一个请求。

算法1  基于最短路径的视频传输算法

输入  被请求的视频C_i, 视频C_i的第j个缓存窗口W_{i, j}, 缓存窗口W_{i, j}所处OpenFlow交换机的ID号N_{i, j}, 请求用户和交换机N_{i, j}之间的跳数h_{i, j}, 交换机N_{i, j}维护的并行会话数目m_{i, j}, 从源媒体服务器到请求用户的跳数h₀, 单个交换机可以维护的最大会话数M, 获得的被请求视频的缓存窗口集合W(i)

输出  最优传输视频的缓存节点N^*

初始化   W(i)=ϕ, h_min=h₀, m_min=M

1.for all W_{i, j}∈C_i do

2.if W_{i, j} is in Building State and m_{i, j} < M then

3.W(i)=W(i)∪{W_{i, j}}

4.if h_{i, j} < h_min then

5.h_min=h_{i, j}

6.end if

7.end if

8.end for

9.if W(i)==ϕ or h_min==h₀ then

10.N^*= Media Streaming Server

11.else

12.for all W_{i, j}∈W(i) do

13.if h_{i, j}==h_min and m_{i, j} < m_min then

14.m_min==m_{i, j}

15.N^*=N_{i, j}

16.end if

17.end for

18.m_{i, j}=m_{i, j}+1

19.end if

20.return N^*

经过以上步骤, 缓存窗口参数如$ \overline{I}_{i, j}$应立即更新。对类VCR操作的情形则更复杂。由于请求的相对接入位置会变化, 也导致相应缓存窗口的状态变化, 因此需要扩展上述缓存策略来支持类VCR操作, 例如暂停和继续播放。特别地, 暂停操作和提前终止的情形类似, 而继续播放和跳转会被当做接收到新的请求。于是, 变化的请求会被分配给一个合适的缓存窗口(可能不同于原来的缓存窗口), 最坏的情况是被重新安排给MSS。结束类VCR操作后, 需要注意的是所有相关的窗口状态也要相应更新。

3.3 最短路径传输策略

除了要讨论交换机中的缓存策略, 本文还需选择合适的交换机传输视频内容。将算法1应用在本文提出的软件定义视频流媒体系统中。具体来说, 该轻量级算法联合考虑了缓存窗口状态、交换机吞吐量和网络拓扑信息来选择一个最优的交换机节点作为视频源实现就近服务。

算法1的第1行~第8行是搜索可用的交换机, 第12行~第17行是搜索离用户最近且能达到负载均衡的维持最少会话连接数的交换机。一旦根据算法1得出最优交换机或源服务器, 传输路径上的交换机就需要创建新的窗口来缓存视频流。

4 原型系统实现

为验证本文系统设计的有效性, 建立一个SDN实验平台来搭建如图 1所示的变长网内缓存的多媒体流系统。选择OpenFlow交换机作为NFV硬件。32 GB内存的Kingston’s DataTravalerSE9G2作为外部USB闪存来提供视频缓存能力, 每个交换机安装有RTP工具。选择POX^[25]作为轻量级的OpenFlow控制器, 在一个有3张网卡的Linux服务器上运行, 第1个NIC连到一个标准的24端口TL-SG1024DT交换机, 该交换机再连接到所有OpenFlow交换机的WAN端口, 从而构建一个out-of-band控制平面网络。第2个NIC连接到MS来共享网络和缓存信息并接收控制信息。OpenFlow控制器的模块也在POX中实现。原型系统的网络拓扑按图 7所示的网络拓扑进行搭建。

MS也在一个有2块NIC的Linux服务器上实现。一块连到OpenFlow控制器来构建控制平面, 另一块连到MSS。MSS是一台安装了VLC 2.0.8媒体播放器的Linux服务器, 作为RTP流化模块来封装数据到RTP/UDP中。本文还构建了不同端口的多UDP socket来流化视频数据给用户, 使得交换机能识别特定请求的数据。终端用Linux客户端实现, 在其上同样部署有一个VLC媒体播放器来解码收到的RTP流并播放视频。

基于以上原型系统研究本文提出的变长间隔缓存窗口(Variable-Length Cache Window, VLCW)算法性能, 并与其他广泛应用的调度算法相比较, 如LRU, 其被认为较适合CDN和ICN网络。考虑2种不同形式的LRU, 即NNC+LRU^[26]及其简单变形Rdm+LRU^[27]算法。对NNC+LRU而言, 内容传输路径上的所有节点都会按照LRU算法尽可能地缓存数据包, 而Rdm+LRU则只随机选择一个有足够缓存空间或可置换目标的节点。这2种缓存置换算法在SDN场景下的性能要优于其在传统CDN缓存架构中的情况^[10], 因此后续实验不再与CDN网络作对比。

在对比实验中, 本文考虑有限的网络带宽和硬件性能的情况。请求到达率λ设置为2请求/min, 且视频片段的长度设置为10 min。使用服务器的实时吞吐量、当前整个网络中同时发生的RTP流的实时数量、从各个缓存节点传输过来的实时RTP会话数量来研究已实现的原型系统性能。

图 8显示同样条件(请求序列、存储空间等)下3种算法的比较结果。图 8(a)表明VLCW算法在大部分时间内具有最低的吞吐量, 即有最少的请求需要由服务器响应。相较于2种对比算法，VLCW的平均服务器负载下降了50%。本文将属于同一个RTP会话的不同物理链路上的数据流作为不同的流来量化整个网络的带宽消耗。图 8(b)表明VLCW算法有最少数量的RTP流, 即其消耗了最少的带宽。图 8(c)说明了VLCW算法中被请求的视频有更大的概率从缓存节点获得, 即其有更高的缓存命中率。

5 仿真及性能评估 5.1 评估指标与仿真环境

为全面评估本文算法的性能, 采用的测量指标如表 2所示。本文使用Mininet 2.2.1 ^[28]来创建一个符合实际场景的虚拟SDN网络。选择一棵深度为4(服务器除外)的完全4-叉树作为网络拓扑进行仿真, 如图 9所示, 包括1个服务器、21个交换机、64个客户端。假定到达服务器的请求服从Poisson分布, 平均到达率为λ, 且视频对象的热度服从类Zipf分布^[3]。

5.2 仿真结果 5.2.1 请求接入速率

实验1  研究不同请求接入速率λ条件下的VLCW性能, 结果如表 3所示。实验结果表明, VLCW在视频请求接入速率较大的情况下显著优于其他2种算法, 说明其缓存视频内容的复用率更高。这得益于其基于视频片段的缓存算法在缓存空间有限的情况下可以缓存更多种类的视频内容, 达到更高的缓存命中率和缓存利用率。在λ较大的情况下, 相对于其他2种算法的优势更明显。随着λ的逐渐增大，VLCW的缓存空间利用率提升了3倍~5倍。

5.2.2 视频数量

实验2  研究不同视频数量N下的VLCW性能。λ值固定为20请求/min, N的范围为5~25, 实验结果如表 4所示。实验结果表明, VLCW在缓存资源利用率r_cache上比其他算法优越。对于r_cache和η, 其他2种算法在N较小时也能达到较好的性能, 因为视频请求集中在小部分视频内容上。然而, VLCW在视频数量增加时仍能获得较好的性能, 因为基于小颗粒度视频片段的缓存算法能够更高效地利用缓存资源。

5.2.3 缓存空间大小

实验3  研究单个交换机的缓存空间M下的VLCW性能。缓存空间在整个视频大小的1倍~5倍范围内变化, λ和T值都与实验2中一样, N设置为20, 实验结果如表 5所示。结果表明, 当M增大时, NNC+LRU和Rdm+LRU都能获得显著的性能提升, 但是缓存效率仍保持较低的增长趋势, 即视频缓存总长度的增长相对较快。而对于VLCW, 所有3个指标都几乎保持不变, 这意味着VLCW可以在降低冗余流量和节省存储资源方面获得更好的性能。

6 结束语

为减少VoD服务引起的冗余流量, 本文设计一种具有网内缓存的软件定义多媒体流化系统, 并提出一种变长间隔的缓存算法, 提高存储资源的利用率和视频流的聚合效率。在此基础上, 搭建一个原型系统来验证该算法的可行性和有效性。为全面评估所提算法的性能, 本文定义了流化效率、缓存效率和效率因子等性能指标, 并将VLCW算法与已有的NNC+LRU和Rdm+LRU算法进行对比实验。结果表明, 在VLCW算法的优化下, 服务器负载下降了50%, 缓存空间利用率提高了3倍~5倍。由于VLCW算法仅适用于VoD系统中的RTP视频流化, 因此下一步将研究网内缓存在其他应用场景下的优化算法, 例如超清视频直播、VR视频点播等, 通过缓存减少此类高网络资源需求应用的带宽消耗, 提升服务质量。