Network Working Group J. You
Internet-Draft Huawei
Intended status: Informational July 8, 2016
Expires: January 9, 2017
Use Cases for Video Transport
draft-you-use-cases-for-video-transport-00
Abstract
IP video traffic represents a large fraction of Internet traffic.
How to transmit video traffic efficiently poses traffic management
challenges to both network operators and Internet applications.
The traffic characteristics of encoded video have a significant
impact on the network transport. 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 January 9, 2017 [Page 1]
Internet-Draft Video Transport July 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 . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Video Service Experience Evaluation . . . . . . . . . . . 4
3.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 4
3.1.2. Information Exposed . . . . . . . . . . . . . . . . . 6
3.2. Intelligent Packet Dropping . . . . . . . . . . . . . . . 6
3.2.1. Problem Statement . . . . . . . . . . . . . . . . . . 6
3.2.2. Information Exposed . . . . . . . . . . . . . . . . . 7
3.3. Network Congestion State Feedback . . . . . . . . . . . . 7
3.3.1. Problem Statement . . . . . . . . . . . . . . . . . . 7
3.3.2. Information Exposed . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Video consumption has grown so fast that the bottleneck link is
congested during peak hours. 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. How to transmit video traffic efficiently
poses traffic management challenges to both network operators and
You Expires January 9, 2017 [Page 2]
Internet-Draft Video Transport July 2016
Internet applications. However, the existing video transport schemes
mainly treat the traffic data in a content agnostic fashion. Such
scheduling 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 provides use cases where network operator and Internet
application can be cooperative to improve video transmission
efficiency, based on the fundamental traffic characteristics, such as
frame types (e.g., I, P, or B), adaptive bit rate, etc. The problem
of optimizing the delivery of video content to clients while meeting
the constraints imposed by the available network resources is
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
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. Use Cases
You Expires January 9, 2017 [Page 3]
Internet-Draft Video Transport July 2016
3.1. Video Service Experience Evaluation
3.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 estimate video Mean Opinion Scores
(MOS). The video MOS model is applicable to progressive download and
adaptive streaming where the quality experienced by the end user is
affected by audio- and video-coding degradations, and delivery
degradations due to initial buffering, re-buffering (which are both
perceivable as stalling of the media), and media adaptations. A
media adaptation is where the player switches video playback between
a known set of media quality levels while adapting to network
conditions. Each of the quality levels typically differs in a
significant video or audio or audio/visual quality change. These
quality changes are most readily observed by changes in bitrate,
resolution, frame rate, and similar attributes.
For the models of estimating video MOS for UHD content, another
crucial scenario - fault localization for QoE degradation is also
considered. For example, 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.
You Expires January 9, 2017 [Page 4]
Internet-Draft Video Transport July 2016
-------------
///// \\\\\
// IPTV HeadEnd \\
| +------+ +------+ |
| |Server| |Server| |
| +------+ +------+ |
\\ //
+--------+ +--------+
| Router |-----| Router +--------------------+
+---+----* *-----+--+ |
| \ / | |
| X | |
| / \ | |
| / \ | |
| / \ | V
+---+---/+ +-\+-----+ +---------+
| Router +--------+ Router +-------------->|Video MOS|
+---+----+ +----+---+ | Center |
| | + --------+
| | ^ ^
| | | |
| | | |
+--+-----+ +-----+--+ | |
| Router |------| Router +-------------------+ |
+----\---+ +---/----+ |
// \ / \\ |
| \ / | |
| \ 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
You Expires January 9, 2017 [Page 5]
Internet-Draft Video Transport July 2016
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.
3.1.2. Information Exposed
The video MOS model will receive media information and prior
knowledge about the media stream or streams. In various modes of
operation, different inputs may be extracted or estimated in
different ways. For example, the video MOS model may need the
following input signals of operation:
Table 1: Video MOS Model Inputs Example
+-------------------+--------------------------+----------------+
| Description | Values | Frequency |
+-------------------+--------------------------+----------------+
| Segment duration | Duration in seconds | Per media |
| | | segment |
+-------------------+--------------------------+----------------+
| Video encoding | Number of pixels (WxH) in| Per media |
| resolution | transmitted video | segment |
+-------------------+--------------------------+----------------+
| Video codec and | One of: H264-baseline, | Per media |
| profile | H264-high, H264-main | segment |
+-------------------+--------------------------+----------------+
| Type of each |"I" or "Non-I" | Per video |
| picture | | frame |
+-------------------+--------------------------+----------------+
3.2. Intelligent Packet Dropping
3.2.1. Problem Statement
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 channel conditions using rate adaptive transmission
You Expires January 9, 2017 [Page 6]
Internet-Draft Video Transport July 2016
technology. [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 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.
3.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 priority, so that the
performance of the network is improved.
A consequence of these requirements is that packets with lower
priority are more likely to be dropped during bouts of congestion
than packets with high priority. For example, B-frames in video
transmissions are more likely to be dropped than I-frames when
congestion.
3.3. Network Congestion State Feedback
3.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. The lack of
control may result in congestion loss and, with retransmissions, may
ultimately lead to congestion collapse.
You Expires January 9, 2017 [Page 7]
Internet-Draft Video Transport July 2016
Network components can be involved in congestion control either
implicitly or explicitly. In the former, their operation is
optimized by properly adjusting the values of a number of free-
selected parameters, to support the end-to-end congestion control.
In the latter, feedback signal are issued by explicit signal
mechanisms, which are typically realized in the network routers. The
network device exploits new 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.
[I-D.flinck-mobile-throughput-guidance] proposes that the cellular
network provides information on throughput guidance to the TCP
server; this information will indicate the throughput estimated to be
available at the radio downlink interface. The throughput guidance
information is added into the Options field of the TCP header of
packets from the TCP client to the TCP server. In our use case, for
example, if video is encoded in multiple bitrates, the application
server can select the appropriate encoding based on the network
conditions. Similar use case is also discussed in
[I-D.kuehlewind-spud-use-cases].
3.3.2. Information Exposed
The interesting feature of explicit signaling scheme is the use of a
minimal amount of feedback from the network to users to enable them
to control the amount of traffic allowed into the network. 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 users by the destination that receives the
packets. This feedback information is examined by the user 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. 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).
5. IANA Considerations
This document has no actions for IANA.
You Expires January 9, 2017 [Page 8]
Internet-Draft Video Transport July 2016
6. References
6.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>.
6.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.
[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.
[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.
You Expires January 9, 2017 [Page 9]
Internet-Draft Video Transport July 2016
[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
Jianjie You
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: youjianjie@huawei.com
You Expires January 9, 2017 [Page 10]