Peer-to-Peer 3D Streaming Dissertation Oral Exam

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

2. IEEE INFOCOM 2008

3. IEEE INFOCOM 2008

4. 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?

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

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

14. Hoppe 1996 Progressive Meshes Object streaming

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

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

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

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. Client-server: has inherent resource limit The scalability problem Resource limit [Funkhouser95]

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

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

22. World model & area of interest (AOI)

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

24. State vs. content management • 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

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

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

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

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

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

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

31. Object discovery via scene descriptions star: self triangles: neighbors circle: AOI rectangles: objects

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

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

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

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

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. 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)‏

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

40. Server bandwidth usage

41. Client bandwidth usage (random)

42. Client bandwidth usage (cluster)‏

43. Effect of user density

44. Fill ratio

45. Base latency

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

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

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

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