ndn rtc
play

NDN-RTC Peter Gusev UCLA REMAP 9/5/2014 NDNComm 2014 Demo - PowerPoint PPT Presentation

Dec 20, 2023 •275 likes •491 views

NDN-RTC Peter Gusev UCLA REMAP 9/5/2014 NDNComm 2014 Demo Producer 1: Live NDNComm HD streaming (1080p 30fps, 1.5Mbps) Producer 2: REMAP office webcam producer (SD, 30fps, 500Kbps) Demo 1: Demo-1 Demo-2 Consumer for 3

  1. NDN-RTC Peter Gusev UCLA REMAP 9/5/2014

  2. NDNComm 2014 Demo • Producer 1: Live NDNComm HD streaming (1080p 30fps, 1.5Mbps) • Producer 2: REMAP office webcam producer (SD, 30fps, 500Kbps) • Demo 1: Demo-1 – Demo-2 Consumer for 3 streams: producer+consumer NDN-Comm NDNComm, REMAP and producer Demo-2 REMAP – Producer: webcam producer (SD, 25fps, 500Kbps) • CAIDA/UCSD UA (arizona) Demo 2: Simulated periodic link break – Demo-2 Consumer for 3 streams: REMAP-1 Demo-1 NDNComm, REMAP and producer producer+consumer Demo-1 – Producer: webcam producer (SD, 25fps, 500Kbps) 1/6/2015 2

  3. NDN Real Time Conferencing Library Goals: – Real-time audio/video/text chat library which allows many-to- many conferencing over the NDN network and requires no direct communication between peers – Starting point for NDN traffic congestion control algorithm research – Test NDN-CPP library and NFD – Traffic generator for the testbed Initial gains over IP: – No load on a publisher (network does content distribution) – Intrinsic multicast (one-to-many and many-to-many scenarios) – On track for peer-to-peer with no STUN, TURN, etc. 1/6/2015 3

  4. NDN-RTC library • C++ code • Linked against NDN-CPP and WebRTC libraries • Interfaces: – Publish media (audio/video) streams – Fetch media (audio/video) streams from multiple producers • Demo app is provided – Publishing audio/video stream – Fetching audio/video streams (multiple) 1/6/2015 4

  5. Publisher 1/6/2015 5

  6. Publisher. Multiple encoder threads 1/6/2015 6

  7. Publisher. Multiple media streams Cache interests data NDN 1/6/2015 7

  8. Segmentation • Encoded frames (1Mbps) : – Key: ~30KB (20 segments) – Delta: ~1-6KB (~4 segments) • Producer stores segments in app cache – Segment size - 1000 bytes – NDN overhead - ~330-450 bytes – Complete segment less than MTU 1/6/2015 8

  9. User namespace root /<root>/ndnrtc/user/<producer-id>/ • Root: – User prefix (username) streams • Media streams: – Media streams (audio/video) media streams audio0 video0 video1 stream info – Streams meta info • Encoding threads: encoding threads thread1 thread1 thread2 thread3 – Individual encoding parameters • Frame type: frames – Key and Delta frames in separate branches • Packet: packet_type delta key – Individual media packets (audio samples, encoded video frames) packet • 0 1 ... N Data type: – Data and Parity segments in separate branches data_type • data parity Segments: – Actual NDN-data objects segment %00 %01 ... %MM %00 %01 1/6/2015 9

  10. Consuming Interests Interest pipeliner NDN Segments %00%N1 %00%N2 ... %00%NN Buffer playhead Playout Encoded Raw frame Decoder Renderer frame 1/6/2015 10

  11. Frame fetching gen – time interval between receiving an interest and satisfying it • Generation delay d n with data ( producer-side ) • asm – time needed to fetch all frame segments ( consumer side ) Assembling time d n • RTT n – consumer-measured round trip time for the interest ( consumer side ) 1/6/2015 11

  12. Interest pipeline and retransmission B 1 >= RTT, B 2 >= RTT Minimal buffer size >= 2*RTT milliseconds 1/6/2015 12

  13. Chase mode • There is no direct coordination b/w consumers and producers • Producer generates data at high rate (~20-30FPS) and this data becomes outdated fast • Start-up time: consumer is aware that stale data is present in the network and tries to avoid playing it back • Chasing mechanism: – Cache exhaustion: • Latest data can not arrive faster than it’s being produced – it arrives at producer’s rate • Cached data arrives with the same frequency it was requested – Chase mode: • issue interest for the RIGHTMOST segment • upon receiving first segment – start issuing interests for the next frames with interval d int < Producer rate • Monitor d arr – frame inter-arrival interval: If d arr is increasing – continue fetching – If d arr is stable – switch to “Fetch“ mode – 1/6/2015 13

  14. Chase mode (cont.) d arr 70 Chase mode Fetch mode 60 50 Milliseconds 40 30 20 10 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Milliseconds Future improvement (suggested by Dave Oran) : 1. piggyback video sync data on audio stream 2. use audio stream for chasing instead of video 1/6/2015 14

  15. Forward Error Correction • OpenFEC library • Producer publishes parity data under separate namespace: – <frame prefix>/<frame#>/parity/<segments> • Consumer may additionally fetch parity data for enabling FEC • If by the playback time frame is missing any segments – FEC is applied as the “last resort” • Amount of parity data is configurable (currently 20%) • Collaborated with Daisuke Ando (Exchange student from Japan) • Future improvement (suggested by Dave Oran) : use frame- level parity data rather than segment-level 1/6/2015 15

  16. Demo app • Console app – MacOS X 10.9 and up – Buildable from sources github.com/remap/ndnrtc – Redmine redmine.named- data.net/projects/ndnrtc • Functionality: – Publish audio/video stream – Fetch multiple audio/video streams 1/6/2015 16

  17. Future steps • Real-time Adaptive Rate Control: – In collaboration with Panasonic R&D department (Muramoto-san, Yoneda-san) – Keep low-latency transmission & best throughput – Maintain RTT fairness (self-fairness) – Consumer-driven – NW bandwidth estimation based on RTT and timeouts – Control interest rate according to bandwidth estimation • Conference discovery (Zhehao Wang) • Text chat (Zhehao Wang) • Browser integration (Zhehao Wang) • Security • Desktop conference tool – Adding modularity to the existing code • Compare to existing solutions – Can be RTC over NDN better than IP? • Scalability tests 1/6/2015 17

  18. Areas for future research • Interests pipelining – Express just enough interests to fetch needed frames and meet the deadline, but keep low latency • Alternatives to cache exhaustion – How consumer can be sure that it’s getting the latest data from the network without explicit producer-consumer signaling? • Security – Trust model; signing and verification; encryption approach? • Scalability – How many conference peers can there be? – What are the requirements for the forwarder? – What are the requirements for the peers? • Relationship between forwarder strategy and application – Best route strategy 2 1/6/2015 18

  19. Links • Source code – https://github.com/remap/ndnrtc – branches: • master – current released version (v0.9.alpha4) • dev – current development branch (v0.9.alpha5) • MacOS binaries (library, demo, supporting files) – https://github.com/peetonn/ndnrtc-archive – Special branch for demo events: • demo/ndncomm2014 • Redmine – http://redmine.named-data.net/projects/ndnrtc/issues 1/6/2015 19

  20. Thanks Q&A Peter Gusev peter@remap.ucla.edu 1/6/2015 20

Recommend

More recommend