RMCAT WG X. Zhu
Internet-Draft Cisco Systems
Intended status: Informational Z. Sarker
Expires: January 8, 2017 Ericsson AB
July 7, 2016
Framework for Real-time Media Congestion Avoidance Techniques
draft-zhu-rmcat-framework-00
Abstract
Congestion control is an essential element in ensuring fair bandwidth
usage and preventing congestion collapse for traffic sharing the
Internet. For interactive real-time media traffic such as video
conferencing, design of congestion control solution also needs to
account for many other factors such as the requirement for low
latency packet delivery and interactions with live video encoder.
This document describes a common framework with the core functional
building blocks for a real-time media congestion solutions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2017.
Copyright Notice
Copyright (c) 2016 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
(http://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
Zhu & Sarker Expires January 8, 2017 [Page 1]
Internet-Draft RMCAT framework July 2016
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
2. Key Words for Requirements . . . . . . . . . . . . . . . . . 2
3. Functional Modules . . . . . . . . . . . . . . . . . . . . . 3
4. Example Configurations . . . . . . . . . . . . . . . . . . . 4
4.1. Example Configurations for a Single Stream . . . . . . . 4
4.2. Example Configurations for Multiple Streams . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Given increasing amount of interactive real-time media traffic over
the Internet, such as video conferencing, it is important that these
applications employ proper congestion control mechanisms to avoid
congestion collapse. [I-D.ietf-rmcat-cc-requirements] specifies the
list of requirements of a viable solution.
This document outlines a common framework for designing a congestion
control mechanism for real-time interactive communication, so that
individual drafts on specific solutions follow a consistent set of
terminologies in describing their respective components. The next
section (Section 3) describes common functional modules in this
framework, whereas Section 4 provides examples on how these modules
build together to support single and multiple media streams.
[ Editor's note : This document does not describe the interaction
between application, codec and congestion control system. The
interaction among application, codec and congestion control system
are defined in other documents. There is a possibility to merge all
the documents into one single document. ]
2. Key Words for Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Zhu & Sarker Expires January 8, 2017 [Page 2]
Internet-Draft RMCAT framework July 2016
3. Functional Modules
A viable solution for real-time media congestion control needs to
comprise of several common modules. This section provides a brief
description of them and their respective functionalities. A
congestion control solution for real-time media should comprise of
the described functional modules. This should help understanding
different congestion control solutions.
o Network Congestion Controller : this is the core module for
estimating available bandwidth over the network based on periodic
RTCP feedback reports [RFC3550] from the receiver. This module
contains key functions and calculations required to detect
congestion and estimate available bandwidth on the transmission
path based on the reception quality of the media traffic.
Different congestion control solutions employ different algorithms
in detecting congestion and estimating available bandwidth for its
media flow. It also possible that multiple media streams are
multiplexed over a single transport, hence share a common
congestion control module in aggregation.
o Transmission Queue : this module is needed to absorb the
instantaneous mismatch between output from a live video encoder
and regulated outgoing media flow. The transmission queue
schedules outgoing traffic according to sending rate recommended
by the rate controller module. It reports back its occupancy
level to the rate controller module to assist future rate control
decisions on target video rate, sending rate, and probing rate.
o Rate Controller : this module takes the estimated available
bandwidth from the network congestion controller, shared states of
other flows, as well as occupancy level of the transmission queue
as input. It makes holistic decisions on: a) target video rate
for the live video encoder; b) sending rate for regulating
outgoing media flow(s) for the transmission queue; and c) rate of
probing packets when needed. In the case where multiple media
streams share a single transport and a common network congestion
controller (for estimating available bandwidth in aggregation),
the rate controller is also responsible for distributing available
bandwidth amongst different media streams according to their
relative priorities as well as share state information. When
losses occur over the network and some previous media packets need
to be retransmitted, the rate controller should also account for
the bandwidth needed for retransmission.
o Network Probe Generator: A congestion control solution can
actively probe to estimate the available bandwidth on the media
transmission path by sending more than what the live video encoder
Zhu & Sarker Expires January 8, 2017 [Page 3]
Internet-Draft RMCAT framework July 2016
produces. Such an approach can be especially effective during the
ramp up period of media and transmission rates, when no congestion
has been observed over the network yet. The network probe
generator is responsible for generating probing packets according
to the probing rate specified by the rate controller. It can
employ different techniques in doing so -- for example by
generating simple dummy packets with unknown payload type or by
generating Forward Error Correction (FEC) packets. While this
document does not specify what probing technique to use or how
those packets should be generated, a complete congestion control
solution needs should specify total rate of the probe packets via
the rate controller module.
o Live Video Encoder : the sender typically also contains a live
video encoder, which adjusts the its encoding parameters according
to the target video rate set by the rate controller. The output
rate from the video encoder may deviate from this target due to
uncertainty in the captured video content characteristics and the
encoder rate control process. The output encoded media packets
are fed to the transmission queue. Note that internal operations
of the live video encoder (i.e., how video encoder rate control
works) is out of scope for this document.
o Shared State: In the case of multiple media streams sharing a
common sender hence a common network congestion controller, the
sender should also contain a shared state module for storage and
exchange of congestion control states [Editor's Note from
Xiaoqing: examples of congestion control states??] amongst the
multiple flows.
4. Example Configurations
4.1. Example Configurations for a Single Stream
Zhu & Sarker Expires January 8, 2017 [Page 4]
Internet-Draft RMCAT framework July 2016
RTCP Feedback
+---------+ +-------------+ Reports
| Live | | Network |<----------------
| Video |<----------------+ | Congestion |
| Encoder | | | Controller |
+---------+ | +-------------+
|| | |(1)
|| | |
|| | \|/
|| +--------------+ | (4) +-------------+
|| | Network | +------| Rate |
|| | Probe |<--------| Controller |
|| | Generator | (5) +-------------+
|| +--------------+ (3)| /|\
|| || | |
|| || Probing \|/ |(2)
|| || Packets +---------------+
|| \\=============> | Transmission |
\\==========================> | Queue |==============>
Encoded Video Packets +---------------+ Outgoing
Packets
Figure 1: RMCAT Solution Framework at the Sender: Single Stream
Figure 1 shows an example configuration at the sender for supporting
a single media stream. The Network Congestion Controller estimates
available bandwidth based on periodic RTCP feedback reports. The
Rate Controller takes as input the estimated available bandwidth (1)
and the current occupancy level of the Transmission Queue (2). It
calculates as output sending rate (3) for the Transmission Queue,
video target rate (4) for the Live Video Encoder, and probing rate
(5) -- if they are needed -- for the Network Probe Generator. The
Transmission Queue holds packets generated by both the Live Video
Encoder and the Network Probe Generator; it paces transmission of its
outgoing packets according to the sending rate (3) specified by Rate
Controller.
Obviously, it is possible for a congestion control solution to
contain alternative configurations between these functional modules.
[TODO: add one quick example on alternative wiring.] It is required
that the candidate solution draft specify how their internal
functional modules align to this framework.
Zhu & Sarker Expires January 8, 2017 [Page 5]
Internet-Draft RMCAT framework July 2016
4.2. Example Configurations for Multiple Streams
RTCP Feedback
+---------+ +-------------+ Reports
| Live | | Network |<----------------
| Video |<----------------+ | Congestion |
| Encoder | | | Controller |
+---------+ | +-------------+
|| | |(1)
|| | |
|| | \|/
|| | (4) +-------------+ +--------+
|| +---------+ +------| Rate |<-----| Shared |
|| | Live | | | Controller | | States |
|| | Video |<----+ +-------------+ +--------+
|| | Encoder | (3)| /|\
|| +---------+ | |
|| || \|/ |(2)
|| || +---------------+
|| || | Transmission |
\\==========================> | Queue |==============>
Encoded Video Packets +---------------+ Outgoing
Packets
Figure 2: RMCAT Solution Framework at the Sender: Multiple Streams
Figure 2 shows an example configuration for multiple video streams
sharing a common Network Congestion Controller. The Network
Congestion Controller calculates an aggregated estimated available
bandwidth (1) based on periodic RTCP feedback reports. The Rate
Controller divides up the aggregate estimated bandwidth (1) from the
Network Congestion Controller amongst sub-streams based on their
relative priority levels, Shared States, as well as current occupancy
level of the Transmission Queue. It subsequently determines the per-
flow sending rate (3) as regulated by the Transmission Queue and
target video rate (4) for each flow.
In this specific example, the transmission queue is envisioned as a
logical entity. For instance, this transmission queue can be
implemented priority-based scheduling and one physical queue per
stream. For sake of simplicity the role of Network Probe Generator
is omitted in the above figure.
Zhu & Sarker Expires January 8, 2017 [Page 6]
Internet-Draft RMCAT framework July 2016
5. Acknowledgements
The RMCAT design team discussions contributed to this memo.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
TBD
8. References
8.1. Normative References
[I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
Zhu & Sarker Expires January 8, 2017 [Page 7]
Internet-Draft RMCAT framework July 2016
8.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
Authors' Addresses
Xianqing Zhu
Cisco Systems
12515 Research Blvd., Building 4
Austin, TX 78759
USA
Email: xiaoqzhu@cisco.com
Zaheduzzaman Sarker
Ericsson AB
Luleae
Sweden
Phone: 00 46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com
Zhu & Sarker Expires January 8, 2017 [Page 8]
