Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Peer-assisted live video streaming is another attractive service in the Internet: 1) Take PPLive, one of the most popular peer-assisted streaming systems nowadays, as an example: at the end of 2005, it has 20 million download and 1 million; independent viewers per day [2]. According to [4], it supports over 200 ; 000 concurrent users at bit rate in the 400-800 Kbps for 2006 Spring Festival Gala on Chinese New Year on January 28, 2006. In 2007, the number of concurrent users for the most popular PPLive session raises to 1 : 5 million [3]. This corresponds to an aggregate bit rate in the vicinity of 600 Gbps, or 540 TB transferred per the 2 hour event. Actually, this type of service but with more challenges than that of file sharing: First,

, either peers joining process is stretched over a longer period of time or application itself can tolerate much longer delay , the dynamic of user population during annual Spring Festival Gala on Chinese New Year

In face of frequent peer churns, the maintenance of streaming tree(s) in tree-based approaches is still challenging, and the recovery of tree(s) incurs extra cost. Recently, mesh-based approaches (also referred to as data-driven approaches) have been adopted in many large-scale peer-assisted live video streaming systems, such as Coolstreaming [32], PPLive, UUSee, and etc. In contrast with tree-based approaches, mesh-based overlay designs do not construct and maintain an explicit structure for delivering data. 4) Generally, a mesh-based streaming system has a tracker to keep track of peers in the video session. 5) A peer may download/upload segments from/to multiple partners simultaneously

over 20% of the users have tried 1 or 2 times in order to successfully start a video session. Hence, a flash crowd has significant impact on the initial joining phase in a P2P streaming system.

it takes longer time for a newly joined peer to obtain video stream

Besides the above, there are also open issues relevant to multiple channels, ISPs which is covered in my report, but not shown here due to time limit

2.
Overview: Internet Video Streaming <ul><li>Enable video distribution from any place to anywhere in the world in any format </li></ul>

3.
<ul><li>Cont. </li></ul><ul><li>Recently, significant deployment in adopting Peer-to-Peer (P2P) technology for Internet live video streaming </li></ul><ul><ul><li>Protocol design: Overcast, CoopNet, SplitStream, Bullet, and etc. </li></ul></ul><ul><ul><li>Real deployment: ESM, CoolStreaming, PPLive, and etc. </li></ul></ul><ul><ul><li>Key </li></ul></ul><ul><li>Requires minimum support from the infrastructure </li></ul><ul><li>Greater demands also generate more resources : Each peer not only downloading the video content, but also uploading it to other participants </li></ul>Easy to deploy Good scalability

5.
Motivation <ul><li>Flash crowd </li></ul><ul><ul><li>A large increase in the number of users joining the streaming in a short period of time ( e.g., during the initial few minutes of a live broadcast program ) </li></ul></ul><ul><ul><li>Difficult to quickly accommodate new peers within a stringent time constraint , without significantly impacting the video streaming quality of existing and newly arrived peers </li></ul></ul><ul><ul><ul><li>Different from file sharing </li></ul></ul></ul><ul><li>Challenge : Large-scale & extreme peer dynamics </li></ul><ul><li>Current P2P live streaming systems still suffer from potentially </li></ul><ul><li>long startup delay & unstable streaming quality </li></ul><ul><li>Especially under realistic challenging scenarios such as flash crowd </li></ul>

6.
Focus <ul><li>Cont. </li></ul><ul><ul><li>Little prior study on the detailed dynamics of P2P live streaming systems during flash crowd and its impacts </li></ul></ul><ul><ul><ul><li>E.g., Hei et al. measurement on PPLive, the dynamic of user population during the annual Spring Festival Gala on Chinese New Year </li></ul></ul></ul>How to capture various effects of flash crowd in P2P live streaming systems? What are the impacts from flash crowd on user experience & behaviors, and system scale? What are the rationales behind them?

10.
Mesh-based (Data-driven) Approaches <ul><li>No explicit structures are constructed and maintained </li></ul><ul><ul><li>e.g., Coolstreaming , PPLive </li></ul></ul><ul><li>Data flow is guided by the availability of data </li></ul><ul><ul><li>Video stream is divided into segments of uniform length, availability of segments in the buffer of a peer is represented by a buffer map (BM) </li></ul></ul><ul><ul><li>Periodically exchange data availability info with a set of partners (partial view of the overlay) and retrieves currently unavailable data from each other </li></ul></ul><ul><ul><li>Segment scheduling algorithm determines which segments are to be fetched from which partners accordingly </li></ul></ul><ul><li>Overhead & delay : peers need to explore the content availability with one another, which is usually achieved with the use of gossip protocol </li></ul>

13.
How to capture flash crowd effects? <ul><li>Two key measures </li></ul><ul><ul><li>Short session distribution </li></ul></ul><ul><ul><ul><li>Counts for those that either fail to start viewing a program or the service is disrupted during flash crowd </li></ul></ul></ul><ul><ul><ul><li>Session duration is the time interval between a user joining and leaving the system </li></ul></ul></ul><ul><ul><li>User retry behavior </li></ul></ul><ul><ul><ul><li>To cope with the possible service disruption often observed during flash crowd, each peer can re-connect (retry) to the program </li></ul></ul></ul>

14.
Short Sessions under Flash Crowd <ul><li>Filter out normal sessions (i.e., users who successfully join the program) </li></ul><ul><li>Focus on short sessions with the duration <= 120 sec and 240 sec </li></ul><ul><li>No. short session increases significantly at around 18:00 when flash crowd </li></ul><ul><ul><li>occurs with a large number of peers joining the live broadcast program </li></ul></ul>

15.
Strong Correlation Between the Number of Short Sessions and Peer Joining Rate

16.
What are the rationales behind these observations? <ul><li>Relevant factors: </li></ul><ul><ul><li>User client connection fault </li></ul></ul><ul><ul><li>Insufficient uploading capacity from at least one of the parents </li></ul></ul><ul><ul><li>Poor sustainable bandwidth at beginning of the stream subscription </li></ul></ul><ul><ul><li>Long waiting time (timeout) for cumulating sufficient video content at playback buffer </li></ul></ul><ul><li>Newly coming peers do not have adequate content to share with others, thus </li></ul><ul><ul><li>initially they can only consume the uploading capacity from existing peers </li></ul></ul><ul><li>With partial knowledge (gossip), the delay to gather enough upload </li></ul><ul><ul><li>bandwidth resources among peers and the heavy resource competition </li></ul></ul><ul><ul><li>could be the fundamental bottleneck </li></ul></ul>

17.
Approximate User Impatient Time <ul><li>In face of poor playback continuity, users either reconnect or opt to leave </li></ul><ul><li>Compare the total downloaded </li></ul><ul><li>bytes of a session with the expected </li></ul><ul><li>total playback video bytes </li></ul><ul><li>according to the session duration </li></ul><ul><li>Extract sessions with insufficient </li></ul><ul><li>download bytes </li></ul><ul><li>The avg. user impatient time </li></ul><ul><li>is between 60s to 120s </li></ul>

18.
User Retry Behavior under Flash Crowd <ul><li>Retry rate: count the NO. peers that opt to re-join to the overlay </li></ul><ul><ul><li>with same IP address and port per unit time </li></ul></ul><ul><li>Users could have tried many times to successfully start a video session </li></ul><ul><li>Again shows that flash crowd has significant impact on the initial </li></ul><ul><li>joining phase </li></ul><ul><li>User perspective: </li></ul><ul><li>playback could be restored </li></ul><ul><li>System perspective: </li></ul><ul><li>amplify the join rates </li></ul>

19.
System Scalability under Flash Crowd Media player ready Received sufficient data to start playing Successfully joined The gap illustrates “ catch up process” <ul><li>Media player ready rate picks up when the flash crowd occurs and </li></ul><ul><li>increases steadily; however, the ratio between these two rates <= 0.67 </li></ul><ul><li>Imply that the system has capability to accommodate a sudden surge </li></ul><ul><li>of the user arrivals (flash crowd), but up to some maximum limit </li></ul>

20.
Media Player Ready Time under different time period <ul><li>Considerably longer during the period </li></ul><ul><li>when the peer join rate is higher </li></ul>

22.
Summary <ul><li>Based on real-world measurement, capture flash crowd effects </li></ul><ul><ul><li>The system can scale up to a limit during the flash crowd </li></ul></ul><ul><ul><li>Strong correlation between the number of short sessions and joining rate </li></ul></ul><ul><ul><li>The user behavior during flash crowd can be best captured by the number of short sessions, retries and the impatient time </li></ul></ul><ul><ul><li>Relevant rationales behind these findings </li></ul></ul>

23.
Future work <ul><li>Modeling to quantify and analyze flash crowd effects </li></ul><ul><li>Correlation among initial system capacity , the user joining rate/startup delay , and system scale ? </li></ul><ul><ul><li>Intuitively, a larger initial system size can tolerate a higher joining rate </li></ul></ul><ul><ul><li>Challenge : how to formulate the factors and performance gaps relevant to partial knowledge (gossip)? </li></ul></ul>

24.
<ul><li>Based on the above study, perhaps more importantly for practical </li></ul><ul><li>systems, how can servers help alleviate the flash crowd problem, i.e., </li></ul><ul><li>shorten users’ startup delays, boost system scaling? </li></ul><ul><li>Commercial systems have utilized self-deployed servers or CDN </li></ul><ul><ul><li>Coolstreaming, Japan Yahoo, 24 servers in different regions that allowed users to join a program in order of seconds </li></ul></ul><ul><ul><li>PPLive is utilizing the CDN services </li></ul></ul><ul><li>On measurement , examine what real-world systems do and experience </li></ul><ul><li>On technical side , derive the relationship between </li></ul>Expected Number of Viewers ??? Amount of Server Provisioning along with their joining behaviors Further, how servers are geographically distributed

38.
Peer Adaptation in Coolstreaming <ul><li>Inequality (1) is used to monitor the buffer status of received sub-streams for node A </li></ul><ul><ul><li>If this inequality does not hold, it implies that at least one sub-stream is delayed beyond threshold value T s </li></ul></ul><ul><li>Inequality (2) is used to monitor the buffer status in the parents of node A </li></ul><ul><ul><li>If this inequality does not hold, it implies that the parent node is considerably lagging behind in the number of blocks received when comparing to at least one of the partners, which currently is not a parent node for the given node A </li></ul></ul>