idnits 2.17.1 draft-zhu-rmcat-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 7, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3551' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RFC4585' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC5104' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC0768' is defined on line 314, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMCAT WG X. Zhu 3 Internet-Draft Cisco Systems 4 Intended status: Informational Z. Sarker 5 Expires: January 8, 2017 Ericsson AB 6 July 7, 2016 8 Framework for Real-time Media Congestion Avoidance Techniques 9 draft-zhu-rmcat-framework-00 11 Abstract 13 Congestion control is an essential element in ensuring fair bandwidth 14 usage and preventing congestion collapse for traffic sharing the 15 Internet. For interactive real-time media traffic such as video 16 conferencing, design of congestion control solution also needs to 17 account for many other factors such as the requirement for low 18 latency packet delivery and interactions with live video encoder. 19 This document describes a common framework with the core functional 20 building blocks for a real-time media congestion solutions. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 8, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 2 58 3. Functional Modules . . . . . . . . . . . . . . . . . . . . . 3 59 4. Example Configurations . . . . . . . . . . . . . . . . . . . 4 60 4.1. Example Configurations for a Single Stream . . . . . . . 4 61 4.2. Example Configurations for Multiple Streams . . . . . . . 6 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Given increasing amount of interactive real-time media traffic over 73 the Internet, such as video conferencing, it is important that these 74 applications employ proper congestion control mechanisms to avoid 75 congestion collapse. [I-D.ietf-rmcat-cc-requirements] specifies the 76 list of requirements of a viable solution. 78 This document outlines a common framework for designing a congestion 79 control mechanism for real-time interactive communication, so that 80 individual drafts on specific solutions follow a consistent set of 81 terminologies in describing their respective components. The next 82 section (Section 3) describes common functional modules in this 83 framework, whereas Section 4 provides examples on how these modules 84 build together to support single and multiple media streams. 86 [ Editor's note : This document does not describe the interaction 87 between application, codec and congestion control system. The 88 interaction among application, codec and congestion control system 89 are defined in other documents. There is a possibility to merge all 90 the documents into one single document. ] 92 2. Key Words for Requirements 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Functional Modules 100 A viable solution for real-time media congestion control needs to 101 comprise of several common modules. This section provides a brief 102 description of them and their respective functionalities. A 103 congestion control solution for real-time media should comprise of 104 the described functional modules. This should help understanding 105 different congestion control solutions. 107 o Network Congestion Controller : this is the core module for 108 estimating available bandwidth over the network based on periodic 109 RTCP feedback reports [RFC3550] from the receiver. This module 110 contains key functions and calculations required to detect 111 congestion and estimate available bandwidth on the transmission 112 path based on the reception quality of the media traffic. 113 Different congestion control solutions employ different algorithms 114 in detecting congestion and estimating available bandwidth for its 115 media flow. It also possible that multiple media streams are 116 multiplexed over a single transport, hence share a common 117 congestion control module in aggregation. 119 o Transmission Queue : this module is needed to absorb the 120 instantaneous mismatch between output from a live video encoder 121 and regulated outgoing media flow. The transmission queue 122 schedules outgoing traffic according to sending rate recommended 123 by the rate controller module. It reports back its occupancy 124 level to the rate controller module to assist future rate control 125 decisions on target video rate, sending rate, and probing rate. 127 o Rate Controller : this module takes the estimated available 128 bandwidth from the network congestion controller, shared states of 129 other flows, as well as occupancy level of the transmission queue 130 as input. It makes holistic decisions on: a) target video rate 131 for the live video encoder; b) sending rate for regulating 132 outgoing media flow(s) for the transmission queue; and c) rate of 133 probing packets when needed. In the case where multiple media 134 streams share a single transport and a common network congestion 135 controller (for estimating available bandwidth in aggregation), 136 the rate controller is also responsible for distributing available 137 bandwidth amongst different media streams according to their 138 relative priorities as well as share state information. When 139 losses occur over the network and some previous media packets need 140 to be retransmitted, the rate controller should also account for 141 the bandwidth needed for retransmission. 143 o Network Probe Generator: A congestion control solution can 144 actively probe to estimate the available bandwidth on the media 145 transmission path by sending more than what the live video encoder 146 produces. Such an approach can be especially effective during the 147 ramp up period of media and transmission rates, when no congestion 148 has been observed over the network yet. The network probe 149 generator is responsible for generating probing packets according 150 to the probing rate specified by the rate controller. It can 151 employ different techniques in doing so -- for example by 152 generating simple dummy packets with unknown payload type or by 153 generating Forward Error Correction (FEC) packets. While this 154 document does not specify what probing technique to use or how 155 those packets should be generated, a complete congestion control 156 solution needs should specify total rate of the probe packets via 157 the rate controller module. 159 o Live Video Encoder : the sender typically also contains a live 160 video encoder, which adjusts the its encoding parameters according 161 to the target video rate set by the rate controller. The output 162 rate from the video encoder may deviate from this target due to 163 uncertainty in the captured video content characteristics and the 164 encoder rate control process. The output encoded media packets 165 are fed to the transmission queue. Note that internal operations 166 of the live video encoder (i.e., how video encoder rate control 167 works) is out of scope for this document. 169 o Shared State: In the case of multiple media streams sharing a 170 common sender hence a common network congestion controller, the 171 sender should also contain a shared state module for storage and 172 exchange of congestion control states [Editor's Note from 173 Xiaoqing: examples of congestion control states??] amongst the 174 multiple flows. 176 4. Example Configurations 178 4.1. Example Configurations for a Single Stream 179 RTCP Feedback 180 +---------+ +-------------+ Reports 181 | Live | | Network |<---------------- 182 | Video |<----------------+ | Congestion | 183 | Encoder | | | Controller | 184 +---------+ | +-------------+ 185 || | |(1) 186 || | | 187 || | \|/ 188 || +--------------+ | (4) +-------------+ 189 || | Network | +------| Rate | 190 || | Probe |<--------| Controller | 191 || | Generator | (5) +-------------+ 192 || +--------------+ (3)| /|\ 193 || || | | 194 || || Probing \|/ |(2) 195 || || Packets +---------------+ 196 || \\=============> | Transmission | 197 \\==========================> | Queue |==============> 198 Encoded Video Packets +---------------+ Outgoing 199 Packets 201 Figure 1: RMCAT Solution Framework at the Sender: Single Stream 203 Figure 1 shows an example configuration at the sender for supporting 204 a single media stream. The Network Congestion Controller estimates 205 available bandwidth based on periodic RTCP feedback reports. The 206 Rate Controller takes as input the estimated available bandwidth (1) 207 and the current occupancy level of the Transmission Queue (2). It 208 calculates as output sending rate (3) for the Transmission Queue, 209 video target rate (4) for the Live Video Encoder, and probing rate 210 (5) -- if they are needed -- for the Network Probe Generator. The 211 Transmission Queue holds packets generated by both the Live Video 212 Encoder and the Network Probe Generator; it paces transmission of its 213 outgoing packets according to the sending rate (3) specified by Rate 214 Controller. 216 Obviously, it is possible for a congestion control solution to 217 contain alternative configurations between these functional modules. 218 [TODO: add one quick example on alternative wiring.] It is required 219 that the candidate solution draft specify how their internal 220 functional modules align to this framework. 222 4.2. Example Configurations for Multiple Streams 224 RTCP Feedback 225 +---------+ +-------------+ Reports 226 | Live | | Network |<---------------- 227 | Video |<----------------+ | Congestion | 228 | Encoder | | | Controller | 229 +---------+ | +-------------+ 230 || | |(1) 231 || | | 232 || | \|/ 233 || | (4) +-------------+ +--------+ 234 || +---------+ +------| Rate |<-----| Shared | 235 || | Live | | | Controller | | States | 236 || | Video |<----+ +-------------+ +--------+ 237 || | Encoder | (3)| /|\ 238 || +---------+ | | 239 || || \|/ |(2) 240 || || +---------------+ 241 || || | Transmission | 242 \\==========================> | Queue |==============> 243 Encoded Video Packets +---------------+ Outgoing 244 Packets 246 Figure 2: RMCAT Solution Framework at the Sender: Multiple Streams 248 Figure 2 shows an example configuration for multiple video streams 249 sharing a common Network Congestion Controller. The Network 250 Congestion Controller calculates an aggregated estimated available 251 bandwidth (1) based on periodic RTCP feedback reports. The Rate 252 Controller divides up the aggregate estimated bandwidth (1) from the 253 Network Congestion Controller amongst sub-streams based on their 254 relative priority levels, Shared States, as well as current occupancy 255 level of the Transmission Queue. It subsequently determines the per- 256 flow sending rate (3) as regulated by the Transmission Queue and 257 target video rate (4) for each flow. 259 In this specific example, the transmission queue is envisioned as a 260 logical entity. For instance, this transmission queue can be 261 implemented priority-based scheduling and one physical queue per 262 stream. For sake of simplicity the role of Network Probe Generator 263 is omitted in the above figure. 265 5. Acknowledgements 267 The RMCAT design team discussions contributed to this memo. 269 6. IANA Considerations 271 This memo includes no request to IANA. 273 7. Security Considerations 275 TBD 277 8. References 279 8.1. Normative References 281 [I-D.ietf-rmcat-cc-requirements] 282 Jesup, R. and Z. Sarker, "Congestion Control Requirements 283 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 284 requirements-09 (work in progress), December 2014. 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 292 Jacobson, "RTP: A Transport Protocol for Real-Time 293 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 294 July 2003, . 296 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 297 Video Conferences with Minimal Control", STD 65, RFC 3551, 298 DOI 10.17487/RFC3551, July 2003, 299 . 301 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 302 "Extended RTP Profile for Real-time Transport Control 303 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 304 DOI 10.17487/RFC4585, July 2006, 305 . 307 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 308 "Codec Control Messages in the RTP Audio-Visual Profile 309 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 310 February 2008, . 312 8.2. Informative References 314 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 315 DOI 10.17487/RFC0768, August 1980, 316 . 318 Authors' Addresses 320 Xianqing Zhu 321 Cisco Systems 322 12515 Research Blvd., Building 4 323 Austin, TX 78759 324 USA 326 Email: xiaoqzhu@cisco.com 328 Zaheduzzaman Sarker 329 Ericsson AB 330 Luleae 331 Sweden 333 Phone: 00 46 10 717 37 43 334 Email: zaheduzzaman.sarker@ericsson.com