Performance Analysis of Google's Congestion Control

Packet Video 2013
San Jose, California

Transcript

1. Performance Analysis of Receive-Side Real-Time Congestion Control (RRTCC) for WebRTC Google’s Congestion Control Algorithm Packet Video 2013 13th December, Friday Varun Singh, Albert Lozano, Jörg Ott
2. RTP and RTCP Sender Receiver RTP media stream (encoded media, FEC, repair) RTCP Sender Reports (SRs) •  Timing, synchronization •  Sending rate, packet count RTCP Receiver Reports (RRs) •  Rough statistics •  Congestion cues RTCP XRs: •  Detailed Statistics •  Dejittering, sync, playout •  Monitoring + reporting •  Event notifications •  Local error concealment Short-term adaptation •  Error-resilience (NACK, PLI) •  Congestion control •  Adaptive source coding Long-term adaptation •  Codec choice •  Packetization size •  FEC, interleaving
3. RRTCC •  Sender-side based on TFRC –  RTT, fractional loss, bytes_sent •  Receiver-side based on variation in inter- arrival time –  Estimation based on a Kalman filter. –  Indicates Receiver Estimate (REMB) in RTCP –  RTCP sent every 1 sec. •  Sender decides based on TFRC and REMB 3
4. Related Work •  Experimental Investigation of the Google Congestion Control for Real-Time Flows, Cicco et al. http://conferences.sigcomm.org/sigcomm/2013/papers/fhmn/p21.pdf •  Performance analysis of topologies for Web- based Real-Time Communication (WebRTC), A. Lozano https://aaltodoc.aalto.fi/bitstream/handle/123456789/11093/master_Abell%C3%B3_Lozano_Albert_2013.pdf?sequence=1 •  Understanding the Dynamic Behaviour of the Google Congestion Control, Cicco et al. 4 Initial NS-2 Results: http://www.netlab.tkk.fi/~varun/rrtcc-tcp-competition-00.pdf
5. Evaluation Setup Chrome Browser v27.01453.12 Foreman VGA, 30FPS 5-10 minutes fakevideosource! Chrome Browser v27.01453.12 Network Video, FEC, RETX à ß RTCP Feedback (every 1s) http://media.xiph.org/video/derf/ 5 StatsAPI (every 1s) tcpdump! https://github.com/vr000m/ConMon
6. Single flow •  Fixed capacity with different 1.  path latencies 2.  path losses 6
7. Different Latencies 0 500 1000 1500 2000 2500 3000 3500 4000 0 50 100 150 200 250 300 Observed rate [kbps] Time [s] 50ms 100ms 200ms 500ms 7
8. Different Loss 0 500 1000 1500 2000 2500 3000 3500 0 50 100 150 200 250 300 Observed rate [kbps] Time [s] 1% 5% 10% 20% 8
9. 3 RMCAT streams 9 0 200 400 600 800 1000 1200 1400 1600 1800 2000 2200 0 50 100 150 200 250 300 Observed rate [kbps] Time [s] Call 1 Call 2 Call 3 0 500 1000 1500 2000 2500 0 50 100 150 200 250 300 Observed rate [kbps] Time [s] Call 1 Call 2 Call 3
10. 3 RMCAT flows (time-shifted arrival) 0 500 1000 1500 2000 2500 3000 0 50 100 150 200 250 300 Observed rate [kbps] Time [s] Call 1 Call 2 Call 3 10 In all the cases, the first call reduced its rate In 20% of the cases it recovered after ~50s.
11. TCP and RMCAT 11 0 200 400 600 800 1000 1200 1400 1600 1800 0 50 100 150 200 250 300 Observed rate [kbps] Time [s] Stream A->B Stream B->A Observed loss < 0.25%
12. Observations •  FEC is ~20% of the average send rate •  Retransmissions (retx) –  Used extensively in low latency scenarios. •  RRTCC is self-fair –  flows increase and decreases synchronously –  first flow collapses when new flows are added later. •  Under-utilizes when competing with TCP traffic 12
13. Conclusions •  Works in low delay networks •  Tolerate transient changes – varying loss, latency •  Compete within limits against varying amount of cross-traffic. 13