INTERNET-DRAFT R. Huang Intended Status: Informational J. You Expires: May 4, 2017 Huawei October 31, 2016 Problem Statement and Use Cases for Video Cooperation Transport draft-huang-fvn-use-cases-00 Abstract IP video traffic represents a large fraction of Internet traffic. Current infrastructures are not prepared to deal with the increasing amount of video traffic. How to transmit video traffic efficiently poses traffic management challenges to both network operators and Internet applications. This document provides use cases where network operator and Internet application can be cooperative to improve video transmission efficiency, based on the fundamental traffic characteristics (e.g. frame priority, adaptive bit rate, etc.). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2017. You Expires May 4, 2017 [Page 1] Internet-Draft Video Transport October 31, 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Abbreviations and acronyms . . . . . . . . . . . . . . . . 3 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Limitation of Current Approaches . . . . . . . . . . . . . . . 4 3.1. Content Agnostic . . . . . . . . . . . . . . . . . . . . . 4 3.2. Deep Packet Inspection (DPI) . . . . . . . . . . . . . . . 4 4. Use Cases for Video Cooperation Transport . . . . . . . . . . 4 4.1. Video Service Experience Evaluation . . . . . . . . . . . 4 4.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 5 4.1.2. Information Exposed . . . . . . . . . . . . . . . . . 6 4.1.3. Privacy Impact . . . . . . . . . . . . . . . . . . . . 6 4.2. Intelligent Packet Dropping . . . . . . . . . . . . . . . 6 4.2.1. Problem Statement . . . . . . . . . . . . . . . . . . 7 4.2.2. Information Exposed . . . . . . . . . . . . . . . . . 7 4.2.3. Privacy Impact . . . . . . . . . . . . . . . . . . . . 8 4.3. Network Congestion State Feedback . . . . . . . . . . . . 8 4.3.1. Problem Statement . . . . . . . . . . . . . . . . . . 8 4.3.2. Information Exposed . . . . . . . . . . . . . . . . . 9 4.3.3. Privacy Impact . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction You Expires May 4, 2017 [Page 2] Internet-Draft Video Transport October 31, 2016 Video consumption has grown so fast that bottleneck links can become congestion much more easily with video traffic, as the impact in terms of bandwidth used of a single video flow is usually much higher than other traffic work loads. Globally, IP video traffic will be 82 percent of all IP traffic (both business and consumer) by 2020, up from 70 percent in 2015. 4K Ultra HD technology is by itself a very new trend in the overall electronics landscape, and the impact of it is growing month by month. 4K content increases the demand for network capacity greatly. According to [SD-364], the minimum bandwidth for Basic 4K Video streaming is 15Mbps. This is almost two times the requirement for Full High Definition (FHD), while Basic 8K (at 50 Mbps) requires more than 6 times the FHD bandwidth. In particular, future bandwidth demands for the emerging Virtual Reality techniques are up to 1 Gbps, which are much higher than 4K or 8K UHD streams. How to transmit video traffic efficiently poses traffic management challenges to both network operators and Internet applications. Current existing video transport schemes mainly treat the traffic data in a content agnostic fashion, or the usage of deep packet inspection (DPI) is required in order to understand the nature of the traffic. Such approaches cannot effectively exploit the limited network resources to maximize the perceived quality as video streaming is characterized by complex content parameters (e.g., frame priority, decoding dependency, etc.). This document explore the possibilities where network operator and Internet application can be cooperative to improve video transmission efficiency, based on the fundamental traffic characteristics, adaptive bit rate, etc. Meanwhile, the problem of optimizing the delivery of video content to clients while meeting the constraints imposed by the available network resources is also considered. 2. Terminology This section contains definitions for terms used frequently throughout this document. 2.1. Abbreviations and acronyms BRAS: Broadband Remote Access Server DRR: Deficit Round Robin HD: High-Definition MOS: Mean Opinion Score You Expires May 4, 2017 [Page 3] Internet-Draft Video Transport October 31, 2016 OLT: Optical Line Terminal QoE: Quality of Experience TCP: Transmission Control Protocol 2.2. Definitions 4K: known as Ultra HD or UHD, is used to describe a new high resolution video format with a minimum resolution of 3840 x 2160 pixels in a 16 x 9 aspect ratio for any display. 3. Limitation of Current Approaches 3.1. Content Agnostic Currently, video streaming techniques treat network as a "black box" and do not make use of feedback that could come from the network. Clients shift from one representation to another based on their own observations, and they only observe the network state indirectly. If several clients are competing for bandwidth, it is possible for them to be locked in a vicious circle of switching representations. Especially, when encryption is widely used in recent years due to concerns about privacy. YouTube traffic is carried via HTTPS (or QUIC) since 2014. Content agnostic impacts current network services, such as policy control, load balancing, QoS guarantee, etc. For example, 3GPP networks have limited radio and transmission resources and need to strictly schedule the utilization of radio and transmit resources using different granularity of bearers to provide and ensure Quality of Service (QoS) for the IP traffic. 3.2. Deep Packet Inspection (DPI) DPI can solve the issue of content agnostic in some extend. It looks at not only the header and footer of a packet, but also examines the data part (content) of the packet searching for illegal statements and predefined criteria, allowing a network devices to make a more informed decision on whether or not to allow the packet through based upon its content. However, it is computationally expensive, which will greatly reduce the efficiency of network dealing with the packets. And it becomes more and more challenging with the prevalence of encrypted media. 4. Use Cases for Video Cooperation Transport 4.1. Video Service Experience Evaluation You Expires May 4, 2017 [Page 4] Internet-Draft Video Transport October 31, 2016 4.1.1. Problem Statement 4K Ultra HD technology is by itself a very new trend in the overall electronics landscape, and the impact of it is growing month by month. As the increasing of the implementations of Ultra HD and to keep the increasingly sophisticated customers content while remaining profitable at the same time, it is important to design and manage the video service based on the user quality of experience (QoE) to provide attractive 4K video. Assessing the QoE of 4K video service is therefore essential. ITU-T Recommendations (see [ITU-T P.1201] and [ITU-T P.1202], for instance) define the models to calculate estimated video quality scores that are intended to correlate as closely as possible with Mean Opinion Score (MOS) obtained from subjective survey methods. These models are very useful for fault localization of QoE degradation. In the scenario below, an IPTV provider can implement video MOS models in their key network devices, such as core router, BRAS (Broadband Remote Access Server), and OLT (Optical Line Terminal), to locate where a QoE degradation fault happens in an IP video network, as shown in figure 1. ------------- ///// \\\\\ // IPTV HeadEnd \\ | +------+ +------+ | | |Server| |Server| | | +------+ +------+ | \\ // +--------+ +--------+ | Router |-----| Router +--------------------+ +---+----* *-----+--+ | | \ / | | | X | | | / \ | | | / \ | | | / \ | V +---+---/+ +-\+-----+ +---------+ | Router +--------+ Router +-------------->|Video MOS| +---+----+ +----+---+ | Center | | | + --------+ | | ^ ^ | | | | | | | | +--+-----+ +-----+--+ | | | Router |------| Router +-------------------+ | +----\---+ +---/----+ | // \ / \\ | You Expires May 4, 2017 [Page 5] Internet-Draft Video Transport October 31, 2016 | \ / | | | \ Metro / | | | \ / | | | \ / | | \\ \ / // | \\\\ +-\/---+//// | ---| BRAS +------------------------------+ +-/--\-+ / \ / \ / \ / \ / \ / \ +--/-------+ +---\------+ |End Device| |End Device| +----------+ +----------+ Figure 1: Video MOS Deployment Example In this use case, the video MOS probes may be deployed on some key network points for monitoring of transmission quality for operations and maintenance purposes. The network monitoring points are required to provide video MOS to the video MOS control center. By estimating the video MOS at different network monitoring points, it is possible to perceive several diagnostic signals and reflect the location of the impairments on the IP network being measured. Traditional way is to implement the network probes in these network points which uses DPI or heuristic method to extract the information of the stream as the input of these models. However, these methods are not efficient and accurate enough, especially the content is encrypted. How to evaluate the HTTPS video is becoming a headache of network providers. 4.1.2. Information Exposed If video cooperation transport is considered, the media information and prior knowledge about the media stream or streams which will be the inputs for the video MOS model can be easily extracted. 4.1.3. Privacy Impact Routers should have some mechanism to verify whether video MOS Model inputs provided by application are accurate and dependable. 4.2. Intelligent Packet Dropping You Expires May 4, 2017 [Page 6] Internet-Draft Video Transport October 31, 2016 4.2.1. Problem Statement Different applications have different communication requirements [QoS]. In interactive applications of real-time video transmission, as well as in virtual reality, the overall one-way delay needs to be short in order to give the user an impression of a real-time response. Yet, these applications may be able to tolerate high loss rates. In conventional text and data networking, delay thresholds are the least stringent. The response time in these types of applications can increase from 2 to 5 seconds before becoming unacceptable. However, given that increased loss reduces the throughput of TCP, these applications desire minimal loss. Backbone routers in the Internet are typically configured with buffers that are several times larger than the product of the link bandwidth and the typical round-trip delay on long network paths. Such buffers can delay packets for as much as half a second during congestion periods. When such large queues carry heavy TCP traffic loads, and are serviced using the Tail-Drop policy, the large queues remain close to full most of the time. Thus, even if each TCP flow is able to obtain its share of the link bandwidth, the end-to-end delay remains very high. This is exacerbated for flows with multiple hops, since packets may experience high queuing delays at each hop. In order to improve the performance, it is desirable for systems to react to current stream conditions using rate adaptive transmission technology. 4.2.2. Information Exposed When congestion is detected, intelligent packet dropping technique is implemented to control congestion due to buffer overflow. The main objective is to drop the packets based on the policy made from the information that the application exposed, so that the performance of the network is improved. [I-D.you-tsvwg-latency-loss-tradeoff] enables an application to request treatment for either low-loss or low-latency at a congested network link. The objective is to retain the best- effort service while providing low delay to real-time applications at the expense of increased loss or providing low loss to non real-time applications at the expense of increased delay. [DSL-IPD] makes use of the fact that some packets containing video information (e.g., I-picture or P- picture) are more important than others (e.g., B-picture), and this importance level can be indicated in the packet header. When congestion in the DSLAM occurs, the low priority packets are preferentially dropped. [IPD] proposes to detect the congestion by measuring the length of the queue. When the buffer occupancy You Expires May 4, 2017 [Page 7] Internet-Draft Video Transport October 31, 2016 increases, the data packets are dropped depending on priority assigned to the data packets. [IPD-TCP] presented DTDRR (Dynamic Threshold DRR) and DSDRR (Discard State DRR) as alternatives to QSDRR (Queue State DRR) that provide comparable performance, while allowing packets to be discarded on arrival, saving memory bandwidth. We consider the rate-delay tradeoffs under the assumption that a small fraction of packets can be dropped. It shows that intelligently dropping packets can dramatically improve the performance in average delay if a non-zero packet drop rate can be tolerated. 4.2.3. Privacy Impact Routers should have some mechanism to verify whether the information exposed by the application is accurate and dependable. 4.3. Network Congestion State Feedback 4.3.1. Problem Statement Network congestion typically occurs in the form of router buffer overflows, when network nodes are subjected to more traffic than they are designed to handle. With the increasing range of speeds of links and the wider use of networks for distributed computing, effective control of the network load is becoming more important. Current video transported by HTTP uses adapts the network congestions by the receivers switch video playback requests between a known set of media quality levels based on network conditions. This depends on the receiver to detect the network congestion, which is not accurate enough and timely. Network components can be involved in congestion control either implicitly or explicitly. In the former, their operation is optimized by properly adjusting the configured buffers to support the end-to-end congestion control. Implicit mechanisms are realized via AQM techniques. In the latter, a feedback signal is issued by an explicit signal mechanism (e.g., ECN), which exploits the bits in the packet header to convey information regarding the path congestion status back to the transmitting source, helping the congestion controller to make the necessary decisions towards congestion avoidance. Most explicit congestion feedback mechanisms work at the transport layer or IP layer, which has two limitations: Firstly, some network nodes may not support such mechanisms and may remove the explicit You Expires May 4, 2017 [Page 8] Internet-Draft Video Transport October 31, 2016 information completely. This will make the congestion control fail down. Secondly, the end users may need to update their operation systems to support such feedbacks. 4.3.2. Information Exposed The routers in the network detect congestion and insert this information into packets flowing in the forward direction. This information is communicated back to the sender by the destination that receives the packets. This feedback information is examined by the sender to control the amount of traffic that is placed on the network, for example by setting the control-related TCP properties. This information enables switching of video quality to an appropriate bit-rate based on the network congestion state, and preserving the important visual information to be transmitted. 4.3.3. Privacy Impact Endpoints should have some mechanisms to verify whether network state information is accurate. The exposed information can be used as hints for rate determination. 5. Security Considerations Trust relationship between network and user is needed as the provided information leads to the accuracy of the video MOS (section 4.1) or differentiated operations by both sides (section 4.2 and 4.3). 6. IANA Considerations This document has no actions for IANA. You Expires May 4, 2017 [Page 9] Internet-Draft Video Transport October 31, 2016 7. References 7.1. Normative References [ITU-T_P.1201] "Recommendation ITU-T P.1201 (2012), Parametric non- intrusive assessment of audiovisual media streaming quality". [ITU-T_P.1202] "Recommendation ITU-T P.1202 (2012), Parametric non- intrusive bitstream assessment of video media streaming quality". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [DSL-IPD] Van Caenegem, T., Struyve, K., Laevens, K., Vleeschauwer, D., and R. Sharpe, "Maintaining video quality and optimizing video delivery over the bandwidth constrained DSL last mile through intelligent packet drop", Bell Labs Technical Journal 13(1): 53-68, 2008. [SD-364] Karagiannis, G., Thorp, O., and J. Hu, "Impact Analysis and Requirements for 4K (UHD) Video Support", https://www.broadband-forum.org/bin/c5i?mid=4&rid=7&gid=0 &k1=48005&k3=4&tid=1476790705, October 2016. [I-D.flinck-mobile-throughput-guidance] Jain, A., Terzis, A., Flinck, H., Sprecher, N., Swaminathan, S., and K. Smith, "Mobile Throughput Guidance Inband Signaling Protocol", draft-flinck-mobile- throughput-guidance-03 (work in progress), September 2015. [I-D.kuehlewind-spud-use-cases] Kuehlewind, M. and B. Trammell, "Use Cases for a Substrate Protocol for User Datagrams (SPUD)", draft-kuehlewind- spud-use-cases-01 (work in progress), March 2016. [I-D.you-tsvwg-latency-loss-tradeoff] You, J., Welzl, M., Trammell, B., Kuehlewind, M., and K. Smith, "Latency Loss Tradeoff PHB Group", draft-you-tsvwg- latency-loss-tradeoff-00 (work in progress), March 2016. You Expires May 4, 2017 [Page 10] Internet-Draft Video Transport October 31, 2016 [IPD] Chakravarthi, R. and C. Gomathy, "IPD: Intelligent Packet Dropping Algorithm for Congestion Control in Wireless Sensor Network", Trendz in Information Sciences and Computing (TISC2010) 2010, pp: 222-225, 2010. [IPD-TCP] Kantawala, A. and J. Turner, "Intelligent Packet Discard Policies for Improved TCP Queue Management", Technical Report WUCSE-2003-41 , May 2003. Author's Address Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China Email: rachel.huang@huawei.com Jianjie You Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China Email: youjianjie@huawei.com You Expires May 4, 2017 [Page 11]