Lumos: towards Better Video Streaming QoE through Accurate Throughput Prediction

基于HTTP的视频流（DASH标准）目前占互联网流量的大部分。在DASH系统中，每个视频被编码成具有相同内容但不同平均比特率（即质量）的多个版本。然后将每个版本的视频分割成具有相同持续时间（通常为2-10秒）的块。视频客户端运行自适应比特率（ABR）算法，根据网络容量和客户端缓冲区占用情况选择下一块的比特率，以最大限度地提高体验质量（QoE），包括最大限度地提高视频质量和最小化缓冲时间和比特率切换。

大多数ABR算法使用吞吐量预测来估计网络容量。最近的工作提出可以通过预测视频块的交付时间以获得更好的QoE。自然，ABR算法中的预测出现了两个关键问题：

输入特征：哪些因素有助于实现更好的预测？

以吞吐量为例，应用程序感知的吞吐量受网络条件和应用程序行为的影响。传统的视频流吞吐量预测，无论是基于history-based还是learning-based，都只将吞吐量波动视为网络条件的变化引起的。最近的工作开始将块大小考虑到预测中。然而，块大小不能代表应用程序的全部行为，例如还有ON-OFF 阶段。此外，以前的工作都没有研究所有可能的影响因素是如何准确地影响吞吐量的。
输出目标：吞吐量和交付时间中哪一个是更好的预测目标？

由于吞吐量和交付时间可以在给定块大小的情况下相互转换，因此这两个指标在表示网络容量时被视为相同的。然而，虽然吞吐量与比特率选择相对应，但交付时间直接用于计算QoE，直观感觉上应该将交付时间视为ABR算法更有效指标。之前没有对这两个指标进行定量比较的工作。

background

图1显示了影响吞吐量和块交付时间的所有影响因素，以及它们之间的关系。由于交付时间可以根据给定块大小和应用程序吞吐量计算，因此影响吞吐量的因素必然会影响交付时间。因此，我们关注直接影响应用程序吞吐量的所有因素。应用程序吞吐量由可用带宽决定。块的吞吐量等于块大小除以交付时间。交付时间是从发出请求的第一个字节到收到响应的最后一个字节的持续时间。可用带宽等于链路容量减去背景流量，链路容量进一步取决于链路的物理属性、流量管理和服务器与视频播放器之间的连接状态（例如，ISP，AS、CDN层、连接类型和信号强度）。至于由服务器的cwnd控制的交付速率，本质上取决于可用带宽和应用程序行为。

on-off阶段是视频流的独特行为，表明播放器定期请求块，而不是在启动后连续请求。在播放器不活动期间（即off期间），播放器和服务器之间不会传输任何数据。如果不活动时间超时（Linux中为200ms），服务器将cwnd重置为初始大小（例如10mss），并返回到慢启动阶段，即慢启动重启。由于应用行为和传输机制的原因，视频播放器的请求模式可以分为两种状态[12]：缓冲状态，其中cwnd在后续块中不断调整；稳定状态即慢启动的重启。

motivation

对于现有的ABR算法和广泛部署的视频服务，ABR选择的比特率和可用带宽之间存在很大差距。作为一个例子，本文给出了一个经典ABR算法（RobustMPC）的真实案例，以说明不准确的吞吐量预测如何损害QoE。图2a显示，如果一个区块的实际吞吐量突然下降（在第81个区块），RobustMPC预测的下一个区块的吞吐量也将下降；但是，当块的实际吞吐量在未来（从第82个块）上升时，预测的吞吐量无法及时做出反应。虽然实际吞吐量足以达到最高比特率（图中未显示），但RobustMPC为3个连续块选择较低的比特率，导致不必要的视频质量降低和波动，从而降低QoE。

人们通常将图2a中吞吐量的暴跌归因于网络带宽的波动，并认为吞吐量很难预测。这在一定程度上是由于混淆了应用程序吞吐量和可用带宽。然而，如图1所示，在大多数现有预测方案中，忽略了影响吞吐量的许多因素。例如，如图2b所示，吞吐量的变化趋势似乎与块大小相同（说明可用带宽还挺大的，但是算法都过于保守了？？？）。这表明，应用程序感知吞吐量的变化可能不像以前那样受网络条件的支配。虽然视频流的吞吐量预测已经得到了广泛的研究，但对这个问题仍然缺乏深入的理解，这也是我们在本文中工作的动机。

PREDICTION FACTORS

Factors that Impact Throughput Prediction

吞吐量和每个考虑因素之间的互信息如图3所示。请注意，互信息没有上限。

观察1：前一个区块的吞吐量和目标区块大小是吞吐量预测中最重要的两个因素。

以前的工作只考虑过去的吞吐量样本，由于忽略了目标块大小，无法实现准确的吞吐量预测。这一结果将应用程序吞吐量与可用带宽区分开来，因为前者随块大小的不同而不同。虽然其他因素对直接预测吞吐量的贡献较小，但我们认为，将它们结合起来可以提高预测精度，这将在下一小节中进行研究。

Correlation between Throughput and Chunk Size

以前的工作已经提出应用程序吞吐量与块大小相关。为了研究这种关系，我们使用最大信息系数（MIC）计算吞吐量和块大小之间的相关性，并发现这种相关性受到客户端播放器状态、比特率水平和网络条件的影响。

观察2：吞吐量和区块大小之间的相关性受到播放器状态、相对区块指数和客户端信号强度的深刻影响。

1）播放器状态：为了研究播放器状态对相关性的影响，我们只关注最佳网络条件下的数据，即在具有50Mbps下游带宽的强信号强度下，其中网络容量足以以最高比特率传输数据。图4a显示了稳态下的相关性高于缓冲状态下的相关性。这是因为steady-state下的cwnd从初始值开始增加，在触发拥塞之前，块越大，cwnd越大，因此吞吐量越高。

我们进一步分析了缓冲状态下relative chunk index对相关性的影响。图4b显示，相关性随着relative chunk index的增加而降低。这是由于后续块不断增加cwnd和交付速率，最终达到缓冲状态结束前的可用带宽。

2）比特率level：图5a表明，相关性随着比特率的增加而降低。原因与上述类似：高比特率的块大小足够大，cwnd可以提升到较大的大小，使得服务器的交付速率达到可用带宽。因此，拥塞事件阻止了应用程序吞吐量继续随区块大小的增加而增加。3）网络条件：我们在不同的网络条件下进行测试，以研究流量策略和信号强度对相关性的影响。

3）服务器的下行带宽：我们将服务器的下行带宽分别限制为50Mbps和5Mbps，并在图5b中显示了流量策略对相关性的影响。我们发现，低下行带宽下的相关性远低于高带宽下的相关性，因为在低下游带宽下交付区块更容易受到流量策略（例如令牌桶）的影响。

4）客户端的无线信号强度：图5c显示了信号强度对相关性的影响。当信号强度变弱时，相关性相应变小。为了解释这一观察结果，我们分析了tcp probe从传输层收集的数据，发现当信号强度较弱时，平滑RTT对于较大的块（尤其是较高比特率的块）往往更长，这直接导致传递时间增加，并进一步降低吞吐量。

LUMOS: DESIGN AND IMPLEMENTATION

Design Choice

作为ABR算法的预测器，Lumos旨在建立输入特征和输出预测之间的一种映射。为了实现这一目标，在设计Lumos时会出现两个问题：

1）映射函数：哪个模型更适合预测视频流中的吞吐量？

最先进的映射函数是通过数据驱动方法构建的，包括三个现成的模型：多元线性回归（MLR）、决策树和深度神经网络（DNN）。虽然DNN有资格精确建模复杂的行为，但之前的研究表明，它们很重，缺乏可解释性、，因此很难设计和部署。相反，最近的工作显示了决策树对于复杂策略的丰富表达性和高解释性，证明了决策树简单但功能强大，足以适应复杂的预测函数。因此，我们开发了基于决策树的预测器，以及用于比较的MLR。

2）输出目标：吞吐量和交付时间中哪一个是更好的预测目标？

给定区块大小，两个目标中的每一个都可以直接从另一个计算。以前的大多数工作利用预测吞吐量来选择比特率，而最近的工作提出交付时间是一个更好的选择。

为了研究这两个问题，我们分别为每个预测目标开发了基于决策树和MLR的不同预测器，并评估其预测性能。

观察3：吞吐量预测比交付时间预测更准确。

第一个问题是为什么吞吐量预测器的预测误差较低。

预测误差是衡量目标被高估或低估程度的指标。

对于交付时间和吞吐量，低估的预测误差不超过100%，而高估的预测误差可能超过100%。因此，高估是增加预测误差的关键因素。图7示出了每个视频块的预测误差的分布。交付时间预测器对更多区块的预测误差超过100%. 这一结果表明，交付时间预测值比吞吐量预测值高估更严重，导致更高的预测误差。

第二个问题是为什么交付时间预测值往往高估。我们推断根本原因是交付时间的长尾分布。如图8所示，交付时间更具长尾性。

交付时间预测器由于交付时间的长尾分布而学习更高的值，因此高估了实际值，如图9所示。相比之下，吞吐量的分布更“均匀”。因此，吞吐量预测器能够学习大多数数据的特征，避免受到异常值的影响。虽然我们可以通过离线过滤异常值来改进交付时间预测器，但我们的目标是设计一个可靠的预测器，在所有数据的分布事先未知的现实世界中表现良好。这样，预测吞吐量是一个更好的选择。

Lumos Mechanism

总结：

这篇论文的核心思想就是在ABR算法里面要区分吞吐量和可用带宽的概念，可用带宽是物理限制，而吞吐量是和块的比特率相关的。有时候吞吐量小，并不意味着可用带宽小，而是选择的块的数据量比较小。上图的特征中5,8,9是这篇文章新颖地方。