ABSTRACT和INTRODUCTION的行文思路
（*0、补充一下关于吞吐量和延迟的知识：两者不是简单成反比
我们可以把网络发送数据包比喻成去街边的 ATM 取钱。每一个人从开始使用 ATM 到取钱结束整个过程都需要一分钟，所以这里的延迟是60秒，那吞吐量呢？当然是 1/60 人/秒。现在银行升级了他们的 ATM 机操作系统，每个人只要30秒就可以完成取款了！延迟是 30秒，吞吐量是 1/30 人/秒。很好理解，可是前面的问题依然存在对不对？别慌，看下面。
因为这附近来取钱的人比较多，现在银行决定在这里增加一台 ATM 机，一共有两台 ATM 机了。现在，一分钟可以让4个人完成取钱了，虽然你去排队取钱时在 ATM 机前还是要用 30 秒！（总的请求随着ATM数量同比增加了，每台ATM的延迟还是不变）也就是说，延迟没有变，但吞吐量增大了！可见，吞吐量可以不用通过减小延迟来提高。
好了，现在银行为了改进服务又做出了一个新的决定：每个来取钱的客户在取完钱之后必须在旁边（不是ATM机上）填写一个调查问卷，用时也是30秒。那么，现在你去取钱的话从开始使用 ATM 到完成调查问卷离开的时间又是 60 秒了！换句话说，延迟是60秒。而吞吐量根本没变！一分钟之内还是可以进来4个人！可见，延迟增加了，而吞吐量没有变。
从这个比喻中我们可以看出，延迟测量的是每个客户（每个应用程序）感受到的时间长短，而吞吐量测量的是整个银行（整个操作系统）的处理效率，是两个完全不同的概念。
然而本文并没有强调两者的区别，只是想表示“两手都要抓”而已……）
- 提出需求
- 为了处理多而小的文件，网络最好有low latency（单个用户感受到的延迟时间。优化方式：服务器需要把一些强迫用户处理的事情揽在自己身上）
- 为了处理大文件，网络最好有high average throughput／short completion time（服务器处理用户请求的效率。优化方式：服务器处理文件的时间不包含额外浪费用户的时间，可以把一些时间拿给用户去等待）
- 对于所有文件，希望的high quality主要包括low startup delays, low buffering, and high bitrates[3, 21]，后两者可以直接统计到（Rebuffering ratio:
中途缓冲时间比是计算缓冲时间除以缓冲加播放时间，不包括暂停或停止时间以及视频启动前的缓冲时间）
- Streaming还要求high quality保持一段时间，因为视频播放需要时间
- 传统的处理方式
- 传统的改进需求要么只保证low latency，要么只保证high throughput；新的要求里，不仅两者都需要，Streaming还要求这样的high quality能保持一段时间，因为视频播放需要时间
- 为此产生了对content delivery infrastructures本身的、从根本上的改进需求。根据本文在客户端进行的测试结果，这个infrastructures实在不好：more than 20% of sessions have a rebuffering ratio 10% and more than 14% of sessions have a video startup delay 10s. 这反映的问题：时间变化性、空间多样性、对hotspots
的应对很差
- 然而目前仍采取HTTP chunk- based streaming protocols的原因：这种商品服务的使用通过允许内容提供商利用现有的HTTP CDN基础设施向广泛的受众传送内容，大大降低了传播成本和进入壁垒
- *需求比较：Video streaming中latency更不重要（这一段没头没脑的）
- video是大文件更注重completion time
- 可以靠应用程序的data unit来补偿latency
- 类似地，completion time中没有捕获到中途缓冲的时间rebuffering-induced interruptions，而中途缓冲时间很影响用户体验：a 1% increase in buffering can lead to more than a 3 minutes reduction in expected viewing time [21].
- 本文解决方案：不优化结构
我们设想一个可以使用网络和CDN性能全局视图的视频控制层，根据所选CDN服务器的带宽，为客户端动态分配CDN和bitrate的合适选择，从而优化视频传输。
意义：即使在最常选择CDN的情况下，通常情况下也可以将平均rebuffering比降低2倍，在极端情况下可以将平均rebuffering比降低10倍以上。
本文给出一个具体实现，包括具体地指定控制层的各个方面，例如分配算法，性能估计和策略功能。
- MOTIVATION——说明需要改进的问题
*潜在的性能问题来源：客户端、单个ISP或自治系统（AS）（这说的是一个边缘用户集群）、CDN三者的性能，都可能随着时空产生波动
（*数据集合统计结果同时包含直播和点播；另外对数据有一些处理，例如对于缓冲比率和平均bitrate，我们删除不到一分钟的会话，因为它们通常来自不感兴趣的用户）
根据Figure 1
40.1% sessions experience rebuffering >= 1%：60%的内容基本没有中途缓冲
19.5% sessions experience rebuffering >= 10%：20%的内容中途缓冲时间过长，同时这20%的视频的中途缓冲时间比分布比较均匀
还有其他一些内容，总之表明终端用户体验远未完美（突显了性能优化的需要）
Figure 2：把相近的客户端带宽分在一起，它们标准差的CDF图
意义：鉴于今天的bitrate水平（例如400,800,1000,3000 Kbps），这自然意味着需要智能bitrate选择和切换，以确保平滑的观看体验。（需要自适应）
（张老师指出：没有指明是同一时间、同一地点的统计结果。不是同一时间地点的话有不同本来就很正常啊？除非是同一时间地点下带宽变化还是很大：一会4M一会5M、你是4M我是5M，那的确是亟待改进）
Figure 3证明CDN在空间上存在连续变化
（具体：
- 不同CDN的表现可以在给定的城市内变化。例如，在City1，CDN1的rebuffering比几乎是CDN2用户的2倍。
- 对于每个度量，所有城市都没有单个CDN是最佳的。例如，比较rebuffering比，CDN1对于City4和City6，City1和City5的CDN2以及City2和City3的CDN3是最佳的。
- CDN在各项指标之间的表现可能不同。例如，当我们考虑视频启动时间时，除了City4之外，CDN3在所有情况下都是最好的。相比之下，当涉及到失败率时，CDN3表现最差。）
表格证明：
对于所有三个指标，没有CDN具有最佳性能。每个CDN在3天内都会遇到一些性能问题。
关于Figure 5：
Figure 5（a）意义：此结果突出表明，供应商需要有多个CDN来优化不同地理区域和随着时间的推移。它还表明动态选择CDN有可能提高整体视频质量。（动态）
Figure 5（b）意义：这些建议可能会导致ISP拥塞。理想情况下，我们希望视频传输基础架构能够了解这些网络热点以优化视频质量。（需要全局调控）
- FRAMEWORK FOR OPTIMIZING VIDEO DELIVERY
1、哪些参数作为自适应参数
这里有两个主要参数：选择bitrate和选择CDN /服务器来服务内容。由于特定的视频服务器是由CDN控制的（例如，基于负载和性能），我们只考虑以CDN粒度（granularity）的服务器选择。（本文不讨论如何具体实现这种bitrate和CDN的切换，切换机制已经广泛应用了）
2、我们什么时候可以选择这些参数
这里有两个自然选择。在启动视频播放器的启动时，或者在中途根据网络条件的变化动态调整这些中间流。（启动表示在视频开始前选定，中途表示在视频中途还可以动态改变）
3、谁决定这些参数的值
服务器（参见[28]）不予考虑，因为它能做到的，客户端或控制层也能做到。那么还有两种选择：客户端（如今采用的机制，它偏向于分布式，擅长观测和应对网络的局部变化），还是可以看见全局状态的控制层（偏向于集中式）。（本文没有考虑把两者结合起来）
参见表3：
为什么要引入全局控制层——客户端适应性有两个优点：（1）客户端处于观察局部网络效应的最佳位置，（2）对网络动态响应的响应时间将很低。然而，如前所述，CDN性能存在显着的时空变异性，难以用纯客户端策略来检测和缓解。为此，我们认为，由内容提供商或第三方代表知道这种时间和空间变化的内容提供商部署控制平台将是有帮助的。 （这个解释有点苍白啊，因此他们也只敢说控制层是helpful的）
控制层真正的好处：以前网站随便选定一个CDN，DNS只能选择好的server，现在是cross CDN：网站给你选择CDN就会选一个好的
CDN bitrate
首先排除S S：策略太简单
客户 控制也排除：引入控制层主要是为了选择CDN而不是选择bitrate
客户 客户（S M）当今策略（张老师指出错误：并不是客户端选择CDN，而是DNS选择）
控制 控制（M M）理想策略
控制 客户（S M／M M）最终妥协：因为bitrate由客户端决策的影响也不大
（张老师提出：靠第三方能看到CDN的时空变化性，但是由此给出的最优解就很好了吗？如果每个CDN服务器都不好，那么该优化的、更主要的矛盾不应该是拥塞控制吗？）
Figure 6显示了视频控制平面中三个关键组件的高级概述：
（1）负责主动监控客户视频质量的测量组件（测量）
（2）使用历史和当前测量的性能表现预测用户将在当前时间内获得CDN和比特率的特定组合的潜在性能（预测）
（3）使用测量和性能oracle为全局用户分配CDN和比特率的全局优化引擎（决策）
测量引擎：挑战是选择合适的属性和质量度量的粒度进行测量，并确定将这些报告发送到控制平面的适当频率。
预测：根据设计，oracle将不得不基于过去和当前的测量来推断性能。例如，它可以基于一组属性（例如，ISP，位置）来聚类用户，并且使用该集群内的经验平均值作为其预测。这里的挑战在于要考虑到噪声和丢失的数据
全局决策：挑战在于1、选择效用函数（utility）的参数；2、决策的速度要快；3、优化是稳定的，本身不会引入偏差或不稳定性（见第5.1节？？？）
- POTENTIAL FOR IMPROVEMENT
理想情况下，每个客户端将尝试所有可能的选择，并选择具有最佳性能的选项。此外，客户将不断重新评估性能，并在必要时切换以改善其性能。当然，在实践中，我们不能让每位客户不断探索所有可能的组合。为了克服这个限制，我们根据我们观察到具有类似属性的其他客户端的性能（如ISP，位置，设备和时间）来推断客户端可以实现的性能。
*本节中我们做出两个简化的假设。1、我们不考虑比特率选择。2、我们假设会话结果是独立的，CDN性能不会随着负载而降级（就是每个服务器的CDN性能是固定的）。我们在5.2节中放宽这些假设。
符号定义：Sa表示属性值为a的所有客户端的集合，Sa,p表示属性值为a、选择了参数p（如CDN）的所有客户端的集合。给定a和p，能表示对它的兴趣的参数，比如rebuffering比，都有一个经验分布，设为PerfDist a,p。当mean(PerfDist a,p1) < mean(PerfDist a,p2)时，认为PerfDist a,p1优于PerfDist a,p2（也可以通过比较中位数或分位数）
外推法（extrapolation）：根据过去和现在的发展趋势推断未来。在数据集中，一个地区认为某个CDN好（少数服从多数，多数人认为它的效用函数值更大），就认为它一直都很好，让这个地区以后都选它（本文起先假设workload不随人数变化的用意就在这里，不让选择本身影响workload）
外推法和效用函数的关系：在数据集上以效用函数为目标函数进行机器学习，然后以外推法为理论根据，进行以后的预测
定义pa* = argmin p{mean(PerfDist a,p)}。以后在真实情况中，就认为给定a时的最优参数为pa*，遵从的分布就是PerfDist a,p
统计问题：随着属性空间变得更细小，可用数据变得稀疏[14]。即：我们希望使用可用的最细粒度的属性信息，但是我们可能没有足够的统计信息来预测非常细粒度的组。在这种情况下，我们要确定一个较粗略的属性组合。具体：优先考虑最细的粒度，再按照规定好的逻辑顺序一步步放宽粒度，直到有足够的数据进行预测。设a和p最后被规约到as*和pas*。
如何从分布PerfDist a*,pas*中预测表现？我们还可以设想将每个会话映射到新分发中的适当百分位数。也就是说，如果本次会议在Sa,p的客户的90-95％的百分位数之内，那么我们从Sa,pa*的表现的90-95％的同一个数据库中抽取出来。
经过4.2的改进分析，这种外推是合理的。同时证明了，更好的CDN选择可以显著提高视频传送质量。
- TOWARD A PRACTICAL DESIGN
本节将bitrate、CDN负载影响、全局优化加入考虑
选定效用函数utility = -3.7*buffRatio + bitrate/20；buffRatio单位为百分比，bitrate单位为Kbps。3.7代表先前提到的一个线性等价关系：rebuffering比增加1％导致观看时间下降3.7分钟[21]。
具体方法，我认为类似登山算法或者随机梯度下降（1、每次的优化都是让一个地区贪心地走最大的一步：改选让效用函数值提高最多的一个服务器；2、每次每个点只考虑自己而不是全局的优化）。首先，给一个公平的随机初始值。接下来，我们使用此分配作为起点，并尝试逐步提高总效用。这是一个贪心算法，它在每次迭代中都会选择客户端和CDN /比特率设置的组合，它为全局效用函数提供最大的增量贡献。
我们并不认为这在理论上是最优的，但我们确实观察到它在一系列现实的工作负载下运行良好。
随机化和knowledge gradient？？？
另外，我们只是将比特率视为我们决策过程的附加属性。也就是说，除了ISP和城市等特征之外，我们还在构建性能估计器和预测模型时，根据当前的比特率对客户端进行分区。我们扩展了上一节的测量结果，以反映我们预测模型中的比特率。（即还是交给客户端自己决策）
- TRACE-DRIVEN SIMULATIONS
在外推法中，选择多长的历史数据作为样本？本文测试了使用前一个小时或使用前一天的两种情况。结果表明，使用上一个小时的预测，在许多情况下差距很小。这说明，CDNs的表现在很大程度上是可以用最近的历史来预测的，但偶尔会出现尖峰。这些性能峰值导致我们使用前一小时的估计变得不准确。我们的初步结果（未显示）表明，这些差距可以通过使用更细粒度的历史信息（例如，前五分钟的时期）得到缓解。
- DISCUSSION
一些其他未解决问题。例如Switching tolerance：一个自然的问题是用户容忍多少bitrate切换？研究表明，用户对频繁切换（例如[18]）和bitrate的突然变化都是敏感的（例如[35]）。然而，我们对转换与保持高比特率和低缓冲的期望之间的权衡没有很好的量化理解。由于这种权衡随着未来的测量研究而变得更加清晰，因此也可以并入控制层优化函数中。