Congestion Control Requirements for Interactive Real-Time Media
RFC 8836

Document Type RFC - Informational (January 2021; No errata)
Authors Randell Jesup  , Zaheduzzaman Sarker 
Last updated 2021-01-18
Replaces draft-jesup-rmcat-reqs
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Mirja Kühlewind
Shepherd write-up Show (last changed 2014-11-13)
IESG IESG state RFC 8836 (Informational)
Consensus Boilerplate Yes
Telechat date
Responsible AD Mirja Kühlewind
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions

Internet Engineering Task Force (IETF)                          R. Jesup
Request for Comments: 8836                                       Mozilla
Category: Informational                                   Z. Sarker, Ed.
ISSN: 2070-1721                                              Ericsson AB
                                                            January 2021

    Congestion Control Requirements for Interactive Real-Time Media


   Congestion control is needed for all data transported across the
   Internet, in order to promote fair usage and prevent congestion
   collapse.  The requirements for interactive, point-to-point real-time
   multimedia, which needs low-delay, semi-reliable data delivery, are
   different from the requirements for bulk transfer like FTP or bursty
   transfers like web pages.  Due to an increasing amount of RTP-based
   real-time media traffic on the Internet (e.g., with the introduction
   of the Web Real-Time Communication (WebRTC)), it is especially
   important to ensure that this kind of traffic is congestion

   This document describes a set of requirements that can be used to
   evaluate other congestion control mechanisms in order to figure out
   their fitness for this purpose, and in particular to provide a set of
   possible requirements for a real-time media congestion avoidance

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Requirements
   3.  Deficiencies of Existing Mechanisms
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Authors' Addresses

1.  Introduction

   Most of today's TCP congestion control schemes were developed with a
   focus on a use of the Internet for reliable bulk transfer of non-
   time-critical data, such as transfer of large files.  They have also
   been used successfully to govern the reliable transfer of smaller
   chunks of data in as short a time as possible, such as when fetching
   web pages.

   These algorithms have also been used for transfer of media streams
   that are viewed in a non-interactive manner, such as "streaming"
   video, where having the data ready when the viewer wants it is
   important, but the exact timing of the delivery is not.

   When handling real-time interactive media, the requirements are
   different.  One needs to provide the data continuously, within a very
   limited time window (no more delay than hundreds of milliseconds end-
   to-end).  In addition, the sources of data may be able to adapt the
   amount of data that needs sending within fairly wide margins, but
   they can be rate limited by the application -- even not always having
   data to send.  They may tolerate some amount of packet loss, but
   since the data is generated in real time, sending "future" data is
   impossible, and since it's consumed in real time, data delivered late
   is commonly useless.

   While the requirements for real-time interactive media differ from
   the requirements for the other flow types, these other flow types
   will be present in the network.  The congestion control algorithm for
   real-time interactive media must work properly when these other flow
   types are present as cross traffic on the network.

   One particular protocol portfolio being developed for this use case
   is WebRTC [RFC8825], where one envisions sending multiple flows using
   the Real-time Transport Protocol (RTP) [RFC3550] between two peers,
   in conjunction with data flows, all at the same time, without having
Show full document text