IETF RMCAT Working Group                                       Z. Sarker
Internet-Draft                                               Ericsson AB
Intended status: Standards Track                              C. Perkins
Expires: January 8, 2017                           University of Glasgow
                                                                V. Singh
                                                            callstats.io
                                                              M. Ramalho
                                                           Cisco Systems
                                                           July 07, 2016


      RTP Control Protocol (RTCP) Feedback for Congestion Control
                   draft-dt-rmcat-feedback-message-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 8, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Sarker, et al.           Expires January 8, 2017                [Page 1]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   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.  Feedback Message  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  RTCP Packet format  . . . . . . . . . . . . . . . . . . .   4
   4.  Feedback Frequency and Overhead . . . . . . . . . . . . . . .   6
   5.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  RTP/AVPF Transport Layer Feedback Message . . . . . . . .   8
     7.2.  RTCP XR Report Blocks . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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




Sarker, et al.           Expires January 8, 2017                [Page 2]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


   (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 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 future RTP congestion
   control algorithms as well.

   [Editor's Note: consider removing this part of the section in the
   later versions ] In preparing this memo, we have considered the
   following:

   o  What are the feedback requirements for the proposed RTP congestion
      control candidate solution?

   o  Can we design a feedback message that is future proof, and general
      enough to meet the needs of algorithms that have yet to be
      defined?

   o  Can we use existing RTCP Extended Report (XR) blocks and/or RTCP
      Feedback Messages?  If not, what is the rationale behind new XR
      blocks and/or RTCP feedback messages?

   o  What will be the wire format of the generic feedback message?

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.  Feedback Message

   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.

   o  Packet Identifier : RTP sequence number.  The RTP packet header
      includes an incremental packet sequence number that the sender




Sarker, et al.           Expires January 8, 2017                [Page 3]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


      needs to correlate packets sent at the sender with packets
      received at the receiver.

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

   o  Packet Explicit Congestion Notification (ECN) Marking : If ECN
      [RFC3168] 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 [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 by Synchronization Source (SSRC) identifier.

   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.

3.1.  RTCP Packet format

   The feedback is over RTCP [RFC3550] and it is described as a stand
   alone RTCP packet for now, suitable for use in regular RTCP reports.
   [FIXME: this is simply a placeholder for now.  We can design
   different wire format of this packet with different efficiency in



Sarker, et al.           Expires January 8, 2017                [Page 4]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


   mind.  This doc will contain a very simple format.  The optimized
   versions will be discussed in the group and finally the selected one
   will replace this simple format in future.  This section will
   describe a new RTP/AVPF transport feedback message and a new RTCP XR
   block report ]

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    BT=RC2F    |   SSRC count  |      Block Length = TBD       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SSRC of Source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Report Timestamp (32bits)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  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    | ...                           |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The XR Discard RLE report block uses the same format as specified for
   the loss and duplicate report blocks in [RFC3611].  The fields "block
   length", "begin_seq", and "end_seq" have the same semantics and
   representation as defined in [RFC3611]

   Block Type (BT, 8 bits): The RMCAT congestion control feedback Report
   Block is identified by the constant RC2F.  [Note to RFC Editor:
   Please replace RC2F with the IANA provided RTCP XR block type for
   this block.]

   SSRC Count (8 bits): field describes the number of SSRCs reported by
   this report block.  The number should at least be 1.





Sarker, et al.           Expires January 8, 2017                [Page 5]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


   SSRC of source (32 bits): The SSRC of the RTP source being reported
   upon by this report block.  This report block MAY report on multiple
   SSRC

   Report Timestamp (RTS, 32 bits): represents the timestamp when this
   report was generated.  [FIXME: It is derived from which clock?]

   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 metrics.  [FIXME: if an odd number of
   reports are included, i.e., end_seq - begin_seq is odd OPTION 1: pad
   to a 32 bit boundary?  How do we mark for padding?  OPTION 2: just
   report on higher than received RTP packet.  In both cases the 16bits
   are set to zero.  A short note on modulo operations for the sequence
   number may be made here?]

   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.

   ECN (2 bits): is the echoed ECN mark of the packet (00 if not
   received or if ECN is not used).

   Arrival time offset (ATO, 13 bits): it 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.

   [FIXME: Should the timestamp of the RTP packets and the RTS be same?
   Needs more information if we go down this path.]  [FIXME: should
   reserve 0xFFF to mean anything greater than 0xFFE.]

   The above packet format is expressed as an RTCP XR report block when
   reported with regular RTCP reports.  However, the same block
   information will need a new RTP/AVPF feedback message if reported
   more frequently than regular RTCP report.

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, and the possible rates of feedback.

   It is a general understanding that the congestion control algorithms
   will work better with more frequent feedback - per packet feedback.



Sarker, et al.           Expires January 8, 2017                [Page 6]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


   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
   [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 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 [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) 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 Section 3) to
   react to the congestion or to avoid funder congestion on the path.

   Codec Control Message for AVPF [RFC5104] 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
   [RFC5506].  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.

   There are number of RTCP eXtended Report (XR) blocks have been
   defined for reporting of delay, loss and ECN marking.  It is possible



Sarker, et al.           Expires January 8, 2017                [Page 7]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


   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.

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

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 Randell Jesup for their valuable
   contribution to the discussions and to the document.

7.  IANA Considerations

7.1.  RTP/AVPF Transport Layer Feedback Message

   TBD

7.2.  RTCP XR Report Blocks

   TBD

8.  Security Considerations

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

9.  References

9.1.  Normative References

   [I-D.ietf-rmcat-rtp-cc-feedback]
              Perkins, C., "Using RTP Control Protocol (RTCP) Feedback
              for Unicast Multimedia Congestion Control", draft-ietf-
              rmcat-rtp-cc-feedback-00 (work in progress), July 2014.

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







Sarker, et al.           Expires January 8, 2017                [Page 8]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


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

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              DOI 10.17487/RFC3551, July 2003,
              <http://www.rfc-editor.org/info/rfc3551>.

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

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              DOI 10.17487/RFC4585, July 2006,
              <http://www.rfc-editor.org/info/rfc4585>.

   [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, <http://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, <http://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-01 (work in
              progress), October 2015.



Sarker, et al.           Expires January 8, 2017                [Page 9]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


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

   [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-04 (work in progress),
              March 2016.

   [I-D.ietf-rmcat-scream-cc]
              Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
              for Multimedia", draft-ietf-rmcat-scream-cc-05 (work in
              progress), June 2016.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
              February 2008, <http://www.rfc-editor.org/info/rfc5104>.

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











Sarker, et al.           Expires January 8, 2017               [Page 10]


Internet-Draft     Congestion Control Feedback in RTCP         July 2016


   Varun Singh
   Nemu Dialogue Systems Oy
   Runeberginkatu 4c A 4
   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

































Sarker, et al.           Expires January 8, 2017               [Page 11]