idnits 2.17.1 draft-alvestrand-rtcweb-congestion-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2011) is 4563 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 751 -- Looks like a reference, but probably isn't: '3' on line 775 ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-01) exists of draft-gharai-avtcore-rtp-tfrc-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Lundin 3 Internet-Draft S. Holmer 4 Intended status: Informational H. Alvestrand, Ed. 5 Expires: May 1, 2012 Google 6 October 29, 2011 8 A Google Congestion Control Algorithm for Real-Time Communication on the 9 World Wide Web 10 draft-alvestrand-rtcweb-congestion-01 12 Abstract 14 This document describes two methods of congestion control when using 15 real-time communications on the World Wide Web (RTCWEB); one sender- 16 based and one receiver-based. 18 It is published to aid the discussion on mandatory-to-implement flow 19 control for RTCWEB applications; initial discussion is expected in 20 the RTCWEB WG's mailing list. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 1, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Mathemathical notation conventions . . . . . . . . . . . . 3 64 2. System model . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Receiver side control . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Arrival-time model . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Arrival-time filter . . . . . . . . . . . . . . . . . . . 6 68 3.3. Over-use detector . . . . . . . . . . . . . . . . . . . . 8 69 3.4. Rate control . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Sender side control . . . . . . . . . . . . . . . . . . . . . 10 71 5. Interoperability Considerations . . . . . . . . . . . . . . . 12 72 6. Implementation Experience . . . . . . . . . . . . . . . . . . 12 73 7. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Appendix A. New proposed functionality . . . . . . . . . . . . . 15 81 A.1. Send timestamp . . . . . . . . . . . . . . . . . . . . . . 15 82 A.2. Receiver Estimated Max Bitrate (REMB) . . . . . . . . . . 16 83 A.2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 84 A.2.2. Message format . . . . . . . . . . . . . . . . . . . . 16 85 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 18 86 B.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Congestion control is a requirement for all applications that wish to 92 share the Internet [RFC2914]. 94 The problem of doing congestion control for real-time media is made 95 difficult for a number of reasons: 97 o The media is usually encoded in forms that cannot be quickly 98 changed to accomodate varying bandwidth, and bandwidth 99 requirements can often be changed only in discrete, rather large 100 steps 102 o The participants may have certain specific wishes on how to 103 respond - which may not be reducing the bandwidth required by the 104 flow on which congestion is discovered 106 o The encodings are usually sensitive to packet loss, while the real 107 time requirement precludes the repair of packet loss by 108 retransmission 110 This memo describes two congestion control algorithms that together 111 are seen to give reasonable performance and reasonable (not perfect) 112 bandwidth sharing with other conferences and with TCP-using 113 applications that share the same links. 115 The signalling used consists of standard RTP timestamps [RFC3550], 116 standard RTCP feedback reports and Temporary Maximum Media Stream Bit 117 Rate Requests (TMMBR) as defined in [RFC5104] section 3.5.4. 119 1.1. Mathemathical notation conventions 121 The mathematics of this document have been transcribed from a more 122 formula-friendly format. 124 The following notational conventions are used: 126 X_bar The variable X, where X is a vector - conventionally marked by 127 a bar on top of the variable name. 129 X_hat An estimate of the true value of variable X - conventionally 130 marked by a circumflex accent on top of the variable name. 132 X(i) The "i"th value of X - conventionally marked by a subscript i. 134 [x y z] A row vector consisting of elements x, y and z. 136 X_bar^T The transpose of vector X_bar. 138 E{X} The expected value of the stochastic variable X 140 2. System model 142 The following elements are in the system: 144 o Incoming media stream 146 o Media codec - has a bandwidth control, and encodes the incoming 147 media stream into an RTP stream. 149 o RTP sender - sends the RTP stream over the network to the RTP 150 receiver. Generates the RTP timestamp. 152 o RTP receiver - receives the RTP stream, notes the time of arrival. 153 Regenerates the media stream for the recipient. 155 o RTCP sender at RTP sender - sends sender reports. 157 o RTCP sender at RTP receiver - sends receiver reports and TMMBR 158 messages. 160 o RTCP receiver at RTP sender - receives receiver reports and TMMBR 161 messages, reports these to sender side control. 163 o RTCP receiver at RTP receiver. 165 o Sender side control - takes loss rate info, round trip time info, 166 and TMMBR messages and computes a sending bitrate. 168 o Receiver side control - takes the packet arrival info at the RTP 169 receiver and decides when to send TMMBR messages. 171 Together, sender side control and receiver side control implement the 172 congestion control algorithm. 174 3. Receiver side control 176 The receive-side algorithm can be further decomposed into three 177 parts: an arrival-time filter, an over-use detector, and a remote 178 rate-control. 180 3.1. Arrival-time model 182 This section describes an adaptive filter that continuously updates 183 estimates of network parameters based on the timing of the received 184 frames. 186 At the receiving side we are observing groups of incoming video 187 packets, where each group of packets corresponding to the same frame 188 having timestamp T(i). 190 Each frame is assigned a receive time t(i), which corresponds to the 191 time at which the whole frame has been received (ignoring any packet 192 losses). A frame is delayed relative to its predecessor if t(i)-t(i- 193 1)>T(i)-T(i-1), i.e., if the arrival time difference is larger than 194 the timestamp difference. 196 We define the (relative) inter-arrival time, d(i) as 198 d(i) = t(i)-t(i-1)-(T(i)-T(i-1)) 200 Since the time ts to send a frame of size L over a path with a 201 capacity of C is 203 ts = L/C 205 we can model the inter-arrival time as 207 L(i)-L(i-1) 208 d(i) = -------------- + w(i) = dL(i)/C+w(i) 209 C 211 Here, w(i) is a sample from a stochastic process W, which is a 212 function of the capacity C, the current cross traffic X(i), and the 213 current send bit rate R(i). We model W as a white Gaussian process. 214 If we are over-using the channel we expect w(i) to increase, and if a 215 queue on the network path is being emptied, w(i) will decrease; 216 otherwise the mean of w(i) will be zero. 218 Breaking out the mean of w(i) to make the process zero mean, we get 220 Equation 5 222 d(i) = dL(i)/C + m(i) + v(i) 224 This is our fundamental model, where we take into account that a 225 large frame needs more time to traverse the link than a small frame, 226 thus arriving with higher relative delay. The noise term represents 227 network jitter and other delay effects not captured by the model. 229 When graphing the values for d(i) versus dL(i) on a scatterplot, we 230 find that most samples cluster around the center, and the outliers 231 are clustered along a line with average slope 1/C and zero offset. 233 When using a regular video codec, most frames are roughly the same 234 size after encoding (the central "cloud"); the exceptions are 235 I-frames (or key frames) which are typically much larger than the 236 average causing positive outliers (the I-frame itself) and negative 237 outliers (the frame after an I-frame) on the dL axis. 239 3.2. Arrival-time filter 241 The parameters d(i) and dL(i) are readily available for each frame i, 242 and we want to estimate C and m(i) and use those estimates to detect 243 whether or not we are over-using the bandwidth currently available. 244 These parameters are easily estimated by any adaptive filter - we are 245 using the Kalman filter. 247 Let 249 theta_bar(i) = [1/C(i) m(i)]^T 251 and call it the state of time i. We model the state evolution from 252 time i to time i+1 as 254 theta_bar(i+1) = theta_bar(i) + u_bar(i) 256 where u_bar(i) is the zero mean white Gaussian process noise with 257 covariance 259 Equation 7 261 Q(i) = E{u_bar(i) u_bar(i)^T} 263 Given equation 5 we get 265 Equation 8 267 d(i) = h_bar(i)^T theta_bar(i) + v(i) 269 h_bar(i) = [dL(i) 1]^T 271 where v(i) is zero mean white Gaussian measurement noise with 272 variance var_v = sigma(v,i)^2 274 The Kalman filter recursively updates our estimate 276 theta_hat(i) = [1/C_hat(i) m_hat(i)]^T 278 as 280 z(i) = d(i) - h_bar(i)^T * theta_hat(i-1) 282 theta_hat(i) = theta_hat(i-1) + z(i) * k_bar(i) 284 E(i-1) * h_bar(i) 285 k_bar(i) = -------------------------------------------- 286 var_v_hat + h_bar(i)^T * E(i-1) * h_bar(i) 288 E(i) = (I - K_bar(i) * h_bar(i)^T) * E(i-1) + Q(i) 290 I is the 2-by-2 identity matrix. 292 The variance var_v = sigma(v,i)^2 is estimated using an exponential 293 averaging filter, modified for variable sampling rate 295 var_v_hat = beta*sigma(v,i-1)^2 + (1-beta)*z(i)^2 297 beta = (1-alpha)^(30/(1000 * f_max)) 299 where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1...i is the 300 highest rate at which frames have been captured by the camera the 301 last K frames and alpha is a filter coefficient typically chosen as a 302 number in the interval [0.1, 0.001]. Since our assumption that v(i) 303 should be zero mean WGN is less accurate in some cases, we have 304 introduced an additional outlier filter around the updates of 305 var_v_hat. If z(i) > 3 var_v_hat the filter is updated with 3 306 sqrt(var_v_hat) rather than z(i). In a similar way, Q(i) is chosen 307 as a diagonal matrix with main diagonal elements given by 309 diag(Q(i)) = 30/(1000 * f_max)[10^-10 10^-2]^T 311 It is necessary to scale these filter parameters with the frame rate 312 to make the detector respond as quickly at low frame rates as at high 313 frame rates. 315 3.3. Over-use detector 317 The offset estimate m(i) is compared with a threshold gamma_1. An 318 estimate above the threshold is considered as an indication of over- 319 use. Such an indication is not enough for the detector to signal 320 over-use to the rate control subsystem. Not until over-use has been 321 detected for at least gamma_2 milliseconds and at least gamma_3 322 frames, a definitive over-use will be signaled. However, if the 323 offset estimate m(i) was decreased in the last update, over-use will 324 not be signaled even if all the above conditions are met. Similarly, 325 the opposite state, under-use, is detected when m(i) < -gamma_1. If 326 neither over-use nor under-use is detected, the detector will be in 327 the normal state. 329 3.4. Rate control 331 The rate control at the receiving side is designed to increase the 332 available bandwidth estimate A_hat as long as the detected state is 333 normal. Doing that assures that we, sooner or later, will reach the 334 available bandwidth of the channel and detect an over-use. 336 As soon as over-use has been detected the available bandwidth 337 estimate is decreased. In this way we get a recursive and adaptive 338 estimate of the available bandwidth. 340 In this document we make the assumption that the rate control 341 subsystem is executed periodically and that this period is constant. 343 The rate control subsystem has 3 states: Increase, Decrease and Hold. 344 "Increase" is the state when no congestion is detected; "Decrease" is 345 the state where congestion is detected, and "Hold" is a state that 346 waits until built-up queues have drained before going to "increase" 347 state. 349 The state transitions (with blank fields meaning "remain in state") 350 are: 352 State ----> | Hold |Increase |Decrease 353 Signal----------------------------------------- 354 v | | | 355 Over-use | Decrease |Decrease | 356 ----------------------------------------------- 357 Normal | Increase | |Hold 358 ----------------------------------------------- 359 Under-use | |Hold |Hold 360 ----------------------------------------------- 361 The subsystem starts in the increase state, where it will stay until 362 over-use or under-use has been detected by the detector subsystem. 363 On every update the available bandwidth is increased with a factor 364 which is a function of the global system response time and the 365 estimated measurement noise variance var_v_hat. The global system 366 response time is the time from an increase that causes over-use until 367 that over-use can be detected by the over-use detector. The variance 368 var_v_hat affects how responsive the Kalman filter is, and is thus 369 used as an indicator of the delay inflicted by the Kalman filter. 371 A_hat(i) = eta*A_hat(i-1) 372 1.001+B 373 eta(RTT, var_v_hat) = ------------------------------------------ 374 1+e^(b(d*RTT - (c1 * var_v_hat + c2))) 376 Here, B, b, d, c1 and c2 are design parameters. 378 Since the system depends on over-using the channel to verify the 379 current available bandwidth estimate, we must make sure that our 380 estimate doesn't diverge from the rate at which the sender is 381 actually sending. Thus, if the sender is unable to produce a bit 382 stream with the bit rate the receiver is asking for, the available 383 bandwidth estimate must stay within a given bound. Therefore we 384 introduce a threshold 386 A_hat(i) < 1.5 * R_hat(i) 388 where R_hat(i) is the incoming bit rate measured over a T seconds 389 window: 391 R_hat(i) = 1/T * sum(L(j)) for j from 1 to N(i) 393 N(i) is the number of frames received the past T seconds and L(j) is 394 the payload size of frame j. 396 When an over-use is detected the system transitions to the decrease 397 state, where the available bandwidth estimate is decreased to a 398 factor times the currently incoming bit rate. 400 A_hat(i) = alpha*R_hat(i) 402 alpha is typically chosen to be in the interval [0.8, 0.95]. 404 When the detector signals under-use to the rate control subsystem, we 405 know that queues in the network path are being emptied, indicating 406 that our available bandwidth estimate is lower than the actual 407 available bandwidth. Upon that signal the rate control subsystem 408 will enter the hold state, where the available bandwidth estimate 409 will be held constant while waiting for the queues to stabilize at a 410 lower level - a way of keeping the delay as low as possible. This 411 decrease of delay is wanted, and expected, immediately after the 412 estimate has been reduced due to over-use, but can also happen if the 413 cross traffic over some links is reduced. In either case we want to 414 measure the highest incoming rate during the under-use interval: 416 R_max = max{R_hat(i)} for i in 1..K 418 where K is the number of frames of under-use before returning to the 419 normal state. R_max is a measure of the actual bandwidth available 420 and is a good guess of what bit rate the sender should be able to 421 transmit at. Therefore the available bandwidth will be set to Rmax 422 when we transition from the hold state to the increase state. 424 One design decision is when to send rate control messages. The time 425 from a change in congestion to the sending of the feedback message is 426 a limitation on how fast the sender can react. Sending too many 427 messages giving no new information is a waste of bandwidth - but in 428 the case of severe congestion, feedback messages can be lost, 429 resulting in a failure to react in a timely manner. 431 The conclusion is that feedback messages should be sent on a 432 "heartbeat" schedule, allowing the sender side control to react to 433 missing feedback messages by reducing its send rate, but they should 434 also be sent whenever the estimated bandwidth value has changed 435 significantly, without waiting for the heartbeat time, up to some 436 limiting upper bound on the send rate. 438 The minimum interval is named t_min_fb_interval. 440 The maximum interval is named t_max_fb_interval. 442 The permissible values of these intervals will be bounded by the RTP 443 session's RTCP bandwidht and its rtcp_frr setting. 445 [TODO: Get some example values for these timers] 447 4. Sender side control 449 An additional congestion controller resides at the sending side. It 450 bases its decisions on the round-trip time, packet loss and available 451 bandwidth estimates transmitted from the receiving side. 453 The available bandwidth estimates produced by the receiving side are 454 only reliable when the size of the queues along the channel are large 455 enough. If the queues are very short, over-use will only be visible 456 through packet losses, which aren't used by the receiving side 457 algorithm. 459 This algorithm is run every time a receive report arrives at the 460 sender, which will happen no more often than t_min_fb_interval, and 461 no less often than t_max_fb_interval. If no receive report is 462 recieved within 2x t_max_fb_interval (indicating at least 2 lost 463 feedback reports), the algorithm will take action as if all packets 464 in the interval have been lost, resulting in a halving of the send 465 rate. 467 o If 2-10% of the packets have been lost since the previous report 468 from the receiver, the sender available bandwidth estimate As(i) 469 (As denotes 'sender available bandwidth') will be kept unchanged. 471 o If more than 10% of the packets have been lost a new estimate is 472 calculated as As(i)=As(i-1)(1-0.5p), where p is the loss ratio. 474 o As long as less than 2% of the packets have been lost As(i) will 475 be increased as As(i)=1.05(As(i-1)+1000) 477 The new send-side estimate is limited by the TCP Friendly Rate 478 Control formula [RFC3448] and the receive-side estimate of the 479 available bandwidth A(i): 480 8 s 481 As(i) >= ---------------------------------------------------------- 482 R*sqrt(2*b*p/3) + (t_RTO*(3*sqrt(3*b*p/8) * p * (1+32*p^2))) 484 As(i) <= A(i) 486 where b is the number of packets acknowledged by a single TCP 487 acknowledgement (set to 1 per TFRC recommendations), t_RTO is the TCP 488 retransmission timeout value in seconds (set to 4*R) and s is the 489 average packet size in bytes. R is the round-trip time in seconds. 491 (The multiplication by 8 comes because TFRC is computing bandwidth in 492 bytes, while this document computes bandwidth in bits.) 494 In words: The sender-side estimate will never be larger than the 495 receiver-side estimate, and will never be lower than the estimate 496 from the TFRC formula. 498 We motivate the packet loss thresholds by noting that if the 499 transmission channel has a small amount of packet loss due to over- 500 use, that amount will soon increase if the sender does not adjust his 501 bit rate. Therefore we will soon enough reach above the 10 % 502 threshold and adjust As(i). However if the packet loss rate does not 503 increase, the losses are probably not related to self-induced channel 504 over-use and therefore we should not react on them. 506 5. Interoperability Considerations 508 There are three scenarios of interest, and one included for reference 510 o Both parties implement the algorithms described here 512 o Sender implements the algorithm described in section Section 4, 513 recipient does not implement Section 3 515 o Recipient implements the algorithm in section Section 3, sender 516 does not implement Section 4. 518 In the case where both parties implement the algorithms, we expect to 519 see most of the congestion control response to slowly varying 520 conditions happen by TMMBR messages from recipient to sender. At 521 most times, the sender will send less than the congestion-inducing 522 bandwidth limit C, and when he sends more, congestion will be 523 detected before packets are lost. 525 If sudden changes happen, packets will be lost, and the sender side 526 control will trigger, limiting traffic until the congestion becomes 527 low enough that the system switches back to the receiver-controlled 528 state. 530 In the case where sender only implements, we expect to see somewhat 531 higher loss rates and delays, but the system will still be overall 532 TCP friendly and self-adjusting; the governing term in the 533 calculation will be the TFRC formula. 535 In the case where recipient implements this algorithm and sender does 536 not, congestion will be avoided for slow changes as long as the 537 sender understands and obeys TMMBR; there will be no backoff for 538 packet-loss-inducing changes in capacity. Given that some kind of 539 congestion control is mandatory for the sender according to the TMMBR 540 spec, this case has to be reevaluated against the specific congestion 541 control implemented by the sender. 543 6. Implementation Experience 545 This algorithm has been implemented in the open-source WebRTC 546 project. 548 7. Further Work 550 This draft is offered as input to the congestion control discussion. 552 Work that can be done on this basis includes: 554 o Consideration of timing info: It may be sensible to use the 555 proposed TFRC RTP header extensions [I-D.gharai-avtcore-rtp-tfrc] 556 to carry per-packet timing information, which would both give more 557 data points and a timestamp applied closer to the network 558 interface. One adaptation of this proposal is given in Appendix 559 A.1. 561 o Considerations of cross-channel calculation: If all packets in 562 multiple streams follow the same path over the network, congestion 563 or queueing information should be considered across all packets 564 between two parties, not just per media stream. A feedback 565 message that may be suitable for such a purpose is given in 566 Appendix A.2. 568 o Considerations of cross-channel balancing: The decision to slow 569 down sending in a situation with multiple media streams should be 570 taken across all media streams, not per stream. 572 o Considerations of additional input: How and where packet loss 573 detected at the recipient can be added to the algorithm. 575 o Considerations of locus of control: Whether the sender or the 576 recipient is in the best position to figure out which media 577 streams it makes sense to slow down, and therefore whether one 578 should use TMMBR to slow down one channel, signal an overall 579 bandwidth change and let the sender make the decision, or signal 580 the (possibly processed) delay info and let the sender run the 581 algorithm. 583 o Considerations of over-bandwidth estimation: Whether we can use 584 the estimate of how much we're over bandwidth in section 3 to 585 influence how much we reduce the bandwidth, rather than using a 586 fixed factor. 588 o Startup considerations. It's unreasonable to assume that just 589 starting at full rate is always the best strategy. 591 o Dealing with sender traffic shaping, which delays sending of 592 packets. Using send-time timestamps rather than RTP timestamps 593 may be useful here, but as long as the sender's traffic shaping 594 does not spread out packets more than the bottleneck link, it 595 should not matter. 597 o Stability considerations. It is not clear how to show that the 598 algoritm cannot provide an oscillating state, either alone or when 599 competing with other algorithms / flows. 601 These are matters for further work; since some of them involve 602 extensions that have not yet been standardized, this could take some 603 time. 605 8. IANA Considerations 607 This document makes no request of IANA. 609 Note to RFC Editor: this section may be removed on publication as an 610 RFC. 612 9. Security Considerations 614 An attacker with the ability to insert or remove messages on the 615 connection will, of course, have the ability to mess up rate control, 616 causing people to send either too fast or too slow, and causing 617 congestion. 619 In this case, the control information is carried inside RTP, and can 620 be protected against modification or message insertion using SRTP, 621 just as for the media. Given that timestamps are carried in the RTP 622 header, which is not encrypted, this is not protected against 623 disclosure, but it seems hard to mount an attack based on timing 624 information only. 626 10. Acknowledgements 628 Thanks to Randell Jesup, Magnus Westerlund, Varun Singh, Tim Panton, 629 Soo-Hyun Choo, Jim Gettys, Ingemar Johansson and others for providing 630 valuable feedback on earlier versions of this draft. 632 11. References 634 11.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 640 Friendly Rate Control (TFRC): Protocol Specification", 641 RFC 3448, January 2003. 643 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 644 Jacobson, "RTP: A Transport Protocol for Real-Time 645 Applications", STD 64, RFC 3550, July 2003. 647 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 648 "Extended RTP Profile for Real-time Transport Control 649 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 650 July 2006. 652 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 653 "Codec Control Messages in the RTP Audio-Visual Profile 654 with Feedback (AVPF)", RFC 5104, February 2008. 656 11.2. Informative References 658 [I-D.gharai-avtcore-rtp-tfrc] 659 Gharai, L. and C. Perkins, "RTP with TCP Friendly Rate 660 Control", draft-gharai-avtcore-rtp-tfrc-00 (work in 661 progress), March 2011. 663 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 664 RFC 2914, September 2000. 666 Appendix A. New proposed functionality 668 This section proposes two new functionalities: An RTP header 669 extension for signalling the time of packet emission, and an RTCP 670 feedback message signalling the requested total bandwidth for a 671 section. 673 If these two functions are available, it is possible to implement the 674 algorithm in this document, or other algorithms that take the same 675 input, in a fashion that is likely to be more precise than the one 676 that depends on RTP timestamps, and can cover multiple flows instead 677 of just one. 679 This section is intended to be pulled out in a later separate 680 Internet-Draft and be proposed for standardization. 682 A.1. Send timestamp 684 The send timestamp serves to record the last time at which the packet 685 was available for modification to the RTP sender - that is, as close 686 as possible to the time at which the packet was actually queued for 687 sending on the wire. 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | 0xBE | 0xBE | length=1 | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | ID | len=2 | send timestamp (t_i) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 Send timestamp (t_i) 24 bits The timestamp indicating when the 698 packet is sent. This timestamp is measured in microseconds and is 699 used for bandwidth estimation. 701 The absolute value of the send timestamp does not matter. The value 702 MUST be consistent between packets sent from the same sender. 704 A.2. Receiver Estimated Max Bitrate (REMB) 706 A.2.1. Semantics 708 This feedback message is used to notify a sender of multiple media 709 streams over the same RTP session of the total estimated available 710 bit rate on the path to the receiving side of this RTP session. 712 Within the common packet header for feedback messages (as defined in 713 section 6.1 of [RFC4585]), the "SSRC of packet sender" field 714 indicates the source of the notification. The "SSRC of media source" 715 is not used and SHALL be set to 0. RFC 5104 section 4.2.2.2. 717 The reception of a REMB message SHALL result in that the total bit 718 rate sent on the RTP session this message applies to is equal to or 719 lower than the bit rate in this message. The new bit rate constraint 720 should be applied as fast as resonable. The sender is free to apply 721 additional bandwidth restrictions based on its own restrictions and 722 estimates. 724 A.2.2. Message format 726 This document describes a message using the application specific 727 paylaod type. This is suitable for experimentation; upon 728 standardization, a specific type can be assigned for the purpose. 730 RTCP message with payload type 206. Reference RFC 3550, 4585 and 731 5104. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |V=2|P| FMT=15 | PT=206 | length | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | SSRC of packet sender | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | SSRC of media source | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Unique identifier 'R' 'E' 'M' 'B' | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Num SSRC | BR Exp | BR Mantissa | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | SSRC feedback | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | ... | 750 The fields V, P, SSRC, and length are defined in the RTP 751 specification [2], the respective meaning being summarized below: 753 version (V): 2 bits This field identifies the RTP version. The 754 current version is 2. 756 padding (P): 1 bit If set, the padding bit indicates that the 757 packet contains additional padding octets at the end that are not 758 part of the control information but are included in the length 759 field. Always 0 761 Feedback message type (FMT): 5 bits This field identifies the type 762 of the FB message and is interpreted relative to the type 763 (transport layer, payload- specific, or application layer 764 feedback). The values for each of the three feedback types are 765 defined in the respective sections below. Always 15, application 766 layer feedback message. RFC 4585 section 6.4 768 Payload type (PT): 8 bits This is the RTCP packet type that 769 identifies the packet as being an RTCP FB message. Always PSFB | 770 206 | Payload-specific FB message. RFC 4585 section 6.4. 772 Length: (16 bits) The length of this packet in 32-bit words minus 773 one, including the header and any padding. This is in line with 774 the definition of the length field used in RTCP sender and 775 receiver reports [3]. RFC 4585 section 6.4. 777 SSRC of packet sender: (32 bits) The synchronization source 778 identifier for the originator of this packet. RFC 4585 section 779 6.4. 781 SSRC of media source:(32 bits) Always 0. 783 Unique identifier (32 bits) Always 'R' 'E' 'M' 'B' 785 Num SSRC (8 bits): Number of SSRCs in this message 787 BR Exp (6 bits): The exponential scaling of the mantissa for the 788 maximum total media bit rate value, ignoring all packet overhead. 789 The value is an unsigned integer [0..63]. RFC 5104 section 790 4.2.2.1 792 BR Mantissa (18 bits): The mantissa of the maximum total media bit 793 rate (ignoring all packet overhead) that the sender of the REMB 794 estimates. The BR is the estimate of the traveled path for the 795 SSRCs reported in this message. The value is an unsigned integer 796 in number of bits per second 798 SSRC feedback (32 bits) Consists of one or more SSRC entries which 799 this feedback message applies to. 801 Appendix B. Change log 803 B.1. Version -00 to -01 805 o Added change log 807 o Added appendix outlining new extensions 809 o Added a section on when to send feedback to the end of section 3.3 810 "Rate control", and defined min/max FB intervals. 812 o Added size of over-bandwidth estimate usage to "further work" 813 section. 815 o Added startup considerations to "further work" section. 817 o Added sender-delay considerations to "further work" section. 819 o Filled in acknowledgements section from mailing list discussion. 821 Authors' Addresses 823 Henrik Lundin 824 Google 825 Kungsbron 2 826 Stockholm 11122 827 Sweden 829 Stefan Holmer 830 Google 831 Kungsbron 2 832 Stockholm 11122 833 Sweden 835 Email: holmer@google.com 837 Harald Alvestrand (editor) 838 Google 839 Kungsbron 2 840 Stockholm 11122 841 Sweden 843 Email: harald@alvestrand.no