IETF RMCAT Working Group                                       Z. Sarker
Internet-Draft                                               Ericsson AB
Intended status: Standards Track                              C. Perkins
Expires: May September 3, 2018                         University of Glasgow
                                                                V. Singh
                                                            callstats.io
                                                              M. Ramalho
                                                           Cisco Systems
                                                        October 30, 2017
                                                           March 2, 2018

      RTP Control Protocol (RTCP) Feedback for Congestion Control
               draft-ietf-avtcore-cc-feedback-message-00
               draft-ietf-avtcore-cc-feedback-message-01

Abstract

   This document describes a an RTCP feedback message intended to enable
   congestion control for interactive real-time traffic.  The RTP Media
   Congestion Avoidance Techniques (RMCAT) Working Group formed a design
   team to analyze feedback requirements from various congestion control
   algorithms and to design a generic feedback message to help ensure
   interoperability across those algorithms. traffic using RTP.  The
   feedback message is designed for use with a sender-based congestion control,
   control algorithm, in which means the receiver of the media will send necessary an RTP flow sends RTCP
   feedback packets to the sender of containing the media information the sender
   needs to perform the congestion control at the sender. control.

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 https://datatracker.ietf.org/drafts/current/. 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 May September 3, 2018.

Copyright Notice

   Copyright (c) 2017 2018 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)
   (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
   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  RTCP Feedback Message  . . . . . . . . . . for Congestion Control  . . . . . . . . . . . .   3
     3.1.  RTCP Congestion Control Feedback Report . . . . . . . . .   4
   4.  Feedback Frequency and Overhead . . . . . . . . . . . . . . .   6
   5.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10  11

1.  Introduction

   For interactive real-time traffic traffic, such as video conferencing flows,
   the typical protocol choice is
   Realtime the Real-time Transport Protocol (RTP)
   running over the User Datagram Protocol (UDP).  RTP does not provide
   any guarantee of Quality of Service (QoS),
   reliable reliability, or timely delivery
   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 to by which the receiver of
   an RTP flow can periodically send transport and media quality metrics
   to the
   media sender which can be utilized and extended for the purposes of
   RMCAT congestion control.  For a congestion control algorithm which
   operates at the media sender, RTCP messages that RTP flow.  This information can be transmitted from
   the media receiver back to used by the media
   sender to enable perform congestion control.  In the absence of standardized
   messages for this purpose,
   the designers of congestion control algorithm designers algorithms
   have designed developed proprietary RTCP messages that convey only those
   parameters required needed for their respective designs.  As a direct result,
   the different congestion control (a.k.a. (i.e., rate adaptation) 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 generic congestion
   control feedback format.

   To help achieve interoperability for unicast RTP congestion control,
   this memo proposes a common RTCP feedback packet format that can be
   used by NADA [I-D.ietf-rmcat-nada], SCReAM
   [I-D.ietf-rmcat-scream-cc], Google Congestion Control

   [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection
   [I-D.ietf-rmcat-sbd], and hopefully also by future RTP congestion
   control algorithms as well. algorithms.

2.  Terminology

   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].

   In addition the terminology defined in [RFC3550], [RFC3551],
   [RFC3611], [RFC4585], and [RFC5506] applies.

3.  RTCP Feedback Message

   The design team analyzed the feedback requirements from the different
   proposed candidate in RMCAT WG.  The for Congestion Control

   Based on an analysis showed some
   commonalities between the proposed solution candidate of NADA [I-D.ietf-rmcat-nada], SCReAM
   [I-D.ietf-rmcat-scream-cc], Google Congestion Control
   [I-D.ietf-rmcat-gcc] and some can be
   derived from other information.  The design team has agreed to have Shared Bottleneck Detection
   [I-D.ietf-rmcat-sbd], the following per-RTP packet information block in the congestion control
   feedback message information has been determined to satisfy
   different requirement analyzed. be necessary:

   o  Packet Identifier :  RTP sequence number. number: The RTP packet header
      includes receiver of an incremental packet sequence number that the sender RTP flow needs to correlate feedback
      the sequence numbers of the received RTP packets sent at to the sender, so
      the sender with can determine which packets were received at the receiver.

   o and which
      were lost.  Packet Arrival Time : Arrival time stamp at the receiver loss is used as an indication of the
      media. congestion by
      many congestion control algorithms.

   o  Packet Arrival Time: The sender requires receiver of an RTP flow needs to feedback
      the arrival time stamp of the
      respective each RTP packet to determine delay and jitter the packet had
      experienced during transmission.  In sender.  Packet delay
      and/or delay variation (jitter) is used as a sender based congestion signal by
      some congestion control solution the sender requires to keep track of the sent
      packets - usually packet sequence number, packet size and packet
      send time.  With the packet arrival time the sender can detect the
      delay and jitter information.  Along with packet loss and delay
      information the sender can estimate the available bandwidth and
      thus adapt to the situation. algorithms.

   o  Packet Explicit Congestion Notification (ECN) Marking : Marking: If ECN
      [RFC3168]
      [RFC3168], [RFC6679] is used, it is necessary to report on feedback 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-CE.
      If the path on which used by the media RTP traffic traversing is ECN capable then the sender can
      use the Congestion Experienced (ECN-CE) marking information for as a
      congestion control.  It is important that the receiver sends the
      ECN-CE marking information of the packet back to the sender to
      take the advantages of ECN marking.  Note that how the receiver
      gets the ECN marking information at application layer is out of
      the scope of this design team.  Additional information for ECN use
      with control signal.

   Every RTP can be found at [RFC6679].

   The feedback messages can have one or more of the above information
   blocks.  For RTCP based feedback message the packet information block
   will be grouped 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 operating system (OS)
   process interruptions can occur at inopportune times.  Thus, the  Accordingly,
   recording of the sent RTP packet send times at the sender sender, and the corresponding
   RTP packet arrival times at the
   receiver should receiver, needs to be made 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 should needs to be
   recorded at the latest last opportunity prior to
   outputting transmitting the media RTP packet
   at the sender (e.g., socket or RTP API) sender, and the arrival time at the receiver (e.g., socket or RTP API) should needs to be
   recorded at the earliest opportunity available to the receiver. opportunity.

3.1.  RTCP Congestion Control Feedback Report

   Congestion 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 [RFC5506] if the RTP/AVPF profile [RFC4585]
   or the RTP/SAVPF profile [RFC5124] 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 as follows: shown in Figure 1:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P| FMT=CCFB |   PT = 205   |          length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 SSRC of RTCP packet sender                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   SSRC of 1st media source RTP Stream                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          begin_seq            |             end_seq           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|ECN|  Arrival time offset    | ...                           .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   SSRC of nth media source RTP Stream                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          begin_seq            |             end_seq           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|ECN|  Arrival time offset    | ...                           |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Report Timestamp (32bits)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 1: RTCP Congestion Control Feedback Packet Format

   The first 8 eight octets are the comprise a standard RTCP header, with PT=205
   and FMT=CCFB
   specifying the remainder indicating that this is a congestion control feedback
   packet, and
   including with the SSRC set to that of the packet sender. sender of the RTCP
   packet.  (NOTE TO RFC EDITOR: please replace CCFB here and in the
   above diagram with the IANA assigned RTCP feedback packet type) type, and
   remove this note)

   Section 6.1 of [RFC4585] requires the RTCP header to be followed by
   the SSRC of the media source 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 the a Report Timestamp.

   The

   Each report for each SSRC received starts block begins with the SSRC of that media
   source.  Then, the received RTP Stream on
   which it is reporting.  Following this, each sequence number between
   the begin_seq and end_seq (both inclusive) inclusive; modulo 65535 to account
   for possible sequence number wrap-around) is represented by a 16-bit
   packet metric block of 16-bits that contains the L, ECN, and ATO fields.  If an odd the
   number of
   reports are included, i.e., end_seq - begin_seq 16-bit packet metric blocks included in the report block is odd
   not a multiple of two, then 16 bits of zero padding MUST be added
   after the last report, packet metric block, to align the
   RTCP end of the packet to a four (4) bytes
   metric blocks with the next 32 bit boundary.  The  In each packet metric
   block, the L, ECN, and ATO fields are as follows:

   o  L (1 bit): is a boolean to indicate if the packet was received. 0
      represents that the packet was not yet received and all the
      subsequent bits (ECN and ATO) are also set to 0.  1 represent the
      packet was received and the subsequent bits in the block need to
      be parsed.

   o  ECN (2 bits): is the echoed ECN mark of the packet.  These are set
      to 00 if not received, or if ECN is not used.

   o  Arrival time offset (ATO, 13 bits): is the relative arrival time of the RTP packets
      packet at the receiver before this receiver.  It is measured as an offset from the time
      at which the RTCP congestion control feedback report was
      generated measured in milliseconds.  It packet is
      sent.  The arrival time offset is calculated by subtracting the
      reception timestamp time of the RTP packet denoted by this 16bit 16 bit packet
      metric block and from the timestamp Report Timestamp (RTS) field of this report. the RTCP
      congestion control feedback report packet in which the packet
      metric report block is contained.  The arrival time offset is
      measured in units of 1/1024 seconds (this unit is chosen to give
      exact offsets from the RTS field).  If the measured value is
      greater than 8.189 8189/1024 seconds (the value that would be coded as
      0x1FFD), the value 0x1FFE MUST be reported to indicate an over-range over-
      range positive measurement.  If the measurement is unavailable,
      the value 0x1FFF MUST be reported.

   The RTCP congestion control feedback report packet concludes with the
   Report Timestamp field (RTS, 32 bits): bits).  This represents the timestamp time
   instant when this the report packet was generated.  The sender value of RTS field
   is derived from the same wallclock used to generate the NTP timestamp
   field in RTCP Sender Report (SR) and Receiver Report (RR) packets.
   It is formatted as the middle 32 bits of an NTP format timestamp, as
   described in Section 4 of [RFC3550].

   RTCP congestion control feedback message decides packets SHOULD include a report
   block for each SSRC that is being congestion controlled.  The
   sequence number ranges reported on
   the wall-clock.  Usually, it should in consecutive reports for an SSRC
   SHOULD be derived consecutive and SHOULD NOT overlap (i.e., begin_seq for a
   report is expected to be one greater, modulo 65535, than end_seq of
   the previous report for that SSRC).  If overlapping reports are sent,
   the information in the later report updates that in any previous
   reports for packets included in both reports (although note that such
   updated information will likely arrive too late to affect congestion
   control decisions at the sender).  Reports that cover RTP sequence
   number ranges that are more than 16384 (i.e., one quarter of the
   sequence number space) ahead of the last end_seq received from an
   SSRC, or behind the same wall-
   clock that is used last begin_seq received from an SSRC, modulo
   65535 to account for timestamping RTP wrap-around, MUST be ignored.

   If no packets arrival . Consistency are received from an SSRC in a reporting interval, then
   no report block is sent for that SSRC.  A regular SR/RR packet SHOULD
   be sent instead, since the unit and resolution (10th non-increased extended highest sequence
   number received field of millisecond should be good enough
   ) is important here.  In addition, that SR/RR packet will inform the media sender can ask for a
   specific resolution it wants.
   that no packets have been received.

4.  Feedback Frequency and Overhead

   There is a trade-off between speed and accuracy of reporting, and the
   overhead of the reports.  [I-D.ietf-rmcat-rtp-cc-feedback] discusses
   this trade-off, suggests desirable RTCP feedback rates, and provides
   guidance on how to configure the possible rates RTCP bandwidth fraction, etc., to
   make appropriate use of feedback. the reporting block described in this memo.
   Specifications for RTP congestion control algorithms can also provide
   guidance.

   It is a general understanding that the congestion control algorithms
   will work better with more frequent feedback - per packet feedback.
   However, RTCP bandwidth and transmission rules put some upper limits
   on how frequently the RTCP feedback messages can be send from the
   media RTP
   receiver to the media RTP sender.  It has been shown
   [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame
   feedback is a reasonable assumption on how frequent the RTCP feedback
   messages can be transmitted.  The design team  It has also have been noted that even if a
   higher frequency of feedback is desired it is not viable if the
   feedback messages starts to compete against the media RTP traffic on the
   feedback path during congestion period.  Analyzing the feedback
   interval requirement [feedback-requirements] it can be seen that the
   candidate algorithms can perform with a feedback interval range of
   50-200ms.  A value within this range need to be negotiated at session
   setup.

5.  Design Rationale

   The primary function of RTCP Sender Report (SR) / Receiver Report
   (RR) SR/RR packets is to report statistics on
   the reception quality of media. RTP packets.  The regular SR /
   RR reports reception report blocks sent in
   these packets contain information about observed jitter, fractional
   packet loss loss, and cumulative packet loss.  The original intent of  It was intended that this
   information was to assist flow and congestion control mechanisms.
   Even though it is possible could be used to do support congestion control based on
   information provided in the SR/RR reports algorithms,
   but experience has shown that it is not sufficient to
   design an efficient congestion control algorithm for interactive
   real-time communication. that purpose.
   An efficient congestion control algorithm requires more fine grain grained
   information on per packet (see Section 3) reception quality than is provided by SR/RR
   packets to react to the congestion or to avoid funder congestion on the path. effectively.

   The Codec Control Message Messages for AVPF the RTP/AVPF profile [RFC5104] defines include
   a Temporary Maximum Media Bit Rate (TMMBR) message which conveys message.  This is used to
   convey a temporary maximum
   bitrate bit rate limitation from the a receiver of the media RTP
   packets to the sender of
   the media. their sender.  Even though it is 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 messages, especially when used with reduced sized reports non-
   compound RTCP packets [RFC5506].  This approach requires the receiver
   of the media RTP packets to analyze the
   data monitor their reception, detect congestion determine the level of
   congestion, and recommend a maximum
   bitrate bit rate suitable for current
   available bandwidth on the path with an
   assumption path; it also assumes that the RTP sender of the media always honors the TMMBR
   message.
   can/will respect that bit rate.  This requirement is completely the opposite of the sender
   based congestion control approach.  Hence, approach suggested in this memo, so TMMBR
   cannot be as a signaling
   means used to convey the information needed for a sender based
   congestion control mechanism.  However, control.  TMMBR should could, however, be viewed a complimentary signaling complementary
   mechanism to
   establish that can inform the sender of the receiver's current view
   of acceptable maximum bitrate which
   a sender based congestion control should honor.

   There are bit rate.

   A number of RTCP eXtended Report (XR) blocks have previously been
   defined for reporting to report details of delay, loss packet loss, arrival times [RFC3611],
   delay [RFC6843], and ECN marking. marking [RFC6679].  It is possible to
   combine several such XR blocks to report the loss detailed loss, arrival
   time, and ECN marking at marking information needed for effective
   sender-based congestion control.  However, the cost of result has high
   overhead both in terms of bandwidth and complexity.  However, there is no existing
   RTCP XR block complexity, due to report packet arrival time.

   Considering the issues discussed here need
   to stack multiple reports.

   Considering these issues, we believe it is rational appropriate to design a new
   congestion control
   RTCP feedback signaling mechanism to convey information for sender based
   congestion control algorithm. algorithms.  The new congestion control feedback
   RTCP packet described in Section 3 provides such a mechanism.

6.  Acknowledgements

   This document is an outcome of RMCAT design team discussion.  We
   would like to thank all participants specially Xiaoquing Zhu, Stefan
   Holmer, David, Ingemar Johansson and Johansson, Randell Jesup Jesup, Ingemar Johansson,
   and Magnus Westerlund for their valuable contribution to the
   discussions and to the document.

7.  IANA Considerations

   IANA is requested to assign a new value in the "FMT Values for RTPFB
   Payload Types" registry for the CCFB transport layer feedback packet
   described in Section 3.1.

8.  Security Considerations

   There is a risk

   The security considerations of causing congestion if an on-path attacker modifies the feedback messages RTP specification [RFC3550], the
   applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]),
   and the RTP congestion control algorithm that is in such use (e.g.,
   [I-D.ietf-rmcat-nada], [I-D.ietf-rmcat-scream-cc],
   [I-D.ietf-rmcat-gcc], or [I-D.ietf-rmcat-sbd]) apply.

   A receiver that intentionally generates inaccurate RTCP congestion
   control feedback reports might be able trick the sender into sending
   at a manner to make available bandwidth greater rate than it the path can support, thereby congesting the
   path.  This will negatively impact the quality of experience of that
   receiver.  Since RTP is an unreliable transport, a sender can
   intentionally leave a gap in reality.  [More on security consideration TBD.] the RTP sequence number space without
   causing harm, to check that the receiver is correctly reporting
   losses.

   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 [RFC3711] can be used to
   authenticate RTCP packets to protect against this attack.

9.  References

9.1.  Normative References

   [I-D.ietf-rmcat-rtp-cc-feedback]
              Perkins, C., "RTP Control Protocol (RTCP) Feedback for
              Congestion Control in Interactive Multimedia Conferences",
              draft-ietf-rmcat-rtp-cc-feedback-03 (work in progress),
              November 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

   [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, <https://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,
              <https://www.rfc-editor.org/info/rfc3551>. <https://www.rfc-
              editor.org/info/rfc3551>.

   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
              "RTP Control Protocol Extended Reports (RTCP XR)",
              RFC 3611, DOI 10.17487/RFC3611, November 2003,
              <https://www.rfc-editor.org/info/rfc3611>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <https://www.rfc-editor.org/info/rfc3711>.

   [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,
              <https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-
              editor.org/info/rfc4585>.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
              2008, <https://www.rfc-editor.org/info/rfc5124>.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
              2009, <https://www.rfc-editor.org/info/rfc5506>.

   [RFC6679]  Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
              and K. Carlberg, "Explicit Congestion Notification (ECN)
              for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
              2012, <https://www.rfc-editor.org/info/rfc6679>.

9.2.  Informative References

   [feedback-requirements]
              "RMCAT Feedback Requirements",
              <://www.ietf.org/proceedings/95/slides/slides-95-rmcat-
              1.pdf>.

   [I-D.ietf-rmcat-gcc]
              Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
              Mascolo, "A Google Congestion Control Algorithm for Real-
              Time Communication", draft-ietf-rmcat-gcc-02 (work in
              progress), July 2016.

   [I-D.ietf-rmcat-nada]
              Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu,
              J., and S. D'Aronco, "NADA: A Unified Congestion Control
              Scheme for Real-Time Media", draft-ietf-rmcat-nada-05 draft-ietf-rmcat-nada-04
              (work in progress), September March 2017.

   [I-D.ietf-rmcat-sbd]
              Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared
              Bottleneck Detection for Coupled Congestion Control for
              RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress),
              July 2017.

   [I-D.ietf-rmcat-scream-cc]
              Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
              for Multimedia", draft-ietf-rmcat-scream-cc-13 draft-ietf-rmcat-scream-cc-10 (work in
              progress), October July 2017.

   [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, <https://www.rfc-editor.org/info/rfc5104>.

   [RFC6843]  Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
              (RTCP) Extended Report (XR) Block for Delay Metric
              Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
              <https://www.rfc-editor.org/info/rfc6843>.

Authors' Addresses

   Zaheduzzaman Sarker
   Ericsson AB
   Luleae
   Sweden

   Phone: +46107173743
   Email: zaheduzzaman.sarker@ericsson.com

   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow  G12 8QQ
   United Kingdom

   Email: csp@csperkins.org

   Varun Singh
   Nemu Dialogue Systems
   CALLSTATS I/O Oy
   Runeberginkatu 4c A 4
   Annankatu 31-33 C 42
   Helsinki  00100
   Finland

   Email: varun.singh@iki.fi
   URI:   http://www.callstats.io/

   Michael A. Ramalho
   Cisco Systems, Inc.
   6310 Watercrest Way Unit 203
   Lakewood Ranch, FL  34202
   USA

   Phone: +1 919 476 2038
   Email: mramalho@cisco.com