Motivation：数据驱动的QoE优化可以应用于广泛的网络应用程序类优化
引用了一些paper的工作来论证，也包括自己以前做的中继选择那篇
Problem：基于预测的机制是不完全的，问题出在数据驱动上
“（1）遭受许多已知的干扰；例如，不完整的可见度。”（意思是训练出了参数后，只按参数计算出唯一的最优解，而没有尝试次优解）
在中继选择那一篇里面，这个问题不是靠先选出Top n作为备选集来解决的吗？
“（2）不能应对突然的改变（例如，负载的改变）。”
上次的idea是，这意味着连续的数据可以归为离散的状态，从而选择搞HMM
Idea：
（1）在第2节中举了两个例子说明了：不该用预测算法（训练与预测完全分离）
因为：1、测试集可能不具备代表性；2、训练集可能方差很大；3、预测实际上跟时间也有关系、且变化是突发的
（2）在第3节中说明了：应该用强化学习（exploration and exploitation：E2）
因为：1、要随机地探测其他解；2、跟多臂老虎机问题一样，奖励可能会随时间而改变，这是一个连续的过程
（3）在第4节中说明了：如果两个session的可以确定E2决策的上下文相同，那它们的一些特定的网络特性也相同。因此，要将相同特征的session（例如，IP预定义，位置）分组。
不过，上一节和这一节都提到了，只有一个小特征的区别可能就导致最后的QoE相差巨大，因此只研究last-mile不好、传统的E2方法也不好。应对方法是把session的粒度分得很细。
1、数据密度够时，将全局E2过程分解成单独的每个组E2过程，然后可以在地理分布式集群中独立运行；2、数据稀疏时，又是用全局数据来做E2
Idea具体：
（1）怎么分组？这次不聚类了，因为：
基于关键特征的分组会话会造成组间的重叠。给定会话集，会话分组逻辑应该输出任何不重叠的会话分区。
解决方法：递归地将会话基于剩余的关键特征进行分组，就是说组之间可以构成树结构。
这样能保证分类分的足够细。关于数据稀疏问题，这个算法尽量避免拆分已有的分组，还是在尽量避免数据稀疏（然而我觉得还是会很严重）
（2）在每组内具体怎么搞E2
在存在QoE drift的情况下，使用Discounted-UCB算法[20]（作为UCB算法的变体[14]），它按指数方式给出测量结果的权重，因此自动对更近的测量结果给予更高的权重。因此，与其他UCB算法（几乎）会收敛于一个决策不同，Discounted-UCB更有可能重新审视次优决策，以保留所有决策的可视性。
（3）系统架构
Pytheas系统设计必须满足四个目标：
1.新数据：每个组、每秒都有最新的QoE测量更新。
2.全局尺度：每秒应该处理数以百万计的session。
3.响应能力：对于请求，它应该在几毫秒内给出决策结果并响应。
4.容错性：当系统部分失效时，QoE不应该被显着影响。
可以采用先前工作主张的、基于预测方法的“split control plane”方法[19,25]
第6节描述了它的内部逻辑、第7节描述了优化问题。事实上，Pytheas已经实现并开源（在Java，python和PHP中约为10K行代码）。
评估：
当使用CloudLab中的Pytheas的端到端实现和部署时，比起现有的最先进的基于预测的系统，Pytheas平均提高了6-31％的视频质量，尤其是尾部QoE提高了24-78％。