idnits 2.17.1 draft-alvestrand-rtcweb-congestion-02.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 (April 25, 2012) is 4382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-alvestrand-rmcat-remb-00 ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: October 27, 2012 Google 6 April 25, 2012 8 A Google Congestion Control Algorithm for Real-Time Communication on the 9 World Wide Web 10 draft-alvestrand-rtcweb-congestion-02 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 October 27, 2012. 45 Copyright Notice 47 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 11 71 5. Interoperability Considerations . . . . . . . . . . . . . . . 12 72 6. Implementation Experience . . . . . . . . . . . . . . . . . . 13 73 7. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 81 A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . . 16 82 A.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 Congestion control is a requirement for all applications that wish to 88 share the Internet [RFC2914]. 90 The problem of doing congestion control for real-time media is made 91 difficult for a number of reasons: 93 o The media is usually encoded in forms that cannot be quickly 94 changed to accommodate varying bandwidth, and bandwidth 95 requirements can often be changed only in discrete, rather large 96 steps 98 o The participants may have certain specific wishes on how to 99 respond - which may not be reducing the bandwidth required by the 100 flow on which congestion is discovered 102 o The encodings are usually sensitive to packet loss, while the real 103 time requirement precludes the repair of packet loss by 104 retransmission 106 This memo describes two congestion control algorithms that together 107 are seen to give reasonable performance and reasonable (not perfect) 108 bandwidth sharing with other conferences and with TCP-using 109 applications that share the same links. 111 The signalling used consists of standard RTP timestamps [RFC3550] 112 possibly augmented with RTP transmission time offsets [RFC5450], 113 standard RTCP feedback reports and Temporary Maximum Media Stream Bit 114 Rate Requests (TMMBR) as defined in [RFC5104] section 3.5.4, or by 115 using the REMB feedback report defined in [I-D.alvestrand-rmcat-remb] 117 1.1. Mathemathical notation conventions 119 The mathematics of this document have been transcribed from a more 120 formula-friendly format. 122 The following notational conventions are used: 124 X_bar The variable X, where X is a vector - conventionally marked by 125 a bar on top of the variable name. 127 X_hat An estimate of the true value of variable X - conventionally 128 marked by a circumflex accent on top of the variable name. 130 X(i) The "i"th value of X - conventionally marked by a subscript i. 132 [x y z] A row vector consisting of elements x, y and z. 134 X_bar^T The transpose of vector X_bar. 136 E{X} The expected value of the stochastic variable X 138 2. System model 140 The following elements are in the system: 142 o RTP packet - an RTP packet containing media data. 144 o Frame - a set of RTP packets transmitted from the sender at the 145 same time instant. This could be a video frame, an audio frame, 146 or a mix of audio and video packets. A frame can be defined by 147 the RTP packet send time (RTP timestamp + transmission time 148 offset), or by the RTP timestamp if the transmission time offset 149 field is not present. 151 o Incoming media streams - a stream of frames consisting of RTP 152 packets. 154 o Media codec - has a bandwidth control, and encodes the incoming 155 media stream into an RTP stream. 157 o RTP sender - sends the RTP stream over the network to the RTP 158 receiver. Generates the RTP timestamp. 160 o RTP receiver - receives the RTP stream, notes the time of arrival. 161 Regenerates the media stream for the recipient. 163 o RTCP sender at RTP sender - sends sender reports. 165 o RTCP sender at RTP receiver - sends receiver reports and TMMBR/ 166 REMB messages. 168 o RTCP receiver at RTP sender - receives receiver reports and TMMBR/ 169 REMB messages, reports these to sender side control. 171 o RTCP receiver at RTP receiver. 173 o Sender side control - takes loss rate info, round trip time info, 174 and TMMBR/REMB messages and computes a sending bitrate. 176 o Receiver side control - takes the packet arrival info at the RTP 177 receiver and decides when to send TMMBR/REMB messages. 179 Together, sender side control and receiver side control implement the 180 congestion control algorithm. 182 3. Receiver side control 184 The receive-side algorithm can be further decomposed into three 185 parts: an arrival-time filter, an over-use detector, and a remote 186 rate-control. 188 3.1. Arrival-time model 190 This section describes an adaptive filter that continuously updates 191 estimates of network parameters based on the timing of the received 192 frames. 194 At the receiving side we are observing groups of incoming packets, 195 where each group of packets corresponding to the same frame having 196 timestamp T(i). 198 Each frame is assigned a receive time t(i), which corresponds to the 199 time at which the whole frame has been received (ignoring any packet 200 losses). A frame is delayed relative to its predecessor if t(i)-t(i- 201 1)>T(i)-T(i-1), i.e., if the arrival time difference is larger than 202 the timestamp difference. 204 We define the (relative) inter-arrival time, d(i) as 206 d(i) = t(i)-t(i-1)-(T(i)-T(i-1)) 208 Since the time ts to send a frame of size L over a path with a 209 capacity of C is roughly 211 ts = L/C 213 we can model the inter-arrival time as 215 L(i)-L(i-1) 216 d(i) = -------------- + w(i) = dL(i)/C+w(i) 217 C 219 Here, w(i) is a sample from a stochastic process W, which is a 220 function of the capacity C, the current cross traffic X(i), and the 221 current send bit rate R(i). We model W as a white Gaussian process. 222 If we are over-using the channel we expect w(i) to increase, and if a 223 queue on the network path is being emptied, w(i) will decrease; 224 otherwise the mean of w(i) will be zero. 226 Breaking out the mean m(i) from w(i) to make the process zero mean, 227 we get 229 Equation 5 231 d(i) = dL(i)/C + m(i) + v(i) 233 This is our fundamental model, where we take into account that a 234 large frame needs more time to traverse the link than a small frame, 235 thus arriving with higher relative delay. The noise term represents 236 network jitter and other delay effects not captured by the model. 238 When graphing the values for d(i) versus dL(i) on a scatterplot, we 239 find that most samples cluster around the center, and the outliers 240 are clustered along a line with average slope 1/C and zero offset. 242 For instance, when using a regular video codec, most frames are 243 roughly the same size after encoding (the central "cloud"); the 244 exceptions are I-frames (or key frames) which are typically much 245 larger than the average causing positive outliers (the I-frame 246 itself) and negative outliers (the frame after an I-frame) on the dL 247 axis. Audio frames on the other hand often consist of single packets 248 of equal size, and an audio-only media stream would have its frames 249 scattered at dL = 0. 251 3.2. Arrival-time filter 253 The parameters d(i) and dL(i) are readily available for each frame i 254 > 1, and we want to estimate C(i) and m(i) and use those estimates to 255 detect whether or not we are over-using the bandwidth currently 256 available. These parameters are easily estimated by any adaptive 257 filter - we are using the Kalman filter. 259 Let 261 theta_bar(i) = [1/C(i) m(i)]^T 263 and call it the state of time i. We model the state evolution from 264 time i to time i+1 as 265 theta_bar(i+1) = theta_bar(i) + u_bar(i) 267 where u_bar(i) is the zero mean white Gaussian process noise with 268 covariance 270 Equation 7 272 Q(i) = E{u_bar(i) u_bar(i)^T} 274 Given equation 5 we get 276 Equation 8 278 d(i) = h_bar(i)^T theta_bar(i) + v(i) 280 h_bar(i) = [dL(i) 1]^T 282 where v(i) is zero mean white Gaussian measurement noise with 283 variance var_v = sigma(v,i)^2 285 The Kalman filter recursively updates our estimate 287 theta_hat(i) = [1/C_hat(i) m_hat(i)]^T 289 as 291 z(i) = d(i) - h_bar(i)^T * theta_hat(i-1) 293 theta_hat(i) = theta_hat(i-1) + z(i) * k_bar(i) 295 E(i-1) * h_bar(i) 296 k_bar(i) = -------------------------------------------- 297 var_v_hat + h_bar(i)^T * E(i-1) * h_bar(i) 299 E(i) = (I - K_bar(i) * h_bar(i)^T) * E(i-1) + Q(i) 301 I is the 2-by-2 identity matrix. 303 The variance var_v = sigma(v,i)^2 is estimated using an exponential 304 averaging filter, modified for variable sampling rate 306 var_v_hat = beta*sigma(v,i-1)^2 + (1-beta)*z(i)^2 308 beta = (1-alpha)^(30/(1000 * f_max)) 310 where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1...i is the 311 highest rate at which frames have been captured by the camera the 312 last K frames and alpha is a filter coefficient typically chosen as a 313 number in the interval [0.1, 0.001]. Since our assumption that v(i) 314 should be zero mean WGN is less accurate in some cases, we have 315 introduced an additional outlier filter around the updates of 316 var_v_hat. If z(i) > 3 var_v_hat the filter is updated with 3 317 sqrt(var_v_hat) rather than z(i). For instance v(i) will not be 318 white in situations where packets are sent at a higher rate than the 319 channel capacity, in which case they will be queued behind each 320 other. In a similar way, Q(i) is chosen as a diagonal matrix with 321 main diagonal elements given by 323 diag(Q(i)) = 30/(1000 * f_max)[10^-10 10^-2]^T 325 It is necessary to scale these filter parameters with the frame rate 326 to make the detector respond as quickly at low frame rates as at high 327 frame rates. 329 3.3. Over-use detector 331 The offset estimate m(i) is compared with a threshold gamma_1. An 332 estimate above the threshold is considered as an indication of over- 333 use. Such an indication is not enough for the detector to signal 334 over-use to the rate control subsystem. Not until over-use has been 335 detected for at least gamma_2 milliseconds and at least gamma_3 336 frames, a definitive over-use will be signaled. However, if the 337 offset estimate m(i) was decreased in the last update, over-use will 338 not be signaled even if all the above conditions are met. Similarly, 339 the opposite state, under-use, is detected when m(i) < -gamma_1. If 340 neither over-use nor under-use is detected, the detector will be in 341 the normal state. 343 3.4. Rate control 345 The rate control at the receiving side is designed to increase the 346 receive-side estimate of the available bandwidth A_hat as long as the 347 detected state is normal. Doing that assures that we, sooner or 348 later, will reach the available bandwidth of the channel and detect 349 an over-use. 351 As soon as over-use has been detected the receive-side estimate of 352 the available bandwidth is decreased. In this way we get a recursive 353 and adaptive estimate of the available bandwidth. 355 In this document we make the assumption that the rate control 356 subsystem is executed periodically and that this period is constant. 358 The rate control subsystem has 3 states: Increase, Decrease and Hold. 359 "Increase" is the state when no congestion is detected; "Decrease" is 360 the state where congestion is detected, and "Hold" is a state that 361 waits until built-up queues have drained before going to "increase" 362 state. 364 The state transitions (with blank fields meaning "remain in state") 365 are: 367 State ----> | Hold |Increase |Decrease 368 Signal----------------------------------------- 369 v | | | 370 Over-use | Decrease |Decrease | 371 ----------------------------------------------- 372 Normal | Increase | |Hold 373 ----------------------------------------------- 374 Under-use | |Hold |Hold 375 ----------------------------------------------- 377 The subsystem starts in the increase state, where it will stay until 378 over-use or under-use has been detected by the detector subsystem. 379 On every update the receive-side estimate of the available bandwidth 380 is increased with a factor which is a function of the global system 381 response time and the estimated measurement noise variance var_v_hat. 382 The global system response time is the time from an increase that 383 causes over-use until that over-use can be detected by the over-use 384 detector. The variance var_v_hat affects how responsive the Kalman 385 filter is, and is thus used as an indicator of the delay inflicted by 386 the Kalman filter. 388 A_hat(i) = eta*A_hat(i-1) 389 1.001+B 390 eta(RTT, var_v_hat) = ------------------------------------------ 391 1+e^(b(d*RTT - (c1 * var_v_hat + c2))) 393 Here, B, b, d, c1 and c2 are design parameters. 395 Since the system depends on over-using the channel to verify the 396 current available bandwidth estimate, we must make sure that our 397 estimate doesn't diverge from the rate at which the sender is 398 actually sending. Thus, if the sender is unable to produce a bit 399 stream with the bit rate the receiver is asking for, the available 400 bandwidth estimate must stay within a given bound. Therefore we 401 introduce a threshold 402 A_hat(i) < 1.5 * R_hat(i) 404 where R_hat(i) is the incoming bit rate measured over a T seconds 405 window: 407 R_hat(i) = 1/T * sum(L(j)) for j from 1 to N(i) 409 N(i) is the number of frames received the past T seconds and L(j) is 410 the payload size of frame j. 412 When an over-use is detected the system transitions to the decrease 413 state, where the receive-side available bandwidth estimate is 414 decreased to a factor times the currently incoming bit rate. 416 A_hat(i) = alpha*R_hat(i) 418 alpha is typically chosen to be in the interval [0.8, 0.95]. 420 When the detector signals under-use to the rate control subsystem, we 421 know that queues in the network path are being emptied, indicating 422 that our available bandwidth estimate is lower than the actual 423 available bandwidth. Upon that signal the rate control subsystem 424 will enter the hold state, where the receive-side available bandwidth 425 estimate will be held constant while waiting for the queues to 426 stabilize at a lower level - a way of keeping the delay as low as 427 possible. This decrease of delay is wanted, and expected, 428 immediately after the estimate has been reduced due to over-use, but 429 can also happen if the cross traffic over some links is reduced. In 430 either case we want to measure the highest incoming rate during the 431 under-use interval: 433 R_max = max{R_hat(i)} for i in 1..K 435 where K is the number of frames of under-use before returning to the 436 normal state. R_max is a measure of the actual bandwidth available 437 and is a good guess of what bit rate the sender should be able to 438 transmit at. Therefore the receive-side available bandwidth estimate 439 will be set to R_max when we transition from the hold state to the 440 increase state. 442 One design decision is when to send rate control messages. The time 443 from a change in congestion to the sending of the feedback message is 444 a limitation on how fast the sender can react. Sending too many 445 messages giving no new information is a waste of bandwidth - but in 446 the case of severe congestion, feedback messages can be lost, 447 resulting in a failure to react in a timely manner. 449 The conclusion is that feedback messages should be sent on a 450 "heartbeat" schedule, allowing the sender side control to react to 451 missing feedback messages by reducing its send rate, but they should 452 also be sent whenever the estimated bandwidth value has changed 453 significantly, without waiting for the heartbeat time, up to some 454 limiting upper bound on the send rate. 456 The minimum interval is named t_min_fb_interval. 458 The maximum interval is named t_max_fb_interval. 460 The permissible values of these intervals will be bounded by the RTP 461 session's RTCP bandwidth and its rtcp_frr setting. 463 [TODO: Get some example values for these timers] 465 4. Sender side control 467 An additional congestion controller resides at the sending side. It 468 bases its decisions on the round-trip time, packet loss and available 469 bandwidth estimates transmitted from the receiving side. 471 The available bandwidth estimates produced by the receiving side are 472 only reliable when the size of the queues along the channel are large 473 enough. If the queues are very short, over-use will only be visible 474 through packet losses, which aren't used by the receiving side 475 algorithm. 477 This algorithm is run every time a receive report arrives at the 478 sender, which will happen no more often than t_min_fb_interval, and 479 no less often than t_max_fb_interval. If no receive report is 480 received within 2x t_max_fb_interval (indicating at least 2 lost 481 feedback reports), the algorithm will take action as if all packets 482 in the interval have been lost, resulting in a halving of the send 483 rate. 485 o If 2-10% of the packets have been lost since the previous report 486 from the receiver, the sender available bandwidth estimate As(i) 487 (As denotes 'sender available bandwidth') will be kept unchanged. 489 o If more than 10% of the packets have been lost a new estimate is 490 calculated as As(i)=As(i-1)(1-0.5p), where p is the loss ratio. 492 o As long as less than 2% of the packets have been lost As(i) will 493 be increased as As(i)=1.05(As(i-1)+1000) 495 The new send-side estimate is limited by the TCP Friendly Rate 496 Control formula [RFC3448] and the receive-side estimate of the 497 available bandwidth A(i): 498 8 s 499 As(i) >= ---------------------------------------------------------- 500 R*sqrt(2*b*p/3) + (t_RTO*(3*sqrt(3*b*p/8) * p * (1+32*p^2))) 502 As(i) <= A(i) 504 where b is the number of packets acknowledged by a single TCP 505 acknowledgement (set to 1 per TFRC recommendations), t_RTO is the TCP 506 retransmission timeout value in seconds (set to 4*R) and s is the 507 average packet size in bytes. R is the round-trip time in seconds. 509 (The multiplication by 8 comes because TFRC is computing bandwidth in 510 bytes, while this document computes bandwidth in bits.) 512 In words: The sender-side estimate will never be larger than the 513 receiver-side estimate, and will never be lower than the estimate 514 from the TFRC formula. 516 We motivate the packet loss thresholds by noting that if the 517 transmission channel has a small amount of packet loss due to over- 518 use, that amount will soon increase if the sender does not adjust his 519 bit rate. Therefore we will soon enough reach above the 10 % 520 threshold and adjust As(i). However if the packet loss rate does not 521 increase, the losses are probably not related to self-induced channel 522 over-use and therefore we should not react on them. 524 5. Interoperability Considerations 526 There are three scenarios of interest, and one included for reference 528 o Both parties implement the algorithms described here 530 o Sender implements the algorithm described in section Section 4, 531 recipient does not implement Section 3 533 o Recipient implements the algorithm in section Section 3, sender 534 does not implement Section 4. 536 In the case where both parties implement the algorithms, we expect to 537 see most of the congestion control response to slowly varying 538 conditions happen by TMMBR/REMB messages from recipient to sender. 539 At most times, the sender will send less than the congestion-inducing 540 bandwidth limit C, and when he sends more, congestion will be 541 detected before packets are lost. 543 If sudden changes happen, packets will be lost, and the sender side 544 control will trigger, limiting traffic until the congestion becomes 545 low enough that the system switches back to the receiver-controlled 546 state. 548 In the case where sender only implements, we expect to see somewhat 549 higher loss rates and delays, but the system will still be overall 550 TCP friendly and self-adjusting; the governing term in the 551 calculation will be the TFRC formula. 553 In the case where recipient implements this algorithm and sender does 554 not, congestion will be avoided for slow changes as long as the 555 sender understands and obeys TMMBR/REMB; there will be no backoff for 556 packet-loss-inducing changes in capacity. Given that some kind of 557 congestion control is mandatory for the sender according to the TMMBR 558 spec, this case has to be reevaluated against the specific congestion 559 control implemented by the sender. 561 6. Implementation Experience 563 This algorithm has been implemented in the open-source WebRTC 564 project. 566 7. Further Work 568 This draft is offered as input to the congestion control discussion. 570 Work that can be done on this basis includes: 572 o Consideration of timing info: It may be sensible to use the 573 proposed TFRC RTP header extensions [I-D.gharai-avtcore-rtp-tfrc] 574 to carry per-packet timing information, which would both give more 575 data points and a timestamp applied closer to the network 576 interface. This draft includes consideration of using the 577 transmission time offset defined in [RFC5450] 579 o Considerations of cross-channel calculation: If all packets in 580 multiple streams follow the same path over the network, congestion 581 or queueing information should be considered across all packets 582 between two parties, not just per media stream. A feedback 583 message (REMB) that may be suitable for such a purpose is given in 584 [I-D.alvestrand-rmcat-remb]. 586 o Considerations of cross-channel balancing: The decision to slow 587 down sending in a situation with multiple media streams should be 588 taken across all media streams, not per stream. 590 o Considerations of additional input: How and where packet loss 591 detected at the recipient can be added to the algorithm. 593 o Considerations of locus of control: Whether the sender or the 594 recipient is in the best position to figure out which media 595 streams it makes sense to slow down, and therefore whether one 596 should use TMMBR to slow down one channel, signal an overall 597 bandwidth change and let the sender make the decision, or signal 598 the (possibly processed) delay info and let the sender run the 599 algorithm. 601 o Considerations of over-bandwidth estimation: Whether we can use 602 the estimate of how much we're over bandwidth in section 3 to 603 influence how much we reduce the bandwidth, rather than using a 604 fixed factor. 606 o Startup considerations. It's unreasonable to assume that just 607 starting at full rate is always the best strategy. 609 o Dealing with sender traffic shaping, which delays sending of 610 packets. Using send-time timestamps rather than RTP timestamps 611 may be useful here, but as long as the sender's traffic shaping 612 does not spread out packets more than the bottleneck link, it 613 should not matter. 615 o Stability considerations. It is not clear how to show that the 616 algorithm cannot provide an oscillating state, either alone or 617 when competing with other algorithms / flows. 619 These are matters for further work; since some of them involve 620 extensions that have not yet been standardized, this could take some 621 time. 623 8. IANA Considerations 625 This document makes no request of IANA. 627 Note to RFC Editor: this section may be removed on publication as an 628 RFC. 630 9. Security Considerations 632 An attacker with the ability to insert or remove messages on the 633 connection will, of course, have the ability to mess up rate control, 634 causing people to send either too fast or too slow, and causing 635 congestion. 637 In this case, the control information is carried inside RTP, and can 638 be protected against modification or message insertion using SRTP, 639 just as for the media. Given that timestamps are carried in the RTP 640 header, which is not encrypted, this is not protected against 641 disclosure, but it seems hard to mount an attack based on timing 642 information only. 644 10. Acknowledgements 646 Thanks to Randell Jesup, Magnus Westerlund, Varun Singh, Tim Panton, 647 Soo-Hyun Choo, Jim Gettys, Ingemar Johansson, Michael Welzl and 648 others for providing valuable feedback on earlier versions of this 649 draft. 651 11. References 653 11.1. Normative References 655 [I-D.alvestrand-rmcat-remb] 656 Alvestrand, H., "RTCP message for Receiver Estimated 657 Maximum Bitrate", draft-alvestrand-rmcat-remb-00 (work in 658 progress), January 2012. 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 664 Friendly Rate Control (TFRC): Protocol Specification", 665 RFC 3448, January 2003. 667 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 668 Jacobson, "RTP: A Transport Protocol for Real-Time 669 Applications", STD 64, RFC 3550, July 2003. 671 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 672 "Codec Control Messages in the RTP Audio-Visual Profile 673 with Feedback (AVPF)", RFC 5104, February 2008. 675 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 676 RTP Streams", RFC 5450, March 2009. 678 11.2. Informative References 680 [I-D.gharai-avtcore-rtp-tfrc] 681 Gharai, L. and C. Perkins, "RTP with TCP Friendly Rate 682 Control", draft-gharai-avtcore-rtp-tfrc-01 (work in 683 progress), September 2011. 685 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 686 RFC 2914, September 2000. 688 Appendix A. Change log 690 A.1. Version -00 to -01 692 o Added change log 694 o Added appendix outlining new extensions 696 o Added a section on when to send feedback to the end of section 3.3 697 "Rate control", and defined min/max FB intervals. 699 o Added size of over-bandwidth estimate usage to "further work" 700 section. 702 o Added startup considerations to "further work" section. 704 o Added sender-delay considerations to "further work" section. 706 o Filled in acknowledgements section from mailing list discussion. 708 A.2. Version -01 to -02 710 o Defined the term "frame", incorporating the transmission time 711 offset into its definition, and removed references to "video 712 frame". 714 o Referred to "m(i)" from the text to make the derivation clearer. 716 o Made it clearer that we modify our estimates of available 717 bandwidth, and not the true available bandwidth. 719 o Removed the appendixes outlining new extensions, added pointers to 720 REMB draft and RFC 5450. 722 Authors' Addresses 724 Henrik Lundin 725 Google 726 Kungsbron 2 727 Stockholm 11122 728 Sweden 730 Stefan Holmer 731 Google 732 Kungsbron 2 733 Stockholm 11122 734 Sweden 736 Email: holmer@google.com 738 Harald Alvestrand (editor) 739 Google 740 Kungsbron 2 741 Stockholm 11122 742 Sweden 744 Email: harald@alvestrand.no