P2P流媒体系统能力研究课件

P2P流媒体系统能力研究流媒体系统能力研究答辩人：陈一帅2010年6月11日北京交通大学博士研究生答辩P2P流媒体系统能力研究答辩人：陈一帅北京交通大学博士研究生大纲P2P流媒体系统简介研究内容实际系统测量媒体块调度算法对Flash Crowd的支持对VBR的支持总结和展望大纲P2P流媒体系统简介历史起源于中国2004，华中科技大学，香港科技大学，成长于春晚海外华人看春晚的最佳途径逐渐获得研究界的关注Sigcom 07 workshopInfocom 09 best paper商业化于中国PPLive，最流行的软件，上亿的用户，同时在线用户上百万奥运直播CNTVIPTV机顶盒历史起源于中国系统组成与技术特点视频质量较好400kbps（标清）800kbps（高清）1.2Mbps（蓝光）网络规模大（百万人同时看一个节目）对服务器的性能和带宽要求低系统组成与技术特点视频质量较好网络规模大（百万人同时看一个节基于Buffer的P2P共享长度：几十秒到上百秒基于Buffer的P2P共享长度：几十秒到上百秒Buffer的滑动本地播放完成&其它Peer不需要时，就Reject。Buffer的滑动本地播放完成&其它Peer不需要时，大纲P2P流媒体系统简介研究内容实际系统测量媒体块调度算法对Flash Crowd的支持对VBR的支持总结和展望大纲P2P流媒体系统简介实际系统测量两部分：Buffer管理策略的测量媒体块的传输性能的测量实际系统测量两部分：Buffer管理策略的测量问题：对Buffer的管理策略依旧模糊不清固定大小：Coolstreaming，BiTos变化大小：Liu Yong PPLiveBuffer管理策略的测量问题：对Buffer的管理策略依旧测量方法观察VBR时缓冲区的变化长度的变化出口处的Rejection速度的变化测量方法观察VBR时缓冲区的变化测量结果长度和速度成正比出口处Rejection的速率随Media Server送出媒体块的速度变化而变化，且时延较固定固定时延Buffer？较难实现测量结果长度和速度成正比固定时延Buffer？实现方法所有Peer以同一个速度Reject同一个媒体块该速度等于该媒体块的演播速度dq(t)/dt=r(t)g(t)d(t)/dt=0固定时延缓冲 好处：-自适应地Buffer Size调整-有利于P2P共享。实现方法所有Peer以同一个速度Reject同一个媒体块dq小结测量了真实世界系统的固定时延缓冲区的性质，揭示了其实现方法。这个连PPLive的人都没有想到，他们完全是无意中这么做的小结测量了真实世界系统的固定时延缓冲区的性质，揭示了其实现方媒体块传输性能的测量媒体块传输性能的测量P2P的媒体块传播实际：alog2(N)，a 1a 越小，性能越好X(t)=2tT=log2(N)P2P的媒体块传播实际：X(t)=2tT=log2(测量的困难传统测量方法记录每个Peer的收到时间统计出X(t)问题：在P2P网络中难以收集大范围的稳定的数据用户不稳定网络规模大缺少时间同步测量的困难传统测量方法从Peer的Buffer填充情况推断整个网络中的媒体块扩散速度用户Buffer的填充情况隐含了媒体块的扩散情况（Bitmap）Buffer位置 扩散时间滑动方向老媒体块新媒体块从Peer的Buffer填充情况推断整个网络中的媒体块扩散速前提：CBR测量方法Pm：填充率1。0前提：CBR测量方法Pm：填充率遍历性的验证遍历性的验证测量结果的验证有m的人的比例测量结果的验证有m的人的比例小结利用系统的特点从单个用户缓冲区来Infer整个网络中的媒体块传输性能一叶而知秋并和大范围的不稳定数据的结果进行比较证明了从单个用户缓冲区能够大致推断整个网络的媒体块传播质量。该方法非常经济。实践表明该方法简单，高效，正确。小结利用系统的特点大纲P2P流媒体系统简介研究内容实际系统测量媒体块调度算法对Flash Crowd的支持对VBR的支持总结和展望大纲P2P流媒体系统简介背景传统媒体块调度方法先收集Bitmap再调度（拿谁）Rarest First【BT】Greedy【BiToS】Random【Yong】问题：回避了何时拿定时困难其实更难背景传统媒体块调度方法请求冲突带来的重试问题冲突，重试 带来延时研究P2P直播流媒体系统的新角度：随机接入、冲突解决的角度特点：1）资源数逐渐增长2）先占式的冲突请求冲突带来的重试问题冲突，重试 研究P2P直播流媒体系新视角下的新调度算法类似Aloha，冲突解决办法当发现媒体服务器送出了一个新的媒体块时，先指数Backoff然后检查自己的邻居是否已经有了这个媒体块。如果有了，就去抢。如果没有，或抢失败了，就再指数Backoff易于实现调度和邻居是否有这个Piece独立：“盲”不需要周期调度，没有定时的难题新视角下的新调度算法类似Aloha，冲突解决办法性能分析扩散过程模型PPLive实测结果a=1.23，1.40性能分析扩散过程模型a=1.23，1.40Heterogeneous网络中的推广用用户类型型上上载带宽（kb/s)用用户所占比例所占比例112820%238440%31 00025%45 00015%用户的上载带宽是不一样的Heterogeneous网络中的推广用户类型上载带宽（kbServer应该优先给高性能节点送给哪个呢？送给哪个呢？Server应该优先给高性能节点送给哪个呢？初始Peer选择的性能分析初始peer的性能越高，媒体块在网络中的扩散越快。和其他研究者的实验结果相符【Marco】基于随机接入，冲突解决的模型能够反映真实世界系统的特征。第四类第一类初始Peer选择的性能分析初始peer的性能越高，媒体块在网高性能节点优先算法先监视邻居或Peer的带宽分布然后选择高性能的peer优先为它提供上载问题监视的成本大不灵活：Peer的不稳定导致带宽浪费高性能节点优先算法先监视邻居或Peer的带宽分布我们的方法从冲突解决的视角出发上载带宽小的节点让一下慢一点重试：请求速度随着带宽变化晚一点请求：初始启动时间随着带宽变化高性能节点自然地能够更早得到Piece，从而发挥它们的作用。好处：简单易行。不需要精确的带宽测量和智能Peer选择算法。我们的方法从冲突解决的视角出发性能慢一点请求平均传输时延减小了15.72%-28.12%晚一点请求平均传输时延减小了63.17%性能慢一点请求 晚一点请求小结从冲突解决的角度提出了盲随机媒体块调度算法，该算法简单，高效。并提出了慢节点让步算法，改进媒体块传播时延。从随机接入，冲突解决的角度建立了媒体块传输模型，正确反映了真实世界中媒体块传输的规律。小结从冲突解决的角度提出了盲随机媒体块调度算法，该算法简单，大纲P2P流媒体系统简介研究内容实际系统测量媒体块调度算法对Flash Crowd的支持对VBR的支持总结和展望大纲P2P流媒体系统简介背景容量问题：传统的能力分析关注稳定情况下缓冲区的大小和演播连续性的关系。Tlog2NFlash Crowd,VBR时系统的容量问题被忽略但是这些都是非常常见、重要的问题背景容量问题：直播中的Flash Crowd现象PPLive财经频道的实测结果11:30am和3pm，股市收盘时，大家涌入的现象。原因直播节目通常有预定的开始时间定义用户到达速度突然增加直播中的Flash Crowd现象PPLive财经频道的实测问题新用户无法启动。短Session意味着用户无法启动问题新用户无法启动。短Session意味着用户无法启动与传统的认识相悖传统认为P2P应对Flash Crowd的能力很强BitTorrent与传统的认识相悖传统认为P2P应对Flash Crowd的能原因新Peer贡献少不拿到一定数量的媒体块，不向外广播Bitmap。严格从最老的拿起。Diversity不好结果：新Peer太多，平均每个人得到的下载速度都不行，大家都拖着。原因新Peer贡献少模型启动过程：累积一定数启动过程：累积一定数目媒体块的过程目媒体块的过程启动节点数目启动节点数目启动节点数目的变化率启动节点数目的变化率稳定节点数目的变化率稳定节点数目的变化率模型启动过程：累积一定数目媒体块的过程启动节点数目启动节点数仿真发现系统具有一定的支持Flash Crowd的能力但这一能力是有限的小规模FC时能扛住（6倍）大规模FC时会崩溃（30倍）仿真发现系统具有一定的支持Flash Crowd的能力小规模能力能扛住的最大FC强度与初始状态无关，能用速度的倍数来表示与稳定Peer停留时长成正比。Power-law能力能扛住的最大FC强度改进方法避免争抢，重点培养一个一个喂，喂起一个来，它就能够贡献改进方法避免争抢，重点培养结果总能恢复稳定恢复时间为O(logV），其中V是FC的强度第一阶段：第二阶段：结果总能恢复稳定第一阶段：第二阶段：小结模型了FC下系统的动态仿真发现了FC极大时系统崩溃的危险，研究了系统支持FC的极限分析了问题的根本原因在于用户之间的冲突，证明了利用CAC方法解决用户之间的冲突后系统支持FC的性能小结模型了FC下系统的动态大纲P2P流媒体系统简介研究内容实际系统测量媒体块调度算法对Flash Crowd的支持对VBR的支持总结和展望大纲P2P流媒体系统简介背景VBR编码效果好但对P2P系统是一个挑战PP实验效果不好但没有人研究过问题：速度增加时，单位时间内更多媒体块到达，使用户的下载带宽overload背景VBR编码效果好问题：速度增加时，单位时间内更多媒体块到研究方法我们以前的测量出现过速率变化的情况以此切入研究系统中VBR时的动态研究方法我们以前的测量出现过速率变化的情况质量评估速度增加时用户缓冲区填充率下降质量评估速度增加时用户缓冲区填充率下降压扁平移原因分析速率增长时下载速度变化不大缓冲区下载位置曲线变化下载速度变化不大平移原因：平移原因：Fixed-Duration Buffer，Buffer Size增长增长压扁原因：更多媒体块的出现使下载范围扩大，但总下载速度不变，所以幅度变小压扁原因：更多媒体块的出现使下载范围扩大，但总下载速度不变，所以幅度变小压扁平移原因分析速率增长时下载速度变化不大下载速度变化不大平模型分析：稳定情况下的缓冲区下载位置曲线缓冲区填充率曲线缓冲区下载位置曲线求导模型分析：稳定情况下的缓冲区下载位置曲线缓冲区填充率曲线缓冲变化过程中的一种连续变化：例：在20s内连续完成下载曲线的变化压扁平移变化过程中的一种连续变化：例：在20s内连续完成下载曲线的变缓冲区填充情况的变化从100%变为了65%对用户演播质量带来冲击缓冲区填充情况的变化从100%变为了65%速率增加的幅度越大，冲击越大幂率速率增加的幅度越大，冲击越大幂率系统的自适应能力自动恢复过程（缺乏模型）提高请求速度，从而提高了下载速度提高下载速度提高下载速度带来的恢复重新站起来了系统的自适应能力自动恢复过程（缺乏模型）提高下载速度提高下载恢复不了的补救措施在800的缓冲区位置，进行一个补救措施。兜底恢复不了的补救措施在800的缓冲区位置，进行一个补救措施。小结测量了VBR时系统的质量问题模型了VBR时用户下载曲线的变化，由此模型分析了VBR时用户缓冲区填充率的变化情况的模型，揭示了问题，得到了VBR幅度和质量下降幅度的定量关系。测量了真实世界系统在VBR下的自适应恢复过程和特殊补救措施。小结测量了VBR时系统的质量问题结论实际系统测量Buffer的Rejection算法验证了遍历性质，从而可以从单个用户的缓冲占用分布，描述块在网络中的传播特征媒体块调度算法新观念：冲突解决问题盲随机调度算法：去掉了定时的问题不同能力用户的不同Backoff策略的算法：改进了性能对Flash Crowd的支持一个被忽视的重要的容量问题建立了理论模型。证明了系统崩溃的可能性提出了CAC算法，解决问题对VBR的支持观察到了VBR时的性能劣化和原因建立了模型进行描述发现了更多模型无法描述的有意思的现象，留待以后解决结论实际系统测量谢谢！谢谢！谢谢观赏 谢谢观赏