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同時在線人數(shù)超過100,000，是目前最流行的IPTV應用。PPLive使用P2P設計，peer下載電視內(nèi)容，并且分發(fā)給其他peer。盡管PPLive已經(jīng)寬帶互聯(lián)網(wǎng)中越來越重要的一種應用，但是由于它的協(xié)議保密，大家對它知之甚少。這篇文章中，我們通過對PPLive進行初步的測量研究，報告一下通過家庭網(wǎng)絡和校園網(wǎng)絡peer的被動式數(shù)據(jù)包嗅探得出的結(jié)果，包括：視頻流性能、負載特點和網(wǎng)絡覆蓋層特性。 1. IntroductionIPTV將改變我們的生活，分為基建式和P2P兩種類型。相對而言，P2P物美價廉。 目前已有若干P2P式的IPTV應用，如Cool Streaming和PPLive, PPLive更加流行。為了設計下一代IPTV系統(tǒng)，我們首先要理解PPLive的設計、性能、流量特點和它的優(yōu)缺點。 這篇文章的結(jié)果來自于對PPLive進行初步的測量研究。我們通過被動數(shù)據(jù)包嗅探和主動爬蟲測量PPLive。這篇文章我們只給出嗅探的結(jié)果。我們的測量研究集中于PPLive視頻流的三個重要方面：視頻流性能、負載特點和網(wǎng)絡覆蓋層特性。我們定量研究結(jié)果揭示了公眾網(wǎng)上實時視頻流的重要性能和設計上的一些問題。 2. Overview of PPLive這里我們描述一下PPLive的基本機制，這是從我們搜集的很多信息中得出的，也被我們的測量所證實。PPLive實現(xiàn)了兩個主要的應用層協(xié)議：用于peer管理和頻道發(fā)現(xiàn)的交流協(xié)議和基于P2P的高質(zhì)量視頻流分發(fā)協(xié)議。圖一描述了PPLive網(wǎng)絡的概況。當用戶啟動PPLive軟件時，首先加入PPLive網(wǎng)路，成為PPLive的peer節(jié)點。然后向頻道服務器發(fā)送查詢消息，獲取最新的頻道列表。在正式開始看某個電視頻道之前，它并不與其他peer交換數(shù)據(jù)。當peer選擇看某個頻道時，它向根服務器發(fā)送多個查詢消息，以獲取該頻道的在線peer列表。列表上用IP地址和端口號來標識一個peer 。獲取peer列表后，他向列表中的其他peer發(fā)送探測消息，發(fā)現(xiàn)活動peer。某些活動的peer也會給它返回自己的peer列表，幫助它找到更多得peer 。peer然后相互共享視頻數(shù)據(jù)，如下所示： 圖一 頻道和peer發(fā)現(xiàn) PPLive的主要組件是它的電視引擎，它負責從PPLive網(wǎng)絡下載視頻數(shù)據(jù)塊，并將下載的視頻流化到媒體播放器。PPLive的流化程序穿越內(nèi)存中的兩個緩沖區(qū)：PPLive的TV引擎緩沖區(qū)和媒體播放器緩沖區(qū)，如圖二所示。設計雙緩沖機制有兩個好處：能夠減輕因下載速率抖動帶來的影響，和能夠更高效的在peer之間進行內(nèi)容分發(fā)。 圖二 PPLive流化程序 緩存的內(nèi)容可以上傳給其他正在收看當前頻道的peer。明確一下：peer客戶端從多個其他peer下載當前頻道的媒體內(nèi)容，同時也多個peer上傳緩存的數(shù)據(jù)。接收到的視頻數(shù)據(jù)塊按順序組裝，并緩沖到PPLive的TV引擎隊列中，在內(nèi)存中形成一個流文件。 當流文件的長度達到預定門限時，PPLive的TV引擎啟動媒體播放器。播放器從本地的HTTP流服務器下載視頻數(shù)據(jù)。大多數(shù)媒體播放器，如windows media player都有內(nèi)置的視頻緩沖機制。當媒體播放器的設定緩沖區(qū)填滿之后，視頻回放就正式開始了。 當PPLive啟動后，TV引擎盡力從其它peer下載媒體內(nèi)容，最小化播放啟動時間。當播放器獲取足夠的內(nèi)容開始播放后，視頻流逐漸穩(wěn)定下來。TV引擎按照視頻的回放速率給媒體播放器流化數(shù)據(jù)。 3. Measurement Setting我們P2P網(wǎng)絡測量分為兩類：被動監(jiān)測和主動爬行。本文描述被動監(jiān)測平臺抓取PPLive流量分析得出的結(jié)果。我們從四臺PC機上收集PPLive的網(wǎng)絡數(shù)據(jù)包：兩臺在Polytechnic大學的100M校園網(wǎng)中，另兩臺在家里通過撥號上網(wǎng)。目前絕大多數(shù)PPLive用戶都是使用這兩種網(wǎng)絡接入方式。撥號的兩臺電腦分別位于紐約的Manhattan和Brooklyn。使用Ethereal抓取所有PPLive流入和流出的數(shù)據(jù)包，過濾掉其他網(wǎng)絡活動的數(shù)據(jù)包。 表一是2006年2月2號抓取的數(shù)據(jù)包概況。一臺家庭電腦和一臺校園電腦收看CCTV3，另外兩臺收看CCTV10. 每個都抓取2個小時。PPLive的網(wǎng)站上，CCTV3流行度被評為五顆星，CCTV10流行度評為三顆星。如果一個IP地址與抓包的這臺電腦之間有TCP連接請求（TCP SYN數(shù)據(jù)包），就認為這個IP地址存在。如果這個IP地址與這臺電腦交換非空數(shù)據(jù)，我們就定義這個IP地址是活躍IP。
4. Statistics of PPLive Sessions在視頻回放過程中，PPLive的peer通常會與很多其他peer建立會話，不只是為了進行數(shù)據(jù)交換，還為了發(fā)送其他信號。這一部分，我們詳細描述了會話統(tǒng)計，如：會話時長，數(shù)據(jù)包大小，他們之間的相互關(guān)系，以及會話中的數(shù)據(jù)傳輸中斷。 4.1 Session Duration and Packet SizePPLive客戶端使用TCP發(fā)送信號和處理視頻流。TCP信號會話通常處理短期任務：下載peer列表和探測peer是否可用。相反，TCP視頻流會話周期長一些。并且，在抓獲比較小的TCP信號數(shù)據(jù)包時，抓到的TCP視頻流數(shù)據(jù)包通常都比較大，超過1200字節(jié)。我們畫出了CCTV3校園電腦上TCP會話時長和平均TCP數(shù)據(jù)包大小的關(guān)系圖，如圖三。其他三臺電腦的圖也類似?？梢悦黠@地看出，長TCP會話的TCP數(shù)據(jù)包較大，其中有很多交換小TCP數(shù)據(jù)包的短時會話。從圖三我們可以推斷，信號會話通常時長較短，大部分只發(fā)送較小的數(shù)據(jù)包；視頻交換會話時長較長，發(fā)送較大的數(shù)據(jù)包。 圖三 CCTV3-Campus中TCP會話周期與TCP包平均大小 既有信號網(wǎng)絡流，又有視頻網(wǎng)絡流，使得理解PPLive的工作機制變得困難。因此，我們通過如下啟發(fā)信息來區(qū)分二者： 我們還在圖四中提出一個視頻會話周期的分布累積補償函數(shù)（Complementary Cumulative Distribution Function, CCDF）。注意視頻會話周期很長。視頻會話周期中位數(shù)大約是20秒，大約10%的會話超過15分鐘，甚至更長。因為很多會話都很短，會話中，peer可能至于它的鄰居peer只交換少量視頻數(shù)據(jù)塊。 圖四 CCTV3-Campus視頻會話周期的CCDF 4.2 Video Traffic Breakdown among SessionsPPLive的peer從其他peer下載/上傳視頻數(shù)據(jù)塊，但是由于網(wǎng)絡不穩(wěn)定，其他peer上的內(nèi)容是否可用等原因，所有peer會話的下載/上傳率并不是平均分布的。圖五中，一個校園的peer，我們比較它全部的下載速率和從貢獻最大的那個下載的速率，貢獻最大的peer貢獻了約50%的下載量。然而貢獻最大的peer的上傳速率卻是非常變化不定的。這通常是那個peer上內(nèi)容可用性和TCP會話固有的速率不穩(wěn)定性造成的。一個重要的結(jié)果就是一個peer通常都是從多個peer那里下載視頻。由于這個多點下載的特點，總體的視頻下載速率就變得很平滑。與緩沖機制（5.4節(jié)將敘述）相結(jié)合，PPLive通常都可以提供平滑地播放效果。在圖五b中，我們用指數(shù)坐標繪制了視頻上傳的對比圖。注意：最大的視頻上傳會話，僅僅占整個上傳流中約5%的流量。這樣，這個校園節(jié)點承擔者重要的多播功能。 圖五 CCTV3-Campus的Peer下載上傳視頻故障 5. PPLive Streaming Performance5.1 Start-up Delay當PPLive第一次啟動的時候，它需要花些時間搜索其他peer，并從活躍的peer那里數(shù)據(jù)。我們記錄了兩種啟動延時：選擇頻道到啟動播放器的延時，啟動播放器到開始播放的延時。通常情況下，播放器啟動延時大約10-15秒，播放器的緩沖時間約10-15秒。因此，總共的延時時間約20-30秒。然而，有些不是很受歡迎的頻道總體延時可能到2分鐘?？傮w說來，PPLive啟動的用戶體驗還是不錯的，盡管網(wǎng)絡下載速率抖動利害，圖六中顯示的總體下載速率效果肯定了這一點。 圖六 四個抓包顯示的視頻上傳和下載速率 5.2 Upload-Download Rates圖六顯示了四個抓包中的上傳和下載視頻流的速率。每個點的的比特速率是取每30秒的平均。注意，對于回放速率來說，下載速率抖動非常嚴重。有意思的是，兩臺校園的PPLive上傳速率上升很快，而CCTV3-Residence上傳速率上升很慢，而CCTV10-Residence卻基本沒怎么上傳。 我們發(fā)現(xiàn)，總體上，校園和家里的視頻下載速率在視頻回放速率上下平滑波動。然而CCTV10-Residence在第33分鐘的時候，下載速率有很大的波動，這個狀況一直持續(xù)了約4分鐘。在下降之后，PPLive的TV引擎全力從網(wǎng)絡上下載，加快下載速率，持續(xù)約3分鐘。之后，下載速率又變得穩(wěn)定了。盡管PPLive和播放器都有緩沖，但是這個波動仍然會明顯影響視頻回放質(zhì)量。 再看上傳速率，校園peer和家庭peer顯示出明顯不同的行為。兩個校園peer上傳明顯要比家庭的多。在這兩個小時里面，兩個校園peer分別上傳了4.4GB和3.7GB的視頻流量給其他peer。盡管不能與校園peer相提并論，但是其中一個家里的peer也上傳了與其下載流量相當?shù)臄?shù)據(jù)。然而，另一個家里的peer僅僅上傳了4.6MB的視頻數(shù)據(jù)。 5.3 Video Traffic Redundancy由于PPLive視頻流的分布式特性，PPLive很可能從多個peer那里下載重復的媒體內(nèi)容。傳輸冗余的視頻數(shù)據(jù)會浪費網(wǎng)絡帶寬，因此，我們對流播放器穩(wěn)定播放之后PPLive視頻流量的冗余測量很感興趣。為了這個目的，我們不分析前十分鐘抓取的數(shù)據(jù)包，盡量減小瞬時行為的影響。除去TCP/IP頭，我們測定了下載流量里面的總體視頻流負載。利用第四節(jié)中的視頻流量啟發(fā)過濾規(guī)則，我們可以抽取出其中的視頻流數(shù)據(jù)包。給定回放時間和媒體回放速率，我們可以粗率估計總體媒體片的大小。我們把總體接收到的視頻流量和估算的視頻片大小之差算作冗余流量，把冗余流量與估算的媒體片大小之比算作冗余率。我們可以從表二看出，PPLive的流量冗余是有限的。這一部分的原因是很長的緩沖時間讓PPLive的peer有足夠時間發(fā)現(xiàn)該頻道的其他peer，并與之交換內(nèi)容可用信息。
CCTV3-Campus負的冗余率表明，它下載的數(shù)據(jù)不足以平滑播放。如圖六(a)所示，在10 < t < 20 min和60 < t < 64 min的時候，CCTV3-Campus的下載速率明顯下降，回放數(shù)據(jù)可能嚴重缺失。由于校園網(wǎng)絡的連接性很好，這種異常情況需要進一步調(diào)查。 5.4 Video Buffering網(wǎng)絡擁塞和peer變動期間，媒體下載速率可能不足以維持正常的回放，導致回放緩沖耗盡。因此，緩沖區(qū)大小影響流應用程序?qū)W(wǎng)絡擁塞的適應性。下面，我們估算PPLive的TV引擎的緩沖區(qū)大小和媒體播放器的緩沖區(qū)大小。 我們這樣來估算PPLive TV引擎的緩沖區(qū)大小。首先，我們播放一個頻道直到流速度穩(wěn)定下來。我們從物理上斷開PC到網(wǎng)絡的連接，同時我們啟動HTTP文件下載軟件從PPLive的流服務器下載媒體文件。注意，在拔掉網(wǎng)線之后，PPLive TV引擎仍然提供流服務。下載的視頻文件大小可以粗略估算PPLive的緩沖區(qū)大小。經(jīng)過多次試驗多個不同碼率的頻道，估算PPLive的緩沖區(qū)大小大約從7.8MB到17.1MB。似乎，PPLive根據(jù)流碼率和媒體源指定的緩沖時間自適應的調(diào)整緩沖區(qū)大小。大體上，PPLive總共的緩沖區(qū)大小約10-30MB。普通PC可以很容易地滿足這個需求。 6. PPLive Peering Statistics圖七畫出了活躍的視頻peer。活躍的peer定義為與我們監(jiān)測的peer有至少10個大數(shù)據(jù)包(>1200字節(jié))交換。校園和家里的peer網(wǎng)絡連接行為差異非常明顯。與期望一致，由于校園網(wǎng)絡接入帶寬很高，校園peer連接著比家里peer多得多的活躍peer。校園peer利用它高帶寬連接，為視頻數(shù)據(jù)交換維護著一個穩(wěn)定數(shù)量的活躍TCP連接。并且，內(nèi)容受歡迎程度明顯影響著家里peer連接的活躍peer的數(shù)量。典型情況下，家里peer收看不太受歡迎的CCTV10，似乎很難找到足夠的peer提供媒體流。在t=33min時，活躍peer下降到只有一個。如圖六(b)所示，近鄰視頻peer數(shù)量的減少對家里peer的下載速率沖擊非常明顯。在這個試驗中，PPLive客戶端很快檢測到下載速率降低，并快速搜索新的peer增加視頻下載。很快就能發(fā)現(xiàn)新的peer，新的流連接也很快建立起來。于是視頻下載速率也快速恢復。 在一個peer的生命期間，這個peer經(jīng)常更換它的上傳下載鄰居。圖七也說明了這一點，其中，視頻peer數(shù)量每30秒采樣一次。兩個連續(xù)采樣點中變化的peer是指，不再向監(jiān)測peer提供視頻數(shù)據(jù)，也不從這里下載視頻數(shù)據(jù)的peer。我們總是發(fā)現(xiàn)，30秒之后，有些peer離開了，有些新的peer加入了，并與監(jiān)測peer交換數(shù)據(jù)，這種現(xiàn)象與網(wǎng)絡接入方式無關(guān)。不過，校園peer連接的peer平均變化數(shù)目不超過10%。然而，家里的peer連接的peer平均變化數(shù)目要占好多個百分比。由此可以推斷，家里peer的視頻下載速率更可能明顯波動。 圖七 活躍連接視頻peer變化 圖八 peer離去與加入 如果頻道數(shù)據(jù)可以從本大陸下載，而去從其他大陸下載，這將很浪費網(wǎng)絡帶資源。我們想研究PPLive進行下載peer選擇是否會考慮peer的地理位置。為了達到這個目的，我們使用了一個簡單的前綴匹配技術(shù)來計算peer的地理位置。peer IP地址的第一個前綴字節(jié)被選作估計這個peer的地理分布。比如：58.a.b.c就認為來自亞洲。注意：兩個有相同前綴的IP地址也有很小的可能性來自不同的大陸。 表三顯示了監(jiān)測的視頻會話中peer的地理分布情況。我們發(fā)現(xiàn)，很大一部分peer都來自亞洲，它們貢獻了大部分的網(wǎng)絡流量。另一方面，我們監(jiān)測的幾個位于New York的peer大部分數(shù)據(jù)都上傳到北美洲。例如表三(b)，家里peer從亞洲下載了81.9%，北美下載了17.8%，卻僅給亞洲上傳了5.4%，而給北美上傳了64.8%。不過，對于表三(d)的顯示CCTV10-Residence的統(tǒng)計，這個趨勢似乎并不有效。更進一步觀察這個監(jiān)測數(shù)據(jù)發(fā)現(xiàn)，這個peer只給有限的幾個peer上傳了少量數(shù)據(jù)（如圖六d）。那些視頻會話都很短暫，而那些peer都只是偶然出現(xiàn)，卻分布在整個互聯(lián)網(wǎng)上。 表三 視頻會話中peer地理分布
7. Conclusion我們介紹了對流行的IPTV應用程序PPLive的測量研究。我們的測量結(jié)果表明，PPLive實施了高效的資源發(fā)現(xiàn)和視頻分發(fā)P2P原則。通過充分利用互聯(lián)網(wǎng)的基礎設施，PPLive流能夠滿足IPTV的流化性能要求。這說明當前的互聯(lián)網(wǎng)基礎設施能夠經(jīng)濟可行的滿足IPTV服務的性能要求。不過，這些剛剛浮現(xiàn)出來的IPTV應用與其他應用有著不同的特點，這也許會極大地改變互聯(lián)網(wǎng)的流量模式。這給互聯(lián)網(wǎng)提供商帶來了新的挑戰(zhàn)和機遇。 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研究》
