idnits 2.17.1 draft-zhu-rmcat-nada-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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 14, 2012) is 4213 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Rmin' is mentioned on line 315, but not defined == Missing Reference: 'Rmax' is mentioned on line 315, but not defined == Unused Reference: 'RFC3168' is defined on line 414, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Zhu 3 Internet Draft R. Pan 4 Intended Status: Informational Cisco Systems 5 Expires: April 17, 2013 October 14, 2012 7 NADA: A Unified Congestion Control Scheme for Real-Time Media 8 draft-zhu-rmcat-nada-00 10 Abstract 12 This document describes a scheme named network-assisted dynamic 13 adaptation (NADA), a novel congestion control approach for 14 interactive real-time media applications, such as video conferencing. 15 In the proposed scheme, the sender regulates its sending rate based 16 on either implicit or explicit congestion signaling, in a unified 17 approach. The scheme can reap the benefits of explicit congestion 18 notification markings from network nodes. It also maintains 19 consistent sender behavior in the absence of such markings, by 20 reacting to queuing delays instead. 22 We present here the overall system architecture, recommended 23 behaviors at the sender and the receiver, as well as expected network 24 nodes operations. Results from extensive simulation studies of the 25 proposed scheme are available upon request. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. System Model . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Network Node Operations . . . . . . . . . . . . . . . . . . . . 4 69 4.1 Default behavior of drop tail . . . . . . . . . . . . . . . 4 70 4.2 ECN marking . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.3 PCN marking . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.4 Comments and Discussions . . . . . . . . . . . . . . . . . . 6 73 5. Sender Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1 Encoder rate control . . . . . . . . . . . . . . . . . . . . 6 75 5.2 Rate shaping buffer . . . . . . . . . . . . . . . . . . . . 7 76 5.3 Encoder target rate calculator . . . . . . . . . . . . . . . 7 77 5.3.1 Slow-start behavior . . . . . . . . . . . . . . . . . . 7 78 5.3.2 ECN-enabled mode . . . . . . . . . . . . . . . . . . . . 8 79 5.4 Sending rate calculator . . . . . . . . . . . . . . . . . . 8 80 6. Receiver Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 81 7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 9 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 85 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 Interactive real-time media applications bring about a unique set of 91 challenges for congestion control. Unlike TCP, the mechanism used for 92 real-time media needs to adapt fast to instantaneous bandwidth 93 changes, accommodate fluctuations in the output of video encoder rate 94 control, and cause low queuing delay over the network. An ideal 95 scheme should also make effective use of all types of congestion 96 signals, including packet losses, queuing delay, and explicit 97 congestion notification (ECN) markings. 99 Based on the above considerations, we present a scheme named network- 100 assisted dynamic adaptation (NADA). The proposed design benefits from 101 explicit congestion control signals (e.g., ECN markings) from the 102 network, and remains compatible in the presence of implicit signals 103 (delay or loss) only. In addition, it supports weighted bandwidth 104 sharing among competing video flows. 106 This documentation describes the overall system architecture, 107 recommended designs at the sender and receiver, as well as expected 108 network nodes operations. The signaling mechanism consists of 109 standard RTP timestamp [RFC3550] and standard RTCP feedback reports. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 3. System Model 119 The system consists of the following elements: 121 * Incoming media stream, in the form of consecutive raw video 122 frames and audio samples; 124 * Media encoder with rate control capabilities. It takes the 125 incoming media stream and encodes it to an RTP stream at a 126 target bit rate R_o. Note that the actual output rate from the 127 encoder R_v may fluctuate randomly around R_o. Also, the encoder 128 can only change its rate at rather coarse time intervals, on the 129 order of seconds. 131 * RTP sender, responsible for calculating the target bit rate 132 R_o based on network congestion signals (delay or ECN marking 133 reports from the receiver), and for regulating the actual 134 sending rate R_s accordingly. The difference between the video 135 encoder output R_v and sending rate R_s are absorbed in a rate 136 shaping buffer. The buffer size L_s, together with R_v, 137 influences the calculation of R_s. The RTP sender also generates 138 RTP timestamp. 140 * RTP receiver, responsible for measuring and estimating end-to- 141 end queuing delay d based on sender RTP timestamp. In the 142 presence of ECN markings, it also maintains the statistics of 143 the marking ratio p. The receiver feeds these statistics back to 144 the sender via periodic RTCP reports. 146 * Network node, with several modes of operation. The system can 147 work with the default behavior of a simple drop tail queue. It 148 can also benefit from advanced AQM features such as RED-based 149 ECN marking, and PCN marking using a token bucket algorithm. 151 In the following, we will elaborate on the respective operations at the 152 network node, the sender, and the receiver. 154 4. Network Node Operations 156 We consider three variations of queue management behavior at the network 157 node, leading to either implicit or explicit congestion signals. 159 4.1 Default behavior of drop tail 161 In conventional network with drop tail or RED queues, congestion is 162 inferred from the estimation of end-to-end queuing delay. No special 163 action is required at network node. 165 This leads to the default operation of delay-based congestion control at 166 the sender. 168 4.2 ECN marking 170 In this mode, the network node randomly marks the ECN field in the IP 171 packet header following the Random Early Detection (RED) algorithm 172 [RFC2309]. Calculation of the marking probability involves the following 173 steps: 175 * upon packet arrival, update smoothed queue size q_avg as: 177 q_avg = alpha*q + (1-alpha)*q_avg. 179 The smoothing parameter alpha is a value between 0 and 1. A value of 180 alpha=0 corresponds to performing no smoothing at all, and 181 calculating the marking probability based on instantaneous queue 182 size. 184 * calculate marking probability p as: 186 p = 0, if q=q_hi. 194 Here, q_lo and q_hi corresponds to the low and high thresholds of queue 195 occupancy. The maximum parking probability is p_max. 197 The ECN markings will trigger the ECN-enabled mode of sender behavior. 199 4.3 PCN marking 201 As a more advanced feature, we also envision network nodes which support 202 PCN marking based on virtual queues. In such a case, the marking 203 probability of the ECN bit in the IP packet header is calculated as 204 follows: 206 * upon packet arrival, meter packet against token bucket (r,b); 208 * update token level b_tk; 210 * calculate the marking probability as: 212 p = 0, if b-b_tk < b_lo; 214 b-b_tk-b_lo 215 p = p_max* --------------, if b_lo<= b-b_tk =b_hi. 220 Here, the token bucket lower and upper limits are denoted by b_lo and 221 b_hi, respectively. The parameter b indicates the size of the token 222 bucket. The parameter r is chosen as r=gamma*C, where gamma<1 is the 223 target utilization ratio and C designates link capacity. The maximum 224 marking probability is p_max. 226 Note that the sender will respond to the observation of markings with 227 exactly the same ECN-enabled mode as in last section. However, the 228 virtual queuing mechanism at the network from the PCN marking algorithm 229 will lead to additional benefits such as zero standing queues and 230 smoother streaming rate. 232 4.4 Comments and Discussions 234 In all three flavors described above, the network queue operates with 235 the simple first-in-first-out (FIFO) principle. There is no need to 236 maintain per-flow state. Such a simple design ensures that the system 237 can scale easily with large number of video flows and high link 238 capacity. 240 5. Sender Behavior 242 As illustrated in Fig. 1, the sender comprises four modules: a) encoder 243 rate control; b) rate shaping buffer; c) encoder target rate calculator, 244 and d) sending rate calculator. 246 The following sections describe these modules in further details, and 247 explain how they interact with each other. 249 ------------ 250 | | Rv -------------- 251 | |----------------> | | | | | --------------> 252 | Encoder | | | | | | / \ 253 | | -------------- | 254 ------------ Rate Shaping Buffer | 255 | | | 256 | | | 257 | | | Rs 258 | Ro | | 259 | Ls | | 260 ----------------- | ----------------- 261 | | | | | 262 | Target Rate | |----->| Sending Rate | 263 | Calculation |------------------------> | Calculation | 264 | | ----------------- 265 ---------------- 266 /\ 267 | 268 --------------- RTCP report (loss/delay/ECN/PC) 270 Figure 1 Sender Structure 272 5.1 Encoder rate control 274 The encoder rate control procedure has the following characteristics: 276 * Rate changes can happen only at large intervals, on the order of 277 seconds. 279 * Given a target rate R_o, the encoder output rate may randomly 280 fluctuate around it. 282 * The encoder output rate is further constrained by video content 283 complexity. The range of the final rate output is [R_min, R_max]. 284 Note that it's content-dependent, and may change over time. 286 5.2 Rate shaping buffer 288 A rate shaping buffer is employed at the sender, to absorb any 289 instantaneous mismatch between encoder rate output R_v and regulated 290 sending rate R_s. The size of the buffer evolves over time, as: 292 L_s(t) = max [0, L_s(t-tau)+R_v*tau-R_s*tau]. 294 A large rate shaping buffer contributes to higher end-to-end delay, 295 which may harm the performance of real-time media communications. 296 Therefore, the sender has a strong incentive to constrain the size of 297 the shaping buffer. It can either deplete it faster by choosing a larger 298 sending rate R_s, or limit its growth by reducing the video encoder 299 target rate R_o. 301 5.3 Encoder target rate calculator 303 The sender calculates the encoder target rate based on network 304 congestion information from receiver RTCP reports. When only delay 305 information is available, the target rate is calculated as 307 R_max-R_min 308 R_o = R_min + kappa*w*------------- (1) 309 d 311 Here, R_min and R_max denote the content-dependent rate range the 312 encoder can produce. The weight of priority level is w. The scaling 313 factor kappa can be tuned to determine how sensitive the rate adaptation 314 scheme is in reaction to fluctuations in observed delay d. The final 315 target rate Ro is clipped within the range of [Rmin, Rmax]. 317 5.3.1 Slow-start behavior 319 In addition, the initial sending rate of a stream is regulated to grow 320 linearly, no more than R_ss at time t: 322 t-t_0 323 R_ss(t) = R_min + -------(R_max-R_min). 325 T 327 The start time of the stream is t_0, and T represents the time horizon 328 over which the slow-start mechanism is effective. The encoder target 329 rate is chosen to be the minimum of R_o and R_ss in the first T 330 seconds. 332 5.3.2 ECN-enabled mode 334 If the receiver reports on observed ECN marking probability p, the 335 target rate calculation of Eq. (1) is replaced by the following, with a 336 scaling factor eta: 338 R_max - R_min 339 R_o = R_min + eta*w*----------------. (2) 340 p 342 All other procedures remain the same. 344 Note that the sender does not need to differentiate whether the network 345 node operates with RED-based ECN marking, or token-bucket-level-based 346 PCN marking. It reacts to observed ECN marking probabilities in exactly 347 the same manner. 349 5.4 Sending rate calculator 351 Finally, the actual outgoing rate over the network is R_s. Its value is 352 calculated based on both the encoder target rate and rate shaping buffer 353 size, as follows: 355 L_s 356 R_s = R_o + beta * -------. 357 tau_v 359 The first term indicates the rate calculated from network congestion 360 feedback alone. The second term exerts additional pressure to send out 361 more packets, if the rate shaping buffer is building up. The scaling 362 factor beta can be tuned to balance between these two competing goals. 364 6. Receiver Behavior 366 The role of the receiver is fairly straightforward. It observes and 367 estimates end-to-end queuing delay d and ECN marking ratio p of the 368 stream. The former can be obtained from the RTP timestamp provided by 369 the sender. The latter can be obtained by keeping a running average of 370 the number of marked and un-marked packets. The detailed mechanisms for 371 obtaining such estimates can be varied, and is out of the scope of this 372 paper. 374 Periodically, the receiver sends back the updated values of d and p in 375 RTCP messages, to aid the sender in its calculation of target rate. 376 Note that the size of acknowledgement packets are typically on the order 377 of tens of bytes, and are significantly smaller than average video 378 packet sizes. Therefore, the bandwidth overhead of the receiver 379 acknowledgement stream is sufficiently low. 381 7. Incremental Deployment 383 One nice property of proposed design is the consistent behavior of video 384 end points regardless of variations in network node operations. This 385 facilitates gradual, incremental adoption of the scheme. 387 To start off with, the scheme operating in delay-assisted congestion 388 control mode can be implemented without any explicit support from the 389 network. 391 When ECN is enabled at the network nodes, together with RED-based 392 marking, the sender can react to these explicit congestion signals 393 instead. Ultimately, networks equipped with proactive marking based on 394 token bucket level metering can reap the additional benefits, including 395 zero standing queues and more smooth streaming rates. 397 8. IANA Considerations 399 There are no actions for IANA. 401 9. References 403 9.1 Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 409 Jacobson, "RTP: A Transport Protocol for Real-Time 410 Applications", STD 64, RFC 3550, July 2003. 412 9.2 Informative References 414 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 415 of Explicit Congestion Notification (ECN) to IP", 416 RFC 3168, September 2001. 418 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 419 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 420 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 421 S., Wroclawski, J., and L. Zhang, "Recommendations on 422 Queue Management and Congestion Avoidance in the 423 Internet", RFC 2309, April 1998. 425 Authors' Addresses 427 Xiaoqing Zhu 428 Cisco Systems, 429 510 McCarthy Blvd, 430 Milpitas, CA 95134, USA 431 EMail: xiaoqzhu@cisco.com 433 Rong Pan 434 Cisco Systems 435 510 McCarthy Blvd, 436 Milpitas, CA 95134, USA 437 Email: ropan@cisco.com