One document matched: draft-zhu-rmcat-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-zhu-rmcat-framework-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="RMCAT framework">Framework for Real-time Media Congestion
Avoidance Techniques</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Xianqing Zhu" initials="X" surname="Zhu">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>12515 Research Blvd., Building 4</street>
<city>Austin</city>
<region>TX</region>
<code>78759</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>xiaoqzhu@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Zaheduzzaman Sarker" initials="Z." surname="Sarker">
<organization>Ericsson AB</organization>
<address>
<postal>
<street></street>
<city>Luleae</city>
<region></region>
<code></code>
<country>Sweden</country>
</postal>
<phone>00 46 10 717 37 43</phone>
<email>zaheduzzaman.sarker@ericsson.com</email>
</address>
</author>
<date year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>RMCAT WG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>RTP</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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. <xref
target="I-D.ietf-rmcat-cc-requirements"></xref> specifies the list of
requirements of a viable solution.</t>
<t>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. <xref
target="sec-functional-modules">The next section</xref> describes common
functional modules in this framework, whereas <xref
target="sec-example-config"></xref> provides examples on how these
modules build together to support single and multiple media streams.</t>
<t>[ 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. ]</t>
</section>
<section title="Key Words for Requirements">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="sec-functional-modules" title="Functional Modules">
<t>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.</t>
<t><list style="symbols">
<t>Network Congestion Controller : this is the core module for
estimating available bandwidth over the network based on periodic
RTCP feedback reports <xref target="RFC3550"></xref> 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.</t>
<t>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.</t>
<t>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.</t>
<t>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
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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="sec-example-config" title="Example Configurations">
<section anchor="subsec-config-single-stream"
title="Example Configurations for a Single Stream">
<t><figure anchor="fig-rmcat-solution-framework"
title="RMCAT Solution Framework at the Sender: Single Stream">
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
<t><xref target="fig-rmcat-solution-framework"></xref> 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.</t>
<t>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.</t>
</section>
<section anchor="subsec-config-multiple-streams"
title="Example Configurations for Multiple Streams">
<t><figure anchor="fig-rmcat-solution-multi-stream"
title="RMCAT Solution Framework at the Sender: Multiple Streams">
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
<t><xref target="fig-rmcat-solution-multi-stream"></xref> 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.</t>
<t>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.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The RMCAT design team discussions contributed to this memo.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-rmcat-cc-requirements"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.3551"?>
<?rfc include="reference.RFC.4585"?>
<?rfc include="reference.RFC.5104"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0768"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:16 |