idnits 2.17.1 draft-huang-fvn-use-cases-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 (October 31, 2016) is 2727 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T P.1201' is mentioned on line 197, but not defined == Missing Reference: 'ITU-T P.1202' is mentioned on line 197, but not defined == Missing Reference: 'QoS' is mentioned on line 285, but not defined == Unused Reference: 'I-D.flinck-mobile-throughput-guidance' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'I-D.kuehlewind-spud-use-cases' is defined on line 447, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-flinck-mobile-throughput-guidance-03 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Huang 3 Intended Status: Informational J. You 4 Expires: May 4, 2017 Huawei 5 October 31, 2016 7 Problem Statement and Use Cases for Video Cooperation Transport 8 draft-huang-fvn-use-cases-00 10 Abstract 12 IP video traffic represents a large fraction of Internet traffic. 13 Current infrastructures are not prepared to deal with the increasing 14 amount of video traffic. How to transmit video traffic efficiently 15 poses traffic management challenges to both network operators and 16 Internet applications. 18 This document provides use cases where network operator and Internet 19 application can be cooperative to improve video transmission 20 efficiency, based on the fundamental traffic characteristics (e.g. 21 frame priority, adaptive bit rate, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Limitation of Current Approaches . . . . . . . . . . . . . . . 4 68 3.1. Content Agnostic . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Deep Packet Inspection (DPI) . . . . . . . . . . . . . . . 4 70 4. Use Cases for Video Cooperation Transport . . . . . . . . . . 4 71 4.1. Video Service Experience Evaluation . . . . . . . . . . . 4 72 4.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 5 73 4.1.2. Information Exposed . . . . . . . . . . . . . . . . . 6 74 4.1.3. Privacy Impact . . . . . . . . . . . . . . . . . . . . 6 75 4.2. Intelligent Packet Dropping . . . . . . . . . . . . . . . 6 76 4.2.1. Problem Statement . . . . . . . . . . . . . . . . . . 7 77 4.2.2. Information Exposed . . . . . . . . . . . . . . . . . 7 78 4.2.3. Privacy Impact . . . . . . . . . . . . . . . . . . . . 8 79 4.3. Network Congestion State Feedback . . . . . . . . . . . . 8 80 4.3.1. Problem Statement . . . . . . . . . . . . . . . . . . 8 81 4.3.2. Information Exposed . . . . . . . . . . . . . . . . . 9 82 4.3.3. Privacy Impact . . . . . . . . . . . . . . . . . . . . 9 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 91 Video consumption has grown so fast that bottleneck links can become 92 congestion much more easily with video traffic, as the impact in 93 terms of bandwidth used of a single video flow is usually much higher 94 than other traffic work loads. Globally, IP video traffic will be 82 95 percent of all IP traffic (both business and consumer) by 2020, up 96 from 70 percent in 2015. 4K Ultra HD technology is by itself a very 97 new trend in the overall electronics landscape, and the impact of it 98 is growing month by month. 4K content increases the demand for 99 network capacity greatly. According to [SD-364], the minimum 100 bandwidth for Basic 4K Video streaming is 15Mbps. This is almost two 101 times the requirement for Full High Definition (FHD), while Basic 8K 102 (at 50 Mbps) requires more than 6 times the FHD bandwidth. In 103 particular, future bandwidth demands for the emerging Virtual Reality 104 techniques are up to 1 Gbps, which are much higher than 4K or 8K UHD 105 streams. 107 How to transmit video traffic efficiently poses traffic management 108 challenges to both network operators and Internet applications. 109 Current existing video transport schemes mainly treat the traffic 110 data in a content agnostic fashion, or the usage of deep packet 111 inspection (DPI) is required in order to understand the nature of the 112 traffic. Such approaches cannot effectively exploit the limited 113 network resources to maximize the perceived quality as video 114 streaming is characterized by complex content parameters (e.g., frame 115 priority, decoding dependency, etc.). 117 This document explore the possibilities where network operator and 118 Internet application can be cooperative to improve video transmission 119 efficiency, based on the fundamental traffic characteristics, 120 adaptive bit rate, etc. Meanwhile, the problem of optimizing the 121 delivery of video content to clients while meeting the constraints 122 imposed by the available network resources is also considered. 124 2. Terminology 126 This section contains definitions for terms used frequently 127 throughout this document. 129 2.1. Abbreviations and acronyms 131 BRAS: Broadband Remote Access Server 133 DRR: Deficit Round Robin 135 HD: High-Definition 137 MOS: Mean Opinion Score 138 OLT: Optical Line Terminal 140 QoE: Quality of Experience 142 TCP: Transmission Control Protocol 144 2.2. Definitions 146 4K: known as Ultra HD or UHD, is used to describe a new high 147 resolution video format with a minimum resolution of 3840 x 2160 148 pixels in a 16 x 9 aspect ratio for any display. 150 3. Limitation of Current Approaches 152 3.1. Content Agnostic 154 Currently, video streaming techniques treat network as a "black box" 155 and do not make use of feedback that could come from the network. 156 Clients shift from one representation to another based on their own 157 observations, and they only observe the network state indirectly. If 158 several clients are competing for bandwidth, it is possible for them 159 to be locked in a vicious circle of switching representations. 160 Especially, when encryption is widely used in recent years due to 161 concerns about privacy. YouTube traffic is carried via HTTPS (or 162 QUIC) since 2014. 164 Content agnostic impacts current network services, such as policy 165 control, load balancing, QoS guarantee, etc. For example, 3GPP 166 networks have limited radio and transmission resources and need to 167 strictly schedule the utilization of radio and transmit resources 168 using different granularity of bearers to provide and ensure Quality 169 of Service (QoS) for the IP traffic. 171 3.2. Deep Packet Inspection (DPI) 173 DPI can solve the issue of content agnostic in some extend. It looks 174 at not only the header and footer of a packet, but also examines the 175 data part (content) of the packet searching for illegal statements 176 and predefined criteria, allowing a network devices to make a more 177 informed decision on whether or not to allow the packet through based 178 upon its content. However, it is computationally expensive, which 179 will greatly reduce the efficiency of network dealing with the 180 packets. And it becomes more and more challenging with the prevalence 181 of encrypted media. 183 4. Use Cases for Video Cooperation Transport 185 4.1. Video Service Experience Evaluation 186 4.1.1. Problem Statement 188 4K Ultra HD technology is by itself a very new trend in the overall 189 electronics landscape, and the impact of it is growing month by 190 month. As the increasing of the implementations of Ultra HD and to 191 keep the increasingly sophisticated customers content while remaining 192 profitable at the same time, it is important to design and manage the 193 video service based on the user quality of experience (QoE) to 194 provide attractive 4K video. Assessing the QoE of 4K video service 195 is therefore essential. 197 ITU-T Recommendations (see [ITU-T P.1201] and [ITU-T P.1202], for 198 instance) define the models to calculate estimated video quality 199 scores that are intended to correlate as closely as possible with 200 Mean Opinion Score (MOS) obtained from subjective survey methods. 201 These models are very useful for fault localization of QoE 202 degradation. In the scenario below, an IPTV provider can implement 203 video MOS models in their key network devices, such as core router, 204 BRAS (Broadband Remote Access Server), and OLT (Optical Line 205 Terminal), to locate where a QoE degradation fault happens in an IP 206 video network, as shown in figure 1. 208 ------------- 209 ///// \\\\\ 210 // IPTV HeadEnd \\ 211 | +------+ +------+ | 212 | |Server| |Server| | 213 | +------+ +------+ | 214 \\ // 215 +--------+ +--------+ 216 | Router |-----| Router +--------------------+ 217 +---+----* *-----+--+ | 218 | \ / | | 219 | X | | 220 | / \ | | 221 | / \ | | 222 | / \ | V 223 +---+---/+ +-\+-----+ +---------+ 224 | Router +--------+ Router +-------------->|Video MOS| 225 +---+----+ +----+---+ | Center | 226 | | + --------+ 227 | | ^ ^ 228 | | | | 229 | | | | 230 +--+-----+ +-----+--+ | | 231 | Router |------| Router +-------------------+ | 232 +----\---+ +---/----+ | 233 // \ / \\ | 235 | \ / | | 236 | \ Metro / | | 237 | \ / | | 238 | \ / | | 239 \\ \ / // | 240 \\\\ +-\/---+//// | 241 ---| BRAS +------------------------------+ 242 +-/--\-+ 243 / \ 244 / \ 245 / \ 246 / \ 247 / \ 248 / \ 249 +--/-------+ +---\------+ 250 |End Device| |End Device| 251 +----------+ +----------+ 253 Figure 1: Video MOS Deployment Example 255 In this use case, the video MOS probes may be deployed on some key 256 network points for monitoring of transmission quality for operations 257 and maintenance purposes. The network monitoring points are required 258 to provide video MOS to the video MOS control center. By estimating 259 the video MOS at different network monitoring points, it is possible 260 to perceive several diagnostic signals and reflect the location of 261 the impairments on the IP network being measured. 263 Traditional way is to implement the network probes in these network 264 points which uses DPI or heuristic method to extract the information 265 of the stream as the input of these models. However, these methods 266 are not efficient and accurate enough, especially the content is 267 encrypted. How to evaluate the HTTPS video is becoming a headache of 268 network providers. 270 4.1.2. Information Exposed 272 If video cooperation transport is considered, the media information 273 and prior knowledge about the media stream or streams which will be 274 the inputs for the video MOS model can be easily extracted. 276 4.1.3. Privacy Impact 278 Routers should have some mechanism to verify whether video MOS Model 279 inputs provided by application are accurate and dependable. 281 4.2. Intelligent Packet Dropping 282 4.2.1. Problem Statement 284 Different applications have different communication requirements 285 [QoS]. In interactive applications of real-time video transmission, 286 as well as in virtual reality, the overall one-way delay needs to be 287 short in order to give the user an impression of a real-time 288 response. Yet, these applications may be able to tolerate high loss 289 rates. In conventional text and data networking, delay thresholds 290 are the least stringent. The response time in these types of 291 applications can increase from 2 to 5 seconds before becoming 292 unacceptable. However, given that increased loss reduces the 293 throughput of TCP, these applications desire minimal loss. 295 Backbone routers in the Internet are typically configured with 296 buffers that are several times larger than the product of the link 297 bandwidth and the typical round-trip delay on long network paths. 298 Such buffers can delay packets for as much as half a second during 299 congestion periods. When such large queues carry heavy TCP traffic 300 loads, and are serviced using the Tail-Drop policy, the large queues 301 remain close to full most of the time. Thus, even if each TCP flow 302 is able to obtain its share of the link bandwidth, the end-to-end 303 delay remains very high. This is exacerbated for flows with multiple 304 hops, since packets may experience high queuing delays at each hop. 306 In order to improve the performance, it is desirable for systems to 307 react to current stream conditions using rate adaptive transmission 308 technology. 310 4.2.2. Information Exposed 312 When congestion is detected, intelligent packet dropping technique is 313 implemented to control congestion due to buffer overflow. The main 314 objective is to drop the packets based on the policy made from the 315 information that the application exposed, so that the performance of 316 the network is improved. 318 [I-D.you-tsvwg-latency-loss-tradeoff] enables an application to 319 request treatment for either low-loss or low-latency at a congested 320 network link. The objective is to retain the best- effort service 321 while providing low delay to real-time applications at the expense of 322 increased loss or providing low loss to non real-time applications at 323 the expense of increased delay. [DSL-IPD] makes use of the fact that 324 some packets containing video information (e.g., I-picture or P- 325 picture) are more important than others (e.g., B-picture), and this 326 importance level can be indicated in the packet header. When 327 congestion in the DSLAM occurs, the low priority packets are 328 preferentially dropped. [IPD] proposes to detect the congestion by 329 measuring the length of the queue. When the buffer occupancy 330 increases, the data packets are dropped depending on priority 331 assigned to the data packets. [IPD-TCP] presented DTDRR (Dynamic 332 Threshold DRR) and DSDRR (Discard State DRR) as alternatives to QSDRR 333 (Queue State DRR) that provide comparable performance, while allowing 334 packets to be discarded on arrival, saving memory bandwidth. 336 We consider the rate-delay tradeoffs under the assumption that a 337 small fraction of packets can be dropped. It shows that 338 intelligently dropping packets can dramatically improve the 339 performance in average delay if a non-zero packet drop rate can be 340 tolerated. 342 4.2.3. Privacy Impact 344 Routers should have some mechanism to verify whether the information 345 exposed by the application is accurate and dependable. 347 4.3. Network Congestion State Feedback 349 4.3.1. Problem Statement 351 Network congestion typically occurs in the form of router buffer 352 overflows, when network nodes are subjected to more traffic than they 353 are designed to handle. With the increasing range of speeds of links 354 and the wider use of networks for distributed computing, effective 355 control of the network load is becoming more important. 357 Current video transported by HTTP uses adapts the network congestions 358 by the receivers switch video playback requests between a known set 359 of media quality levels based on network conditions. This depends on 360 the receiver to detect the network congestion, which is not accurate 361 enough and timely. 363 Network components can be involved in congestion control either 364 implicitly or explicitly. In the former, their operation is 365 optimized by properly adjusting the configured buffers to support the 366 end-to-end congestion control. Implicit mechanisms are realized via 367 AQM techniques. In the latter, a feedback signal is issued by an 368 explicit signal mechanism (e.g., ECN), which exploits the bits in the 369 packet header to convey information regarding the path congestion 370 status back to the transmitting source, helping the congestion 371 controller to make the necessary decisions towards congestion 372 avoidance. 374 Most explicit congestion feedback mechanisms work at the transport 375 layer or IP layer, which has two limitations: Firstly, some network 376 nodes may not support such mechanisms and may remove the explicit 377 information completely. This will make the congestion control fail 378 down. Secondly, the end users may need to update their operation 379 systems to support such feedbacks. 381 4.3.2. Information Exposed 383 The routers in the network detect congestion and insert this 384 information into packets flowing in the forward direction. This 385 information is communicated back to the sender by the destination 386 that receives the packets. This feedback information is examined by 387 the sender to control the amount of traffic that is placed on the 388 network, for example by setting the control-related TCP properties. 389 This information enables switching of video quality to an appropriate 390 bit-rate based on the network congestion state, and preserving the 391 important visual information to be transmitted. 393 4.3.3. Privacy Impact 395 Endpoints should have some mechanisms to verify whether network state 396 information is accurate. The exposed information can be used as hints 397 for rate determination. 399 5. Security Considerations 401 Trust relationship between network and user is needed as the provided 402 information leads to the accuracy of the video MOS (section 4.1) or 403 differentiated operations by both sides (section 4.2 and 4.3). 405 6. IANA Considerations 407 This document has no actions for IANA. 409 7. References 411 7.1. Normative References 413 [ITU-T_P.1201] 414 "Recommendation ITU-T P.1201 (2012), Parametric non- 415 intrusive assessment of audiovisual media streaming 416 quality". 418 [ITU-T_P.1202] 419 "Recommendation ITU-T P.1202 (2012), Parametric non- 420 intrusive bitstream assessment of video media streaming 421 quality". 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 7.2. Informative References 430 [DSL-IPD] Van Caenegem, T., Struyve, K., Laevens, K., Vleeschauwer, 431 D., and R. Sharpe, "Maintaining video quality and 432 optimizing video delivery over the bandwidth constrained 433 DSL last mile through intelligent packet drop", Bell Labs 434 Technical Journal 13(1): 53-68, 2008. 436 [SD-364] Karagiannis, G., Thorp, O., and J. Hu, "Impact Analysis 437 and Requirements for 4K (UHD) Video Support", 438 https://www.broadband-forum.org/bin/c5i?mid=4&rid=7&gid=0 439 &k1=48005&k3=4&tid=1476790705, October 2016. 441 [I-D.flinck-mobile-throughput-guidance] 442 Jain, A., Terzis, A., Flinck, H., Sprecher, N., 443 Swaminathan, S., and K. Smith, "Mobile Throughput Guidance 444 Inband Signaling Protocol", draft-flinck-mobile- 445 throughput-guidance-03 (work in progress), September 2015. 447 [I-D.kuehlewind-spud-use-cases] 448 Kuehlewind, M. and B. Trammell, "Use Cases for a Substrate 449 Protocol for User Datagrams (SPUD)", draft-kuehlewind- 450 spud-use-cases-01 (work in progress), March 2016. 452 [I-D.you-tsvwg-latency-loss-tradeoff] 453 You, J., Welzl, M., Trammell, B., Kuehlewind, M., and K. 454 Smith, "Latency Loss Tradeoff PHB Group", draft-you-tsvwg- 455 latency-loss-tradeoff-00 (work in progress), March 2016. 457 [IPD] Chakravarthi, R. and C. Gomathy, "IPD: Intelligent Packet 458 Dropping Algorithm for Congestion Control in Wireless 459 Sensor Network", Trendz in Information Sciences and 460 Computing (TISC2010) 2010, pp: 222-225, 2010. 462 [IPD-TCP] Kantawala, A. and J. Turner, "Intelligent Packet Discard 463 Policies for Improved TCP Queue Management", Technical 464 Report WUCSE-2003-41 , May 2003. 466 Author's Address 468 Rachel Huang 469 Huawei 470 101 Software Avenue, Yuhua District 471 Nanjing 210012 472 China 474 Email: rachel.huang@huawei.com 476 Jianjie You 477 Huawei 478 101 Software Avenue, Yuhua District 479 Nanjing 210012 480 China 482 Email: youjianjie@huawei.com