1. Using FEC for Rate Adaptation of Multimedia Streams Marcin Nagy Supervised by: Jörg Ott 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 RTCWeb Is 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 + FEC Reduce rate Increase rate Steady state

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 Reduce rate Increase rate Steady state

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-2 Variable 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-2 Variable 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 FBRA Avg. rate = 149 kbit/s Delivery ratio = 98.9% N-FBRA Avg. rate = 160 kbit/s Delivery ratio = 98.6% Avg. link capacity = 186kbit/s

15. Evaluation in ns-2 TCP competition scenario for 50ms delay Link capacity = 2Mbit/s Number of TCP flows FBRA avg. rateN-FBRA avg. rate 1832kbit/s1504kbit/s 2284kbit/s1150kbit/s 3185kbit/s899kbit/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 Number of TCP flows FBRA avg. rateN-FBRA avg. rate 11308kbit/s1529kbit/s 2840kbit/s1312kbit/s 3485kbit/s1074kbit/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 Number of TCP flows FBRA 1 avg. rate FBRA 2 avg. rate N-FBRA 1 avg. rate N-FBRA 2 avg. rate 1349kbit/s584kbit/s718kbit/s871kbit/s 2236kbit/s178kbit/s642kbit/s690kbit/s 3159kbit/s125kbit/s557kbit/s556kbit/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 Number of TCP flows FBRA 1 avg. rate FBRA 2 avg. rate N-FBRA 1 avg. rate N-FBRA 2 avg. rate 1539kbit/s856kbit/s799kbit/s810kbit/s 2433kbit/s518kbit/s707kbit/s691kbit/s 3305kbit/s320kbit/s581kbit/s615kbit/s Delivery ratio in all cases > 98.7% FBRA performance improves for higher delays

19. Evaluation in AMuSys AMuSyS is 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 1. At the moment N-FBRA looks more promising as a future rate adaptation algorithm 2. FBRA shows excellent reliability properties, but recoveries are not often and it’s uncompetitive to TCP. Too early to say if it’s useful 3. We predict that FBRA could perform better if more lossy network environment used (e.g. mobile network)

23. Acknowledgements Professor Jörg Ott Varun Singh Professor Raimo Kantola