R2: Random Push with Random Network Coding in Live Peer-to-Peer Streaming

1
R2 Random Push with Random Network Coding in
Live Peer-to-Peer Streaming

• Mea Wang, Baochun Li
• Department of Electrical and Computer Engineering
• University of Toronto
• Dec. 2007

2
Main Idea
3
In traditional pull-based protocol

• select a segment
• the remaining segments the p has not completely
  received so fat.
• the segments that p has already received should
  be excluded.
• the explicit requests are made on the peer p to
  the seed.
• the seed then sending the segments.

4
In R2

• use random push
• randomly chooses a segment
• produces one coded block, among all remaining
  segments that p has not completely received
• sent the coded block to p
• without any request
• all seed cooperatively serve the missing segments
• without any explicit exchanges of protocol
  messages

5
Outline

• Introduction
• The design of R2
• Experiment
• Conclusion

6
Introduction
7
Introduction

• Network coding has been originally proposed in
  information theory.
• Can effectively improve the throughput of
  multicast communication sessions.

8
Introduction

• R2, incorporate random network coding with
  randomized push algorithm.
• To improve
• initial buffer delay
• reduced bandwidth cost
• In comparisons with a typical live streaming
  protocol.
• Vanilla, both without and with network coding.

9
The Design of R2
10
Environment Settings

• a typical live P2P session.
• referred to as a channel.
• a number of dedicated streaming servers.
• a large number of peers.
• live streaming is coded into a constant bit rate.
• 38-50 KB/S, real-world streaming application

11
Objective

• Shorter initial buffering delays
• Reduced server bandwidth costs
• streaming services have to provide additional
  bandwidth
• it is critical to minimize server bandwidth costs
  
• Smoother playback when bandwidth supply barely
  exceeds the demand
• when a very small number of servers (one or two)
  and a few hundred peers are engaged

12
Random network coding

• In traditional P2P, the live streaming is divided
  into segments.
• In R2, each segments is further divided into n
  blocks b1, b2, bn.
• Each bi has a fixed number of bytes k (referred
  to as the block size).

13
Random network coding

• when a segment is selected, the seed
  independently and randomly chooses a set of
  coefficients (m lt n) in
  for each coded block.
• then randomly chooses m blocks ,
  and produces one coded block x of k bytes.

14
Random network coding
b11 b12 b13 b14 b15 b16 b17 b18 b19
Segment-1 Segment-2

• 9 blocks, 3 coefficients (C1, C2, C3)
• X1 C1b11 C2b12 C3b13
• X2 C1b14 C2b15 C3b16
• X3 C1b17 C2b18 C3b19

15
Network coding

• Referred to the Network Coding for Large Scale
  Content Distribution.
• Without network coding
• Decide which block to receive based on a local
  decision.
• With network coding
• Do not have to worry about how to pick the block
  to transmit.

16
Network coding
17
Network coding
18
Random network coding

• The coding coefficients used to encode original
  blocks to x,
• and embedded in the header of the coded block for
  transmission.
• Theses n coding coefficients can easily be
  computed by multiplying with the (m n) matrix.

19
Random network coding

• As a total of n coded blocks x1 xn has been
  received, the original blocks can be recovered as
  Gauss-Jordan elimination computes.

20
Random push

• An important concern
• The missing segments that are close to the
  playback time is more urgent.

21
Priority Region

• The range of urgent segments may be T seconds.

22
Priority Region

• If a few missing segments -
• all of its seeds will serve these segments
• If there are no missing segment -
• choose missing segments from outside of the
  priority region in the playback buffer
• Randomized choice -
• is a certain probability distribution with a PDF.
  (Weibull distribution )

23
Knowledge of the missing segments

• The buffer map
• no longer sent periodically.
• when buffer status changes.
• played back or a segment is completed.
• The delay of obtaining buffer map is never higher
  than the network transmission delay.

24
Use larger segment

• In pull-based, a missing segment can only be
  served by one seed at a time.
• In R2, a segment can be served by multiple seeds.
• Each seed used its randomized selection algorithm
  to select a segment.
• Seeds collaborate with each other without any
  protocol messages.

25
Experiment
26
Experiment Settings

• Focused on our objective
• Contrast with Vanilla, network coding
• A data-driven pull-based design.
• Implemented Vanilla with network coding
• In order to obtain reasonable observation
• Only one stream server with 1MB/sec upload
  capacity
• Limits all peer connections to DSL with upload
  capacity uniformly distributed between 80 100
  KB/sec
• A stream rate of 64 KB/sec.

27
Experiment Settings

• Evaluate several important metrics
• Playback skip
• Bandwidth redundancy
• Buffering levels
• The uplink bandwidth consumption

28
Scalability
29
Scalability
30
Scalability

• The scalability of R2, peers in the live
  streaming session from 88 to 792 peers
• Fig(4a) shows that R2 offers steady playback
  quality, with less than 0.02 of playback skip
• Whereas Vanilla and network coding have an
  increasing percentage of playback skip as the
  number of peers increases
• Fig(4b) shows that R2 is effective use of
  bandwidth
• Fig(4c) shows that R2 saves almost 15 of the
  upload bandwidth on the streaming server
• R2 delivers robust and convincing performance in
  terms of both playback quality and bandwidth
  costs on the servers

31
Buffering Levels

• Average buffering level during the sessions and
  on each peer in a 64 KB/sec
• streaming session deployed to networks that
  consist of 88792 peers

32
Buffering Levels

• Examine the fluctuations in average buffering
  levels of a streaming session.
• In two representative sessions
• The buffering level ramps up quickly and remains
  stable in R2.
• The buffering level increases as more peers
  become available
• It is shows that
• The perfect playback quality (nearly nonexistent
  playback skips)
• The random push and priority region design
  guarantee fast delivery of each segment.

33
Initial Buffering Delays

• Present the time that all three algorithms take
  to fill the priority region when a peer join a
  session.
• It takes less time for R2 to fill the priority
  region

34
Initial Buffering Delays

• The effect of different initial buffering delays
  in R2

35
Initial Buffering Delays

• The effect of different initial buffering delays
  in R2 is not as significant as it is in
  traditional protocols.
• Both Vanilla and network coding have unacceptable
  playback quality when the initial buffering delay
  is 8 seconds
• Which explains why they cannot support fast
  channel switching well

36
Initial Buffering Delays

• To gain a better understanding of the priority
  region setting
• fixed the initial buffering delay to 24 seconds
• Increased the length of the priority region from
  8 sec to 20 sec.

37
Initial Buffering Delays
38
Initial Buffering Delays

• As the priority region grows, the earlier
  segments in the buffer become less urgent,
  leading to lower playback quality.
• The length of the priority region does not
  materially affect the performance,
• since R2 effectively utilizes all bandwidth to
  maintains high buffering levels

39
Effects of random segment size
40
Effects of random segment size

• Though larger segments offer higher buffering
  levels, the priority region is not filled as
  quickly as during the initial buffering delay.
• Larger segment does not necessarily offer better
  quality since a missing segment may results in
  longer skips in seconds.

41
Conclusion

• Priority region.
• Buffer map?

42
THANKSQA