1. Peer-to-Peer 3D Streaming Dissertation Oral Exam Shun-Yun Hu Department of Computer Science and Information Engineering National Central University Dissertation Advisor: Prof. Jehn-Ruey Jiang 2009/11/17

2. IEEE INFOCOM 2008

5. Motivation Two trends in virtual environments (VEs)  Larger and more dynamic content  More worlds Content streaming is needed  80% - 90% content is 3D (e.g., 3D streaming) How to support millions of concurrent users? 5/

6. Imagine you start with a globe

7. Zoom in…

8. To Chung-Li

9. and NCU

10. Right now it’s flat…

11. But in the near future…

12. Outline Introduction Background A Model for P2P 3D Streaming The Design and Evaluation of FLoD FLoD Extensions Discussions Conclusion 12/

13. 13/ What is 3D streaming? Continuous and real-time delivery of 3D content over network connections to allow user interactions without a full download.

14. 14/ Object streaming Hoppe 1996 Progressive Meshes

15. 15/ Scene streaming Multiple objects Object selection & transmission Teler &Lischinski 2001

16. 16/ Visualization streaming Large volume Time-varying Resource intensive Olbrich & Pralle 1999

17. 17/ Image-based streaming Server- rendered Thin clients Less responsive Cohen-Or et. al. 2002

18. 18/ 3D streaming vs. media streaming Video / audio media streaming is very matured User access patterns are different for 3D content  Highly interactive  Latency-sensitive  Behaviour-dependent  Non-sequential Analogy  Constant & frequent switching of multiple channels

19. The scalability problem Client-server: has inherent resource limit Resource limit [Funkhouser95] 19/

20. A potential solution Peer-to-Peer: Use the clients’ resources Resource limit [Keller & Simon 2003] 20/

21. Outline Introduction Background A Model for P2P 3D Streaming The Design and Evaluation of FLoD FLoD Extensions Discussions Conclusion 21/

22. 22/ World model & area of interest (AOI)

23. 23/ Model and assumptions For a given object (mesh or texture) All content is initially stored at a server

24. State management  Small & updatable (~ KB)  May require security / anti-cheating  Ex. Avatar positions, health points, equipments Content management  Large & relatively static (~ MB)  May authenticate via hashing  Ex. 3D polygonal models & textures State vs. content management 24/

25. 25/ 3D streaming requirements Streaming quality  User's perspective  “how much?” & “how fast?”  Speed Scalability  Server's perspective  How to offload?  Concurrent users

26. Challenges for P2P 3D streaming Distributed visibility determination  Minimize server involvement  Efficient determination without global knowledge Dynamic group management  Discovery of data sources  Continuous avatar movements and real-time constrain Peer & piece selection  Optimal visual quality  Content availability and bandwidth constrain 26/

27. A conceptual model Pre-install: movement, rendering (client) 3D streaming: partition + fragmentation(server) prefetching + prioritization(client) P2P: selection(client) 27/

28. P2P 3D streaming issues Object discovery Source discovery State exchange Content exchange P2P video/file sharing 28/

29. Outline Introduction Background A Model for P2P 3D Streaming The Design and Evaluation of FLoD FLoD Extensions Discussions Conclusion 29/

30. 30/ Observation Users tend to cluster at hotspots Overlapped visibility = shared content

31. 31/ Object discovery via scene descriptions star: selftriangles: neighbors circle: AOIrectangles: objects

32. 32/ Source (neighbor) discovery via VON Boundary neighbors New neighbors Non-overlapped neighbors [Hu et al., IEEE Network, 2006] Voronoi diagrams identify boundary neighbors for neighbor discovery

33. Flowing Level-of-Details (FLoD) Object discovery: scene descriptions Source discovery:VON State exchange: query-response (pull) Content exchange:randompeer selection sequential piece selection 33/

34. 34/ System architecture Data flows (A): scene request list(B): scene descriptions (C): piece request list(D): object pieces

35. 35/ Prototype experiment Progressive models in a scene (by NTU) Peer-to-peer AOI neighbor requests(by NCU)

36. 36/ Prototype experiment Data  3D scene from a game demo (total ~50 MB) Setup  100 Mbps LAN  10 participants, 48 logins captured in 40 min. Results  Found matching client upload & download  Avg. server request ratio (SRR): 36%

37. 37/ Simulation setup Environment  1000x1000 world, 100ms / step, 3000 steps  client: 1 Mbps / 256 Kbps, server: 10 Mbps (both)‏ Objects  Random object placement (500 objects)‏  Object size based on prototype (~ 15 KB / object) User behavior  Random & clustering movement (1.5 * ln(n) hotspots)‏

38. 38/

39. Simulation metrics Scalability  Bandwidth usage(Kbytes / sec)  Server request ratio(% obtained from server) Streaming quality  Base latency(delay to obtain 1 st piece)  Fill ratio(obtained / visible data) 39/

40. 40/ Server bandwidth usage

41. 41/ Client bandwidth usage (random)

42. 42/ Client bandwidth usage (cluster)‏

43. 43/ Effect of user density

44. 44/ Fill ratio

45. 45/ Base latency

46. 46/ Effect of upload bandwidth

47. Outline Introduction Background A Model for P2P 3D Streaming The Design and Evaluation of FLoD FLoD Extensions Discussions Conclusion 47/

48. Problems with basic FLoD Source discovery: too few sources State exchange: pull may be slow Content exchange:better than random? Real environment considerations  Peer heterogeneity  Bandwidth utilization 48/

49. FLoD enhancements Enhanced peer & piece selection  Wei-Lun Sung(ACM NOSSDAV’08) Bandwidth-aware streaming  Chien-Hao Chien(ACM NetGames’09) 49/

50. 50 Enhanced Selection Proactive notification of availability (push) Periodic incremental exchange of content availability information with neighbors. Msg_TypeObj_IDMax_PIDObj_IDMax_PID ‧‧‧‧ incremental content information 50/

51. 51 Multi-Level AOI Request Localized requests may prevent contentions Peers request from closer neighbors/levels first 51/

52. Compare enhanced strategy with FLoD Simulation Environment 52/

53. 53 Base Latency 53/

54. 54 Fill ratio 54/

55. Bandwidth-aware Peer Selection Region-based Peer List to increase sources Pre-allocation of connection channels Multi-source peer selection  Channel neighbors(bandwidth reservation)  AOI neighbors(no response guarantee)  Server(no response guarantee) Tit-for-Tat peer selection (from BitTorrent)  Channel-neighbor first  Higher contributor first 55/

56. Simulation environment World Size 1000 x 1000 (units) Cell Size 100 x 100 (units) AOI Radius 100 (units) Time steps 1500 (steps/ sec) Object Data Size Range 100 – 300 (KB) % of Base Piece 10% Refinement Piece Size 5 (KB) Server Bandwidth Download/Upload 1000/ 1000 (KB/sec) User Bandwidth Distribution Downlink (KB/sec) Uplink (KB/sec) Fraction of nodes 96100.05 187300.45 3751000.40 12506250.10 [Bharambe et al, 2006] 56/

57. Streaming quality (= BW utilization) 100 to 500 objects, fixed at 100 peers 57/

58. System scalability 50 to 450 peers, fixed 300 objects 58/

59. Fill ratio time-series (QoS) original FLoDEnhanced 59/

60. Outline Introduction Background A Model for P2P 3D Streaming The Design and Evaluation of FLoD FLoD Extensions Discussions Conclusion 60/

61. LODDT (Cavagna et al. 2006) ‧ ‧ ‧ ‧ ‧ Object Tree NodeAura U 61/

62. HyperVerse (Botev et al, 2008) Backbone + overlay architecture 62/

63. Comparisons 63/

64. Outline Introduction Background A Model for P2P 3D Streaming The Design and Evaluation of FLoD FLoD Extensions Discussions Conclusion 64/

65. Summary P2P 3D streaming has four main issues  Object discovery  Source discovery  State exchange  Content exchange FLoD demonstrates that P2P allows  Much lower server resource usage  Better performance in crowding FLoD’s performance can be enhanced with  Pushed-based state exchange  Pre-allocated fixed-size bandwidth channels 65/

66. Conclusion 3D streaming could become an important net traffic  Non-sequential access  Latency-sensitive Peer-to-peer streaming is promising  Reduce server resource usage  Dynamic interest groups New area with many interesting issues  Graphics: progressive encoding / decoding, compression  Networking:group discovery, prefetching, topology, versioning 66/

67. Future works Practical Adoptions  Dynamic content update  Topology-aware P2P 3D streaming  Secure P2P 3D streaming Open questions  Many small worlds vs. one large world  High-definition (HD) content  Incentives & killer apps 67/

68. FLoD publications 1. Shun-Yun Hu, "A Case for 3D Streaming on Peer-to-Peer Networks," in Proc. ACM Web3D, Apr. 2006, pp. 57-63. 2. Shun-Yun Hu, Ting-Hao Huang, Shao-Chen Chang, Wei-Lun Sung, Jehn- Ruey Jiang, and Bing-Yu Chen, "FLoD: A Framework for Peer-to-Peer 3D Streaming," in Proc. IEEE INFOCOM, pp. 1373-1381, Apr. 2008. 3. Wei-Lun Sung, Shun-Yun Hu, and Jehn-Ruey Jiang, "Selection Strategies for Peer-to-Peer 3D Streaming," in Proc. NOSSDAV, May. 2008. 4. Chang-Hua Wu, Shun-Yun Hu, and Li-Ming Tseng, "Discovery of Physical Neighbors for P2P 3D Streaming," in Proc. ICUMT, Oct. 2009. 5. Mo-Che Chan, Shun-Yun Hu, and Jehn-Ruey Jiang, "Secure Peer-to-Peer 3D Streaming," Multimedia Tools and Applications, vol. 45, no. 1-3, Oct. 2009, pp. 369-384. 6. Chien-Hao Chien, Shun-Yun Hu, and Jehn-Ruey Jiang, "Bandwidth-Aware Peer-to-Peer 3D Streaming," in Proc. NetGames, Nov. 2009. 7. Shun-Yun Hu, Jehn-Ruey Jiang, and Bing-Yu Chen, "Peer-to-Peer 3D Streaming," IEEE Internet Computing, to appear, 2009. 68/

69. 69/ Q & A Thank you! http://ascend.sourceforge.net

70. 70/ Related work 3D streaming  Progressive meshes [Hoppe 96]  Geometry image [Gu et al. 02]  Scene streaming [Teler and Lischinski 2001] P2P media streaming  Zigzag, oStream, Coolstreaming, Prime Nonlinear media streaming  Channel Set Adaptation (CSA) [Gotz, 2006] P2P 3D streaming  LOD-DT [Cavagna et al. 2006]

71. Secure P2P 3D streaming How to authenticate content from untrusted peers? Four types of content  Whole model(digital signature)  Linear stream(hash chain)  Independent stream(Rabin-based)  Partially linear stream(hash DAG)

72. 72/ Cache utilization

73. Experimental results

74. 74 Extended Candidate Buffer Non-AOI neighbors may still possess data Maintain extra list of non-AOI neighbors R S Obj 74/