using fec for rate adaptation of multimedia streams marcin nagy supervised by: jörg ott instructed...
TRANSCRIPT
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