问题背景：
现如今，视频直播具有以下特点：
- 需求量巨大，预计今年高峰期视频流速率可达50Tbps;
- 用户众多，如Twitch上每月都有5千5百万用户在观看直播视频；
- 直播视频总类繁多：
1）类别按照制作类型可分成专业制作（professionally-produced）和用户上传(user-generated)两大类视频直播；
2）按照工作量来分类：则可分成重大热门事件视频直播（mega-events）和较小众但有一定市场的视频直播(long-tail)
问题描述：
现如今种类繁多且流量巨大的视频直播传输给现有的内容传输基础设施带来了巨大的挑战；除了该挑战之外，如何有效的满足用户（user）、CDNs和网络运营商的额外要求也是一大挑战。其中，
- 用户的要求是：高质量（high quality）的视频、较短的视频播放时间（instant start-up （join）times,）较低的缓存时间；
- CDNs的要求是：在满足用户的要求的同时希望能够将传输费用最小化和能够及时对问题进行响应；
- 网络运营商的要求：控制时延的差异化和解决通信故障。
问题的现有解决方案及其不足点：
- 流量管控（traffic engineering）
- 不足点：现有的流量管控系统只是在较粗的时间段（coarse timescale）内对流量进行管控，不能在较小的时间段内（fine timescale）满足用户对视频高质量的需求，以及CDNs快速的故障恢复控制要求。
- overlay multicast system：
- 不足点：it focuses on individual stream optimization, but overlooks issues that arise with the many concurrent, independent, high-bandwidth streams in today’s environment.
- Internet-scale,video-specific systems use client-aside analytics to pick the best CDN for a given client at a given time but ignore the actual data delivery.
- 现有的CDNs已经能提供了较高的视频质量，但研究表明，若能够在CDNs中建立一个集中式的视频管控算法，则可以更好的提高用户的体验。然而，集中式控制算法因为不能够在广域网中对网络故障进行快速的响应，使得集中式算法未被现有CDNs所采用。
本文工作的主要目的：
主要目的有三个：
- 第一个目的(quality/cost tradeoff)：主要在CDNs中对基于HTTP的直播视频传输进行优化，使得在满足用户对高质量直播视频要求的同时尽量降低网络传输费用,即trade-off between high quality service for users with video delivery cost.
- 第二个目的：可拓展性（scalability），即能满足不同类型直播视频的传输要求，即mega-events类、long-tail类等
- 第三个目的（fine timescale/ responsiveness）:即在广域网中能够提供较快的播放速度（fast join time）和快速的故障恢复速度（fast failure recovery）
本文的工作：
为达到上述目的，本文提出了一个视频传输网络系统（VDN）,即一个集中式控制算法和分布式控制算法混合使用的系统。
其中，集中式算法是一个对quality/cost tradeoff进行0-1整数规划（目标函数是对quality最大化和Cost最小化这个双目标，分别乘上两个权重系数进行平衡）；而由于集中式算法需要采集整个网络的链路状况信息和全网中的请求分布情况，并且定期地更新，所以如上文提到的，集中式算法不能满足在fine timescale内提供fast join time and fast failure recovery。
所以为弥补这一不足点，本文又提出了一个分布式的算法，该算法实质上是一个距离矢量算法，即在满足基本的链路带宽要求前提上，选择一条到视频源最近的路径。因为该分布式算法只需要节点采集与自身相连的链路信息和本地的视频请求量信息，所以可以提供fast join time and fast failure recovery。
那么，集中式算法和分布式算法如何协调使用呢？
由于集中式算法是对全网进行了优化，所以在网络没有发生故障的情况下（如节点、链路或者控制器发生故障），节点都使用集中式算法计算出来的结果进行为用户请求的转发选择最优路径。而当节点在本地上判断出相邻节点或链路发生故障，而集中式算法未能及时更新结果时，以及本地节点的FIB上还没有该请求的表项时，则本地节点使用分布式算法计算出来的结果进行转发。