RTP Control Protocol (RTCP) Feedback for Congestion ControlEricsson ABTorshamnsgatan 23Stockholm164 83Sweden+46 10 717 37 43zaheduzzaman.sarker@ericsson.comUniversity of GlasgowSchool of Computing ScienceGlasgowG12 8QQUnited Kingdomcsp@csperkins.orgCALLSTATS I/O OyAnnankatu 31-33 C 42Helsinki00100Finlandvarun.singh@iki.fihttps://www.callstats.io/AcousticComms Consulting6310 Watercrest Way Unit 203Lakewood RanchFL34202-5122United States of America+1 732 832 9723mar42@cornell.eduhttp://ramalho.webhop.info/Congestion controlfeedback messageRTPRTCP
An effective RTP congestion control algorithm requires more fine-grained
feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the
standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver
Report (RR) packets.
This document describes an RTCP feedback message intended to enable
congestion control for interactive real-time traffic using RTP. The
feedback message is designed for use with a sender-based congestion
control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP
feedback packets containing the information the sender
needs to perform congestion control.
Status of This Memo
This is an Internet Standards Track document.
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). Further
information on Internet Standards is available in 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
. Introduction
. Terminology
. RTCP Feedback for Congestion Control
. RTCP Congestion Control Feedback Report
. Feedback Frequency and Overhead
. Response to Loss of Feedback Packets
. SDP Signaling
. Relationship to RFC 6679
. Design Rationale
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionFor interactive real-time traffic, such as video conferencing
flows, the typical protocol choice is the Real-time Transport
Protocol (RTP) running over the User Datagram Protocol (UDP). RTP
does not provide any guarantee of Quality of Service (QoS), reliability,
or timely delivery, and expects the underlying transport protocol to
do so. UDP alone certainly does not meet that expectation. However,
the RTP Control Protocol (RTCP) provides a mechanism by which the
receiver of an RTP flow can periodically send transport and media
quality metrics to the sender of that RTP flow. This information can
be used by the sender to perform congestion control. In the absence
of standardized messages for this purpose, designers of congestion
control algorithms have developed proprietary RTCP messages that
convey only those parameters needed for their respective designs.
As a direct result, the different congestion control
designs are not interoperable. To enable algorithm
evolution as well as interoperability across designs (e.g., different
rate adaptation algorithms), it is highly desirable to have a generic
congestion control feedback format.To help achieve interoperability for unicast RTP congestion control,
this memo specifies a common RTCP feedback packet format that can be used by
Network-Assisted Dynamic Adaptation
(NADA) ,
Self-Clocked Rate Adaptation for Multimedia (SCReAM) , Google Congestion Control
, and Shared Bottleneck
Detection , and, hopefully,
also by future RTP congestion control algorithms.
TerminologyThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.In addition, the terminology defined in ,
, and applies.RTCP Feedback for Congestion ControlBased on an analysis of NADA ,
SCReAM , Google
Congestion Control , and
Shared Bottleneck Detection ,
the following per-RTP packet congestion control feedback information
has been determined to be necessary:
RTP Sequence Number:
The receiver of an RTP flow needs to feed
the sequence numbers of the received RTP packets back to the sender, so the
sender can determine which packets were received and which were lost.
Packet loss is used as an indication of congestion by many congestion
control algorithms.
Packet Arrival Time:
The receiver of an RTP flow needs to feed
the arrival time of each RTP packet back to the sender. Packet delay and/or
delay variation (jitter) is used as a congestion signal by some congestion
control algorithms.
If ECN
is
used, it is necessary to feed back the 2-bit ECN mark in received
RTP packets, indicating for each RTP packet whether it is marked
not-ECT, ECT(0), ECT(1), or ECN Congestion Experienced (ECN-CE).
("ECT" stands for "ECN-Capable Transport".) If the path used by the RTP
traffic is ECN capable, the sender can use ECN-CE marking information as a congestion control signal.
Every RTP flow is identified by its Synchronization Source (SSRC)
identifier. Accordingly, the RTCP feedback format needs to group its
reports by SSRC, sending one report block per received SSRC.As a practical matter, we note that host operating system (OS)
process interruptions can occur at inopportune times. Accordingly,
recording RTP packet send times at the sender, and the corresponding
RTP packet arrival times at the
receiver, needs to be done with deliberate care. This is because the time
duration of host OS interruptions can be significant relative to the
precision desired in the one-way delay estimates. Specifically, the send
time needs to be recorded at the last opportunity prior to transmitting
the RTP packet at the sender, and the arrival time at the receiver needs
to be recorded at the earliest available opportunity.RTCP Congestion Control Feedback ReportCongestion control feedback can be sent as part of a regular
scheduled RTCP report or in an RTP/AVPF early feedback packet.
If sent as early feedback, congestion control feedback MAY be
sent in a non-compound RTCP packet
if the RTP/AVPF profile or the
RTP/SAVPF profile is used.Irrespective of how it is transported, the congestion control
feedback is sent as a Transport-Layer Feedback Message (RTCP packet
type 205). The format of this RTCP packet is shown in
:The first 8 octets comprise a standard RTCP header, with
PT=205 and FMT=11 indicating that this is a congestion control
feedback packet, and with the SSRC set to that of the sender of
the RTCP packet.
requires the RTCP
header to be followed by the SSRC of the RTP flow being reported
upon. Accordingly, the RTCP header is followed by a report block
for each SSRC from which RTP packets have been received, followed
by a Report Timestamp.Each report block begins with the SSRC of the received RTP stream
on which it is reporting. Following this, the report block contains a
16-bit packet metric block for each RTP packet that has a sequence number
in the range begin_seq to begin_seq+num_reports inclusive (calculated using
arithmetic modulo 65536 to account for possible sequence number wrap-around).
If the number of 16-bit packet metric blocks included in the report
block is not a multiple of two, then 16 bits of zero padding MUST be
added after the last packet metric block, to align the end of the
packet metric blocks with the next 32-bit boundary.
The value of num_reports MAY be 0, indicating that there are no
packet metric blocks included for that SSRC.
Each report block MUST NOT include more than 16384 packet metric blocks
(i.e., it MUST NOT report on more than one quarter of the sequence
number space in a single report).
The contents of each 16-bit packet metric block comprise the R, ECN,
and ATO fields as follows:
Received (R, 1 bit):
A boolean that indicates whether the packet was
received. 0 indicates that the packet was not yet received and
the subsequent 15 bits (ECN and ATO) in this 16-bit packet
metric block are also set to 0 and MUST be ignored.
1 indicates that the packet was received and the subsequent
bits in the block need to be parsed.
ECN (2 bits):
The echoed ECN mark of the packet. These bits
are set to 00 if not received or if ECN is not used.
Arrival time offset (ATO, 13 bits):
The arrival time of
the RTP packet at the receiver, as an offset before the time
represented by the Report Timestamp (RTS) field of this RTCP congestion control
feedback report. The ATO field is in units of 1/1024 seconds
(this unit is chosen to give exact offsets from the RTS field)
so, for example, an ATO value of 512 indicates that the
corresponding RTP packet arrived exactly half a second before
the time instant represented by the RTS field.
If the measured value is greater than 8189/1024 seconds (the
value that would be coded as 0x1FFD), the value 0x1FFE MUST
be reported to indicate an over-range measurement.
If the measurement is unavailable or if the arrival time of
the RTP packet is after the time represented by the RTS field,
then an ATO value of 0x1FFF MUST be reported for the packet.
The RTCP congestion control feedback report packet concludes with
the Report Timestamp field (RTS, 32 bits). This denotes the time
instant on which this packet is reporting and is the instant from
which the arrival time offset values are calculated.
The value of the RTS field is derived from the same clock used to generate
the NTP timestamp field in RTCP Sender Report (SR) packets. It
is formatted as the middle 32 bits of an NTP format timestamp, as
described in .RTCP Congestion Control Feedback Packets SHOULD include a report
block for every active SSRC. The sequence
number ranges reported on in consecutive reports for a given SSRC will
generally be contiguous, but overlapping reports MAY be sent (and need
to be sent in cases where RTP packet reordering occurs across the
boundary between consecutive reports).
If an RTP packet was reported as received in one report, that packet
MUST also be reported as received in any overlapping reports sent later that cover its sequence number range.
If feedback reports covering overlapping sequence number ranges are sent,
information in later feedback reports may update any data sent in previous
reports for RTP packets included in both feedback reports.
RTCP Congestion Control Feedback Packets can be large if they are
sent infrequently relative to the number of RTP data packets. If an
RTCP Congestion Control Feedback Packet is too large to fit within the
path MTU, its sender SHOULD split it into multiple feedback packets.
The RTCP reporting interval SHOULD be chosen such that feedback packets
are sent often enough that they are small enough to fit within the path
MTU. ( discusses how to
choose the reporting interval; specifications for RTP congestion control
algorithms can also provide guidance.)If duplicate copies of a particular RTP packet are received, then the
arrival time of the first copy to arrive MUST be reported. If any of the
copies of the duplicated packet are ECN-CE marked, then an ECN-CE mark
MUST be reported for that packet; otherwise, the ECN mark of the first
copy to arrive is reported.If no packets are received from an SSRC in a reporting interval,
a report block MAY be sent with begin_seq set to the highest sequence
number previously received from that SSRC and num_reports set to 0
(or the report can simply be omitted). The corresponding
Sender Report / Receiver Report (SR/RR) packet
will have a non-increased extended highest sequence number received
field that will inform the sender that no packets have been received,
but it can ease processing to have that information available in the
congestion control feedback reports too.A report block indicating that certain RTP packets were lost is
not to be interpreted as a request to retransmit the lost packets.
The receiver of such a report might choose to retransmit such packets,
provided a retransmission payload format has been negotiated, but
there is no requirement that it do so.Feedback Frequency and OverheadThere is a trade-off between speed and accuracy of reporting, and the
overhead of the reports.
discusses this trade-off, suggests desirable RTCP feedback rates, and
provides guidance on how to configure, for example, the RTCP bandwidth fraction
to make appropriate use of the reporting block described in this memo.
Specifications for RTP congestion control algorithms can also provide
guidance.It is generally understood that congestion control algorithms work
better with more frequent feedback.
However, RTCP bandwidth and transmission rules put some upper limits
on how frequently the RTCP feedback messages can be sent from an RTP
receiver to the RTP sender.
In many cases, sending feedback once per frame is an upper bound
before the reporting overhead becomes excessive, although this will
depend on the media rate and more frequent feedback might be needed
with high-rate media flows .
Analysis has also shown
that some candidate congestion control algorithms can operate with less
frequent feedback, using a feedback interval range of 50-200 ms.
Applications need to negotiate an appropriate congestion control
feedback interval at session setup time, based on the choice of
congestion control algorithm, the expected media bitrate, and
the acceptable feedback overhead.
Response to Loss of Feedback Packets
Like all RTCP packets, RTCP Congestion Control Feedback Packets
might be lost. All RTP congestion control algorithms MUST specify
how they respond to the loss of feedback packets.
RTCP packets do not contain a sequence number, so loss of feedback
packets has to be inferred based on the time since the last feedback
packet.
If only a single congestion control feedback packet is lost, an
appropriate response is to assume that the level of congestion
has remained roughly the same as the previous report. However,
if multiple consecutive congestion control feedback packets are
lost, then the media sender SHOULD rapidly reduce its sending rate as
this likely indicates a path failure. The RTP circuit
breaker specification provides further guidance.
SDP Signaling
A new "ack" feedback parameter, "ccfb", is defined for use with the
"a=rtcp-fb:" Session Description Protocol (SDP) extension to indicate the use of the RTP Congestion
Control Feedback Packet format defined in .
The ABNF definition of this SDP parameter extension is:
rtcp-fb-ack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-ack-param =/ ccfb-par
ccfb-par = SP "ccfb"
The payload type used with "ccfb" feedback MUST be the wildcard type ("*").
This implies that the congestion control feedback is sent
for all payload types in use in the session, including any Forward Error Correction (FEC) and
retransmission payload types.
An example of the resulting SDP attribute is:
a=rtcp-fb:* ack ccfb
The offer/answer rules for these SDP feedback parameters are
specified in the RTP/AVPF profile.
An SDP offer might indicate support for both the congestion control
feedback mechanism specified in this memo and one or more alternative
congestion control feedback mechanisms that offer substantially the
same semantics. In this case, the answering party SHOULD include
only one of the offered congestion control feedback mechanisms in its
answer. If a subsequent offer containing the same set of congestion control
feedback mechanisms is received, the generated answer SHOULD choose
the same congestion control feedback mechanism as in the original
answer where possible.
When the SDP BUNDLE extension
is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing category
IDENTICAL-PER-PT .
Relationship to RFC 6679
The use of Explicit Congestion Notification (ECN) with RTP is
described in , which specifies how
to negotiate the use of ECN with RTP and defines an RTCP ECN
Feedback Packet to carry ECN feedback reports. It uses an SDP
"a=ecn-capable-rtp:" attribute to negotiate the use of ECN, and
the "a=rtcp-fb:" attribute with the "nack" parameter "ecn" to
negotiate the use of RTCP ECN Feedback Packets.
The RTCP ECN Feedback Packet is not useful when ECN is used with
the RTP Congestion Control Feedback Packet defined in this memo,
since it provides duplicate information. When
congestion control feedback is to be used with RTP and ECN,
the SDP offer generated MUST include an "a=ecn-capable-rtp:"
attribute to negotiate ECN support, along with an "a=rtcp-fb:"
attribute with the "ack" parameter "ccfb" to indicate that the
RTP Congestion Control Feedback Packet can be used.
The "a=rtcp-fb:" attribute MAY also include the "nack" parameter
"ecn" to indicate that the RTCP ECN Feedback Packet is also
supported. If an SDP offer signals support for both RTP
Congestion Control Feedback Packets and the RTCP ECN Feedback
Packet, the answering party SHOULD signal support for one, but
not both, formats in its SDP answer to avoid sending duplicate
feedback.
When using ECN with RTP, the guidelines in MUST be followed to initiate the use of ECN in an
RTP session. The guidelines in regarding the ongoing use of ECN within an RTP
session MUST also be followed, with the exception that feedback is sent using the RTCP
Congestion Control Feedback Packets described in this memo rather
than using RTP ECN Feedback Packets. Similarly, the guidance
in
related to detecting failures
MUST be followed, with the exception that the necessary information is
retrieved from the RTCP Congestion Control Feedback Packets rather than
from RTP ECN Feedback Packets.
Design RationaleThe primary function of RTCP SR/RR packets is to report statistics
on the reception of RTP packets. The reception report blocks sent in
these packets contain information about observed jitter, fractional
packet loss, and cumulative packet loss. It was intended that this
information could be used to support congestion control algorithms,
but experience has shown that it is not sufficient for that purpose.
An efficient congestion control algorithm requires more fine-grained
information on per-packet reception quality than is provided by SR/RR
packets to react effectively. The feedback format defined in this memo
provides such fine-grained feedback.Several other RTCP extensions also provide more detailed feedback
than SR/RR packets:
TMMBR:
The codec control messages for the RTP/AVPF profile
include a
Temporary Maximum Media Stream Bit Rate Request (TMMBR) message. This is used to convey a temporary maximum bitrate limitation from a receiver of RTP packets to their sender. Even
though it was not designed to replace congestion control, TMMBR has
been used as a means to do receiver-based congestion control where
the session bandwidth is high enough to send frequent TMMBR messages,
especially when used with non-compound RTCP packets .
This approach requires the receiver of the RTP packets to monitor
their reception, determine the level of congestion, and recommend
a maximum bitrate suitable for current available bandwidth on the
path; it also assumes that the RTP sender can/will respect that bitrate. This is the opposite of the sender-based congestion control
approach suggested in this memo, so TMMBR cannot be used to convey
the information needed for sender-based congestion control. TMMBR
could, however, be viewed as a complementary mechanism that can inform
the sender of the receiver's current view of an acceptable maximum bitrate. Mechanisms that convey the receiver's estimate of the maximum
available bitrate provide similar feedback.
RTCP Extended Reports (XRs):
Numerous RTCP XR blocks have been defined to report details of packet
loss, arrival times , delay
, and ECN marking .
It is possible to combine several such XR blocks into a compound
RTCP packet, to report the detailed loss, arrival time, and ECN
marking information needed for effective sender-based
congestion control. However, the result has high overhead
in terms of both bandwidth and complexity, due to the need to stack
multiple reports.
Transport-wide Congestion Control:
The format
defined in this memo provides individual feedback on each SSRC.
An alternative is to add a header extension to each RTP packet,
containing a single, transport-wide, packet sequence number,
then have the receiver send RTCP reports giving feedback on
these additional sequence numbers
.
Such an approach increases the size of each RTP packet by 8 octets, due to
the header extension, but reduces the size of the RTCP feedback packets,
and can simplify
the rate calculation at the sender if it maintains a single
rate limit that applies to all RTP packets sent, irrespective
of their SSRC.
Equally, the use of transport-wide feedback makes
it more difficult to adapt the sending rate, or respond to lost
packets, based on the reception and/or loss patterns observed
on a per-SSRC basis (for example, to perform differential rate
control and repair for audio and video flows, based on knowledge
of what packets from each flow were lost). Transport-wide
feedback is also a less natural fit with the wider RTP framework,
which makes extensive use of per-SSRC sequence numbers and
feedback.
Considering these issues, we believe it appropriate to design a
new RTCP feedback mechanism to convey information for sender-based
congestion control algorithms. The new congestion control feedback
RTCP packet described in
provides such a mechanism.IANA Considerations
The IANA has registered one new RTP/AVPF Transport-Layer
Feedback Message in the "FMT Values for RTPFB Payload Types" table
as defined in :
Name:
CCFB
Long name:
RTP Congestion Control Feedback
Value:
11
Reference:
RFC 8888
The IANA has also registered one new SDP "rtcp-fb" attribute
"ack" parameter, "ccfb", in the SDP '"ack" and "nack" Attribute Values'
registry:
Value name:
ccfb
Long name:
Congestion Control Feedback
Usable with:
ack
Mux:
IDENTICAL-PER-PT
Reference:
RFC 8888
Security ConsiderationsThe security considerations of the RTP specification
, the applicable RTP profile (e.g.,
, , or
), and the RTP congestion control algorithm
being used (e.g., ,
,
, or
) apply.A receiver that intentionally generates inaccurate RTCP congestion
control feedback reports might be able to trick the sender into sending
at a greater rate than the path can support, thereby causing congestion on the
path.
This scenario will negatively impact the quality of experience
of that receiver, potentially causing both denial of service
to other traffic sharing the path and excessively increased resource
usage at the media sender.
Since RTP is an unreliable transport, a sender can intentionally drop a packet,
leaving a gap in the RTP sequence number space without causing serious harm, to
check that the receiver is correctly reporting losses. (This needs to be done with
care and some awareness of the media data being sent, to limit impact on the user
experience.)An on-path attacker that can modify RTCP Congestion Control Feedback
Packets can change the reports to trick the sender into sending at either
an excessively high or excessively low rate, leading to denial of service.
The secure RTCP profile can be used to authenticate
RTCP packets to protect against this attack.An off-path attacker that can spoof RTCP Congestion Control Feedback
Packets can similarly trick a sender into sending at an incorrect
rate, leading to denial of service. This attack is difficult, since the
attacker needs to guess the SSRC and sequence number in addition to the
destination transport address. As with on-path attacks, the secure RTCP
profile can be used to authenticate RTCP packets
to protect against this attack.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Addition of Explicit Congestion Notification (ECN) to IPThis memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]RTP: A Transport Protocol for Real-Time ApplicationsThis memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]RTP Profile for Audio and Video Conferences with Minimal ControlThis document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]The Secure Real-time Transport Protocol (SRTP)This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and ConsequencesThis memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]Explicit Congestion Notification (ECN) for RTP over UDPThis memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]Multimedia Congestion Control: Circuit Breakers for Unicast RTP SessionsThe Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Negotiating Media Multiplexing Using the Session Description Protocol (SDP)A Framework for Session Description Protocol (SDP) Attributes When MultiplexingInformative ReferencesRMCAT Feedback RequirementsIETF 95A Google Congestion Control Algorithm for Real-Time CommunicationWork in ProgressRTP Control Protocol Extended Reports (RTCP XR)This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric ReportingThis document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]Self-Clocked Rate Adaptation for MultimediaThis memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.Shared Bottleneck Detection for Coupled Congestion Control for RTP MediaThis document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed.Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time MediaThis document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead.RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia ConferencesUniversity of Glasgow This memo discusses the types of congestion control feedback that it
is possible to send using the RTP Control Protocol (RTCP), and their
suitability of use in implementing congestion control for unicast
multimedia applications.
Work in ProgressRTP Extensions for Transport-wide Congestion Control This document proposes an RTP header extension and an RTCP message
for use in congestion control algorithms for RTP-based media flows.
It adds transport-wide packet sequence numbers and corresponding
feedback message so that congestion control can be performed on a
transport level at the send-side, while keeping the receiver dumb.
Work in ProgressAcknowledgementsThis document is based on the outcome of a design team discussion
in the RTP Media Congestion Avoidance Techniques (RMCAT) Working Group.
The authors would like to thank
,
,
,
,
,
,
,
,
and
for their valuable feedback.Authors' AddressesEricsson ABTorshamnsgatan 23Stockholm164 83Sweden+46 10 717 37 43zaheduzzaman.sarker@ericsson.comUniversity of GlasgowSchool of Computing ScienceGlasgowG12 8QQUnited Kingdomcsp@csperkins.orgCALLSTATS I/O OyAnnankatu 31-33 C 42Helsinki00100Finlandvarun.singh@iki.fihttps://www.callstats.io/AcousticComms Consulting6310 Watercrest Way Unit 203Lakewood RanchFL34202-5122United States of America+1 732 832 9723mar42@cornell.eduhttp://ramalho.webhop.info/