Coupled Congestion Control for RTP Media
RFC 8699

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09



Internet Engineering Task Force (IETF)                          S. Islam
Request for Comments: 8699                                      M. Welzl
Category: Experimental                                       S. Gjessing
ISSN: 2070-1721                                       University of Oslo
                                                            January 2020

                Coupled Congestion Control for RTP Media

Abstract

   When multiple congestion-controlled Real-time Transport Protocol
   (RTP) sessions traverse the same network bottleneck, combining their
   controls can improve the total on-the-wire behavior in terms of
   delay, loss, and fairness.  This document describes such a method for
   flows that have the same sender, in a way that is as flexible and
   simple as possible while minimizing the number of changes needed to
   existing RTP applications.  This document also specifies how to apply
   the method for the Network-Assisted Dynamic Adaptation (NADA)
   congestion control algorithm and provides suggestions on how to apply
   it to other congestion control algorithms.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  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
   https://www.rfc-editor.org/info/rfc8699.

Copyright Notice

   Copyright (c) 2020 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
   (https://trustee.ietf.org/license-info) 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
   2.  Definitions
   3.  Limitations
   4.  Architectural Overview
   5.  Roles
     5.1.  SBD
     5.2.  FSE
     5.3.  Flows
       5.3.1.  Example Algorithm 1 - Active FSE
       5.3.2.  Example Algorithm 2 - Conservative Active FSE
   6.  Application
     6.1.  NADA
     6.2.  General Recommendations
   7.  Expected Feedback from Experiments
   8.  IANA Considerations
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Appendix A.  Application to GCC
   Appendix B.  Scheduling
   Appendix C.  Example Algorithm - Passive FSE
     C.1.  Example Operation (Passive)
   Acknowledgements
   Authors' Addresses

1.  Introduction

   When there is enough data to send, a congestion controller attempts
   to increase its sending rate until the path's capacity has been
   reached.  Some controllers detect path capacity by increasing the
   sending rate further, until packets are ECN-marked [RFC8087] or
   dropped, and then decreasing the sending rate until that stops
   happening.  This process inevitably creates undesirable queuing delay
   when multiple congestion-controlled connections traverse the same
   network bottleneck, and each connection overshoots the path capacity
   as it determines its sending rate.

   The Congestion Manager (CM) [RFC3124] couples flows by providing a
   single congestion controller.  It is hard to implement because it
   requires an additional congestion controller and removes all per-
   connection congestion control functionality, which is quite a
   significant change to existing RTP-based applications.  This document
   presents a method to combine the behavior of congestion control
   mechanisms that is easier to implement than the Congestion Manager
   [RFC3124] and also requires fewer significant changes to existing
   RTP-based applications.  It attempts to roughly approximate the CM
   behavior by sharing information between existing congestion
   controllers.  It is able to honor user-specified priorities, which is
   required by WebRTC [RTCWEB-OVERVIEW] [RFC7478].

   The described mechanisms are believed safe to use, but they are
   experimental and are presented for wider review and operational
   evaluation.

2.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",