CLive Cloud-Assisted P2P Live Streaming Authors: Amir H. Payberah, Hanna Kavalionak, Vimalkumar Kumaresan, Seif Haridi, Alberto Montresor Speaker :吳靖緯 MA0G0101 2012 IEEE 12th International Conference on Peer-to-Peer Computing (P2P), On page(s): 79 - 90, Sep 2012 2012.12.7

Outline Introduction System model and problem definition System architecture

Introduction For live streaming, QoS means high playback continuity and short playback delay. There is a trade off between these two properties: it is possible to increase the playback continuity by adopting larger stream buffers, but at the expense of delay. Increasing the bandwidth at the media source is not always an option. 即時串流的QoS意味著高播放的連續性和播放延遲短。 這兩個屬性之間存在一個折衷：經由採用較大的串流緩衝區來增加撥放的連續性，但會犧牲延遲。 增加多媒體來源的頻寬並不總是可行的。

Introduction An interesting approach to solve this issue is the addition of auxiliary helpers to accelerate the content propagation. A helper could be an active computational node that participates in the streaming protocol, or it could be a passive storage service that just provides content on demand. The helpers increase the total upload bandwidth available in the system, thus, potentially reducing the playback delay. 一個有趣的方法來解決這個問題是附加輔助助理來加速內容傳播。 一個幫手可以積極的計算節點，參與串流協議，或者它可能是一個被動的存儲服務，只提供內容的需求。 helpers增加系統上的總上傳頻寬，因此可能會減少播放延遲。

Introduction Considering the capacity and the cost of helpers, the problem consists in selecting the right type of helpers (passive vs. active), and provisioning their number with respect to the dynamic behavior of the users. On the other hand, renting helpers is costly, and their number should be minimized. 考慮到helpers的能力和成本，問題包含選擇助理(被動和主動)的正確類型，和動態的供應用戶數量。 另一方面，租助理是昂貴的，其數量應盡量減少。

Introduction This P2P-cloud hybrid approach, termed cloud-assisted P2P computing. The contribution of this paper is the design and evaluation of CLIVE, a novel cloud-assisted P2P live streaming system that guarantees a predefined QoS level by dynamically renting helpers from a cloud infrastructure. 這個P2P雲端混合的方法，被稱為cloud-assisted P2P computing。 本文的貢獻是CLIVE的設計和評估，一個新的cloud-assisted P2P live streaming system，保證了預定義的QoS級別通過動態租用helpers的雲端基礎設施。

System model and problem definition There are two types of helpers: (i) an active helper (AH) is an autonomous virtual machine composed of one or more computing cores, volatile memory and permanent storage, e.g., Amazon EC2. (ii) a passive helper (PH) is a simple storage service that can be used to store (PUT) and retrieve (GET) arbitrary pieces of data, e.g., Amazon S3. 有兩種類型的helpers： (i)一個active helper (AH)是一個自主的虛擬機由一個或多個計算核心、記憶體與永久性存儲組成，如Amazon EC2 (ii)一個passive helper (PH)是一個簡單的存儲服務，可用於存儲（PUT）和取回（GET）任意資料，如Amazon S3。

System model and problem definition We assume that customers of the cloud service are required to pay for computing time and bandwidth in the case of AHs. For storage space, bandwidth and the number of PUT/GET requests in the case of PHs. We assume the source generates a constant-rate bitstream and divides it into a number of chunks. A chunk c is uniquely identified by the real time t(c) at which is generated. 我們假設在Ahs的情況下雲端服務的客戶需支付計算時間和頻寬。 且對於儲存空間、頻寬和數個PUT/GET請求，在PHs的情況下。 我們假定來源產生一個恆定速率(constant-rate)的比特流，並將其劃分成多個chunks。 一個chunk c 有一個唯一確定的即時t(c)生成時間。

System model and problem definition The generation time is used to play chunks in the correct order. We define the number of download slots, Down(p), and upload slots, Up(p), of a peer p as its number of download and upload connections. The goal of CLIVE peers is to play the video with predefined playback delay and playback continuity. To reach this goal, CLIVE is allowed to rent a PH and/or AHs from the cloud. 生成時間是用來以正確的順序播放chunks 我們定義下載通道的數量，Down(p)，和上傳通道，Up(p)，一個peer p有多個下載和上傳的連接。 CLIVE peers的目標是播放視訊，預定義的播放延遲和播放的連續性。 為了達到這個目標，CLIVE被允許從雲端租用一個PH and/or AHs。

System model and problem definition Deciding about which and how much resources to rent from the cloud can be modeled as an optimization problem: the maximum playback delay should be less than or equal to 𝑇 𝑑𝑒𝑙𝑎𝑦 , meaning that if a chunk c is generated at time t(c) at the source. the maximum percentage of missing chunks should be less than or equal to P loss . 判定從雲端租多少資源可以視為一個優化問題： 最大播放延遲應小於或等於 𝑇 𝑑𝑒𝑙𝑎𝑦 ，意思是如果一個chunk c從來源產生時間為t(c) 。 丟失chunks的最大百分比應小於或等於 P loss 。

System architecture The basic elements forming CLIVE have been already introduced: the media source a swarm of peers a single passive helper (PH) a number of active helpers (AH) We present two architectural models, illustrated in Figures 1 and 2. 將對CLIVE基本要素作介紹：media來源，一個swarm的peers，一個的單一passive helper (PH)，和一些active helpers (AH)。 我們提出了兩個架構模型，如圖1和圖2所示。

System architecture The baseline model (Figure 1) can be described as a P2P streaming protocol, where peers revert to the PH whenever a chunk cannot be retrieved from other peers. 基準模型（圖1）可以被描述為一個P2P的流媒體協議，peers恢復PH，每當一個chunk沒辦法從其他peers檢索。

System architecture The enhanced model (Figure 2) builds upon the baseline, by considering AHs and by providing a distributed mechanism to provision their number and appropriately organizing them. 增強模型（圖2）建立在baseline的基礎上，考慮AHs並提供一個分佈式的機制來提供它們的數量和適當的組織。

System architecture The baseline model The baseline model builds upon this P2P video streaming protocol by adding a PH (Figure 1). The source, apart from pushing newly created video chunks to the swarm, temporary stores them on the PH. In order to guarantee a given level of QoS, each peer is required to have a predefined amount of chunks buffered ahead of its playback time, called last chance window (LCW), corresponding to a time interval of length 𝑇 𝐿𝐶𝑊 . 基楚模型是建立在這個P2P視頻流媒體傳輸協議，通過添加PH（圖1）。 來源，除了推動新創建的video chunks到swarm，臨時存儲在PH上。 為了保證一個給定的服務質量水平，再影片撥放前每個peer必須有一個預定義的chunks緩衝，被稱為最後的機會窗口(LCW)，對應的時間長度間隔 𝑇 𝐿𝐶𝑊 。

System architecture If a given chunk has not been obtained from the swarm T LCW time units before the playback time, it is retrieved directly from the PH. The enhanced model The enhanced model pursues this goal by adding a number of AHs to the swarm (Figure 2). AHs receive chunks from the source or from other AHs, and push them to other AHs and/or to peers in the swarm. 如果一個給定的chunk尚未從swarm 𝑇 𝐿𝐶𝑊 的時間單位取得，在影片撥放之前，它會直接從PH抓取。 增強型實現這一目標經由增添了許多Ahs到swarm中（圖2）。 AHs從來源或從其他AHs接收chunks，並push他們到其他AHs或到swarm中的peers裡。

System architecture To discover such peers, AHs join the peer sampling protocol and obtain a partial view of the whole system. We use a modified version of CYCLON, such that peers exchange their number of upload slots along with their ID. AH chooses a subset of root peers (Figure 2) from their partial view and establish a connection to them, pushing chunks as soon as they become available. Root peers of an AH are not changed over time, unless they fail or leave the system, or AH finds a peer with more upload slots than the existing root peers. 為了發現這樣的peers，AHs加入peer的採樣協議，並獲得整個系統的局部圖。 我們使用CYCLON的修改版本，使的peers互相交換他們的上傳通道數量以及他們的ID。 AH從他們的局部視圖選擇root peers（圖2）的一個子集並和他們建立連接，pushing chunks盡快為他們成為可用的。 Root peers的AH並不會隨時間而改變，除非他們失敗或離開系統，或AH找到一個peer比現有的root peers有更多的上傳通道

System architecture Architecturally speaking, an important issue is how to organize multiple AHs and how to feed chunks to them. There are two possible models: Flat: the AHs receive all their chunks directly from the source and then push them to peers in the swarm. Hierarchical: the AHs are organized in a tree with one AH at the root; the source pushes chunks to the root, which pushes them through the tree. 從體系結構上講，一個重要的問題是如何組織多個AHs並傳送chunks給他們。 有兩種可能的模式： 平坦：AHs直接從來源接收他們所有的chunks，然後再push它們到swarm中的peers。 層次化：AHs與一個root的AH是在一個tree的組織中；來源pushes chunks給root，再通過tree pushes給他們。

System architecture

System architecture One important question in the enhanced model is: how many AHs to add? The decision on the number of AHs to include in the system is taken by the CLIVE manager (CM), a unit that is responsible for monitoring the state of the system and organizing the AHs. 在增強模型中有一個重要的問題是：需要添加多少AHs？ 在系統中決定AHs的數量採取經由CLIVE管理器（CM），是負責監測系統的狀態和組織AHs。

The CLIVE manager The theoretical number of AHs that minimize the cost is not so straightforward to compute, because no peer has a global view of the system and its dynamics, e.g., which peers are connected and how many upload slots each peer has. We describe a heuristic solution, where each peer runs a small collection of gossip-based protocols, with the goal of obtaining approximate aggregate information about the system. The CM, then, uses this information to detect whether the current number of AHs is adequate to the current size of the swarm, or if correcting actions are needed by adding/removing AHs. 理論上AHs的數量以最小的成本來計算不是那麼簡單的，因為沒有peer擁有系統的全局視圖與peer動態變化，例如peers連接與在每個peer上有多少上傳通道。 我們描述了一種啟發式的解決方案，每個peer執行一個gossip-based協議的小採集，獲得系統總訊息的近似目標。 接著CM使用此信息來檢測是否當前的AHs的數量足夠應付swarm目前的大小，或修正方法如需要添加/刪除AHs。

The CLIVE manager The participating swarm peers and CM in the gossip-based aggregation protocol collect the following information: the current size of the swarm the probability density function of the upload slots available at peers in the swarm The swarm size estimation. The size of the current swarm, 𝑁 𝑠𝑤𝑎𝑟𝑚 , is computed, with high precision, through an existing aggregation protocol. This information is made available to all peers in the system. 在gossip-based聚集協議中參與的swarm peers和CM收集以下信息： swarm目前的大小。 在swarm中的peers上傳通道可用的概率密度函數。 當前swarm的大小， 𝑁 𝑠𝑤𝑎𝑟𝑚 ，是計算具有高精確性，通過現有的聚合協議。 在系統中這些信息被提供給所有peers。

The CLIVE manager Upload slots estimation. Assume ω is the actual upload slot distribution among all peers. We adopt ADAM2 to compute P ω :ℕ→ℝ, an estimate probability density function of ω. P ω (i), represents the proportion of peers that have i upload slots w.r.t. the total number of peers, so that i P ω i =1. 假設ω是所有peers之間的實際上傳通道分配。 我們採用ADAM2來計算 P ω :N→R，一個估計ω的概率密度函數。 P ω (i)，代表peers所佔的比例，i為上傳通道，w.r.t.表示peers的總數，使的 i P ω i =1。

The CLIVE manager Chunk lifetime. T delay : No more than T delay time units must pass between the generation of a chunk at the source and its playback at any of the peers. T latency : The maximum time needed for a newly generated chunk to reach the root peers. T lcw : If a chunk is not available at a peer T lcw time units before its playback time, it will be retrieved from the PH. T delay ：沒有超過 T delay 的時間單位，必須通過在來源與任何的peers撥放產生的chunk之間。 T latency ：最大時間需要對於一個新生成的chunk來到達root peers。 T lcw ：如果在先前的撥放時間一個chunk在一個peer T lcw 時間單位是不可用的，他將會從PH檢索。

The CLIVE manager Moreover, the chunk c becomes available at a root peer at time t c + T latency , and it should be available in the local buffer of any peer in the swarm by time t c + T delay − T lcw , otherwise the chunk will be downloaded from the PH (Figure 3). 此外chunk c在root peer的時間t c + T latency 成為可用的，它應該是可以在任何swarm中peer的本地buffer經由時間t c + T delay − T lcw ，其他的chunk將被下載從PH（圖3）。

The CLIVE manager This means that the lifetime T life of a chunk from the root peer on is equal to: 這意味著一個從root peer的chunk壽命 T life 如下公式：