idnits 2.17.1 draft-holmer-rmcat-transport-wide-cc-extensions-01.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 (October 19, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Reserved' is mentioned on line 281, but not defined ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-02) exists of draft-ietf-rmcat-gcc-00 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-nada-01 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-scream-cc-01 Summary: 1 error (**), 0 flaws (~~), 6 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: April 21, 2016 Google 6 October 19, 2015 8 RTP Extensions for Transport-wide Congestion Control 9 draft-holmer-rmcat-transport-wide-cc-extensions-01 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 April 21, 2016. 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 3.1.1. Packet Status Symbols . . . . . . . . . . . . . . . . 6 67 3.1.2. Packet Status Chunks . . . . . . . . . . . . . . . . 7 68 3.1.3. Run Length Chunk . . . . . . . . . . . . . . . . . . 7 69 3.1.4. Status Vector Chunk . . . . . . . . . . . . . . . . . 8 70 3.1.5. Receive Delta . . . . . . . . . . . . . . . . . . . . 9 71 4. Overhead discussion . . . . . . . . . . . . . . . . . . . . . 10 72 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11 79 A.1. First version . . . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This document proposes RTP header extension containing a transport- 85 wide packet sequence number and an RTCP feedback message feeding back 86 the arrival times and sequence numbers of the packets received on a 87 connection. 89 Some of the benefits that these extensions bring are: 91 o The congestion control algorithms are easier to maintain and 92 improve as there is less synchronization between sender and 93 receiver versions needed. It should be possible to implement 94 [I-D.ietf-rmcat-gcc], [I-D.ietf-rmcat-nada] and 95 [I-D.ietf-rmcat-scream-cc] with the proposed protocol. 97 o More flexibility in what algorithms are used, as long as they are 98 having most of their logic on the send-side. For instance 99 different behavior can be used depending on if the rate produced 100 is application limited or not. 102 2. Transport-wide Sequence Number 104 2.1. Semantics 106 This RTP header extension is added on the transport layer, and uses 107 the same counter for all packets which are sent over the same 108 connection (for instance as defined by bundle). 110 The benefit with a transport-wide sequence numbers is two-fold: 112 o It is a better fit for congestion control as the congestion 113 controller doesn't operate on media streams, but on packet flows. 115 o It allows for earlier packet loss detection (and recovery) since a 116 loss in stream A can be detected when a packet from stream B is 117 received, thus we don't have to wait until the next packet of 118 stream A is received. 120 2.2. RTP header extension format 122 This document describes a message using the application specific 123 payload type. This is suitable for experimentation; upon 124 standardization, a specific type can be assigned for the purpose. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | 0xBE | 0xDE | length=1 | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | ID | L=1 |transport-wide sequence number | zero padding | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 An RTP header extension with a 16 bits sequence number attached to 135 all packets sent. This sequence number is incremented by 1 for each 136 packet being sent over the same socket. 138 2.3. Signaling of use of this extension 140 When signalled in SDP, the standard mechanism for RTP header 141 extensions [RFC5285] is used: 143 a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide- 144 cc-extensions 146 3. Transport-wide RTCP Feedback Message 148 To allow the most freedom possible to the sender, information about 149 each packet delivered is needed. The simplest way of accomplishing 150 that is to have the receiver send back a message containing an 151 arrival timestamp and a packet identifier for each packet received. 152 This way, the receiver is dumb and simply records arrival timestamps 153 (A) of packets. The sender keeps a map of in-flight packets, and 154 upon feedback arrival it looks up the on-wire timestamp (S) of the 155 corresponding packet. From these two timestamps the sender can 156 compute metrics such as: 158 o Inter-packet delay variation: d(i) = A(i) - S(i) - (A(i-1) - 159 S(i-1)) 161 o Estimated queueing delay: q(i) = A(i) - S(i) - 162 min{j=i-1..i-w}(A(j) - S(j)) 164 Since the sender gets feedback about each packet sent, it will be set 165 to better assess the cost of sending bursts of packets compared to 166 aiming at sending at a constant rate decided by the receiver. 168 Two down-sides with this approach are: 170 o It isn't possible to differentiate between lost feedback on the 171 downlink and lost packets on the uplink. 173 o Increased feedback rate on the reverse direction. 175 From a congestion control perspective, lost feedback messages are 176 handled by ignoring packets which would have been reported as lost or 177 received in the lost feedback messages. This behavior is similar to 178 how a lost RTCP receiver report is handled. 180 It is recommended that a feedback message is sent for every frame 181 received, but in cases of low uplink bandwidth it is acceptable to 182 send them less frequently, e.g., for instance once per RTT, to reduce 183 the overhead. 185 3.1. Message format 187 The message is an RTCP message with payload type 206. RFC 3550 188 [RFC3550] defines the range, RFC 4585 [RFC3550] defines the specific 189 PT value 206 and the FMT value 15. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |V=2|P| FMT=15 | PT=205 | length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | SSRC of packet sender | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | SSRC of media source | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | base sequence number | packet status count | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | reference time | fb pkt. count | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | packet chunk | packet chunk | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 . . 207 . . 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | packet chunk | recv delta | recv delta | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 . . 212 . . 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | recv delta | recv delta | zero padding | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 version (V): 2 bits This field identifies the RTP version. The 218 current version is 2. 220 padding (P): 1 bit If set, the padding bit indicates that the packet 221 contains additional padding octets at the end that are 222 not part of the control information but are included in 223 the length field. 225 feedback message type (FMT): 5 bits This field identifies the type 226 of the FB message. It must have the value 15. 228 payload type (PT): 8 bits This is the RTCP packet type that 229 identifies the packet as being an RTCP FB message. The 230 value must be RTPFB = 205. 232 SSRC of packet sender: 32 bits The synchronization source identifier 233 for the originator of this packet. 235 SSRC of media source: 32 bits The synchronization source identifier 236 of the media source that this piece of feedback 237 information is related to. TODO: This is transport wide, 238 do we just pick any of the media source SSRCs? 240 base sequence number: 16 bits The transport-wide sequence number of 241 the first packet in this feedback. This number is not 242 necessarily increased for every feedback; in the case of 243 reordering it may be decreased. 245 packet status count: 16 bits The number of packets this feedback 246 contains status for, starting with the packet identified 247 by the base sequence number. 249 reference time: 24 bits Signed integer indicating an absolute 250 reference time in some (unknown) time base chosen by the 251 sender of the feedback packets. The value is to be 252 interpreted in multiples of 64ms. The first recv delta 253 in this packet is relative to the reference time. The 254 reference time makes it possible to calculate the delta 255 between feedbacks even if some feedback packets are lost, 256 since it always uses the same time base. 258 feedback packet count: 8 bits A counter incremented by one for each 259 feedback packet sent. Used to detect feedback packet 260 losses. 262 packet chunk: 16 bits A list of packet status chunks. These 263 indicate the status of a number of packets starting with 264 the one identified by base sequence number. See below 265 for details. 267 recv delta: 8 bits For each "packet received" status, in the packet 268 status chunks, a receive delta block will follow. See 269 details below. 271 3.1.1. Packet Status Symbols 273 The status of a packet is described using a 2-bit symbol: 275 00 Packet not received 277 01 Packet received, small delta 279 10 Packet received, large or negative delta 281 11 [Reserved] 283 Packets with status "Packet not received" should not necessarily be 284 interpreted as lost. They might just not have arrived yet. 286 For each packet received with a delta, to the previous received 287 packet, within +/-8191.75ms, a receive delta block is appended to the 288 feedback message. 290 Note: In the case the base sequence number is decreased, creating a 291 window overlapping the previous feedback messages, the status for any 292 packets previously reported as received must be marked as "Packet not 293 received" and thus no delta included for that symbol. 295 3.1.2. Packet Status Chunks 297 Packet status is described in chunks, similar to a Loss RLE Report 298 Block. The are two different kinds of chunks: 300 o Run length chunk 302 o Status vector chunk 304 All chunk types are 16 bits in length. The first bit of the chunk 305 identifies whether it is an RLE chunk or a vector chunk. 307 3.1.3. Run Length Chunk 309 A run length chunk starts with 0 bit, followed by a packet status 310 symbol and the run length of that symbol. 312 0 1 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |T| S | Run Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 chunk type (T): 1 bit A zero identifies this as a run length chunk. 320 packet status symbol (S): 2 bits The symbol repeated in this run. 321 See above. 323 run length (L): 13 bits An unsigned integer denoting the run length. 325 Example 1: 327 0 1 328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |0|0 0|0 0 0 0 0 1 1 0 1 1 1 0 1| 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 This is a run of the "packet not received" status of length 221. 335 Example 2: 337 0 1 338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |0|1 1|0 0 0 0 0 0 0 0 1 1 0 0 0| 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 This is a run of the "packet received, w/o recv delta" status of 344 length 24. 346 3.1.4. Status Vector Chunk 348 A status vector chunk starts with a 1 bit to identify it as a vector 349 chunk, followed by a symbol size bit and then 7 or 14 symbols, 350 depending on the size bit. 352 0 1 353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |T|S| symbol list | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 chunk type (T): 1 bit A one identifies this as a status vector 359 chunk. 361 symbol size (S): 1 bit A zero means this vector contains only 362 "packet received" (0) and "packet not received" (1) 363 symbols. This means we can compress each symbol to just 364 one bit, 14 in total. A one means this vector contains 365 the normal 2-bit symbols, 7 in total. 367 symbol list: 14 bits A list of packet status symbols, 7 or 14 in 368 total. 370 Example 1: 372 0 1 373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |1|0|0 1 1 1 1 1 0 0 0 1 1 1 0 0| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 This chunk contains, in order: 380 1x "packet not received" 382 5x "packet received" 383 3x "packet not received" 385 3x "packet received" 387 2x "packet not received" 389 Example 2: 391 0 1 392 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |1|1|0 0 1 1 0 1 0 1 0 1 0 0 0 0| 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 This chunk contains, in order: 399 1x "packet not received" 401 1x "packet received, w/o timestamp" 403 3x "packet received" 405 2x "packet not received" 407 3.1.5. Receive Delta 409 Deltas are represented as multiples of 250us: 411 o If the "Packet received, small delta" symbol has been appended to 412 the status list, an 8-bit unsigned receive delta will be appended 413 to recv delta list, representing a delta in the range [0, 63.75] 414 ms. 416 o If the "Packet received, large or negative delta" symbol has been 417 appended to the status list, a 16-bit signed receive delta will be 418 appended to recv delta list, representing a delta in the range 419 [-8192.0, 8191.75] ms. 421 o If the delta exceeds even the larger limits, a new feedback 422 message must be used, where the 24-bit base receive delta can 423 cover very large gaps. 425 Note that the first receive delta is relative to the reference time 426 indicated by the base receive delta. 428 TODO: Add examples. 430 The smaller receive delta upper bound of 63.75 ms means that this is 431 only viable at about 1000/25.5 ~= 16 packets per second and above. 432 With a packet size of 1200 bytes/packet that amounts to a bitrate of 433 about 150 kbit/s. 435 The 0.25 ms resolution means that up to 4000 packets per second can 436 be represented. With a 1200 bytes/packet payload, that amounts to 437 38.4 Mbit/s payload bandwidth. 439 4. Overhead discussion 441 TODO: Examples of overhead in various scenarios. 443 5. IANA considerations 445 Upon publication of this document as an RFC (if it is decided to 446 publish it), IANA is requested to register the string "goog-remb" in 447 its registry of "rtcp-fb" values in the SDP attribute registry group. 449 6. Security Considerations 451 If the RTCP packet is not protected, it is possible to inject fake 452 RTCP packets that can increase or decrease bandwidth. This is not 453 different from security considerations for any other RTCP message. 455 7. Acknowledgements 457 8. References 459 8.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 465 Jacobson, "RTP: A Transport Protocol for Real-Time 466 Applications", STD 64, RFC 3550, July 2003. 468 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 469 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 470 2008, . 472 8.2. Informative References 474 [I-D.ietf-rmcat-gcc] 475 Holmer, S., Marcon, J., Carlucci, G., Cicco, L., and S. 476 Mascolo, "A Google Congestion Control Algorithm for Real- 477 Time Communication", draft-ietf-rmcat-gcc-00 (work in 478 progress), September 2015. 480 [I-D.ietf-rmcat-nada] 481 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, 482 J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified 483 Congestion Control Scheme for Real-Time Media", draft- 484 ietf-rmcat-nada-01 (work in progress), October 2015. 486 [I-D.ietf-rmcat-scream-cc] 487 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 488 for Multimedia", draft-ietf-rmcat-scream-cc-01 (work in 489 progress), July 2015. 491 Appendix A. Change log 493 A.1. First version 495 Authors' Addresses 497 Stefan Holmer 498 Google 499 Kungsbron 2 500 Stockholm 11122 501 Sweden 503 Email: holmer@google.com 505 Magnus Flodman 506 Google 507 Kungsbron 2 508 Stockholm 11122 509 Sweden 511 Email: mflodman@google.com 513 Erik Sprang 514 Google 515 Kungsbron 2 516 Stockholm 11122 517 Sweden 519 Email: sprang@google.com