Coupled Congestion Control for RTP Media
RFC 8699
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",
Show full document text