reduction of the impact of chunk losses in p2p live streaming networks

CHUNK LOSSES IN P2P LIVE STREAMING NETWORKS

João Oliveira

Orientador: Sérgio Campos

Live Streaming

• Motivação

07/12/2015 2 CHUNK LOSSES

IN P2P LIVE STREAMING NETWORKS

Live Streaming



Live Streaming

• Teens are using less old social networks • Live video broadcast using smartphones • Apps

– Periscope – YouNow – Snapchat – Meerkat

07/12/2015 5


Peer-to-Peer

07/12/2015 6

• Scalability

• Load distribution

• Transfer rates maximization

• Shared responsibility

• Economy @source


P2P Live Streaming

• Content = Stream Chunks

+ Live Requirements

– Chunks must be as fresh as possible

– Each chunk must be received prior to its playback

• Chunk’s life is short



P2P Live Streaming



07/12/2015 9

P2P Live Streaming

• Problems? Quality is yet an issue

– I can hear others cheering for events that haven’t happened yet!

– I often visualize fragments during exhibition…

– I can’t watch!

Chunk loss impairs exhibition


Objectives

• Study chunk losses and propose new methods to avoid/eliminate them

• Reduce associated costs

• Let’s try to guarantee chunk delivery!



Contributions

• TVPP

• Chunk Loss Characterization

• SURE

• Emergency Request Service

• AERO



TVPP – A RESEARCH ORIENTED SYSTEM Let’s look inside system’s design



TVPP – A Research Oriented System

• Mesh-pull system mimicking commercial ones

• Advantages

– Easy data acquisition

– Configurability

– Modularity

– Collection of arbitrary data




• Overlay Formation

– Bootstrap: overlay entry point

• Channel creation

• Peer sampling

– Knowledge about viewers address

• Fresh info granted by constant pings from each viewer

– Neighborhood Management

• Connection algorithms

• Disconnection algorithms




• Scheduler – BufferMap Exchange

• System’s heartbeat

• Neighbor content view

• Avoids transmission redundancy

– Chunk Exchange • Which chunk to start asking for? (TipChunk - few seconds)

• Earliest Deadline First

• Search desirable chunk in neighbors’ buffermaps

• Configurable way of selecting candidate peer to request to

07/12/2015 15

347 0 1 1 1 1 0 1 1 ...

Initial ChunkID Bitmap



• Monitoring and Data gathering – Chunks: sent, received, requested, responded, lost,

duplicated – Latency and hop count for each chunk – Neighborhood size – Timestamps: generation, transmission, consumption – ...

• Fine-grained metrics – Latency – Chunk loss rates – Average path length of a chunk



CHUNK LOSS CHARACTERIZATION Where are the lost chunks?



Chunk Loss Characterization

• Identify common reasons and patterns on delivery and failure situations

• Guiding questions – "Do chunks losses occur?“

– "How frequently?”

– "Why?“

– Expand those to grasp the influence of available bandwidth, load at the peers, neighborhood, and time, over chunk losses




• General Setup

• Analysis of:

– Resourceful scenario

– Bandwidth-constrained scenarios

• Free riders




• General scenario – ~500 PlanetLab nodes – 420 kbps stream – 8 minutes experiments

• 1:30 warm-up and cool down removed

– 10 repetitions for each scenario – TVPP

• Random peer selectors • 20 neighbors • 1600 chunks buffer • 3 retry attempts • 3s to undo an unresponsive partnership • 10s to remove an unresponsive peer from the channel



Resourceful (System Behavior)

• Knee around 92% with 0.8% loss

• Classes of loss

– ~60% peers lose 0%

– ~35% peers lose ]0; 3]%

– ~5% peers lose ]3; 100]%

– These 5% bare 86% of total loss

• Stable loss through time



Resourceful (Peer Behavior)

• Do more losses occur at peers that are serving more?

• Were peers overloaded with chunk requests?

• Requests received and not responded as an abstraction to peer load and chunk losses

• Expected linear correlation



Resourceful (Peer Behavior)

• Samples:



75% peers have responded to all the chunk requests

0,4% peers have responded to zero chunk requests

19% peers have received no chunk requests

Resourceful (Chunk Behavior)

• What happens when I hit a chunk?

– 98% of the time I got it from the first attempt




• What happens when I hit a chunk?

– Candidates in each attempt for hit

• Smooth Spread

– Greedy pattern (EDF)




• What happens when I lose a chunk?

– 15% of the misses caused by no candidates

– Candidates in each attempt for miss

• Slower spread




• Whenever a miss occurs there are less partners that are able to respond the request

• Many possibilities: – Bad overlay organization

– Loss of synchronism between peers

– Bad luck…

• Data availability is different under hits and misses

07/12/2015 27



• What about bursts of miss?

– Majority of misses are temporally independent

– 1% of the bursts are above 10 consecutive misses

– 0,2% are above 100

– Bursts are still expressive




• Is the same chunk missed by many peers?

– No! Chunk misses are spatially independent • No chunk have being missed by more than 3% of the network

• 10% - 0

• 22% - 1

• 25% - 2

• 21% - 3

• 10% - 4

• 7,5% - 5

• 5% - >5



Bandwidth-constrained

• Free riders

– Oblivious: I have no bandwidth to share

• Outgoing stream messages won’t be sent

• Simulated through a leaky bucket

– Conscious: I have no chunks to share

• I announce that I have an empty chunk map

• No one will ask me for chunks




07/12/2015 31

• Chunk loss (oblivious) – Requesting to someone that won’t respond is a waste of limited tries

– Small degradation have large impact



• Latency (oblivious) – Shortage of contributing partners causes chunk forwarding paths to

become longer

– A request issued to a free won’t be responded, hence retries




07/12/2015 33

• SURE – Simple Unanswered Request Eliminator – Let’s avoid requesting to peers that aren’t responding

– Whenever requesting, use candidate peer with less pending requests

50% free rider

curves



• Chunk loss is an issue present even in resourceful scenarios

– Eventual low candidate availability

• Overlay organization might be improved

– Otherwise, reasons seem random

• Emergency Request Service(*)

• Bandwidth restrictions are fierce

– SURE selects responsive chunk sources

07/12/2015 34


EMERGENCY REQUEST SERVICE A P2P approach to an almost lost chunk



Emergency Request Service

• Why? – Best Effort Policies

• Try a few times

• Low concerns

• If it fails… it fails!

• Problems might be diverse – It’s hard to even identify the probable cause

– Solutions might have to be different for each problem • Do I need to reorganize my neighborhood?

• Do I have to pull a link to another peer of the overlay out of thin air? If so, to what peer?

• Are there peers with spare capacity to solve these requests?

07/12/2015 36



• Monitoring

– Control the chunk delivery “real-time”ness

• How far is each chunk playback deadline?

• Can I afford to request that chunk a few more times?

• Explore P2P capacity at maximum

– Peers may choose or be elected to become part of an emergency overlay, and that may grant benefits (reputation/lag)

– Non P2P nodes can back the system up if everything else fails






H

H

H

H

H

H

! Emergency Request Service


• 100% delivery, if achievable, has a price…

– Emergency Request Handlers have to provide bandwidth that has not been provided before

– …which might be spare bandwidth, or not(!)



07/12/2015 40

ADAPTIVE EMERGENCY REQUEST OPTIMIZATION Reducing costs of emergency requests


SmoothCache

• P2P component for Hive (commercial system)

• CDN-P2P Hybrid

– CDN has all chunks

– Peers would request all chunks to CDN

• First, peers query the P2P network for a chunk

– CDN seed chunks to a few peers (prefetchers)

• Seeding Ratio Σ(pref bw)/Σ(all bw)

– Most mechanims from P2P are the same



CDN-P2P

07/12/2015 42

P

P

P

P

Back End

Distribution Servers (CDN)

P2P Overlay


Adaptive Emergency Request Optimization

• General setup – 331 kbps stream rate

– Underlay • transmission error = 0

• one-way delay = [10;50] ms

• bandwidth distribution following Internet test measurements of North American hosts

• CDN servers have “infinite” bandwidth

– Bandwidth distribution restrictions: BASE, 50F, 75F, DIV2, DIV4




• General setup – Overlay

• size = {100, 500, 1000, 2000}

• peer in-degrees vary between 2 and 5; default = 3

• peer out-degrees vary between 0 and 10; default = Min(Bp/R, 10)

• topology policy: {random, bw-aware, bw-relax}

• Churn and Flash-crowds

– Initial seeding ratio = 2.5%

– 5 repetitions for each scenario

– Numerical results ignore 3 first minutes



P2P Distribution Efficiency

• Savings

– Bandwidth constrains reduce P2P efficiency



Average Peer Up. Bandwidth

BASE 7x

50F 3.5x

75F & DIV4

1.75x


• Problems

– Peers cannot establish input partnerships

– Peers underutilize upload bandwidth

– Emergency requests are not P2P-friendly

• High utility to a peer, low utility to the overlay




• Let’s give high bandwidth peers a better opportunity to contribute (cascade benefits) – How many should become prefetchers?

• AERO – Choose the prefetcher set size dinamicaly relative to the

amount of emergency requests – Increase prefetchers

• Improve data availability • Reduce emergency requests • Increase seeding cost

– AERO searches a sweet spot where (seeding + emergency) costs are minimum




07/12/2015 IMPLEMENTING QUALITY OF SERVICE INTO

P2P LIVE STREAMING NETWORKS 48

• AERO modify |Os| via seeding ratio S

• Total servers upload bandwidth consumption Ct

• Expected bandwidth consumption

– R|Os|t-1 (streaming rate x #prefetchersLastRound)

• Seeding Ratio Error Et = Ct - R|Os|t-1

Seeding Ratio Error

Positive Negative

Consumption > Expectation Consumption < Expectation

Underprovisioning Overprovisioning

Need to add prefetchers Need to remove prefetchers


07/12/2015 IMPLEMENTING QUALITY OF SERVICE INTO

P2P LIVE STREAMING NETWORKS 49

• How much to change S?

– Scaling factor: δ and Δ

• Increase δ; if Et has the same signal as before (trend)

• Decrease δ; we are close to a minima (+precision)

• δ <- Δ; if fluctuation on error is too big – Surge of peers

– Surge of emergency requests

AERO Results

07/12/2015 50

• Improvement over savings

– BASE could be using a lower S


AERO Results

07/12/2015 51

• Improvement over savings

– 75F needed a higher S

• Savings increase for DIV4 ~= 30%


AERO Results

07/12/2015 52

• Benefits result from less Emergency Request

– More prefetchers makes data more available resulting in a stronger reduction on emergency


AERO Results

07/12/2015 53

• Churn – 3% of peers are randomly selected to be replaced every 10s

– Reduction of 18% caused by constant initialization (~60s)


AERO Results

07/12/2015 54

• Flash crowd – Initial overlay size: 100 peers

– 1000 peers Join or Leave every 10’


AERO and TVPP

07/12/2015 55

• Hybrid CDN-P2P systems adapt easy to AERO

• AERO and the Emergency Request Service – Trivial accountancy of emergency request

– No seeding ratio to adjust • Increase handler’s out-degree to reduce their need

• Supernodes or bandwidth-aware topology needed

• Adaptive handler set

– Peer (that act as handler) capacity is not dedicated



07/12/2015 56

• Emergency Requests – Guarantee QoS

– P2P inefficient (less time to distribute)

– Costly

• AERO – Reduces servers costs adjusting S

– Replace lots of emergency by a few seeded

– Easily integrated and highly compatible with other solutions

CHUNK LOSSES


07/12/2015 57

CONCLUSION


Conclusion

• Most losses happen for specific reasons

– Emergency requests

• One important reason has been identified and treated

– SURE

• Emergency requests increase costs

– AERO



Conclusion

• How results connect to the other?



Future Work

• Implement the Emergency Request Service at TVPP – Explore multiple conceptual approaches

• Tweaks at AERO – AERO conception resulted from exploratory

research (17 versions)

• Implement AERO over TVPP



07/12/2015 61

THE END


Live Streaming




• Topology

– Mesh

– Tree

• Data exchange mechanisms

– Push

– Pull

07/12/2015 63

Hybrid

Hybrid



• What if the requests that miss are sent to the same candidate? – Candidates in each attempt for miss that always

requested to the same candidate • Much less candidates!




• Chunk loss (conscious)




• Latency (conscious)




• Peer Upload Bandwidth Distribution

07/12/2015 CHUNK LOSSES

IN P2P LIVE STREAMING NETWORKS 67


• Problem 1) Peers cannot establish input partnerships




• Problem 2) Peers underutilize upload bandwidth




• Problem 3) Emergency requests are not P2P-friendly

– High utility to a peer, low utility to the overlay




• Peers can’t establish input partnerships




• Peers underutilize upload bandwidth



AERO Results

07/12/2015 73

• Different overlay construction configurations


AERO Results

07/12/2015 74

• Different neighbor selection policies

– AERO benefits are greater than policies exchange


AERO Results

07/12/2015 75

• Local minima

– AERO can get stuck at a minima that is not global

– Decay tries to prevent that


This might happen!

reduction of the impact of chunk losses in p2p live streaming networks

Science