Using FEC for Rate Adaptation of

Multimedia StreamsMarcin Nagy

Supervised by: Jörg OttInstructed by: Varun Singh

Conducted at Comnet, School of Electrical Engineering, Aalto University

Contents Motivation

Problem statement

Backgrounda) RTP and RTCP protocols

b) FEC

c) Rate adaptation of multimedia flows

Proposed Algorithmsa) FEC Based Rate Adaptation (FBRA)

b) Non-FEC Based Rate Adaptation (N-FBRA)

Evaluation

Conclusion

MotivationRapid 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 ???

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

BackgroundReal-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: JitterRTTFractional lossHighest sequence number received

BackgroundForward Error Correction (FEC)

Concept: Receiver performs mathematical operation on delivered RTP and FEC packets to recover missing data

Rate adaptationTwo 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

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

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

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

Evaluation in ns-2Three 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

Evaluation in ns-2Variable link capacity for 50ms delay

FBRAAvg. rate = 178 kbit/sDelivery ratio = 99.4%

N-FBRAAvg. rate = 161 kbit/sDelivery ratio = 97.5%

Avg. link capacity = 186kbit/s

Evaluation in ns-2Variable link capacity for 100ms delay

FBRAAvg. rate = 171 kbit/sDelivery ratio = 99.3%

N-FBRAAvg. rate = 162 kbit/sDelivery ratio = 97.8%

Avg. link capacity = 186kbit/s

Evaluation in ns-2Variable link capacity for 240ms delay

FBRAAvg. rate = 149 kbit/sDelivery ratio = 98.9%

N-FBRAAvg. rate = 160 kbit/sDelivery ratio = 98.6%

Avg. link capacity = 186kbit/s

Evaluation in ns-2TCP competition scenario for 50ms delay

Link capacity = 2Mbit/s

Number of TCP flows

FBRA avg. rate N-FBRA avg. rate

1 832kbit/s 1504kbit/s

2 284kbit/s 1150kbit/s

3 185kbit/s 899kbit/s

Delivery ratio in all cases > 98.9%

FBRA becomes uncompetitive if multiple TCP flows present

Evaluation in ns-2TCP competition scenario for 100ms delay

Link capacity = 2Mbit/s

Number of TCP flows

FBRA avg. rate N-FBRA avg. rate

1 1308kbit/s 1529kbit/s

2 840kbit/s 1312kbit/s

3 485kbit/s 1074kbit/s

Delivery ratio in all cases > 99.1%

FBRA performs more competitively than in 50ms delay case

Evaluation in ns-2RTP-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

1 349kbit/s 584kbit/s 718kbit/s 871kbit/s

2 236kbit/s 178kbit/s 642kbit/s 690kbit/s

3 159kbit/s 125kbit/s 557kbit/s 556kbit/s

Delivery ratio in all cases > 98.7% FBRA becomes uncompetitive if multiple TCP flows presentN-FBRA driven flows are fairer between one another to FBRA ones

Evaluation in ns-2RTP-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

1 539kbit/s 856kbit/s 799kbit/s 810kbit/s

2 433kbit/s 518kbit/s 707kbit/s 691kbit/s

3 305kbit/s 320kbit/s 581kbit/s 615kbit/s

Delivery ratio in all cases > 98.7%

FBRA performance improves for higher delays

Evaluation in AMuSysAMuSyS is multimedia testing framework based on:

- Dummynet network emulator

- GStreamer library

- Extended JRTPLIB

Evaluation in AMuSysDummynet 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

Evaluation in AMuSys - example

FBRA performance in variable link capacity scenario for 50ms delay

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

Acknowledgements

Professor Jörg Ott

Varun Singh

Professor Raimo Kantola