Network Working Group S. Holmer Internet-Draft M. Flodman Intended status: Experimental E. Sprang Expires: September 10, 2015 Google March 9, 2015 RTP Extensions for Transport-wide Congestion Control draft-holmer-rmcat-transport-wide-cc-extensions-00 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 September 10, 2015. 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 September 10, 2015 [Page 1] Internet-Draft trnsprt-wide-cc-exts March 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 4. Overhead discussion . . . . . . . . . . . . . . . . . . . . . 6 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 7 A.1. First version . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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.alvestrand-rmcat-congestion], [I-D.zhu-rmcat-nada] and [I-D.johansson-rmcat-scream-cc] with the proposed protocol. 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. Holmer, et al. Expires September 10, 2015 [Page 2] Internet-Draft trnsprt-wide-cc-exts March 2015 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: a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/transport- sequence-number Holmer, et al. Expires September 10, 2015 [Page 3] Internet-Draft trnsprt-wide-cc-exts March 2015 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 Link propagation time delta: 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. Lost feedback messages shouldn't be a big problem as we could simply ignore losses which coincide with lost feedback messages from a congestion control perspective. 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. 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 September 10, 2015 [Page 4] Internet-Draft trnsprt-wide-cc-exts March 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fb seq num |r| base sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | base receive time | sequence number ack vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | recv delta | recv delta | recv delta |...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | recovery base sequence number | recovery vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ fb sequence number: Incremented by one for each feedback message sent. This can be used to figure out if feedback messages have been lost, so that the sender can avoid interpreting lost feedback messages on the downlink as lost media packets on the uplink. r: Set if the recovery base sequence number and recovery vector are included. base transport sequence number: The lowest received (not recovered) sequence number of this feedback message. base receive time: Receive time of the base packet in multiples of 0.1 milliseconds, able to represent up to (2^16 - 1) * 0.1 = 6553.5 milliseconds. This allows probing of up to 96 Mbps with 1200 bytes packets. sequence number ack vector: A bit vector where a 1 at position i represents that base sequence number + i + 1 has been received, and that a recv delta will be included in the feedback message. Recovered packets are not acked here, but will instead be acked using the recovery base sequence number and the recovery vector. recv delta: A signed receive delta in multiples of 0.1 milliseconds relative to the base receive time, able to represent up to (2^9 - 1) * 0.1 = +/-51.1 milliseconds between packets. A feedback message contains the same number of recv deltas as there are 1s in the sequence number ack vector. recovery base sequence number: The lowest recovered sequence number of this feedback message. It is optional and can be Holmer, et al. Expires September 10, 2015 [Page 5] Internet-Draft trnsprt-wide-cc-exts March 2015 omitted if no sequence numbers were recovered. If it is included the r bit of the second byte should be set. recovery vector: A bit vector where a 1 at position i represents that sequence number recovery base + i + 1 has been recovered and therefore the sender can stop sending it. The length of a feedback message can be derived by counting the number of acked packets and acked feedback packets. Therefore several feedback messages can be stacked to ack more than 17 packets with a single RTCP. 4. Overhead discussion The overhead of this scheme will be higher than what the overhead is for a regular audio/video call over RTP. To get an understanding of this overhead, let's consider the following example: A 2 Mbps, 30 fps, (208 pps) video is sent in one direction and audio only is sent in the other direction. Average packet size of the video stream is 1200 bytes. A feedback message is sent over RTCP sent for every frame received. The average feedback delay will be ~16.7 ms, compared to having logic at the receiver and immediately sending an RTCP when an event is detected. The average protocol overhead is: o 30 packets per second and (5*4 + 3*4) * 30 * 8 = 7680 bits per second. o Transport-wide sequence number overhead: 4 * 8 * 208 = 6656 bps. For extremely asymmetric connections the feedback frequency could be reduced. 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. Holmer, et al. Expires September 10, 2015 [Page 6] Internet-Draft trnsprt-wide-cc-exts March 2015 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, July 2008. 8.2. Informative References [I-D.alvestrand-rmcat-congestion] Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A Google Congestion Control Algorithm for Real-Time Communication", draft-alvestrand-rmcat-congestion-02 (work in progress), February 2014. [I-D.johansson-rmcat-scream-cc] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", draft-johansson-rmcat-scream-cc-05 (work in progress), March 2015. [I-D.zhu-rmcat-nada] Zhu, X., Pan, R., Ramalho, M., Cruz, S., Ganzhorn, C., Jones, P., and S. D'Aronco, "NADA: A Unified Congestion Control Scheme for Real-Time Media", draft-zhu-rmcat- nada-04 (work in progress), September 2014. Appendix A. Change log A.1. First version Authors' Addresses Stefan Holmer Google Kungsbron 2 Stockholm 11122 Sweden Email: holmer@google.com Holmer, et al. Expires September 10, 2015 [Page 7] Internet-Draft trnsprt-wide-cc-exts March 2015 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 September 10, 2015 [Page 8]