VoIP traffic and Congestion Control

RFC 3714: IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet [Floyd 2004] - describes the concerns of the IAB due to the persistence of VoIP clients which continue to send RTP streams despite high packet loss rates WRT^†:

the risks of congestion collapse (along the end-to-end route) and
fairness for congestion-controlled TCP traffic sharing the links.

When a steady-state packet drop rate >> a specified drop rate the flow should be terminated or suspended. Thus:

RFC3551: RTP Profile for Audio and Video Conferences with Minimal Control - should be changed to say:
“… RTP receivers SHOULD MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters.” and hence “MUST detect and respond to a persistent high loss rate”
CODECs - should adapt so as to reduce congestion

Suggested heuristic: VoIP applications should suspend or terminate when:

RTCP reported loss rate is greater than 30%, or
N back-to-back RTCP reports are missing

^† With Respect To

Slide Notes

S. Floyd and J. Kempf (Editors), “IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet”, IETF, RFC 3714, Network Working Group, March 2004. ftp://ftp.rfc-editor.org/in-notes/rfc3714.txt Links to an external site.

Transcript

[slide472] But as soon as you start talking about computers making a decision to set up a session, one of the interesting problems becomes about congestion control. We said we were running RTP on top of UDP. UDP has no concept about congestion control. So, the Internet Activities Board, in RFC 3714, said, we have to do something about this. So, if there are problems, so if we're losing lots of packets, we change it so that if we're in a steady state where there's a high packet drop rate, RTP receivers must monitor the packet loss to ensure it's within acceptable parameters and must detect and respond to persistent high loss rate. That means they have to adapt. Just simply continuing to blast UDP datagrams with your RTP isn't appropriate. And even the CODEC should adapt to reduce congestion. Now, their suggested heuristic was you should suspend or terminate when RTCP reports a loss rate greater than 30% or more than N back-to-back RTCP reports, remember they're sent around every 5 seconds, are missing. That says things are really, really bad. It's time to give up. So, this really changes the required behavior for the UDP.