P2P Live Streaming with TreeMesh Based Hybrid Overlay

1
P2P Live Streaming with Tree-Mesh Based Hybrid
Overlay
qihuang_at_mail.hust.edu.cn http//grid.hust.edu.cn/q
ihuang

• Qi Huang, Hai Jin, Xiaofei Liao
• Services Computing Technology and System Lab
• Cluster and Grid Computing Lab
• Huazhong University of Science and Technology

2
Outline

• A Problem motivation of our approach
• Our solution hybrid overlay
• Control tree (GUID, Maintenance, Synchronization)
• Data mesh (based on the control tree)
• More improvements
• Bandwidth estimation
• Zonal buffer request scheme
• Evaluation
• Conclusion
• Future ongoing work

3
A Problem

• Tree-based
• Good Peer Manage
• Churn Intolerance
• Load Imbalance
• Mesh-based
• High Data Utilization
• Inaccurate Control
• High Overhead
• Multi-Overlay
• Augment Transfer
• Still Control and Transfer in any single One

Peer Selection Optimization
Solo-Overlay Design
?
Control Transfer Overlay
Trade-Off
Data Distribution Optimization
4
Our Solution of the Problem

• Control Tree
• Transmit the Control Message
• Peer Selection
• Synchronization
• Log Collection
• Data Mesh
• Transmit the Data
• Media Data
• Buffer Status

Control Tree
Control Transfer Overlay
Data Mesh
Separate the Overlay by function
Use Both Benefits, Disregard trade-off
5
Control Tree for peer control/selection

• Separation Benefit tree adjustment not affect
  data
• Put Adjacent peers under the same sub-tree
• Same sub-tree are the selection preference

?How
BC
Broadcaster
E
A
B
Selection order
C
A
D
I
J
F
H
D
G
E
I
J
One channel, One Tree
6
GUID Control Tree Construction Rule

• GUID is both the peer ID and Landmark here
• Assumption Same ISP, Near District, Near IP
  decide network performance orderly
• Fortunately! This is not only assumption!
• Drawback Rely on the correctness of IP database

ISP/1B
City/2B
Postcode/2B
Public IP/4B
Private IP/4B
Type/1B
Extend/2B
Set Value
Nearer to A!
Easy and effect at most time!
7
Control Tree Maintenance(1/3)

• Peer Join - Based on GUID comparison
• A simplest example

Broadcaster

• Join S, compare ISP with A, C, F
• N, A have same ISP, redirect N to A, compare City
  with B
• N, A have same City, redirect N to B
• B has no child, join B

S
N
A
F
C
B
G
E
D
GUID
ISP
City
Postcode
Public IP
Private IP
N
No compare
Different Color, Different ISP
8
Control Tree Maintenance(2/3)

• Peer Join - Principles
• Local peers should be together.
• Service should be balance in distributed areas

Max Children3

• Ns ISP ! any A, C, Fs ISP S have no more
  service capabilities
• The most distributed three stay under S, the rest
  join the nearest one

B
G
Different Color, Different ISP
9
Control Tree Maintenance(3/3)

• Peer Leave
• Use leaf nodes (not behind NAT) for more service
  space
• Use peers in the same sub-tree

Broadcaster
Broadcaster
S
S
A
A
F
C
F
C
Leave
B
I
G
E
D
G
E
D
H
H
I
10
Time Synchronization

• In prevention of too big lag among peers
• Gossip in random mesh can not promise the time
  sensitivity
• Using Control Tree, GUID rule promises the
  synchronizing time sensitivity

Broadcaster
S
Inter-ISP connection
F
A
C
Synchronization
D
G
I
H
E
Different Color, Different ISP
11
Data Mesh Construction

• The mesh is based on the adjacent control tree
• Two Layers Member and Partner
• Members are from the same sub tree
• Partners are from Members with an elimination
  mechanism

BC
Broadcaster
E
I
A
A
B
Partner
C
J
D
F
H
D
G
E
Member
I
J
12
More Improvement Aspects(1/2)

• Bandwidth (BW) Estimation
• Network dynamics
• External value ! Internal can be used in the
  system
• Estimate peers Capabilities, considering
  historical records for adjustment
• initial as 4 times of streaming bit-rate

Cap
Request lt Cap
Cap 1
Cap - 1
Cap - 2
lt
Received
Former Missed
Cap - 3

Requested
Cap 0
13
More Improvement Aspects(2/2)

• Zonal Buffer Request Scheme
• Coolstreaming proved the LRF (Local Rarest First)
  has good load balance and fast data diffusion
• Optimize the LRF to a Zonal version

Urgent from source Ease LRF with broadcaster at
probabilities Common LRF without broadcaster
Time
First Slot
Buffer
2 Cycles
10 Slots
Common
Prefer
End
14
Evaluation Method

• Topology generated by BRITE
• Time Unit T 2 seconds
• 1000 router nodes with 28 hosts assigned each
• Choose hosts join the system with Poisson
  Distribution
• Bandwidth between routers are 4-15slots/T
• Delay and Bandwidth between hosts and routers are
  T/20, and 20slots/T
• Simulation Setup
• Simulation program comparing with coolstreaming
  and anysee.
• Source creates 8 slots per T
• Peer caches 256 slots of media data
• Peer maintains 38 partners
• Each peer runs 2000 T schedule periods and 5 times

15
Evaluation Result

• Comparison
• Control overhead coolstreaming(1.6),
  anysee(1), anysee2(0.9)
• Buffer full coolstreaming(35), anysee2(56)

Control Overhead Percentage
Buffer Full Percentage
16
Conclusion

• Separate the control and data transmit into
  different overlays
• Reduce the control overhead
• Adjacent selection promises the time sensitivity
• Optimize the LRF to zonal LRF request scheme
• Augment the buffer full percentage

17
Future Ongoing Work

• Control-Tree related
• Make the tree shared from one channel to multiple
  channels
• Improve the adjacent rule to AS-aware rule, to
  reduce the inter-AS traffic
• Change peer oriented to cluster oriented
• Data-Mesh related
• Propose new buffer management and schedule
  algorithm for high bit-rate media streaming like
  HDTV ( about 10mbps )
• Bring content-based transfer idea, to address
  multi-source problem

18
Thanks !