idnits 2.17.00 (12 Aug 2021) /tmp/idnits26128/draft-you-use-cases-for-video-transport-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 8, 2016) is 2143 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T P.1201' is mentioned on line 150, but not defined == Missing Reference: 'ITU-T P.1202' is mentioned on line 150, but not defined == Outdated reference: A later version (-04) exists of draft-flinck-mobile-throughput-guidance-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. You 3 Internet-Draft Huawei 4 Intended status: Informational July 8, 2016 5 Expires: January 9, 2017 7 Use Cases for Video Transport 8 draft-you-use-cases-for-video-transport-00 10 Abstract 12 IP video traffic represents a large fraction of Internet traffic. 13 How to transmit video traffic efficiently poses traffic management 14 challenges to both network operators and Internet applications. 16 The traffic characteristics of encoded video have a significant 17 impact on the network transport. This document provides use cases 18 where network operator and Internet application can be cooperative to 19 improve video transmission efficiency, based on the fundamental 20 traffic characteristics (e.g. frame priority, adaptive bit rate, 21 etc.). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 9, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Abbreviations and acronyms . . . . . . . . . . . . . . . 3 66 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Video Service Experience Evaluation . . . . . . . . . . . 4 69 3.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 4 70 3.1.2. Information Exposed . . . . . . . . . . . . . . . . . 6 71 3.2. Intelligent Packet Dropping . . . . . . . . . . . . . . . 6 72 3.2.1. Problem Statement . . . . . . . . . . . . . . . . . . 6 73 3.2.2. Information Exposed . . . . . . . . . . . . . . . . . 7 74 3.3. Network Congestion State Feedback . . . . . . . . . . . . 7 75 3.3.1. Problem Statement . . . . . . . . . . . . . . . . . . 7 76 3.3.2. Information Exposed . . . . . . . . . . . . . . . . . 8 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 6.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Video consumption has grown so fast that the bottleneck link is 87 congested during peak hours. Globally, IP video traffic will be 82 88 percent of all IP traffic (both business and consumer) by 2020, up 89 from 70 percent in 2015. 4K Ultra HD technology is by itself a very 90 new trend in the overall electronics landscape, and the impact of it 91 is growing month by month. 4K content increases the demand for 92 network capacity greatly. How to transmit video traffic efficiently 93 poses traffic management challenges to both network operators and 94 Internet applications. However, the existing video transport schemes 95 mainly treat the traffic data in a content agnostic fashion. Such 96 scheduling approaches cannot effectively exploit the limited network 97 resources to maximize the perceived quality as video streaming is 98 characterized by complex content parameters (e.g., frame priority, 99 decoding dependency, etc.). 101 This document provides use cases where network operator and Internet 102 application can be cooperative to improve video transmission 103 efficiency, based on the fundamental traffic characteristics, such as 104 frame types (e.g., I, P, or B), adaptive bit rate, etc. The problem 105 of optimizing the delivery of video content to clients while meeting 106 the constraints imposed by the available network resources is 107 considered. 109 2. Terminology 111 This section contains definitions for terms used frequently 112 throughout this document. 114 2.1. Abbreviations and acronyms 116 BRAS: Broadband Remote Access Server 118 DRR: Deficit Round Robin 120 HD: High-Definition 122 MOS: Mean Opinion Score 124 OLT: Optical Line Terminal 126 QoE: Quality of Experience 128 TCP: Transmission Control Protocol 130 2.2. Definitions 132 4K: known as Ultra HD or UHD, is used to describe a new high 133 resolution video format with a minimum resolution of 3840 x 2160 134 pixels in a 16 x 9 aspect ratio for any display. 136 3. Use Cases 137 3.1. Video Service Experience Evaluation 139 3.1.1. Problem Statement 141 4K Ultra HD technology is by itself a very new trend in the overall 142 electronics landscape, and the impact of it is growing month by 143 month. As the increasing of the implementations of Ultra HD and to 144 keep the increasingly sophisticated customers content while remaining 145 profitable at the same time, it is important to design and manage the 146 video service based on the user quality of experience (QoE) to 147 provide attractive 4K video. Assessing the QoE of 4K video service 148 is therefore essential. 150 ITU-T Recommendations (see [ITU-T P.1201] and [ITU-T P.1202], for 151 instance) define the models to estimate video Mean Opinion Scores 152 (MOS). The video MOS model is applicable to progressive download and 153 adaptive streaming where the quality experienced by the end user is 154 affected by audio- and video-coding degradations, and delivery 155 degradations due to initial buffering, re-buffering (which are both 156 perceivable as stalling of the media), and media adaptations. A 157 media adaptation is where the player switches video playback between 158 a known set of media quality levels while adapting to network 159 conditions. Each of the quality levels typically differs in a 160 significant video or audio or audio/visual quality change. These 161 quality changes are most readily observed by changes in bitrate, 162 resolution, frame rate, and similar attributes. 164 For the models of estimating video MOS for UHD content, another 165 crucial scenario - fault localization for QoE degradation is also 166 considered. For example, an IPTV provider can implement video MOS 167 models in their key network devices, such as core router, BRAS 168 (Broadband Remote Access Server), and OLT (Optical Line Terminal), to 169 locate where a QoE degradation fault happens in an IP video network, 170 as shown in figure 1. 172 ------------- 173 ///// \\\\\ 174 // IPTV HeadEnd \\ 175 | +------+ +------+ | 176 | |Server| |Server| | 177 | +------+ +------+ | 178 \\ // 179 +--------+ +--------+ 180 | Router |-----| Router +--------------------+ 181 +---+----* *-----+--+ | 182 | \ / | | 183 | X | | 184 | / \ | | 185 | / \ | | 186 | / \ | V 187 +---+---/+ +-\+-----+ +---------+ 188 | Router +--------+ Router +-------------->|Video MOS| 189 +---+----+ +----+---+ | Center | 190 | | + --------+ 191 | | ^ ^ 192 | | | | 193 | | | | 194 +--+-----+ +-----+--+ | | 195 | Router |------| Router +-------------------+ | 196 +----\---+ +---/----+ | 197 // \ / \\ | 198 | \ / | | 199 | \ Metro / | | 200 | \ / | | 201 | \ / | | 202 \\ \ / // | 203 \\\\ +-\/---+//// | 204 ---| BRAS +------------------------------+ 205 +-/--\-+ 206 / \ 207 / \ 208 / \ 209 / \ 210 / \ 211 / \ 212 +--/-------+ +---\------+ 213 |End Device| |End Device| 214 +----------+ +----------+ 216 Figure 1: Video MOS Deployment Example 218 In this use case, the video MOS probes may be deployed on some key 219 network points for monitoring of transmission quality for operations 220 and maintenance purposes. The network monitoring points are required 221 to provide video MOS to the video MOS control center. By estimating 222 the video MOS at different network monitoring points, it is possible 223 to perceive several diagnostic signals and reflect the location of 224 the impairments on the IP network being measured. 226 3.1.2. Information Exposed 228 The video MOS model will receive media information and prior 229 knowledge about the media stream or streams. In various modes of 230 operation, different inputs may be extracted or estimated in 231 different ways. For example, the video MOS model may need the 232 following input signals of operation: 234 Table 1: Video MOS Model Inputs Example 235 +-------------------+--------------------------+----------------+ 236 | Description | Values | Frequency | 237 +-------------------+--------------------------+----------------+ 238 | Segment duration | Duration in seconds | Per media | 239 | | | segment | 240 +-------------------+--------------------------+----------------+ 241 | Video encoding | Number of pixels (WxH) in| Per media | 242 | resolution | transmitted video | segment | 243 +-------------------+--------------------------+----------------+ 244 | Video codec and | One of: H264-baseline, | Per media | 245 | profile | H264-high, H264-main | segment | 246 +-------------------+--------------------------+----------------+ 247 | Type of each |"I" or "Non-I" | Per video | 248 | picture | | frame | 249 +-------------------+--------------------------+----------------+ 251 3.2. Intelligent Packet Dropping 253 3.2.1. Problem Statement 255 Backbone routers in the Internet are typically configured with 256 buffers that are several times larger than the product of the link 257 bandwidth and the typical round-trip delay on long network paths. 258 Such buffers can delay packets for as much as half a second during 259 congestion periods. When such large queues carry heavy TCP traffic 260 loads, and are serviced using the Tail-Drop policy, the large queues 261 remain close to full most of the time. Thus, even if each TCP flow 262 is able to obtain its share of the link bandwidth, the end-to-end 263 delay remains very high. This is exacerbated for flows with multiple 264 hops, since packets may experience high queuing delays at each hop. 266 In order to improve the performance, it is desirable for systems to 267 react to current channel conditions using rate adaptive transmission 268 technology. [I-D.you-tsvwg-latency-loss-tradeoff] enables an 269 application to request treatment for either low-loss or low-latency 270 at a congested network link. The objective is to retain the best- 271 effort service while providing low delay to real-time applications at 272 the expense of increased loss or providing low loss to non real-time 273 applications at the expense of increased delay. [DSL-IPD] makes use 274 of the fact that some packets containing video information (e.g., 275 I-picture or P-picture) are more important than others (e.g., 276 B-picture), and this importance level can be indicated in the packet 277 header. When congestion in the DSLAM occurs, the low priority 278 packets are preferentially dropped. [IPD] proposes to detect the 279 congestion by measuring the length of the queue. When the buffer 280 occupancy increases, the data packets are dropped depending on 281 priority assigned to the data packets. [IPD-TCP] presented DTDRR 282 (Dynamic Threshold DRR) and DSDRR (Discard State DRR) as alternatives 283 to QSDRR (Queue State DRR) that provide comparable performance, while 284 allowing packets to be discarded on arrival, saving memory bandwidth. 286 We consider the rate-delay tradeoffs under the assumption that a 287 small fraction of packets can be dropped. It shows that 288 intelligently dropping packets can dramatically improve the 289 performance in average delay if a non-zero packet drop rate can be 290 tolerated. 292 3.2.2. Information Exposed 294 When congestion is detected, intelligent packet dropping technique is 295 implemented to control congestion due to buffer overflow. The main 296 objective is to drop the packets based on priority, so that the 297 performance of the network is improved. 299 A consequence of these requirements is that packets with lower 300 priority are more likely to be dropped during bouts of congestion 301 than packets with high priority. For example, B-frames in video 302 transmissions are more likely to be dropped than I-frames when 303 congestion. 305 3.3. Network Congestion State Feedback 307 3.3.1. Problem Statement 309 Network congestion typically occurs in the form of router buffer 310 overflows, when network nodes are subjected to more traffic than they 311 are designed to handle. With the increasing range of speeds of links 312 and the wider use of networks for distributed computing, effective 313 control of the network load is becoming more important. The lack of 314 control may result in congestion loss and, with retransmissions, may 315 ultimately lead to congestion collapse. 317 Network components can be involved in congestion control either 318 implicitly or explicitly. In the former, their operation is 319 optimized by properly adjusting the values of a number of free- 320 selected parameters, to support the end-to-end congestion control. 321 In the latter, feedback signal are issued by explicit signal 322 mechanisms, which are typically realized in the network routers. The 323 network device exploits new bits in the packet header to convey 324 information regarding the path congestion status back to the 325 transmitting source, helping the congestion controller to make the 326 necessary decisions towards congestion avoidance. 328 [I-D.flinck-mobile-throughput-guidance] proposes that the cellular 329 network provides information on throughput guidance to the TCP 330 server; this information will indicate the throughput estimated to be 331 available at the radio downlink interface. The throughput guidance 332 information is added into the Options field of the TCP header of 333 packets from the TCP client to the TCP server. In our use case, for 334 example, if video is encoded in multiple bitrates, the application 335 server can select the appropriate encoding based on the network 336 conditions. Similar use case is also discussed in 337 [I-D.kuehlewind-spud-use-cases]. 339 3.3.2. Information Exposed 341 The interesting feature of explicit signaling scheme is the use of a 342 minimal amount of feedback from the network to users to enable them 343 to control the amount of traffic allowed into the network. The 344 routers in the network detect congestion and insert this information 345 into packets flowing in the forward direction. This information is 346 communicated back to the users by the destination that receives the 347 packets. This feedback information is examined by the user to 348 control the amount of traffic that is placed on the network, for 349 example by setting the control-related TCP properties. This 350 information enables switching of video quality to an appropriate bit- 351 rate based on the network congestion state, and preserving the 352 important visual information to be transmitted. 354 4. Security Considerations 356 Trust relationship between network and user is needed as the provided 357 information leads to the accuracy of the video MOS (section 4.1) or 358 differentiated operations by both sides (section 4.2 and 4.3). 360 5. IANA Considerations 362 This document has no actions for IANA. 364 6. References 366 6.1. Normative References 368 [ITU-T_P.1201] 369 "Recommendation ITU-T P.1201 (2012), Parametric non- 370 intrusive assessment of audiovisual media streaming 371 quality". 373 [ITU-T_P.1202] 374 "Recommendation ITU-T P.1202 (2012), Parametric non- 375 intrusive bitstream assessment of video media streaming 376 quality". 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 6.2. Informative References 385 [DSL-IPD] Van Caenegem, T., Struyve, K., Laevens, K., Vleeschauwer, 386 D., and R. Sharpe, "Maintaining video quality and 387 optimizing video delivery over the bandwidth constrained 388 DSL last mile through intelligent packet drop", Bell Labs 389 Technical Journal 13(1): 53-68, 2008. 391 [I-D.flinck-mobile-throughput-guidance] 392 Jain, A., Terzis, A., Flinck, H., Sprecher, N., 393 Swaminathan, S., and K. Smith, "Mobile Throughput Guidance 394 Inband Signaling Protocol", draft-flinck-mobile- 395 throughput-guidance-03 (work in progress), September 2015. 397 [I-D.kuehlewind-spud-use-cases] 398 Kuehlewind, M. and B. Trammell, "Use Cases for a Substrate 399 Protocol for User Datagrams (SPUD)", draft-kuehlewind- 400 spud-use-cases-01 (work in progress), March 2016. 402 [I-D.you-tsvwg-latency-loss-tradeoff] 403 You, J., Welzl, M., Trammell, B., Kuehlewind, M., and K. 404 Smith, "Latency Loss Tradeoff PHB Group", draft-you-tsvwg- 405 latency-loss-tradeoff-00 (work in progress), March 2016. 407 [IPD] Chakravarthi, R. and C. Gomathy, "IPD: Intelligent Packet 408 Dropping Algorithm for Congestion Control in Wireless 409 Sensor Network", Trendz in Information Sciences and 410 Computing (TISC2010) 2010, pp: 222-225, 2010. 412 [IPD-TCP] Kantawala, A. and J. Turner, "Intelligent Packet Discard 413 Policies for Improved TCP Queue Management", Technical 414 Report WUCSE-2003-41 , May 2003. 416 Author's Address 418 Jianjie You 419 Huawei 420 101 Software Avenue, Yuhua District 421 Nanjing 210012 422 China 424 Email: youjianjie@huawei.com