[YuxuanYi Notes] CS2P – Throughput Prediction

2017-11-11

Posted by 易宇轩

Motivaion:

如何提高视频比特率初始选择和自适应的准确度?

先前的工作认为,一个好的吞吐量预测器是几个现有的比特率自适应算法的必要组成部分(例如,[30,45,47],可以参见8 Related Work)

Problem:

问题转化到,如何做到准确的吞吐量预测?

Idea:本文的贡献:

1、分析20M +会话数据集中的吞吐量特征

*使用的是中国领先的商业视频提供商iQIYI [8]的大数据集

2、开发了一个吞吐量预测系统CS2P,它使用数据驱动的方法学习

(a)采用一种简单的方法来预测初始吞吐量,方法是使用该集群中会话的中位吞吐量。

(b)利用过去视频会话的观察吞吐量,使用HMM建模吞吐量随时间的变化。

 

 

 

HMM:通过已知的观察值序列,求隐状态序列,这需要:

1、初始概率分布(隐状态的初始分布)

2、转移概率矩阵(隐状态之间转移)

3、发射概率矩阵(已知隐状态,它到观察值的概率,即P(观察值|隐状态))

为什么能用HMM呢?

如果将时间分槽(本文记录的是每6秒的平均吞吐量;把这个时长称为“epoch”)

(a)吞吐量可以看成是离散的序列。下列observation说明,吞吐量在一段时间内是相对稳定和持续的,但偶尔会切换到不同的状态并持续到新的状态。

(b)网络状态可以看成是离散的序列。

(c)数据稀疏问题:下列observation说明,相似的会话有相似的吞吐量pattern。聚类相似的会话,得到的数据是足够的。

(d)所以可以用HMM。观察值是当前epoch的网络状态,隐状态是吞吐量

 

 

 

贡献1,特征分析:

1、吞吐量总体是有变化的。

“我们计算变异系数,其定义为会话内不同测量的吞吐量的标准偏差(“stddev”)与吞吐量测量的平均值的比率。结果显示,大约一半的会话的标准化stddev≥30%,20%以上的会话的标准化stddev≥50%。”

2、时间相关性

“我们看到吞吐量在一段时间内是相对稳定和持续的,但偶尔会切换到不同的状态并持续到新的状态。”参见图4a

3、空间相关性

“共享类似关键特征(例如,相同的ISP,地区)的会话呈现相似的初始、平均吞吐量值和动态模式。”

4、简单模型(例如last-mile的特征)不足以捕获会话相似性

只用它来预测的话,预测的误差很大。看来,“会话特征具有显着的多样性,并且会话特征与吞吐量之间的关系可能相当复杂。”

 

 

 

贡献2,CS2P的具体实现

 

1、如何聚类相似的会话?

从所有可能的特征组合(即n个特征的2^n个子集,候选会话特征如表2所示)和时间窗口中选择一组给定特征Ms。一旦Ms特征集合被选中,CS2P就会基于Ms集合先前的会话。例如,给定Ms = 1小时,CS2P将聚合所有先前在同一个ISP=s、并在最近1小时内发生的会话。这组会话用Agg(Ms, s)表示。

如果Ms使Agg(Ms, s)小于阈值数量(例如100),则会移除该会话群集。注意,如果不能实现合适的聚类,该模型可以回归到“全局”模型(即,用以前的所有会话进行过训练的模型)(7The probability of sessions using global model in our dataset is ≤4%. )

 

2、如何自动训练模型?

跟普通的HMM一样,训练-预测

HMM模型的训练是离线的、预测是在线的。

*离线算法就是知道了所有的输入,根据某些条件来选取最佳策略,而在线算法就是无法预知到后面的输入,只能按照目前的状况来做出下一步的最好决策,由于你永远不知道下一步会怎样,只能根据过去来猜测。一旦走错了,就无法再重来。

 

3、如何利用这些模型进行吞吐量预测和比特率适应?

CS2P在哪里工作呢,服务器、客户端还是控制层?

(Coordinated Internet Video Control Plane一文也讨论了这个问题)

客户端和服务器端都有基于吞吐量的比特率自适应算法,CS2P也给两者都提供了解决方案。

(a)在服务器端解决方案中,中央服务器需要从所有客户端收集吞吐量测量结果,并为每个视频会话计算比特率,这是一个潜在的瓶颈。

(b)比特率适应也可以由每个视频客户端完成。在这里,每个视频客户端从预测引擎下载自己的HMM和初始吞吐量预测,并运行实时吞吐量预测模型和自身的比特率自适应。(分布式的优势是客户端通常能够快速检测性能问题并响应动态。缺点是它需要客户端维护自己的HMM。)