Adaptive Delay Aware Error Control for Internet telephony Catherine Boutremans Jean-Yves Le Boudec IP Telephony Workshop’2001 Institute for computer Communication and Applications phone: ; fax:

Framework Real-time audio over Best Effort networks suffers from varying packet loss rates, delays and available bandwidth. Forward Error Correction (FEC) is an efficient way to recover from packet losses but : –  bandwidth requirement –  end-to-end delay Adaptive rate/error control was proposed but it does not try to optimize the end-to-end delay

Motivation Above a certain threshold (around 150ms): the end-to-end delay is annoying New differentiated services, such as Alternative Best Effort offer applications the trade-off between receiving lower end-to-end delay (and higher loss rates) or more overall throughput.  important to take the end-to-end delay into account in the adaptive control scheme

Adaptive Delay aware error control Problem definition: develop an error control scheme for audio which is delay aware (namely, which chooses the FEC according to its impact on the end-to-end delay) for Best Effort Internet services such as: 1) Flat2) ABE Out of scope: validation of perceptual models

Outline A.Our Joint rate/error/delay control scheme –1. Error recovery taken from media specific FEC –2. An RTCP-based Rate control scheme –3. A new Delay control scheme –4. Our Global optimization problem B.Simulation examples –1. Flat Network: what do we improve? –2. ABE: Is it worth to be green?

Dr Rr Dr Rr 1.How media specific FEC Works Qmax Rmax Qmax Rmax Audio Frame 3Audio Frame 4 primary/source encoding Dp Rp Dp Rp rate Quality... packet stream 345 Start with high rate audio encoding 234 copy audio, compress, and delay secondary/redundancy encoding 354 reconstruction if packet lost, recover from redundancy

1.Efficiency of FEC mainly depends on packet loss process Loss process of audio packets in the Internet can be modeled as low order Markov chain In this work: Gilbert Model 1 0 p 1-q 1-p q

2.Our RTCP-based Rate Control scheme Audio streams have to share bandwidth fairly with TCP connections  TCP-Friendly Equation-Based TCP Friendly rate control (Padhye): Rate controlled via packet size (constant packet intervals) Use RTCP for Feedback EWMA filter of PLR in order to smooth the rate

2. Our Rate control achieves fairness Our scheme shares bandwidth fairly with TCP connections

3.Quality is function of rate and delay Audio quality is function of reconstructed rate (SNR,MOS,...) Audio quality is function of end-to-end delay: decreases rapidly above 150ms

3.Quality is function of rate and delay Consider the user perceived quality (utility) as a function of the reconstructed rate (R) and the overall end-to-end delay (D) We use several utility curves as we don’t know which one is the best.

4.Our Joint rate/error/delay control A source with flexibility to encode audio at rate Unreliable network characterized by –a loss distribution  Gilbert Model : r.v. –a delay distribution –an available bandwidth  TCP-Friendly rate constraint A utility function of delay and reconstructed rate  Consider:

4.Our Joint rate/error/delay control Constrained optimization problem: Define: K =  of copies of audio segment sent over the network,the delay spent on FEC the r.v. the set of copies that make it across the network Under

General solution is derived using Lagrange Multipliers for small values of K and via numerical method SQP for K  4 The solution has the following properties: – –if (p+q)  1  it pays to offset and to put more quality into the end packets –if (p+q)  1  better not to offset and 4.Our Joint rate/error/delay control Solution:

B.Simulation examples Single bottleneck Topology with small and long flows Bottleneck BW = 15Mbps, 5Mbps variable number of connections d1 d2

Example 1: when delay is important

Example 2: when delay is not important

Example 3: tradeoff between delay and audio distortion

1. FLAT: Conclusion The Delay aware scheme increases utility by avoiding that the source waste delay on the FEC when it is not really needed.

2.ABE: Alternative Best Effort ABE is a novel service for IP networks which offers the choice between receiving a lower end- to-end delay or more overall throughput. Packets are marked either green or blue. Green packets receive a low, bounded queuing delay but they receive more losses during bouts of congestion. Blue packets receive more throughput (and less losses) but also more delay jitter.

Is it worth being green? Green packets receive a lower delay  but they experience more losses (and hence, receive less throughput). Losses are repaired using FEC but FEC increases the e2e delay  and the BW requirement.

With small RTT, difference is minor.

Higher RTT (2 bottlenecks): green is better if load not too high.

Higher RTT (1 bottleneck): green always better

2. ABE: Conclusions It is worth accepting to receive less bandwidth (and more losses) except in trivial cases where –the RTT is small anyway –the network is badly congested Need for adaptive Color choosing algorithms

Conclusions We proposed an adaptive Delay aware error control scheme. We showed it could prevent a source from wasting delay on FEC when not necessary. It helped us to figure out that it was worth trading throughput for delay.