Presentation Transcript

1. Using FEC for Rate Adaptation of Multimedia Streams

   Marcin Nagy Supervised by: JörgOtt Instructed by: Varun Singh Conducted at Comnet, School of Electrical Engineering, Aalto University
2. Contents Motivation Problem statement Background RTP and RTCP protocols FEC Rate adaptation of multimedia flows Proposed Algorithms FEC Based Rate Adaptation (FBRA) Non-FEC Based Rate Adaptation (N-FBRA) Evaluation Conclusion
3. Motivation Rapid increase of multimedia content available in the Internet Cisco predicts that video traffic should take about 90% of all consumer traffic by 2015 Increasing popularity of Video and Voice over IP (VVoIP) applications Nielsen’s Law of Internet Bandwidth vs. Moore’s Law Amount of multimedia content grows faster than available bandwidth There are no good rate control mechanisms for conversational multimedia flows HTTP streaming RTCWebIs it the future ???
4. Problem statement TCP congestion control algorithms not optimal for conversational applications Real-time Transport Protocol (RTP) dedicated to sending multimedia content Currently most of RTP-driven multimedia applications sent over UDP NO CONGESTION CONTROL AVAILABLE Forward Error Correction (FEC) Redundant packets can be used by the receiver to recover lost packets Can they be also used to probe the path capacity if the sending rate can be increased??? Hypothesis: RTP + FEC = rate adaptation algorithm + good error resiliency
5. Background Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) (RFC 3550) end-to-end transport protocol for real-time traffic RTCP sends feedback on reception statistics. In the basic standard it provides: Jitter RTT Fractional loss Highest sequence number received
6. Background Forward Error Correction (FEC) Concept: Receiver performs mathematical operation on delivered RTP and FEC packets to recover missing data
7. Rate adaptation Two problems: Congestion indicators provided by standard RTCP insufficient for rate adaptation of conversational applications RTCP report interval too large to respond quickly to changing network conditions IETF defines extensions to standard RTCP protocol: e.g. RTCP XR (Extended Reports) (RFC 3611) Extended RTP Profile (RFC 4585) allows for more frequent feedback
8. FEC Based Rate Adaptation (FBRA) Idea: before increasing the sending rate, probe the network by adding FEC, if it doesn’t hurt exchange FEC rate for RTP rate Steady state Increase rate Steady state + FEC Reduce rate
9. FEC Based Rate Adaptation (FBRA) Transit from Steady state to Steady state + FEC if good conditions Transit from Steady state + FEC to Increase rate if good conditions Stay in current state or go to Reduce rate otherwise Good conditions: No losses No discards “Normal” RTT FEC rate is the function of the current rate
10. Non FEC Based Rate Adaptation (N-FBRA) Idea: use FBRA concept, but instead of probing network with FEC increase the rate immediately by the hypothetical FEC rate Increase rate Steady state Reduce rate
11. Evaluation in ns-2 Three scenarios with dumbbell topology for three different link delays (50ms, 100ms, 240ms): Variable link capacity Constant link capacity with 1 RTP flow competing against 1-3 TCP flows Constant link capacity with 2 RTP flows competing against 1-3 TCP flows
12. Evaluation in ns-2Variable link capacity for 50ms delay FBRA Avg. rate = 178 kbit/s Delivery ratio = 99.4% N-FBRA Avg. rate = 161 kbit/s Delivery ratio = 97.5% Avg. link capacity = 186kbit/s
13. Evaluation in ns-2Variable link capacity for 100ms delay FBRA Avg. rate = 171 kbit/s Delivery ratio = 99.3% N-FBRA Avg. rate = 162 kbit/s Delivery ratio = 97.8% Avg. link capacity = 186kbit/s
14. Evaluation in ns-2 Variable link capacity for 240ms delay N-FBRA Avg. rate = 160 kbit/s Delivery ratio = 98.6% FBRA Avg. rate = 149 kbit/s Delivery ratio = 98.9% Avg. link capacity = 186kbit/s
15. Evaluation in ns-2 TCP competition scenario for 50ms delay Link capacity = 2Mbit/s Delivery ratio in all cases > 98.9% FBRA becomes uncompetitive if multiple TCP flows present
16. Evaluation in ns-2 TCP competition scenario for 100ms delay Link capacity = 2Mbit/s Delivery ratio in all cases > 99.1% FBRA performs more competitively than in 50ms delay case
17. Evaluation in ns-2 RTP-TCP competition scenario for 50ms delay Link capacity = 2Mbit/s Delivery ratio in all cases > 98.7% FBRA becomes uncompetitive if multiple TCP flows present N-FBRA driven flows are fairer between one another to FBRA ones
18. Evaluation in ns-2 RTP-TCP competition scenario for 100ms delay Link capacity = 2Mbit/s Delivery ratio in all cases > 98.7% FBRA performance improves for higher delays
19. Evaluation in AMuSys AMuSySis multimedia testing framework based on: Dummynet network emulator GStreamer library Extended JRTPLIB
20. Evaluation in AMuSys Dummynet does not forward packets properly when link bandwidth is limited Packets are discarded in the receiver due to late arrival, or lost in the network despite the rate never approaching the capacity limit On the positive side: the FBRA algorithm correctly reacts to received congestion indicators
21. Evaluation in AMuSys - example FBRA performance in variable link capacity scenario for 50ms delay
22. Conclusion At the moment N-FBRA looks more promising as a future rate adaptation algorithm FBRA shows excellent reliability properties, but recoveries are not often and it’s uncompetitive to TCP. Too early to say if it’s useful We predict that FBRA could perform better if more lossy network environment used (e.g. mobile network)
23. Acknowledgements Professor JörgOtt Varun Singh Professor RaimoKantola