Consumer driven Adaptive Rate Control for Real-time Video Streaming in CCN/NDN

Transcription

1 Consumer driven Adaptive Rate Control for Real-time Video Streaming in CCN/NDN Takahiro YONEDA, Ryota OHNISHI, Eiichi MURAMOTO(Presenter),, Panasonic Corporation Jeff Burke, UCLA Contact: Paper will be to appear in IEICE (conditional acceptance)

2 Table of Contents Focused requirements and target applications Function of PIT, CS in CCN/NDN (background knowledge) 2 types of RTT variation Source change, congestion Proposed method Receiver driven, focusing on RTT fairness Simulation result Single bottleneck (basic), multiple-rtt Implementation Conclusion 2

3 Requirement for the Real-time Adaptive Rate Controlling Target: Live real-time streaming like conferencing Live Buffer time tolerant Archiving video (Library) CDN of video (VoD, youtube, etc) CDN of Live video (Live sports, etc) Security Camera (airport, street,,,) Security Camera (real-time tracking) Video conferencing (interactive talk) Low delay delivery less than 2ms for example Sneaker network(production)

4 Example of the target application Security camera, Real-time tracking Multiple user access to the different sources criminal Some content ( at certain bit-rate) might be cached on router

5 Assumption for the target application Data (frame data) is divided into a plurality of data chunk Each data chunk has sequential number (in its name) Ex. NDNvideo Sequential number

6 Background knowledge: CCN/NDN, CS and PIT 2 Fig: Presentation at Panasonic Named Data Networking(NDN), Jeff Burke, June 213

7 (1) RTT variation by source change (unexpected) Publisher node Hits Content Store P Router Router1 Router2 Router3 (a) Hits PIT (b) C1 C2 C3 Consumer nodes Hits Content Store P Router Router1 Router2 Router3 Hits Content Store C1 C2 C3 (c) P Router Router1 Router2 Router3 Hits PIT Hits PIT C1 C2 C3 Interest packet Data packet 7

8 (2) RTT increase by congestion, by queuing delay Queuing delay increasing other traffic audio/video data packets Router Link buffer Link buffer If input rate is over the output link speed incoming packets are stacked in the link buffer, so that network delay of each packet is increase. 8

9 Problem scope Targets Keep low latency transmission & available best throughput Maintain RTT fairness (self fairness + RTT fairness) Points Consumer-driven, (no router support) Network bandwidth estimation based on RTT variation & packet loss Control Interest sending rate according to the bandwidth estimation Select video stream bit-rate according to the bandwidth estimation Considering 2 types of RTT variation (unexpected or congestion) 9

10 Related works (1) Consumer-driven approach AIMD based transport mechanism [1-3] Low throughputs in large RTT environment Easy to increase queuing delay Live video distribution [4,5] fixed sliding window might be assumed? No adaptability for network bandwidth variation [1] Giovanna Carofiglio, et al. Icp: Design and evaluation of an interest control protocol for content-centric networking. INFOCOM NOMEN Workshop, 212. [2] Stefano Salsano, et al. Transport-layer issues in information centric networks. ACM SIGCOMM ICN Workshop, 212. [3] Somaya Arianfar, et al. Contug: A receiver-driven transport protocol for content centric networks. IEEE ICNP, 21 [4] Ciancaglini V., et al. CCN-TV: A Data-centric Approach to Real-Time Video Services. Advanced Information Networking and Applications Workshops [5] Derek Kulinski, and Jeff Burke. NDNVideo: Random-access Live and Pre-recorded Streaming using NDN. In Technical Report 1

11 Related works (2) Router support approach Hop-by-hop Interest flow sharping mechanism [6] Problem of deployment [6] Giovanna Carofiglio, et al. Joint hop by hop and receiver-driven interest control protocol for content-centric networks. ACM SIGCOMM ICN Workshop,

12 Proposed method Receiver driven 1. Measure RTT on receiving each Data packet 2. Calculate average RTT in each short period 3. Control Interest sending rate in each short period AvgRTT (RTTmin + jitter_offset) or Consecutive AvgRTT decrease pps pps / pps (α 1) now prev prev Consecutive AvgRTT increase or Packet loss pps now pps prev pps prev (<β<1) AvgRTT : Average RTT in each short period RTTmin : Minimum RTT pps : Number of sending Interest packet per second

13 Distinguish consecutive RTT change and unexpected one Average RTT [ms] Consecutive RTT increase or packet loss Judge to be congested Decrease Interest rate P Single RTT increase Judge to be changed location of content cash Keep Interest rate Average RTT calculation in each period Time [ms] Consecutive RTT decrease/stable RTT Judge to be stable Increase Interest rate Increase Interest rate pps pps / pps t t t P Decrease Interest rate pps pps pps t P t P t P Interest sending interval ppt t Number of Interest packet Interval s x pps t in one second P Constant period of estimation s Content chunk size [byte] x Pre-defined constant value 13

14 Simulation with ndnsim (ns-3) Basic evaluation on single bottleneck link Assumption Each consumer node requests content with sequential numbering in the Content Name for each Interest packet Each consumer node has determined the Content Name to fetch through other means Each publisher node provides single video stream with variable bit-rate Publisher nodes Consumer nodes BW Pn-R1 1Gbps P1 P2 Router1 Bottleneck Link Router2 C1 C2 D Pn-R1 BW R2-Cn D R2-Cn 1ms 1Gbps 1ms Pn Cn Queue Droptail Link bandwidth=bw link Link delay=d link Queue Size 5pkt 14

15 Estimate Rate [kbps] Estimate Rate [kbps] Basic simulation results (1-1) Evaluation of bandwidth efficiency & transmission latency on the single bottleneck link 12 C Time [sec] (n=1, BW R1-R2 =1Mbps, D R1-R2 =8ms) C1 C2 C3 C4 Average RTT [ms] 4 C Time [sec] (n=4, BW R1-R2 =1Mbps, D R1-R2 =8ms) Average RTT [ms] C1 C2 C3 C Time [sec] 1 2 Time 3 [sec]

16 Comparison vs. AIMD AIMD (Additive Increase/Multiplicative Decrease) Decrease when packet loss, (duplicated ACK or time-out) Proposed method: - The throughput is more stable in various RTT - Lower delay (especially in short RTT) (n=1, BW R1-R2 =1Mbps, D R1-R2 =3-148ms) [%] Network bandwidth efficiency Minimum network delay (both-way) [ms] [ms] 3 Average increase of transmission latency 25 2 Proposal 15 AIMD Minimum network delay (both-way) [ms] Proposal AIMD 16

17 Evaluation of RTT fairness Proposed method - each consumer gains almost same throughput AIMD - shorter RTT consumers gain more (n=32, BW R1-R2 =1Mbps, D R1-R2 =8ms) Number of nodes Number of node(proposal) Number of Node(AIMD) Cumulative relative frequency(proposal) Cumulative relative frequency(aimd) Average throughput [Mbps] Cumulative relative frequency Number of nodes Number of node(proposal) Number of Node(AIMD) Cumulative relative frequency(proposal) Cumulative relative frequency(aimd) Average throughput [Mbps] Cumulative relative frequency (Delay R2-Cn =1 ms) (Delay R2-Cn =5*n+1 ms) 17

18 Evaluation of RTT fairness on the multi-bottleneck link topology Proposed method - adapt to the narrowest bottleneck and fairly share the bandwidth Publisher node P1 (n=32, D all link =5ms) P2 Router Router1 Router16 Router17 Router n Pn C1 C16 C17 Cn Average throughputs [kbp] Link bandwidth=bw link Link delay=d link Consumer nodes Case1 Case2 Case Cn Case1 BW R-R1 =1Mbps Case2 BW R-R1 =1Mbps BW R16-R17 =5Mbps Case3 BW R-R1 =1Mbps BW R16-R17 =25Mbps 18

19 Feasibility for the implementation On NDNvideo NDN-based live and pre-recorded video streaming (made by UCLA ) random access to key frames using a time-code based namespace On-the-fly archival of live streams; identical playback approach for pre-recorded video 19

20 Implementation on NDNvideo (2) Feasible to be implemented in the real-world application (confirm the basic behavior of our implementation on NDNvideo) Estimate Rate [kbps] Network bandwidth Estemate Rate Average RTT Average RTT [sec] Time [sec] 2

21 Conclusion Focus on the Live real-time video streaming RTT fairness would be important because it would be unexpectedly changed by source change in NDN/CCN Proposed method Receiver driven (no router support) Periodically (re-)compute PPS (not per RTT) Use Short period average RTT (not EMWA) Simulation result lower delay, more RTT-fair compared to AIMD Implemented on NDNvideo to show the feasibility Future work Implementation on NDNRTC with UCLA Supporting multi-source, multi-interface scenario