CMPT 886 Presentation

1
CMPT 886 Presentation

• Tran, Hua and Do A peer-to-peer architecture for
  media streaming
• Savio Lau (saviol_at_cs.sfu.ca)
• July 5, 2004

2
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

3
Introduction

• Recall Chaining
• A technique to pipeline the distribution of media
  in a unicast environment
• A receiver acts as a server to other receivers
  down the chain
• Tran, Hua and Do proposed the Zigzag approach to
  distribute live media in a peer-to-peer
  environment
• How is live streaming different from VoD?

4
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

5
P2P streaming requirements (1)

• End-to-end delay is a measure of liveliness
• Multicast tree height should be small to ensure
  liveliness
• However, bandwidth bottleneck occurs if tree is
  too wide especially when rooted at source
• Chain has least bottleneck but least lively
• A compromise between tree height and node degree
  is needed

6
P2P streaming requirements (2)

• Receiver behaviour is unpredictable
• Leave and join can occur at any time
• Descendents are abandoned on leaving
• Requires a quick, graceful and robust recovery
  mechanism

7
P2P streaming requirements (3)

• Receivers need to have some notion of the state
  of its peers
• To maintain connectivity
• Improve efficiency of network
• Thus require a control protocol that has small
  overhead to ensure scalability

8
C-Rules (1)

• Multicast tree Node degree is bounded by a
  constant
• Tree height is bounded by O(logN)
• Regional failure recovery affecting at most a
  constant number of receivers and little source
  burden

9
C-Rules (2)

• Low control protocol overhead
• A receiver at most exchanges to O(logN) receivers
• Average case is constant
• Fast join procedure
• Maintenance overhead is small and independent of N

10
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

11
Zigzag organization (1)

• Layer 0 contains all peers
• Each layer is partitioned into k,3k clusters,
  kgt3.
• Layer H-1 has one cluster of size 2,3k
• Each cluster at each layer j has a peer
  designated as the head. This head is the member
  of the higher layer j1 if j lt H-1.
• Server S is head of any cluster it belongs to

12
Zigzag organization (2)

• Each cluster has a non-head peer designated as
  the associate-head
• Exception Server S is the head and the
  associate-head at the highest layer H-1

13
Zigzag organization (2a)

• Cluster size is higher-bounded by size 3k to
  avoid undersize problems after splitting
• H is bounded by log3kN,logkN1 for N ? k
• Any peer at level jgt0 must be the head for all
  lower layers

14
Zigzag organization (3)
15
Zigzag organization (4)
16
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

17
Zigzag tree construction (1)

• Rule 1 A peer not at its highest layer has no
  links in or out
• Rule 2 Non-head members of a clusters receives
  content directly from its associate-head
• Rule 3 The associate-head of a cluster,
  excluding the server, gets content from a foreign
  head

18
Zigzag tree construction (2)
19
Zigzag tree construction (3)

• Observations
• Worst-case node degree of the tree is at most
  6k-3
• Height of multicast tree is at most 2logkN1

20
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

21
Zigzag control protocol (1)

• To non-head peers within the same cluster,
• A peer X sends its peer degree dX
• To the cluster head a peer X sends
• D(X), current end-to-end delay
• List of of current layer clustermates(1) where X
  is forwarding content to(2) who is the head of
  foreign subordinates X is forwarding content to

22
Zigzag control protocol (2)

• To the parent a peer X sends
• Its node degree dX
• Reachable(X) true if a path exists from X to a
  layer-0 peer, false otherwise
• Addable(X) true if a path exists from X to a
  layer-0 peer whose cluster size is in k, 3k-1

23
Zigzag control protocol (3)
24
Zigzag control protocol (4)

• Worst case control overhead is O(k logkN)
• Amortized worse-case overhead is O(k)

25
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

26
Zigzag client join (1)

• If P is a new client the join algorithm is as
  follows
• If X is a layer-0 associate-head
• Add P to the only cluster of X
• Make P a new child of X
• Else
• If Addable(X)
• Select a child Y where Addable(Y) and
  D(Y)d(Y,P) is minimum
• Forward the join request to Y
• Else
• Select a child Y where Reachable(Y) and
  D(Y)d(Y,P) is minimum
• Forward the join request to Y

27
Zigzag client join (2)

• Join algorithm terminates at layer-0
• If not at layer 0 a client goes down the
  multicast tree trying to find a non-full cluster
  to join with the least delay
• If no non-full cluster exists then try to find a
  reachable cluster with the least delay
• This requires the splitting algorithm
• Join Overhead number of nodes contacted is O(k
  logkN)

28
Zigzag client join (3)
29
Zigzag client departure (1)

• Departure of client X at layer j results in the
  following
• Parent removes link to X
• Children need new parent to get content
• Lower layer clusters 0,j-1 requires new head
• Current layer j requires new associate-head if X
  was the associate-head

30
Zigzag client departure (2)

• Case j0
• No work required if X was not associate- head
• If X was associate-head the non-head member with
  the best end-to-end delay is elected as associate
  head

31
Zigzag client departure (3)

• Case jgt0
• Each of Xs foreign subordinate Ys head is
  responsible to find a new parent for Y
• The new parent is chosen from Xs layer j
  clustermate with minimum degree
• For the layer j-1 cluster with X as its head, a
  new head is chosen randomly from its non-head
  peers. This peer replaces X at all layers 0,
  j-1 as well as at level j.

32
Zigzag client departure (4)
33
Zigzag client departure (5)
34
Zigzag client departure (6)
35
Zigzag client departure (7)

• At the worst case the number of peers that
  requires reconnection is 6k-2

36
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

37
Zigzag splitting (1)

• Case 1 j0
• Sort X1,,Xn in descending order of end-to-end
  delay. Move first n/2 peer X1,,Xn/2 to new
  cluster V
• Select X1 to be head of cluster V and X2 to be
  the associate-head. X3,,Xn/2 to be children
  of X2
• X1 and X2 as head and associate-head are then
  closer to the server

38
Zigzag splitting (2)

• Case 2 j exists in (0,H-1)
• Split cluster into 2 sets u and v such that the
  cluster size is in k,3k
• Redistribute peers in u and v such that the Xi ?u
  will have the least number of connection to
  foreign subordinates at level j-1 whose parents
  are Xl ?v and vice versa

39
Zigzag splitting (3)

• Case 2 j exists in (0,H-1) contd
• For each case where Xi foreign subordinates head
  residing in cluster V, subordinate should remove
  link to Xi and select new parent from cluster V
  and vice versa
• Cluster V selects new head and associate-head
  with least and 2nd least degree

40
Zigzag splitting (4)
41
Zigzag splitting (5)

• Case 3 j H-1
• Follow case 2s 3 steps
• S is promoted to a layer H, its foreign
  subordinate (LH-2) will reconnect to a random
  foreign head at LH-1 with the least degree
• Cluster U elects new associate-head with minimum
  degree and gets content from foreign head at
  layer H

42
Zigzag splitting (6)
43
Zigzag splitting (7)

• Oversize usually occurs at layer 0 but could
  cause its super cluster at higher layers
  resulting in multiple splits
• Worst-case split overhead is O(k)

44
Zigzag merging (1)

• Carried out from top to bottom with the highest
  undersize cluster merged first
• If cluster U is undersized cluster V from the
  same layer is chosen where V has the smallest
  size
• U and V must also have the same supercluster
• Cluster U and cluster V has head and
  associate-head XU, YU, XV, and YV respectively

45
Zigzag merging (2)

• Case 1 XU or XV is head at layer j1
• If XU and XV are heads, XU and YV are chosen as
  head and associate-head
• If XV was the associate-head a new associate-head
  with min degree is chosen
• Members reconnects to new associate-head as
  necessary
• XVs abandoned children selects new foreign heads
  with minimum degree

46
Zigzag merging (3)
47
Zigzag merging (4)

• Case 2 Neither XU nor XV is head at layer j1
• If one of them is associate-head at layer j1,
  then its chosen as head
• Else the higher degree of XU, XV is chosen as new
  head suppose XU has higher degree

48
Zigzag merging (5)

• Case 2 Neither XU nor XV is head (contd)
• XVs abandoned children reconnects to XU
• If cluster U is larger than V, then YU is chosen
  as associate head, else YV is chosen
• Members connect to YV to conform C-rules
• If YVs parent is XU then a new parent with
  smallest degree is chosen

49
Zigzag merging (6)
50
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

51
Zigzag performance enhancement

• Periodically, non-head clustermate can balance
  their service load to provide better quality of
  service
• Non-head clustermate with most load (as ratio to
  its bandwidth) transfers the load to the least
  loaded peer
• If the period is too often too many reconnection
  will result

52
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

53
Performance join
54
Performance split
55
Performance node degree
56
Performance control overhead
57
Performance failure overhead
58
Performance merge overhead
59
Questions and issues

• The value of k is highly important as to the
  server/peer load as well as the liveliness
• Relationship between liveliness and load given
  various values of k?
• Given a bound of end-to-end delay, is it possible
  to find a optimum value of k?
• Merge-split phenomenon may require a better merge
  algorithm
• (k-1)3k gt 4k-1 gt (2k-1) (2k)

60
Outline

• Introduction
• P2P streaming requirements and C-Rules
• Zigzag approach
• Organization
• Tree construction
• Control protocol
• Client join and departure
• Maintenance and enhancement
• Performance and issues
• Conclusion

61
Conclusion

• Zigzag provides a method of live streaming in a
  unicast peer-to-peer environment
• A novel multicast tree construction that provides
  upper bounds guarantees on all operations (join,
  departure, split, merge)
• Introduction of C-rules allows the algorithm to
  have high liveliness, low control overhead,
  efficient join and failure recovery and low
  maintenance overhead

62
References

• S. Sheu, Kien A. Hua, and W. Tavanapong,
  "Chaining A generalized batching technique for
  video-on- demand," in Proc. of the IEEE Int'l
  Conf. on Multimedia computing and System, June
  1997, pp. 110-117.
• S. Sheu, K. A. Hua, and T. Hu, Virtual Batching
  A New Scheduling Technique for Video-On-Demand
  Servers, In Proc. Of Intl Conf. On Database
  Systems for Advanced Applications (DASFAA97),
  Melbourne, Australia, April 1997.
• Tai Do, Kien A. Hua, and Mounir Tantaoui, P2VoD
  Providing Fault Tolerant Video-on-Demand
  Streaming in Peer-to-Peer Environment to appear
  in the Proc. of the IEEE International Conference
  on Communications (ICC 2004), June 20-24 2004,
  Paris, France

63
References

• A. Dan, D. Sitaram, and P. Shahabuddin, Dynamic
  batching policies for an on-demand video server,
  Multimedia Systems, Nov 1994. Vol 4. pp.112-121
• C.C. Aggarwal, J.L. Wolf, and P.S. Yu, On
  optimal batching policies for video-on-demand
  storage servers, in Proc. Of IEEE Intl Conf on
  Multimedia computing and System, Japan, June
  1996.
• Y. Guo, K. Suh, J. Kurose, D. Towsley, P2Cast
  P2P Patching Scheme for VoD Service, in WWW
  2003.
• V. Padmanabhan, H.Wang, P. Chou, Distributing
  Streaming Media Content Using Cooperative
  Networking, in NOSSDAV 2002.
• D. Tran, K. Hua, T. Do, A Peer-to-Peer
  Architecture for Media Streaming, in IEEE JSAC
  2003.

64
Questions?