【Gang Yi’s note】A Case for a Coordinated Internet Video Control Plane

2017-11-11

Posted by 易港

Vedio deliverity逐年增加，预计将会成为network  traffic中最重要的一部分。不同于用户对传统worloads低延迟或者高吞吐率的需求，vedio user更需要持续的高bitrate服务。

这篇文章的contribution:

  • 实验并分析现有video deliverity的不足
  • 通过一个video control plane来动态进行全局优化
  • 通过推理的方式估计提升空间。

之前的工作：

Specialized streaming protocols and infrastrusture RTMP, 由于是为vedio进行的特殊的服务

，随着人们对视频流的需求增加，vedio traffic也会急剧增加。

基于HTTP进行视频传输，大大提高了视频的可获取性，因为HTTP服务的普遍性，（CDN）。但是用户在使用中遇到了新的问题，rebuffering ratio较高，start up时间长，平均bitrate低。

  • HLS，是苹果公司实现的基于 HTTP 的流媒体传输协议，全称 HTTP Live Streaming，可支持流媒体的直播和点播，主要应用在 iOS 系统，为 iOS 设备（如 iPhone、iPad）提供音视频直播和点播方案。
  • RTMP，实时消息传输协议，Real Time Messaging Protocol，是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。协议基于 TCP，是一个协议族，包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议，主要用来在 Flash/AIR 平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。

上面是这两种协议的简介，那它们在实际应用中会有什么差异呢？

HLS

先说说 HLS。HLS 的基本原理就是当采集推流端将视频流推送到流媒体服务器时，服务器将收到的流信息每缓存一段时间就封包成一个新的 ts 文件，同时服务器会建立一个 m3u8 的索引文件来维护最新几个 ts 片段的索引。当播放端获取直播时，它是从 m3u8 索引文件获取最新的 ts 视频文件片段来播放，从而保证用户在任何时候连接进来时都会看到较新的内容，实现近似直播的体验。相对于常见的流媒体直播协议，例如 RTMP 协议、RTSP 协议等，HLS 最大的不同在于直播客户端获取到的并不是一个完整的数据流，而是连续的、短时长的媒体文件，客户端不断的下载并播放这些小文件。这种方式的理论最小延时为一个 ts 文件的时长，一般情况为 2-3 个 ts 文件的时长。HLS 的分段策略，基本上推荐是 10 秒一个分片，这就看出了 HLS 的缺点：

  • 通常 HLS 直播延时会达到 20-30s，而高延时对于需要实时互动体验的直播来说是不可接受的。
  • HLS 基于短连接 HTTP，HTTP 是基于 TCP 的，这就意味着 HLS 需要不断地与服务器建立连接，TCP 每次建立连接时的三次握手、慢启动过程、断开连接时的四次挥手都会产生消耗。

不过 HLS 也有它的优点：

  • 数据通过 HTTP 协议传输，所以采用 HLS 时不用考虑防火墙或者代理的问题。
  • 使用短时长的分片文件来播放，客户端可以平滑的切换码率，以适应不同带宽条件下的播放。
  • HLS 是苹果推出的流媒体协议，在 iOS 平台上可以获得天然的支持，采用系统提供的 AVPlayer 就能直接播放，不用自己开发播放器。

 

相对于 HLS 来说，采用 RTMP 协议时，从采集推流端到流媒体服务器再到播放端是一条数据流，因此在服务器不会有落地文件。这样 RTMP 相对来说就有这些优点：

  • 延时较小，通常为 1-3s。
  • 基于 TCP 长连接，不需要多次建连。

通过NetConnection连接到FMS/Red5服务器，并实时播放服务器的FLV文件，这种方式可以任意选择视频播放点（SEEK()），并不象HTTP方式需要缓存完整个FLV文件到本地才可以任意选择播放点，其优点就是在本地缓存里是找不到这个FLV文件的。不会缓存在客户端，保密性好，其缺点就是消耗服务器资源，连接始终是实时的

Industry-standard video quality metrics

  • Average bitrate: The average bitrate experienced by a view over its lifetime.
  • Rebuffering ratio: This is computed the buffering time divided by buffering plus playing time, excluding paused or stopped time and buffering time before video start. (We use the term rebuffering ratio and buffering ratio interchangeably.)
  • Startup time: This is the wait or buffering time before a video starts to play.
  • Failure rate: This is the percentage of views that failed to start playing and experienced a fatal error during the process. In our experience, these fatal errors usually indicate CDN issues. One example is missing content that the CDN failed to populate to edge servers, and thus users cannot access the video. Another

possibility is the CDN server rejecting new connections (e.g., due to overload).

  • Exits before video start: This is the percentage of views that failed to play the video without experiencing a fatal error. There are generally two causes: (1) users are not interested in the content,

and (2) users waited too long for the video to load and lose patience.

 

通过实验得到现有vedio deliverity‘s quality并结合结果进行分析

一、实验数据

视频内容包括直播和点播流。实验收集的数据有两方面： 一方面为用户当前的网络条件（如ISP服务商、地理位置等）,另一方面包括用户的视频观看质量（重缓冲比例、比特率).。

dataset

 

二、实验结果——Video quality today

result

三、实验结果原因分析

  • Client-side variability. 对于不同的session（inter-和intra-）的不同bitrate service，计算bandwidth方差，差异较大。结论：在session建立时需要选择一个合适的biterate，另外在midstream中需要动态调整bitrate。
  • CDN variabilty across space and time: CDN的选择受制于空间位置以及时间（不同时间load不同）
  • AS under stress： 对于某些hotspot，rebuffering ratio高。将load分给CDN没有用，必须控制bitrate。

 

Framework for optimizing video deliverity

一、优化空间

需要调整的参数：比特率的调整和CDN服务商的选择

调整的时间： 视频开始时，视频流中

谁决定调整参数：用户和服务商

design space

 

希望能够通过一个control plane感知到CDN、client-side的variations动态地调整CDN，bitrate.

vedio control plane

 

评测引擎：通过用户的播放器周期性的对用户视频播放质量数据收集，并收集用户的一些会话信息，包括位置、ISP提供商。问题在于选择一个合适的粒度和评测标准，去决定一个合适的频率来发送这些报告.

性能预测：主要作用是在给定的用户在当前时间如果 选择不同的比特率和CDN会有什么样的性能差别。通过以前的数据和当前的数据结合推理预测用户的视频播放性能。

全局优化：主要是做一个资源分配，优化指标是global utility(可以是一个关于biterate, metrics, provider’s policy的函数等)有三大挑战，1 设计一个合理的工具以及政策，例如，过载的时候是限流还是为VIP用户提供更好的服务。2.优化必须够快， 来应对动态变化的网络环境。3必须确保这个优化是稳定的，并且不会有偏见和不稳定。

 

 

 

 

 

 

一个client可以实现的选择一个best CDN的approach

在实际中client不能对所有CDN和bitrate的组合进行测试，为了达到最优，作者提出了一种基于已经观察到的其他clients(特点是拥有相同的attributes:ISP,location,device,time-of-day)的性能测试结果来推测的方法。这个approach将会在performance oracle中用到。

这一节没有考虑bitrate和CDN performance.

approach分为两部分： estimation和extrapolation

  • Estimation

a: a set of values of attributes.

Sa : the set of clients sharing same attribute value a.

Sa,p: 选择同样CDN p的Sa

通过计算MEAN(PerfDista,p)来比较CDN p的优劣。

  • Extrapolation

Pa* = argminp{MEAN(PerfDista,p)} 表示当a确定时选择p性能最佳。我们拿这个来预测所有的满足a的session的最佳性能。

问题： a分的越细，拥有相同a的clients数目就越少。解决办法是提出了一个分层模型。

这一部分不是很懂。

 

这个approach比以前的方法在性能上提升了很多。

 

A practical design

这一部分主要是给了一个具体的实例。还记得我们之前提到的utility吗？这里给出了一个计算utility的公式：utility = -3.7*buffRatio + bitrate/20。通过贪心算法来最大化这个utility.

首先每一个client都会被随机分到一个CDN和一个平均bitrate。然后开始局部优化，不断增大utility.

问题：

有可能有client分配不到CDN或bitrate。我觉得可以在贪心时加限制条件，比如bitrate上限等。作者给出的解决方法是首先随机选择一些对话（这些对话不会受到优化，每一次都是随机的，总体可以优化）去观察在未进行优化情况下的工作性能。使用这些大规模的未优化的用户数据来建立一个鲁棒性的模型来进行性能预测。

 

这里为什么没有用到之前performance oracle 得到的结果？或者说performance oracle和 global optimization 的区别在哪里？

局部优化利用到了performance oracle的结果。局部优化不是通过遍历，而是通过统计结果分配最优。

Simulation

  1. Baseline: Each client chooses a CDN and bitrate at random. This can be viewed as a strawman point of comparison.
  2. Global coordination: The control plane algorithm proposed in Section 5.
  3. Hybrid: Each client is assigned to a CDN with lowest load and a bitrate by the global optimization when it first arrives, but the subsequent adaptation is only limited to client-driven bitrate adaptation, i.e., no midstream CDN switching. This can be viewed as a simplified version of what many providers deploy

today: start time CDN selection and client-side mid-stream bitrate adaptation.

这里在仿真时还考虑了global optimization以及local limitation。