Internet DRAFT - draft-holmer-rmcat-transport-wide-cc-extensions

draft-holmer-rmcat-transport-wide-cc-extensions







Network Working Group                                          S. Holmer
Internet-Draft                                                M. Flodman
Intended status: Experimental                                  E. Sprang
Expires: April 21, 2016                                           Google
                                                        October 19, 2015


          RTP Extensions for Transport-wide Congestion Control
           draft-holmer-rmcat-transport-wide-cc-extensions-01

Abstract

   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.

Requirements Language

   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 RFC 2119 [RFC2119].

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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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



Holmer, et al.           Expires April 21, 2016                 [Page 1]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


   (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.  Transport-wide Sequence Number  . . . . . . . . . . . . . . .   3
     2.1.  Semantics . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  RTP header extension format . . . . . . . . . . . . . . .   3
     2.3.  Signaling of use of this extension  . . . . . . . . . . .   3
   3.  Transport-wide RTCP Feedback Message  . . . . . . . . . . . .   4
     3.1.  Message format  . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Packet Status Symbols . . . . . . . . . . . . . . . .   6
       3.1.2.  Packet Status Chunks  . . . . . . . . . . . . . . . .   7
       3.1.3.  Run Length Chunk  . . . . . . . . . . . . . . . . . .   7
       3.1.4.  Status Vector Chunk . . . . . . . . . . . . . . . . .   8
       3.1.5.  Receive Delta . . . . . . . . . . . . . . . . . . . .   9
   4.  Overhead discussion . . . . . . . . . . . . . . . . . . . . .  10
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .  11
     A.1.  First version . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document proposes RTP header extension containing a transport-
   wide packet sequence number and an RTCP feedback message feeding back
   the arrival times and sequence numbers of the packets received on a
   connection.

   Some of the benefits that these extensions bring are:

   o  The congestion control algorithms are easier to maintain and
      improve as there is less synchronization between sender and
      receiver versions needed.  It should be possible to implement
      [I-D.ietf-rmcat-gcc], [I-D.ietf-rmcat-nada] and
      [I-D.ietf-rmcat-scream-cc] with the proposed protocol.




Holmer, et al.           Expires April 21, 2016                 [Page 2]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


   o  More flexibility in what algorithms are used, as long as they are
      having most of their logic on the send-side.  For instance
      different behavior can be used depending on if the rate produced
      is application limited or not.

2.  Transport-wide Sequence Number

2.1.  Semantics

   This RTP header extension is added on the transport layer, and uses
   the same counter for all packets which are sent over the same
   connection (for instance as defined by bundle).

   The benefit with a transport-wide sequence numbers is two-fold:

   o  It is a better fit for congestion control as the congestion
      controller doesn't operate on media streams, but on packet flows.

   o  It allows for earlier packet loss detection (and recovery) since a
      loss in stream A can be detected when a packet from stream B is
      received, thus we don't have to wait until the next packet of
      stream A is received.

2.2.  RTP header extension format

   This document describes a message using the application specific
   payload type.  This is suitable for experimentation; upon
   standardization, a specific type can be assigned for the purpose.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       0xBE    |    0xDE       |           length=1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  ID   | L=1   |transport-wide sequence number | zero padding  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   An RTP header extension with a 16 bits sequence number attached to
   all packets sent.  This sequence number is incremented by 1 for each
   packet being sent over the same socket.

2.3.  Signaling of use of this extension

   When signalled in SDP, the standard mechanism for RTP header
   extensions [RFC5285] is used:





Holmer, et al.           Expires April 21, 2016                 [Page 3]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


   a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-
   cc-extensions

3.  Transport-wide RTCP Feedback Message

   To allow the most freedom possible to the sender, information about
   each packet delivered is needed.  The simplest way of accomplishing
   that is to have the receiver send back a message containing an
   arrival timestamp and a packet identifier for each packet received.
   This way, the receiver is dumb and simply records arrival timestamps
   (A) of packets.  The sender keeps a map of in-flight packets, and
   upon feedback arrival it looks up the on-wire timestamp (S) of the
   corresponding packet.  From these two timestamps the sender can
   compute metrics such as:

   o  Inter-packet delay variation: d(i) = A(i) - S(i) - (A(i-1) -
      S(i-1))

   o  Estimated queueing delay: q(i) = A(i) - S(i) -
      min{j=i-1..i-w}(A(j) - S(j))

   Since the sender gets feedback about each packet sent, it will be set
   to better assess the cost of sending bursts of packets compared to
   aiming at sending at a constant rate decided by the receiver.

   Two down-sides with this approach are:

   o  It isn't possible to differentiate between lost feedback on the
      downlink and lost packets on the uplink.

   o  Increased feedback rate on the reverse direction.

   From a congestion control perspective, lost feedback messages are
   handled by ignoring packets which would have been reported as lost or
   received in the lost feedback messages.  This behavior is similar to
   how a lost RTCP receiver report is handled.

   It is recommended that a feedback message is sent for every frame
   received, but in cases of low uplink bandwidth it is acceptable to
   send them less frequently, e.g., for instance once per RTT, to reduce
   the overhead.

3.1.  Message format

   The message is an RTCP message with payload type 206.  RFC 3550
   [RFC3550] defines the range, RFC 4585 [RFC3550] defines the specific
   PT value 206 and the FMT value 15.




Holmer, et al.           Expires April 21, 2016                 [Page 4]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


        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=15 |    PT=205     |           length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      SSRC of media source                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      base sequence number     |      packet status count      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 reference time                | fb pkt. count |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          packet chunk         |         packet chunk          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         packet chunk          |  recv delta   |  recv delta   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           recv delta          |  recv delta   | zero padding  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   version (V):  2 bits This field identifies the RTP version.  The
               current version is 2.

   padding (P):  1 bit If set, the padding bit indicates that the packet
               contains additional padding octets at the end that are
               not part of the control information but are included in
               the length field.

   feedback message type (FMT):  5 bits This field identifies the type
               of the FB message.  It must have the value 15.

   payload type (PT):  8 bits This is the RTCP packet type that
               identifies the packet as being an RTCP FB message.  The
               value must be RTPFB = 205.

   SSRC of packet sender:  32 bits The synchronization source identifier
               for the originator of this packet.

   SSRC of media source:  32 bits The synchronization source identifier
               of the media source that this piece of feedback




Holmer, et al.           Expires April 21, 2016                 [Page 5]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


               information is related to.  TODO: This is transport wide,
               do we just pick any of the media source SSRCs?

   base sequence number:  16 bits The transport-wide sequence number of
               the first packet in this feedback.  This number is not
               necessarily increased for every feedback; in the case of
               reordering it may be decreased.

   packet status count:  16 bits The number of packets this feedback
               contains status for, starting with the packet identified
               by the base sequence number.

   reference time:  24 bits Signed integer indicating an absolute
               reference time in some (unknown) time base chosen by the
               sender of the feedback packets.  The value is to be
               interpreted in multiples of 64ms.  The first recv delta
               in this packet is relative to the reference time.  The
               reference time makes it possible to calculate the delta
               between feedbacks even if some feedback packets are lost,
               since it always uses the same time base.

   feedback packet count:  8 bits A counter incremented by one for each
               feedback packet sent.  Used to detect feedback packet
               losses.

   packet chunk:  16 bits A list of packet status chunks.  These
               indicate the status of a number of packets starting with
               the one identified by base sequence number.  See below
               for details.

   recv delta: 8 bits For each "packet received" status, in the packet
               status chunks, a receive delta block will follow.  See
               details below.

3.1.1.  Packet Status Symbols

   The status of a packet is described using a 2-bit symbol:

      00 Packet not received

      01 Packet received, small delta

      10 Packet received, large or negative delta

      11 [Reserved]

   Packets with status "Packet not received" should not necessarily be
   interpreted as lost.  They might just not have arrived yet.



Holmer, et al.           Expires April 21, 2016                 [Page 6]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


   For each packet received with a delta, to the previous received
   packet, within +/-8191.75ms, a receive delta block is appended to the
   feedback message.

   Note: In the case the base sequence number is decreased, creating a
   window overlapping the previous feedback messages, the status for any
   packets previously reported as received must be marked as "Packet not
   received" and thus no delta included for that symbol.

3.1.2.  Packet Status Chunks

   Packet status is described in chunks, similar to a Loss RLE Report
   Block.  The are two different kinds of chunks:

   o  Run length chunk

   o  Status vector chunk

   All chunk types are 16 bits in length.  The first bit of the chunk
   identifies whether it is an RLE chunk or a vector chunk.

3.1.3.  Run Length Chunk

   A run length chunk starts with 0 bit, followed by a packet status
   symbol and the run length of that symbol.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T| S |       Run Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   chunk type (T):  1 bit A zero identifies this as a run length chunk.

   packet status symbol (S):  2 bits The symbol repeated in this run.
               See above.

   run length (L):  13 bits An unsigned integer denoting the run length.

   Example 1:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0 0|0 0 0 0 0 1 1 0 1 1 1 0 1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is a run of the "packet not received" status of length 221.



Holmer, et al.           Expires April 21, 2016                 [Page 7]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


   Example 2:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|1 1|0 0 0 0 0 0 0 0 1 1 0 0 0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is a run of the "packet received, w/o recv delta" status of
   length 24.

3.1.4.  Status Vector Chunk

   A status vector chunk starts with a 1 bit to identify it as a vector
   chunk, followed by a symbol size bit and then 7 or 14 symbols,
   depending on the size bit.

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |T|S|       symbol list         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   chunk type (T):  1 bit A one identifies this as a status vector
               chunk.

   symbol size (S):  1 bit A zero means this vector contains only
               "packet received" (0) and "packet not received" (1)
               symbols.  This means we can compress each symbol to just
               one bit, 14 in total.  A one means this vector contains
               the normal 2-bit symbols, 7 in total.

   symbol list:  14 bits A list of packet status symbols, 7 or 14 in
               total.

   Example 1:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|0|0 1 1 1 1 1 0 0 0 1 1 1 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This chunk contains, in order:

      1x "packet not received"

      5x "packet received"



Holmer, et al.           Expires April 21, 2016                 [Page 8]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


      3x "packet not received"

      3x "packet received"

      2x "packet not received"

   Example 2:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|1|0 0 1 1 0 1 0 1 0 1 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This chunk contains, in order:

      1x "packet not received"

      1x "packet received, w/o timestamp"

      3x "packet received"

      2x "packet not received"

3.1.5.  Receive Delta

   Deltas are represented as multiples of 250us:

   o  If the "Packet received, small delta" symbol has been appended to
      the status list, an 8-bit unsigned receive delta will be appended
      to recv delta list, representing a delta in the range [0, 63.75]
      ms.

   o  If the "Packet received, large or negative delta" symbol has been
      appended to the status list, a 16-bit signed receive delta will be
      appended to recv delta list, representing a delta in the range
      [-8192.0, 8191.75] ms.

   o  If the delta exceeds even the larger limits, a new feedback
      message must be used, where the 24-bit base receive delta can
      cover very large gaps.

   Note that the first receive delta is relative to the reference time
   indicated by the base receive delta.

   TODO: Add examples.





Holmer, et al.           Expires April 21, 2016                 [Page 9]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


   The smaller receive delta upper bound of 63.75 ms means that this is
   only viable at about 1000/25.5 ~= 16 packets per second and above.
   With a packet size of 1200 bytes/packet that amounts to a bitrate of
   about 150 kbit/s.

   The 0.25 ms resolution means that up to 4000 packets per second can
   be represented.  With a 1200 bytes/packet payload, that amounts to
   38.4 Mbit/s payload bandwidth.

4.  Overhead discussion

   TODO: Examples of overhead in various scenarios.

5.  IANA considerations

   Upon publication of this document as an RFC (if it is decided to
   publish it), IANA is requested to register the string "goog-remb" in
   its registry of "rtcp-fb" values in the SDP attribute registry group.

6.  Security Considerations

   If the RTCP packet is not protected, it is possible to inject fake
   RTCP packets that can increase or decrease bandwidth.  This is not
   different from security considerations for any other RTCP message.

7.  Acknowledgements

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
              2008, <http://www.rfc-editor.org/info/rfc5285>.

8.2.  Informative References








Holmer, et al.           Expires April 21, 2016                [Page 10]

Internet-Draft            trnsprt-wide-cc-exts              October 2015


   [I-D.ietf-rmcat-gcc]
              Holmer, S., Marcon, J., Carlucci, G., Cicco, L., and S.
              Mascolo, "A Google Congestion Control Algorithm for Real-
              Time Communication", draft-ietf-rmcat-gcc-00 (work in
              progress), September 2015.

   [I-D.ietf-rmcat-nada]
              Zhu, X., Pan, R., Ramalho, M., 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-01 (work in progress), October 2015.

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

Appendix A.  Change log

A.1.  First version

Authors' Addresses

   Stefan Holmer
   Google
   Kungsbron 2
   Stockholm  11122
   Sweden

   Email: holmer@google.com


   Magnus Flodman
   Google
   Kungsbron 2
   Stockholm  11122
   Sweden

   Email: mflodman@google.com


   Erik Sprang
   Google
   Kungsbron 2
   Stockholm  11122
   Sweden

   Email: sprang@google.com



Holmer, et al.           Expires April 21, 2016                [Page 11]