Efficient Uplink Bandwidth Utilization in P2P-TV STREAMING SYSTEMS - PowerPoint PPT Presentation

About This Presentation
Title:

Efficient Uplink Bandwidth Utilization in P2P-TV STREAMING SYSTEMS

Description:

Title: Efficient Uplink Bandwidth Utilization in P2P-TV STREAMING SYSTEMS Last modified by: Jehan-Fran ois P ris Document presentation format – PowerPoint PPT presentation

Number of Views:62
Avg rating:3.0/5.0
Slides: 33
Provided by: uhe4
Learn more at: https://www2.cs.uh.edu
Category:

less

Transcript and Presenter's Notes

Title: Efficient Uplink Bandwidth Utilization in P2P-TV STREAMING SYSTEMS


1
Efficient Uplink Bandwidth Utilization in P2P-TV
STREAMING SYSTEMS
  • Presenter
  • Sonal Khodiyar

2
Idea!!
  • Mesh based P2P systems
  • peers exchange small Chunks of video over a
    generic overlay topology
  • automatic adaption of a peer service rate to its
    upload capacity
  • match the demand from other peers
  • Maximize peer upload capacity utilization
  • Minimize chunk delivery time

3
Introduction
  • Meshed based P2P systems
  • video encoded in real time
  • sliced in chunks
  • exploits fully distributed epidemic approach
  • Delivery delay, a key aspect
  • Download rate is dictated by video rate
  • chunk scheduling policy
  • peers decide delivery of chunks to peers

4
Chunk Distribution Algorithm
  • Push Based
  • peers organized in distribution tree
  • static
  • number of consecutive chunks are delivered
  • Pull Based
  • generic overlay topology
  • preliminary trading phase
  • advertises chunks to neighbors
  • neighbors select desired chunks

5
Drawbacks
  • Push based algorithms
  • higher complexity managing trees
  • lower robustness to churning
  • scalability limited in term of number of peers
  • Pull based algorithms
  • careful design of trading phase
  • additional signaling delay
  • excessive cost for better resource usage and
    resilience to churning

6
Paper Focus
7
Design of Trading Phase
  • Advertisement via OFFER message
  • Response via SELECT message
  • Transmission of chunks using FIFO queue
  • Acknowledgement via ACK message

8
Requirements of pull mechanism
  • Video chunks must be small
  • UDP preferred
  • need to handle congestion control
  • download rate limited by stream rate
  • Controlling uplink bandwidth utilization

9
Paper Propose
10
  • Scheme to automatically adapt
  • frequency of peer OFFERS
  • no of peers receiving OFFERS
  • Solution is to adapt above parameters to
  • Video rate
  • upload capacity
  • exploiting upload capacity reducing chunk
    delivery delay and losses

11
System Description
  • N, set of peers composing overlay with
    cardinality N
  • playout Delay Dmax
  • Cp, Set of p neighbors
  • Considering simplest case
  • overlay network is built once and on random bases
  • uplink capacity bottleneck system performance
  • chunk delivery loss main performance indexes
  • allows us to gauge fairness and efficiency in
    allocating system upload capacity

12
Tdiff is the time between a new chunk arrival
and the moment in which the tx queue becomes
empty.Toffer is the time between a new chunk
arrival and the moment in which starts a new
offer session.Tqueue is the interval that runs
from the reception of last select message until
the moment in which the tx queue becomes
empty.Np is the number of neighbors that a peer
contacts in every offer session.
P1
P5
P2
13
Design Choices
  • Peer Selection
  • Chunk Selection
  • OFFER Frequency
  • values of parameter M( desired Chunks) Np

14
  • utilizes Random Peer - Random Useful Chunk
    Selection policy
  • set M1, to avoid transmitting many chunks to
    same neighbor
  • issue a new offer based on no. of chunks waiting
    to be transmitted.

15
Adaptive Signaling Protocol
  • Np has to match the peer upload capacity
  • Np determines bandwidth allocation
  • if Np is too small
  • upload bandwidth not exploited at best
  • transmission queue empties quickly
  • long period of inactivity
  • if Np is too large
  • transmission queue fills up
  • additional chunk delivery delay / losses
  • lot of signaling overhead produced

16
  • Np must be adapted to upload capacity of each
    peer, avg. RTT, and actual system demand rate
  • We have the following algorithm
  • if( Tdiff gt 2AvgRTT)
  • Np--
  • else if( PosSelectNum / OfferNum gt CR)
  • Np
  • algorithm runs only once per trading phase a
    new chunk arrives

17
Performance Evaluation
  • Assumptions Scenario
  • 15 of peers are in class1, total Bandwidth equal
    to 5Mb/s /- 10
  • 35 of peers are in class2, total Bandwidth equal
    to 1Mb/s /- 10
  • 30 of peers are in class3, total Bandwidth equal
    to 0.64Mb/s /- 10
  • 20 of peers are in class4 with negligible upload
    bandwidth

18
  • Video source belog to Class1 peers, corresponding
    avg. Bandwidth is EBp 1.3Mbps
  • video rate rs , so that load is
  • ? rs / EBp
  • Chunk size is fixed, L100Kb, i.e, 8 UDP packets.
  • source emits 2000 chunks, rs 0.8Mbps
  • latency lpq is added to transmission time.

19
(No Transcript)
20
clipping ratio 0, load 0.9
21
load 0.9, rs1.1Mbps, shows there is tradeoff
between losses and signaling overhead
22
selected reasonable tradeoff between signaling
overhead and loss probability
23
Performance Analysis Comparison with fixed Np
Schemes
24
loss probability VS load
25
Larger CR can actually help in reducing delays
when the system is underloaded
26
Bandwidth allocation among peers
27
bandwidth utilization per peer measured as the
fraction of time the uplink channel is used to
transmit chunks
28
Avg. values per class and Jains fairness Index
29
Signaling Overhead
30
total number of received signaling messages per
peer Versus Load
31
Np5, leads to smallest number of signaling
messages, however also leads to worst performances
32
Conclusion
  • Strong limitation of the number of signaling
    messages leads to bad performance in terms of
    losses
  • proposed algorithm
  • actually reduces the amount of signaling
    overhead
  • introduces fair efficient upload bandwidth
    utilization
  • improved system performance in terms of delay and
    losses
Write a Comment
User Comments (0)
About PowerShow.com