draft-ietf-avtcore-cc-feedback-message-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-avtcore-cc-feedback-message-00"
     ipr="trust200902">
  <front>
    <title abbrev="Congestion Control Feedback in RTCP">RTP Control Protocol
    (RTCP) Feedback for Congestion Control</title>

    <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>+46107173743</phone>

        <email>zaheduzzaman.sarker@ericsson.com</email>
      </address>
    </author>

    <author fullname="Colin Perkins" initials="C. S." surname="Perkins">
      <organization>University of Glasgow</organization>

      <address>
        <postal>
          <street>School of Computing Science</street>

          <city>Glasgow</city>

          <code>G12 8QQ</code>

          <country>United Kingdom</country>
        </postal>

        <email>csp@csperkins.org</email>
      </address>
    </author>

    <author fullname="Varun Singh" initials="V." surname="Singh">
      <organization abbrev="callstats.io">Nemu Dialogue Systems
      Oy</organization>

      <address>
        <postal>
          <street>Runeberginkatu 4c A 4</street>

          <city>Helsinki</city>

          <code>00100</code>

          <country>Finland</country>
        </postal>

        <email>varun.singh@iki.fi</email>

        <uri>http://www.callstats.io/</uri>
      </address>
    </author>

    <author fullname="Michael A. Ramalho" initials="M. A." surname="Ramalho">
      <organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>6310 Watercrest Way Unit 203</street>

          <city>Lakewood Ranch</city>

          <region>FL</region>

          <code>34202</code>

          <country>USA</country>
        </postal>

        <phone>+1 919 476 2038</phone>

        <email>mramalho@cisco.com</email>
      </address>
    </author>

    <date day="30" month="October" year="2017" />

    <area>Transport</area>

    <workgroup>IETF RMCAT Working Group</workgroup>

    <keyword>Congestion control, feedback message, RTP, RTCP</keyword>

    <abstract>
      <t>This document describes a 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. The feedback message is
      designed for a sender-based congestion control, which means the receiver
      of the media will send necessary feedback to the sender of the media to
      perform the congestion control at the sender.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>For interactive real-time traffic the typical protocol choice is
      Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP). RTP
      does not provide any guarantee of Quality of Service (QoS), reliable or
      timely delivery and expects the underlying transport protocol to do so.
      UDP alone certainly does not meet that expectation. However, RTP Control
      Protocol (RTCP) provides a mechanism to periodically send transport and
      media 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 can be
      transmitted from the media receiver back to the media sender to enable
      congestion control. In the absence of standardized messages for this
      purpose, the congestion control algorithm designers have designed
      proprietary RTCP messages that convey only those parameters required for
      their respective designs. As a direct result, the different congestion
      control (a.k.a. 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.</t>

      <t>To help achieve interoperability for unicast RTP congestion control,
      this memo proposes a common RTCP feedback format that can be used by
      NADA <xref target="I-D.ietf-rmcat-nada"></xref>, SCReAM <xref
      target="I-D.ietf-rmcat-scream-cc"></xref>, Google Congestion Control
      <xref target="I-D.ietf-rmcat-gcc"></xref> and Shared Bottleneck
      Detection <xref target="I-D.ietf-rmcat-sbd"></xref>, and hopefully
      future RTP congestion control algorithms as well.</t>
    </section>

    <section title="Terminology">
      <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>

      <t>In addition the terminology defined in <xref
      target="RFC3550"></xref>, <xref target="RFC3551"></xref>, <xref
      target="RFC3611"></xref>, <xref target="RFC4585"></xref>, and <xref
      target="RFC5506"></xref> applies.</t>
    </section>

    <section anchor="feedback_message" title="Feedback Message">
      <t>The design team analyzed the feedback requirements from the different
      proposed candidate in RMCAT WG. The analysis showed some commonalities
      between the proposed solution candidate and some can be derived from
      other information. The design team has agreed to have following packet
      information block in the feedback message to satisfy different
      requirement analyzed.</t>

      <t><list style="symbols">
          <t>Packet Identifier : RTP sequence number. The RTP packet header
          includes an incremental packet sequence number that the sender needs
          to correlate packets sent at the sender with packets received at the
          receiver.</t>

          <t>Packet Arrival Time : Arrival time stamp at the receiver of the
          media. The sender requires the arrival time stamp of the respective
          packet to determine delay and jitter the packet had experienced
          during transmission. In a sender based 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.</t>

          <t>Packet Explicit Congestion Notification (ECN) Marking : If ECN
          <xref target="RFC3168"></xref> is used, it is necessary to report on
          the 2-bit ECN mark in received packets, indicating for each packet
          whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE. If the path
          on which the media traffic traversing is ECN capable then the sender
          can use the Congestion Experienced (ECN-CE) marking information for
          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 RTP can be
          found at <xref target="RFC6679"></xref>.</t>
        </list></t>

      <t>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 by Synchronization Source (SSRC) identifier.</t>

      <t>As a practical matter, we note that host Operating System (OS)
      process interruptions can occur at inopportune times. Thus, the
      recording of the sent times at the sender and arrival times at the
      receiver should be made 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 be recorded at the latest opportunity prior to outputting
      the media packet at the sender (e.g., socket or RTP API) and the arrival
      time at the receiver (e.g., socket or RTP API) should be recorded at the
      earliest opportunity available to the receiver.</t>

      <section anchor="sec:ccfb" title="RTCP Congestion Control Feedback Report">
        <t>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 <xref target="RFC5506"></xref> 
        if the RTP/AVPF profile <xref target="RFC4585"></xref> or the 
        RTP/SAVPF profile <xref target="RFC5124"></xref> is used.</t>

        <t>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:</t>

        <t><figure>
            <artwork><![CDATA[
     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 packet sender                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  SSRC of 1st media source                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          begin_seq            |             end_seq           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |L|ECN|  Arrival time offset    | ...                           .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  SSRC of nth media source                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          begin_seq            |             end_seq           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |L|ECN|  Arrival time offset    | ...                           |
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Report Timestamp (32bits)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>The first 8 octets are the RTCP header, with PT=205 and FMT=CCFB
        specifying the remainder is a congestion control feedback packet, and
        including the SSRC of the packet sender. (NOTE TO RFC EDITOR: please
        replace CCFB here and in the above diagram with the IANA assigned 
        RTCP feedback packet type)</t>

        <t>Section 6.1 of <xref target="RFC4585"></xref> requires the RTCP
        header to be followed by the SSRC of the media source being reported 
        upon.  Accordingly, the RTCP header is followed by a report for each
        SSRC received, followed by the Report Timestamp.</t>
     
        <t>The report for each SSRC received starts with the SSRC of that
        media source. Then, each sequence number between the begin_seq and 
        end_seq (both inclusive) is represented by a packet metric block of 
        16-bits that contains the L, ECN, and ATO fields. If an odd number
        of reports are included, i.e., end_seq - begin_seq is odd then 16 
        bits of zero padding MUST be added after the last report, to align 
        the RTCP packet to a four (4) bytes boundary. The L, ECN, and ATO
        fields are as follows:
          <list style="symbols">
            <t>
              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.
            </t>

            <t>
              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.
            </t>

            <t>
              Arrival time offset (ATO, 13 bits): is the relative arrival
              time of the RTP packets at the receiver before this feedback
              report was generated measured in milliseconds. It is
              calculated by subtracting the reception timestamp of the RTP
              packet denoted by this 16bit block and the timestamp (RTS) of
              this report.  If the measured value is greater than 8.189
              seconds (the value that would be coded as 0x1FFD), the value
              0x1FFE MUST be reported to indicate an over-range positive
              measurement.  If the measurement is unavailable, the value
              0x1FFF MUST be reported.
            </t>
          </list>
        </t>

        <t>Report Timestamp (RTS, 32 bits): represents the timestamp when this
        report was generated. The sender of the feedback message decides on
        the wall-clock. Usually, it should be derived from the same wall-clock
        that is used for timestamping RTP packets arrival . Consistency in the
        unit and resolution (10th of millisecond should be good enough ) is
        important here. In addition, the media sender can ask for a specific
        resolution it wants.</t>

      </section>
    </section>

    <section title="Feedback Frequency and Overhead">
      <t>There is a trade-off between speed and accuracy of reporting, and the
      overhead of the reports. <xref
      target="I-D.ietf-rmcat-rtp-cc-feedback"></xref> discusses this
      trade-off, and the possible rates of feedback.</t>

      <t>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
      receiver to the media sender. It has been shown <xref
      target="I-D.ietf-rmcat-rtp-cc-feedback"></xref> 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 also have 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 traffic on
      the feedback path during congestion period. Analyzing the feedback
      interval requirement <xref target="feedback-requirements"></xref> 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.</t>
    </section>

    <section title="Design Rationale">
      <t>The primary function of RTCP Sender Report (SR) / Receiver Report
      (RR) is to report the reception quality of media. The regular SR / RR
      reports contain information about observed jitter, fractional packet
      loss and cumulative packet loss. The original intent of this information
      was to assist flow and congestion control mechanisms. Even though it is
      possible to do congestion control based on information provided in the
      SR/RR reports it is not sufficient to design an efficient congestion
      control algorithm for interactive real-time communication. An efficient
      congestion control algorithm requires more fine grain information on per
      packet (see <xref target="feedback_message"></xref>) to react to the
      congestion or to avoid funder congestion on the path.</t>

      <t>Codec Control Message for AVPF <xref target="RFC5104"></xref> defines
      Temporary Maximum Media Bit Rate (TMMBR) message which conveys a
      temporary maximum bitrate limitation from the receiver of the media to
      the sender of the media. Even though it is 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 with reduced sized reports <xref
      target="RFC5506"></xref>. This requires the receiver of the media to
      analyze the data reception, detect congestion level and recommend a
      maximum bitrate suitable for current available bandwidth on the path
      with an assumption that the sender of the media always honors the TMMBR
      message. This requirement is completely opposite of the sender based
      congestion control approach. Hence, TMMBR cannot be as a signaling means
      for a sender based congestion control mechanism. However, TMMBR should
      be viewed a complimentary signaling mechanism to establish receiver's
      current view of acceptable maximum bitrate which a sender based
      congestion control should honor.</t>

      <t>There are number of RTCP eXtended Report (XR) blocks have been
      defined for reporting of delay, loss and ECN marking. It is possible to
      combine several XR blocks to report the loss and ECN marking at the cost
      of overhead and complexity. However, there is no existing RTCP XR block
      to report packet arrival time.</t>

      <t>Considering the issues discussed here it is rational to design a new
      congestion control feedback signaling mechanism for sender based
      congestion control algorithm.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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 Randell Jesup for their valuable
      contribution to the discussions and to the document.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>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 <xref target="sec:ccfb"/>.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>There is a risk of causing congestion if an on-path attacker modifies
      the feedback messages in such a manner to make available bandwidth
      greater than it is in reality. [More on security consideration TBD.]</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.3550'?>

      <?rfc include='reference.RFC.3551'?>

      <?rfc include='reference.RFC.3611'?>

      <?rfc include='reference.RFC.4585'?>

      <?rfc include='reference.RFC.5124'?>

      <?rfc include='reference.RFC.5506'?>

      <?rfc include='reference.RFC.3168'?>

      <?rfc include='reference.RFC.6679'?>

      <?rfc include='reference.I-D.ietf-rmcat-rtp-cc-feedback'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-rmcat-nada'?>

      <?rfc include="reference.I-D.ietf-rmcat-scream-cc"?>

      <?rfc include="reference.I-D.ietf-rmcat-gcc"?>

      <?rfc include="reference.I-D.ietf-rmcat-sbd"?>

      <?rfc include='reference.RFC.5104'?>

      <reference anchor="feedback-requirements"
                 target="://www.ietf.org/proceedings/95/slides/slides-95-rmcat-1.pdf">
        <front>
          <title>RMCAT Feedback Requirements</title>

          <author>
            <organization></organization>
          </author>

          <date />
        </front>
      </reference>
    </references>
  </back>
</rfc>