{"id":159,"date":"2016-11-02T01:05:23","date_gmt":"2016-11-02T01:05:23","guid":{"rendered":"https:\/\/testmozilla.wpengine.com\/webrtc\/?p=159"},"modified":"2016-11-02T01:05:23","modified_gmt":"2016-11-02T01:05:23","slug":"what-is-rmcat-congestion-control","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webrtc\/what-is-rmcat-congestion-control\/","title":{"rendered":"What is RMCAT congestion control, and how will it affect WebRTC?"},"content":{"rendered":"

RMCAT<\/strong><\/a> is an IETF Working Group which came out of proposal by myself and Harald Alvestrand, and an associated Congestion Control IAB\/IRTF workshop at IETF 84 in Vancouver in 2012.\u00a0 The report from the workshop is RFC 7295<\/a>.<\/p>\n

tl;dr:<\/strong>
\nThe RMCAT WG is working to develop new congestion control protocols for realtime RTP traffic to improve on state-of-the-art, to ensure that media streams don’t harm other users of the networks (both non-RTP and other RTP media streams), and to maximize quality.\u00a0 There are several proposed algorithms, and this work will feed back into mainline WebRTC implementations to improve network usage and media quality.<\/p>\n

History:<\/strong><\/h3>\n

Historically, RTP was unmanaged from a congestion-control perspective.\u00a0 If there wasn’t enough bandwidth for a stream, packets would queue somewhere, and if the queue overflowed, it would drop packets from the tail of the queue.\u00a0 This was seen as loss and delay, and in the case of the router being susceptible to Bufferbloat<\/a>, it would cause major delay (even seconds of delay).<\/p>\n

In response to problems with this, some VoIP devices would let you choose high or low bandwidth.\u00a0 For audio it did this using different codecs, like G.711 (64Kbps payload) vs G.729 (8Kbps).\u00a0 For video, the fixed video codec rate would be set according to the bandwidth the user said they had.<\/p>\n

As you might guess, this was not a very good solution.\u00a0 Users often didn’t know their bandwidth; it would vary (especially if there was competing traffic at the bottleneck); if you guessed too low (or set it low to deal with an occasional problem), then quality would always be low.\u00a0 If you guessed too high, the call might totally fall apart.<\/p>\n

The next logical step was to use congestion control, which is how most traffic on the internet is managed.\u00a0 TCP uses various algorithms for congestion control<\/a>, but in general uses variations on AIMD algorithms<\/a>.<\/p>\n

Problems with traditional congestion control:<\/strong><\/h3>\n

AIMD causes a sawtooth in the transmission rate when loss is seen.\u00a0 Loss is the indicator of congestion to TCP; in classic routers it means a buffer-queue overflowed due to congestion.\u00a0 Typically in TCP a loss will cause a 50% reduction in bitrate, and then a steady increase until loss is seen again. Needless to say, this is not ideal (or even OK) behavior for video codecs (or non-fixed-rate audio codecs).\u00a0 And because the signal for reduction was queue overflow, serious delay would build up, then start to drain away, then build up again.<\/p>\n

You can see a nice graph of AIMD sawtooth here<\/a> (the “Fast Retransmit” points are in response to loss).<\/p>\n

Proprietary Solutions:<\/strong><\/h3>\n

So people started thinking about it (I was one of them, working on the Worldgate Ojo videophone<\/a> – image in a call<\/a>), and came up with more media-friendly methods.\u00a0 What I did and what GIPS (now part of Google) did was to build a delay-sensitive congestion mechanism, which as a side-effect tries to avoid the conditions (queue overflow) that lead to packet loss.\u00a0 Typically they worked something like this:<\/p>\n