idnits 2.17.1 draft-holmer-rmcat-transport-wide-cc-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-03) exists of draft-alvestrand-rmcat-congestion-02 == Outdated reference: A later version (-06) exists of draft-zhu-rmcat-nada-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Holmer 3 Internet-Draft M. Flodman 4 Intended status: Experimental E. Sprang 5 Expires: September 10, 2015 Google 6 March 9, 2015 8 RTP Extensions for Transport-wide Congestion Control 9 draft-holmer-rmcat-transport-wide-cc-extensions-00 11 Abstract 13 This document proposes an RTP header extension and an RTCP message 14 for use in congestion control algorithms for RTP-based media flows. 15 It adds transport-wide packet sequence numbers and corresponding 16 feedback message so that congestion control can be performed on a 17 transport level at the send-side, while keeping the receiver dumb. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 10, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Transport-wide Sequence Number . . . . . . . . . . . . . . . 3 61 2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. RTP header extension format . . . . . . . . . . . . . . . 3 63 2.3. Signaling of use of this extension . . . . . . . . . . . 3 64 3. Transport-wide RTCP Feedback Message . . . . . . . . . . . . 4 65 3.1. Message format . . . . . . . . . . . . . . . . . . . . . 4 66 4. Overhead discussion . . . . . . . . . . . . . . . . . . . . . 6 67 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 7 74 A.1. First version . . . . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 This document proposes RTP header extension containing a transport- 80 wide packet sequence number and an RTCP feedback message feeding back 81 the arrival times and sequence numbers of the packets received on a 82 connection. 84 Some of the benefits that these extensions bring are: 86 o The congestion control algorithms are easier to maintain and 87 improve as there is less synchronization between sender and 88 receiver versions needed. It should be possible to implement 89 [I-D.alvestrand-rmcat-congestion], [I-D.zhu-rmcat-nada] and 90 [I-D.johansson-rmcat-scream-cc] with the proposed protocol. 92 o More flexibility in what algorithms are used, as long as they are 93 having most of their logic on the send-side. For instance 94 different behavior can be used depending on if the rate produced 95 is application limited or not. 97 2. Transport-wide Sequence Number 99 2.1. Semantics 101 This RTP header extension is added on the transport layer, and uses 102 the same counter for all packets which are sent over the same 103 connection (for instance as defined by bundle). 105 The benefit with a transport-wide sequence numbers is two-fold: 107 o It is a better fit for congestion control as the congestion 108 controller doesn't operate on media streams, but on packet flows. 110 o It allows for earlier packet loss detection (and recovery) since a 111 loss in stream A can be detected when a packet from stream B is 112 received, thus we don't have to wait until the next packet of 113 stream A is received. 115 2.2. RTP header extension format 117 This document describes a message using the application specific 118 payload type. This is suitable for experimentation; upon 119 standardization, a specific type can be assigned for the purpose. 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | 0xBE | 0xDE | length=1 | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | ID | L=1 |transport-wide sequence number | zero padding | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 An RTP header extension with a 16 bits sequence number attached to 130 all packets sent. This sequence number is incremented by 1 for each 131 packet being sent over the same socket. 133 2.3. Signaling of use of this extension 135 When signalled in SDP, the standard mechanism for RTP header 136 extensions [RFC5285] is used: 138 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/transport- 139 sequence-number 141 3. Transport-wide RTCP Feedback Message 143 To allow the most freedom possible to the sender, information about 144 each packet delivered is needed. The simplest way of accomplishing 145 that is to have the receiver send back a message containing an 146 arrival timestamp and a packet identifier for each packet received. 147 This way, the receiver is dumb and simply records arrival timestamps 148 (A) of packets. The sender keeps a map of in-flight packets, and 149 upon feedback arrival it looks up the on-wire timestamp (S) of the 150 corresponding packet. From these two timestamps the sender can 151 compute metrics such as: 153 o Link propagation time delta: d(i) = A(i) - S(i) - (A(i-1) - 154 S(i-1)) 156 o Estimated queueing delay: q(i) = A(i) - S(i) - 157 min{j=i-1..i-w}(A(j) - S(j)) 159 Since the sender gets feedback about each packet sent, it will be set 160 to better assess the cost of sending bursts of packets compared to 161 aiming at sending at a constant rate decided by the receiver. 163 Two down-sides with this approach are: 165 o It isn't possible to differentiate between lost feedback on the 166 downlink and lost packets on the uplink. 168 o Increased feedback rate on the reverse direction. 170 Lost feedback messages shouldn't be a big problem as we could simply 171 ignore losses which coincide with lost feedback messages from a 172 congestion control perspective. 174 It is recommended that a feedback message is sent for every frame 175 received, but in cases of low uplink bandwidth it is acceptable to 176 send them less frequently, e.g., for instance once per RTT. 178 3.1. Message format 180 The message is an RTCP message with payload type 206. RFC 3550 181 [RFC3550] defines the range, RFC 4585 [RFC3550] defines the specific 182 PT value 206 and the FMT value 15. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | fb seq num |r| base sequence number | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | base receive time | sequence number ack vector | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | recv delta | recv delta | recv delta |...| 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 . . 194 . . 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | recovery base sequence number | recovery vector | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 fb sequence number: Incremented by one for each feedback message 200 sent. This can be used to figure out if feedback 201 messages have been lost, so that the sender can avoid 202 interpreting lost feedback messages on the downlink as 203 lost media packets on the uplink. 205 r: Set if the recovery base sequence number and recovery 206 vector are included. 208 base transport sequence number: The lowest received (not recovered) 209 sequence number of this feedback message. 211 base receive time: Receive time of the base packet in multiples of 212 0.1 milliseconds, able to represent up to (2^16 - 1) * 213 0.1 = 6553.5 milliseconds. This allows probing of up to 214 96 Mbps with 1200 bytes packets. 216 sequence number ack vector: A bit vector where a 1 at position i 217 represents that base sequence number + i + 1 has been 218 received, and that a recv delta will be included in the 219 feedback message. Recovered packets are not acked here, 220 but will instead be acked using the recovery base 221 sequence number and the recovery vector. 223 recv delta: A signed receive delta in multiples of 0.1 milliseconds 224 relative to the base receive time, able to represent up 225 to (2^9 - 1) * 0.1 = +/-51.1 milliseconds between 226 packets. A feedback message contains the same number of 227 recv deltas as there are 1s in the sequence number ack 228 vector. 230 recovery base sequence number: The lowest recovered sequence number 231 of this feedback message. It is optional and can be 232 omitted if no sequence numbers were recovered. If it is 233 included the r bit of the second byte should be set. 235 recovery vector: A bit vector where a 1 at position i represents 236 that sequence number recovery base + i + 1 has been 237 recovered and therefore the sender can stop sending it. 239 The length of a feedback message can be derived by counting the 240 number of acked packets and acked feedback packets. Therefore 241 several feedback messages can be stacked to ack more than 17 packets 242 with a single RTCP. 244 4. Overhead discussion 246 The overhead of this scheme will be higher than what the overhead is 247 for a regular audio/video call over RTP. To get an understanding of 248 this overhead, let's consider the following example: 250 A 2 Mbps, 30 fps, (208 pps) video is sent in one direction and audio 251 only is sent in the other direction. Average packet size of the 252 video stream is 1200 bytes. A feedback message is sent over RTCP 253 sent for every frame received. 255 The average feedback delay will be ~16.7 ms, compared to having logic 256 at the receiver and immediately sending an RTCP when an event is 257 detected. 259 The average protocol overhead is: 261 o 30 packets per second and (5*4 + 3*4) * 30 * 8 = 7680 bits per 262 second. 264 o Transport-wide sequence number overhead: 4 * 8 * 208 = 6656 bps. 266 For extremely asymmetric connections the feedback frequency could be 267 reduced. 269 5. IANA considerations 271 Upon publication of this document as an RFC (if it is decided to 272 publish it), IANA is requested to register the string "goog-remb" in 273 its registry of "rtcp-fb" values in the SDP attribute registry group. 275 6. Security Considerations 277 If the RTCP packet is not protected, it is possible to inject fake 278 RTCP packets that can increase or decrease bandwidth. This is not 279 different from security considerations for any other RTCP message. 281 7. Acknowledgements 283 8. References 285 8.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 291 Jacobson, "RTP: A Transport Protocol for Real-Time 292 Applications", STD 64, RFC 3550, July 2003. 294 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 295 Header Extensions", RFC 5285, July 2008. 297 8.2. Informative References 299 [I-D.alvestrand-rmcat-congestion] 300 Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A 301 Google Congestion Control Algorithm for Real-Time 302 Communication", draft-alvestrand-rmcat-congestion-02 (work 303 in progress), February 2014. 305 [I-D.johansson-rmcat-scream-cc] 306 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 307 for Multimedia", draft-johansson-rmcat-scream-cc-05 (work 308 in progress), March 2015. 310 [I-D.zhu-rmcat-nada] 311 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Ganzhorn, C., 312 Jones, P., and S. D'Aronco, "NADA: A Unified Congestion 313 Control Scheme for Real-Time Media", draft-zhu-rmcat- 314 nada-04 (work in progress), September 2014. 316 Appendix A. Change log 318 A.1. First version 320 Authors' Addresses 322 Stefan Holmer 323 Google 324 Kungsbron 2 325 Stockholm 11122 326 Sweden 328 Email: holmer@google.com 329 Magnus Flodman 330 Google 331 Kungsbron 2 332 Stockholm 11122 333 Sweden 335 Email: mflodman@google.com 337 Erik Sprang 338 Google 339 Kungsbron 2 340 Stockholm 11122 341 Sweden 343 Email: sprang@google.com