Internet DRAFT - draft-huang-fvn-use-cases
draft-huang-fvn-use-cases
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,
<http://www.rfc-editor.org/info/rfc2119>.
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]
