Insights into PPLive: A Measurement Study of a Large-Scale P2P IPTV System（译）Insights into PPLive: A Measurement Study of a Large-Scale P2P IPTV System（译）Xiaojun Hei, Chao Liang, Jian Liang, Yong Liu and Keith W. Ross Abstract典型情况下，PPLive同时在线人数超过100,000，是目前最流行的IPTV应用。PPLive使用P2P设计，peer下载电视内容，并且分发给其他peer。尽管PPLive已经宽带互联网中越来越重要的一种应用，但是由于它的协议保密，大家对它知之甚少。这篇文章中，我们通过对PPLive进行初步的测量研究，报告一下通过家庭网络和校园网络peer的被动式数据包嗅探得出的结果，包括：视频流性能、负载特点和网络覆盖层特性。 1. IntroductionIPTV将改变我们的生活，分为基建式和P2P两种类型。相对而言，P2P物美价廉。 目前已有若干P2P式的IPTV应用，如Cool Streaming和PPLive, PPLive更加流行。为了设计下一代IPTV系统，我们首先要理解PPLive的设计、性能、流量特点和它的优缺点。 这篇文章的结果来自于对PPLive进行初步的测量研究。我们通过被动数据包嗅探和主动爬虫测量PPLive。这篇文章我们只给出嗅探的结果。我们的测量研究集中于PPLive视频流的三个重要方面：视频流性能、负载特点和网络覆盖层特性。我们定量研究结果揭示了公众网上实时视频流的重要性能和设计上的一些问题。 2. Overview of PPLive这里我们描述一下PPLive的基本机制，这是从我们搜集的很多信息中得出的，也被我们的测量所证实。PPLive实现了两个主要的应用层协议：用于peer管理和频道发现的交流协议和基于P2P的高质量视频流分发协议。图一描述了PPLive网络的概况。当用户启动PPLive软件时，首先加入PPLive网路，成为PPLive的peer节点。然后向频道服务器发送查询消息，获取最新的频道列表。在正式开始看某个电视频道之前，它并不与其他peer交换数据。当peer选择看某个频道时，它向根服务器发送多个查询消息，以获取该频道的在线peer列表。列表上用IP地址和端口号来标识一个peer 。获取peer列表后，他向列表中的其他peer发送探测消息，发现活动peer。某些活动的peer也会给它返回自己的peer列表，帮助它找到更多得peer 。peer然后相互共享视频数据，如下所示： 图一 频道和peer发现 PPLive的主要组件是它的电视引擎，它负责从PPLive网络下载视频数据块，并将下载的视频流化到媒体播放器。PPLive的流化程序穿越内存中的两个缓冲区：PPLive的TV引擎缓冲区和媒体播放器缓冲区，如图二所示。设计双缓冲机制有两个好处：能够减轻因下载速率抖动带来的影响，和能够更高效的在peer之间进行内容分发。 图二 PPLive流化程序 缓存的内容可以上传给其他正在收看当前频道的peer。明确一下：peer客户端从多个其他peer下载当前频道的媒体内容，同时也多个peer上传缓存的数据。接收到的视频数据块按顺序组装，并缓冲到PPLive的TV引擎队列中，在内存中形成一个流文件。 当流文件的长度达到预定门限时，PPLive的TV引擎启动媒体播放器。播放器从本地的HTTP流服务器下载视频数据。大多数媒体播放器，如windows media player都有内置的视频缓冲机制。当媒体播放器的设定缓冲区填满之后，视频回放就正式开始了。 当PPLive启动后，TV引擎尽力从其它peer下载媒体内容，最小化播放启动时间。当播放器获取足够的内容开始播放后，视频流逐渐稳定下来。TV引擎按照视频的回放速率给媒体播放器流化数据。 3. Measurement Setting我们P2P网络测量分为两类：被动监测和主动爬行。本文描述被动监测平台抓取PPLive流量分析得出的结果。我们从四台PC机上收集PPLive的网络数据包：两台在Polytechnic大学的100M校园网中，另两台在家里通过拨号上网。目前绝大多数PPLive用户都是使用这两种网络接入方式。拨号的两台电脑分别位于纽约的Manhattan和Brooklyn。使用Ethereal抓取所有PPLive流入和流出的数据包，过滤掉其他网络活动的数据包。 表一是2006年2月2号抓取的数据包概况。一台家庭电脑和一台校园电脑收看CCTV3，另外两台收看CCTV10. 每个都抓取2个小时。PPLive的网站上，CCTV3流行度被评为五颗星，CCTV10流行度评为三颗星。如果一个IP地址与抓包的这台电脑之间有TCP连接请求（TCP SYN数据包），就认为这个IP地址存在。如果这个IP地址与这台电脑交换非空数据，我们就定义这个IP地址是活跃IP。
4. Statistics of PPLive Sessions在视频回放过程中，PPLive的peer通常会与很多其他peer建立会话，不只是为了进行数据交换，还为了发送其他信号。这一部分，我们详细描述了会话统计，如：会话时长，数据包大小，他们之间的相互关系，以及会话中的数据传输中断。 4.1 Session Duration and Packet SizePPLive客户端使用TCP发送信号和处理视频流。TCP信号会话通常处理短期任务：下载peer列表和探测peer是否可用。相反，TCP视频流会话周期长一些。并且，在抓获比较小的TCP信号数据包时，抓到的TCP视频流数据包通常都比较大，超过1200字节。我们画出了CCTV3校园电脑上TCP会话时长和平均TCP数据包大小的关系图，如图三。其他三台电脑的图也类似。可以明显地看出，长TCP会话的TCP数据包较大，其中有很多交换小TCP数据包的短时会话。从图三我们可以推断，信号会话通常时长较短，大部分只发送较小的数据包；视频交换会话时长较长，发送较大的数据包。 图三 CCTV3-Campus中TCP会话周期与TCP包平均大小 既有信号网络流，又有视频网络流，使得理解PPLive的工作机制变得困难。因此，我们通过如下启发信息来区分二者： 我们还在图四中提出一个视频会话周期的分布累积补偿函数（Complementary Cumulative Distribution Function, CCDF）。注意视频会话周期很长。视频会话周期中位数大约是20秒，大约10%的会话超过15分钟，甚至更长。因为很多会话都很短，会话中，peer可能至于它的邻居peer只交换少量视频数据块。 图四 CCTV3-Campus视频会话周期的CCDF 4.2 Video Traffic Breakdown among SessionsPPLive的peer从其他peer下载/上传视频数据块，但是由于网络不稳定，其他peer上的内容是否可用等原因，所有peer会话的下载/上传率并不是平均分布的。图五中，一个校园的peer，我们比较它全部的下载速率和从贡献最大的那个下载的速率，贡献最大的peer贡献了约50%的下载量。然而贡献最大的peer的上传速率却是非常变化不定的。这通常是那个peer上内容可用性和TCP会话固有的速率不稳定性造成的。一个重要的结果就是一个peer通常都是从多个peer那里下载视频。由于这个多点下载的特点，总体的视频下载速率就变得很平滑。与缓冲机制（5.4节将叙述）相结合，PPLive通常都可以提供平滑地播放效果。在图五b中，我们用指数坐标绘制了视频上传的对比图。注意：最大的视频上传会话，仅仅占整个上传流中约5%的流量。这样，这个校园节点承担者重要的多播功能。 图五 CCTV3-Campus的Peer下载上传视频故障 5. PPLive Streaming Performance5.1 Start-up Delay当PPLive第一次启动的时候，它需要花些时间搜索其他peer，并从活跃的peer那里数据。我们记录了两种启动延时：选择频道到启动播放器的延时，启动播放器到开始播放的延时。通常情况下，播放器启动延时大约10-15秒，播放器的缓冲时间约10-15秒。因此，总共的延时时间约20-30秒。然而，有些不是很受欢迎的频道总体延时可能到2分钟。总体说来，PPLive启动的用户体验还是不错的，尽管网络下载速率抖动利害，图六中显示的总体下载速率效果肯定了这一点。 图六 四个抓包显示的视频上传和下载速率 5.2 Upload-Download Rates图六显示了四个抓包中的上传和下载视频流的速率。每个点的的比特速率是取每30秒的平均。注意，对于回放速率来说，下载速率抖动非常严重。有意思的是，两台校园的PPLive上传速率上升很快，而CCTV3-Residence上传速率上升很慢，而CCTV10-Residence却基本没怎么上传。 我们发现，总体上，校园和家里的视频下载速率在视频回放速率上下平滑波动。然而CCTV10-Residence在第33分钟的时候，下载速率有很大的波动，这个状况一直持续了约4分钟。在下降之后，PPLive的TV引擎全力从网络上下载，加快下载速率，持续约3分钟。之后，下载速率又变得稳定了。尽管PPLive和播放器都有缓冲，但是这个波动仍然会明显影响视频回放质量。 再看上传速率，校园peer和家庭peer显示出明显不同的行为。两个校园peer上传明显要比家庭的多。在这两个小时里面，两个校园peer分别上传了4.4GB和3.7GB的视频流量给其他peer。尽管不能与校园peer相提并论，但是其中一个家里的peer也上传了与其下载流量相当的数据。然而，另一个家里的peer仅仅上传了4.6MB的视频数据。 5.3 Video Traffic Redundancy由于PPLive视频流的分布式特性，PPLive很可能从多个peer那里下载重复的媒体内容。传输冗余的视频数据会浪费网络带宽，因此，我们对流播放器稳定播放之后PPLive视频流量的冗余测量很感兴趣。为了这个目的，我们不分析前十分钟抓取的数据包，尽量减小瞬时行为的影响。除去TCP/IP头，我们测定了下载流量里面的总体视频流负载。利用第四节中的视频流量启发过滤规则，我们可以抽取出其中的视频流数据包。给定回放时间和媒体回放速率，我们可以粗率估计总体媒体片的大小。我们把总体接收到的视频流量和估算的视频片大小之差算作冗余流量，把冗余流量与估算的媒体片大小之比算作冗余率。我们可以从表二看出，PPLive的流量冗余是有限的。这一部分的原因是很长的缓冲时间让PPLive的peer有足够时间发现该频道的其他peer，并与之交换内容可用信息。
CCTV3-Campus负的冗余率表明，它下载的数据不足以平滑播放。如图六(a)所示，在10 < t < 20 min和60 < t < 64 min的时候，CCTV3-Campus的下载速率明显下降，回放数据可能严重缺失。由于校园网络的连接性很好，这种异常情况需要进一步调查。 5.4 Video Buffering网络拥塞和peer变动期间，媒体下载速率可能不足以维持正常的回放，导致回放缓冲耗尽。因此，缓冲区大小影响流应用程序对网络拥塞的适应性。下面，我们估算PPLive的TV引擎的缓冲区大小和媒体播放器的缓冲区大小。 我们这样来估算PPLive TV引擎的缓冲区大小。首先，我们播放一个频道直到流速度稳定下来。我们从物理上断开PC到网络的连接，同时我们启动HTTP文件下载软件从PPLive的流服务器下载媒体文件。注意，在拔掉网线之后，PPLive TV引擎仍然提供流服务。下载的视频文件大小可以粗略估算PPLive的缓冲区大小。经过多次试验多个不同码率的频道，估算PPLive的缓冲区大小大约从7.8MB到17.1MB。似乎，PPLive根据流码率和媒体源指定的缓冲时间自适应的调整缓冲区大小。大体上，PPLive总共的缓冲区大小约10-30MB。普通PC可以很容易地满足这个需求。 6. PPLive Peering Statistics图七画出了活跃的视频peer。活跃的peer定义为与我们监测的peer有至少10个大数据包(>1200字节)交换。校园和家里的peer网络连接行为差异非常明显。与期望一致，由于校园网络接入带宽很高，校园peer连接着比家里peer多得多的活跃peer。校园peer利用它高带宽连接，为视频数据交换维护着一个稳定数量的活跃TCP连接。并且，内容受欢迎程度明显影响着家里peer连接的活跃peer的数量。典型情况下，家里peer收看不太受欢迎的CCTV10，似乎很难找到足够的peer提供媒体流。在t=33min时，活跃peer下降到只有一个。如图六(b)所示，近邻视频peer数量的减少对家里peer的下载速率冲击非常明显。在这个试验中，PPLive客户端很快检测到下载速率降低，并快速搜索新的peer增加视频下载。很快就能发现新的peer，新的流连接也很快建立起来。于是视频下载速率也快速恢复。 在一个peer的生命期间，这个peer经常更换它的上传下载邻居。图七也说明了这一点，其中，视频peer数量每30秒采样一次。两个连续采样点中变化的peer是指，不再向监测peer提供视频数据，也不从这里下载视频数据的peer。我们总是发现，30秒之后，有些peer离开了，有些新的peer加入了，并与监测peer交换数据，这种现象与网络接入方式无关。不过，校园peer连接的peer平均变化数目不超过10%。然而，家里的peer连接的peer平均变化数目要占好多个百分比。由此可以推断，家里peer的视频下载速率更可能明显波动。 图七 活跃连接视频peer变化 图八 peer离去与加入 如果频道数据可以从本大陆下载，而去从其他大陆下载，这将很浪费网络带资源。我们想研究PPLive进行下载peer选择是否会考虑peer的地理位置。为了达到这个目的，我们使用了一个简单的前缀匹配技术来计算peer的地理位置。peer IP地址的第一个前缀字节被选作估计这个peer的地理分布。比如：58.a.b.c就认为来自亚洲。注意：两个有相同前缀的IP地址也有很小的可能性来自不同的大陆。 表三显示了监测的视频会话中peer的地理分布情况。我们发现，很大一部分peer都来自亚洲，它们贡献了大部分的网络流量。另一方面，我们监测的几个位于New York的peer大部分数据都上传到北美洲。例如表三(b)，家里peer从亚洲下载了81.9%，北美下载了17.8%，却仅给亚洲上传了5.4%，而给北美上传了64.8%。不过，对于表三(d)的显示CCTV10-Residence的统计，这个趋势似乎并不有效。更进一步观察这个监测数据发现，这个peer只给有限的几个peer上传了少量数据（如图六d）。那些视频会话都很短暂，而那些peer都只是偶然出现，却分布在整个互联网上。 表三 视频会话中peer地理分布
7. Conclusion我们介绍了对流行的IPTV应用程序PPLive的测量研究。我们的测量结果表明，PPLive实施了高效的资源发现和视频分发P2P原则。通过充分利用互联网的基础设施，PPLive流能够满足IPTV的流化性能要求。这说明当前的互联网基础设施能够经济可行的满足IPTV服务的性能要求。不过，这些刚刚浮现出来的IPTV应用与其他应用有着不同的特点，这也许会极大地改变互联网的流量模式。这给互联网提供商带来了新的挑战和机遇。 8. References[1] S. Cherry, "The battle for broadband [Internet protocol television]," IEEE Spectrum, vol.42, no. 1, pp. 24 –29, Jan. 2005. |
|
|
来自： ljyang.2011 > 《p2p研究》
