Internet DRAFT - draft-mou-pcp-application-network-feedback
draft-mou-pcp-application-network-feedback
PCP Working Group H. Moustafa
Internet-Draft D. Moses
Intended status: Standards Track Intel Corporation
Expires: May 14, 2015 M. Boucadair
France Telecom
November 10, 2014
PCP Extension for Signaling Feedback Information from the End-User
Application to the Application Sever and to the Network
draft-mou-pcp-application-network-feedback-02
Abstract
Nowadays users consumption style for video and multimedia
applications is strongly changing. Users are consuming content
through multi-screen and are heavily counting on wireless and mobile
devices for video streaming and interactive video and multimedia
applications. This necessitates more intelligence in the service and
the network infrastructure to better suit a differentiated users
consumption style, which can be achieved through having: (i) a
knowledge in the network and service platform about the available
device and network conditions for the end-user and (ii) a knowledge
in the network about the content requirements in terms of devices
capabilities and network resources for content stored either in the
network or in the application server. To obtain such knowledge with
no need for changing the current infrastructure and in a generalized
way to all applications, feedback/notification mechanisms between the
end-user application, the network and the service platform is needed
to provide information helping the content delivery and adaptation
decisions. This document is investigating such application-agnostic
track.
This document extends the Port Control Protocol (PCP) RFC 6887
[RFC6887] to allow: (i) the users application to notify the network
and application server about its available resources in terms of
devices capabilities and network conditions as well as information
about the user (e.g., location, mobility status) and (ii) the
application server to notify the network about the requirements of
the content it stores in terms of devices and network resources. A
new PCP option, denoted the FEEDBACK, is specified to allow such
feedback notification signaling. This option is used with both PEER
and MAP Opcodes.
Moustafa, et al. Expires May 14, 2015 [Page 1]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
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 May 14, 2015.
Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Real-time Transcoding for Video Delivery Optimization . . 4
3.2. Content Adaptation during Content Mirroring to External
Display . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Optimization Examples . . . . . . . . . . . . . . . . . . 5
4. Why PCP? . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. FEEDBACK PCP Option . . . . . . . . . . . . . . . . . . . . . 7
5.1. PCP Request and Responses . . . . . . . . . . . . . . . . 8
6. Security Consideration . . . . . . . . . . . . . . . . . . . 10
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Moustafa, et al. Expires May 14, 2015 [Page 2]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Existing Protocols of Relevance to User's Feedback
Information and their Limitations . . . . . . . . . 13
1. Introduction
Nowadays, Internet traffic includes huge amount of video traffic
which is expected to highly dominate the Internet traffic in the
coming years. The users consumption style for video services is
strongly evolving towards a user-centric model enabling video
services access based on users profiles and making receiving device
(e.g., Laptops, tablets, smartphones, and future devices models)
constitute the majority of end-user devices for video services
through plenty of services over the Internet.
Although this big evolution, the network and service infrastructure
are not optimized enough to handle the content delivery and
adaptation function of the network resources, devices resources,
application and content requirements. As a result, Quality of
Experience (QoE) for video services and multimedia applications can
not be guaranteed in some situations.
This document defines an extension to the Port Control Protocol (PCP)
RFC 6887 [RFC6887] allowing: (i) the end-user application to signal
in real-time to the network and application server information about
its available device capabilities and network connectivities (e.g.,
support to different content bitrates, buffering status as an
indication of the network connectivity level) as well as other useful
context information (e.g., location, mobility status) and (ii) the
application server to signal in real-time to the network the
requirement of the content it stores in terms of devices and network
resources. The extension defines a new PCP option for the existing
PEER and MAP OpCodes: FEEDBACK Option for signaling information
between the end-users application, the network and the application
server.
Motivations to undertake this effort are discussed in Section 3
through a number of use cases, while justifications for the use of
PCP are elaborated in Section 4.
2. Terminology
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 RFC 2119 [RFC2119].
Moustafa, et al. Expires May 14, 2015 [Page 3]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
3. Use Cases
The new model for video services consumption over mobile and wireless
networks creates the need for feedback information between the end-
user application, the network and the service platform in real-time.
This helps optimizing the content for device/network resources on one
hand and end-user QoE and battery experience on the other hand. In
this view more intelligence needs to be considered in the network. A
way to do that is through having several service functions in the
network middle boxes on the path between the end-user and the
application server, as shown in Draft [ServiceFunctions], that could
be collocated with the NAT function or not. Examples of service
functions that we consider to better manage the video delivery are:
video optimization function (including transcoding), caching
capabilities, TCP optimizer, video controller allowing for example
content recommendation or intelligent scheduling in the case of
cellular networks. The following subsections present a use-case on
video delivery optimization using PCP signaling to provide feedback
information between the end-user application, the network and the
service platform:
3.1. Real-time Transcoding for Video Delivery Optimization
In this use-case, the end-users device is the host implementing the
PCP client and a middle box network node in the network (e.g. edge
router, home gateway or any cache node close to the user) is the PCP
server. This middle box node can store a copy of the content or can
be just a content relay from the application server to the end-user.
o If the middle box network node is only a relay, then it receives
the feedback information sent to the network by the end-user
application and by the application server and makes use of this
information for optimizing the content it relays to the end-user
through real-time transcoding. This allows the server to send one
version of content to the network node and this latter does real
time transcoding to several clients with different capabilities
connected to the edge router. The middle box network node can be
an edge router or home gateway supporting real-time transcoding
function.
o If the middle box network node stores a copy of the content, then
it makes use of the feedback information sent to the network by
the end-user application to optimize the stored content when
requested by the end-user before its delivery. This allows
optimizing the storage space through storing few presentations of
content and providing the necessary presentation on-demand through
real-time transcoding. The middle box network node can be a
Moustafa, et al. Expires May 14, 2015 [Page 4]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
network cache node, edge router or home gateway caching the
content and supporting real-time transcoding function.
3.2. Content Adaptation during Content Mirroring to External Display
In this use-case, the end-users device implements the PCP server and
the external display adaptor implements the PCP client. The former
can be a PC, tablet or Smartphone and the latter is the TV adaptor/
box receiving the content from the end-user device. The end user-
device mirrors the content to the TV screen through wireless WiDi,
Miracast, or Airplay.
o The TV adaptor (e.g. WiDi or Miracast receivers) makes use of the
feedback information to share the TV screen characteristics and
the wireless connectivity status. The end-user device uses this
information to optimize the mirrored content function of the TV
characteristics (e.g. screen resolution, frames per second, screen
refresh rate).
3.3. Optimization Examples
The following are some examples on how to optimize the content for
device and network resources on one hand and end-user QoE and battery
experience on the other hand.
o For a high display resolution, a video of high bitrate/resolution
is sent if the users application buffering level and the global
network bandwidth conditions are sufficient and the battery level
is sufficient.
o If the battery level degrades during the session even if the users
application buffering level remains sufficient, then the video is
continued to be streamed in lesser bitrate/resolution to save
battery and prevent video session interruption due to battery
failure (keeping a threshold on the quality based on the remaining
resources). In this case, lesser resources can be allocated for
cellular users to match the bandwidth required for the low bitrate
video.
o If the battery level is fine but the users application buffering
level and global network bandwidth conditions degrades, the video
switches to lower bitrate (following the ordinary adaptive
streaming approach), which in turns save in the battery level.
o For small size display, the transmission errors are less observed
by the user especially if the user is mobile and is in a noisy
environment and so video can be displayed with lesser quality
(bitrate) to save battery resources and network resources even if
the buffering level and global network bandwidth conditions are
not poor. This is much useful for content categories as news and
Moustafa, et al. Expires May 14, 2015 [Page 5]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
non-live content, in which transmission errors have lesser impact
on the users perception.
4. Why PCP?
The use of PCP to signal feedback/notification between the end-users
application, the network and service platform in real-time is
motivated by the following: In the Port Control Protocol (PCP)
specification RFC 6887 [RFC6887], PCP is viewed as a request/response
protocol and also as a hint/notification protocol between a PCP
client and a PCP server. Message flows in PCP are viewed as
independent streams carrying information between the PCP client and
the PCP server, in which the PCP client sends a stream of hints
indicating to its server its mapping status and the PCP server sends
to the client a notification informing the client on the actual state
of its mapping. In this view of the protocol, PCP can be extended to
carry more mapping information than the IP internal versus external
addresses. Draft [Flowdata] is an example of the use of PCP for
signaling by the client the flow characteristics to the network and
signaling by the network its ability to accommodate that flow back to
the client.
In addition, PCP allows learning and influencing the mapping
lifetime, which helps reducing network bandwidth, overload on
application servers and middle boxes and battery resources for
wireless and mobile devices. This makes PCP suitable for conveying
feedback information in our use-cases in real-time and resource wise
way.
Further advantages for PCP motivating its use are as follows:
o PCP can be used to install state in upstream devices such as NAT,
firewalls or other flow-aware devices.
o PCP can be used to notify a failure that may occur at an upstream
PCP-controlled device, and therefore the PCP client can react
accordingly.
o PCP allows learning the lifetime of installed mappings and would
therefore avoid overloading the network and service platform with
keepalive messages. This also saves the battery resources for
wireless and mobile end-user devices.
o PCP can be used to notify the network with the flow
characteristics so as to enforce policies at the access segment.
o PCP can be used to receive informative information from the
network so that client may use them to select the interface to use
to place a session.
o PCP can be extended easily to allow reporting capabilities to a
remote server.
Moustafa, et al. Expires May 14, 2015 [Page 6]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
o Extending PCP with the FEEDBACK feature avoids making assumptions
on how media streams are exchanged (e.g., RTP, IAX mini-frames,
etc.).
o PCP extension does not require an OS support. The feature can be
managed at the application level.
5. FEEDBACK PCP Option
This document presents an extension to PCP through the definition of
FEEDBACK option in PCP. The FEEDBACK option aims to signal feedback
information between the end-user application, the network and service
platform to help optimizing the network and devices resources and
enhancing the users experience. This feedback mechanism makes also
use of the PCP FLOWDATA option [Flowdata]. This means that the PCP
client sends both FLOWDATA and the FEEDBACK options in the same
requests.
The information signaled in the FEEDBACK Option may include the
screen size, screen resolution and battery level as device
capabilities information and the users location, environment type and
mobility status as context information on the user side. This
information is signaled once at the beginning of the session and can
be updated upon variation. Following the information signaling, the
PCP server uses the FEEDBACK option to signal its ability of
providing content with characteristics matching the device and
network resources as well as the user context. This information will
be used by the application server and by the network (through the
middle box network nodes having service functions) for optimized
content adaptation as explained in Section 3.
The FEEDBACK option does not make any assumption on the presence of
NAT and/or firewall. In particular, PCP-based mechanism to
instantiate state in an upstream NAT, firewall and any other flow-
aware device are not impacted by the use of FEEDBACK option.
The PCP client is implemented at the end-user device and the
application server (content server), and the PCP server is
implemented at the middle box network node storing the content and
the application server. The PCP client may be configured with
multiple IP addresses; each of them pointing to a distinct PCP
server. The PCP client will contact all these PCP server in parallel
as discussed in [I-D.ietf-pcp-server-selection].
A PCP Proxy [PCPProxy] functionality can be enabled in intermediate
nodes (e.g., Customer Premise Equipment (CPE)) on the path between
the PCP client and the PCP server.
Moustafa, et al. Expires May 14, 2015 [Page 7]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
Upon receipt of the FEEDBACK option by the PCP Server, its content is
passed to the Application Server that decides whether an action is
needed to serve the requesting client to better accommodate its
resources and conditions.
The procedure for generating a request that includes the FEEDBACK
option, handling a request that includes the FEEDBACK option, and
generating a response to a request that includes the FEEDBACK option
is similar to the behavior specified in [Flowdata].
Triggers to generate a request that capture the network conditions
and device recourses in a FLOWDATA and FEEDBACK options are local to
the application. How the application server or network middle boxes
makes use of the content of the FLOWDATA and FEEDBACK options is also
local to the PCP Server and to each the decision-making process at
the Application Server side or network middle box node.
5.1. PCP Request and Responses
The PCP client follows the steps of generating the PEER and MAP
opcodes request and response as described in [Flowdata]. The
FEEDBACK option is included in the request and response according to
the format described in this section.
Option Name: FEEDBACK
Number: to be assigned by IANA
Purpose: Describe to the network information on the end-user
application and user context (e.g., device characteristics,
buffering status as indication of the network conditions,
location, environment light/noise, mobility status), and
information on the content that can be provided by the application
server.
Valid for opcodes: PEER and MAP
Length: 16 Octets
May appear in: request. May appear in response only if it
appeared in the associated request
Maximum occurrences: 1
The FEEDBACK option request has the following format:
Moustafa, et al. Expires May 14, 2015 [Page 8]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option code=TBA|Reserved Option| Option Length= 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRPW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRPH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLS | SSz |MStat| Location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEEDBACK Option Request
The fields are described as follows:
o SRPW: Screen Resolution Pixels in Width, giving the number of
pixels in width for the screen. This field takes a value 0 if no
information/update is required to be sent.
o SRPH: Screen Resolution Pixels in Height, giving the number of
pixels in height for the screen. This field takes a value 0 if no
information/update is required to be sent.
o BLS: Battery Level Status. The following values are defined:
* 0 if no information/update is required to be sent
* 1= fading,
* 2= weak,
* 3= medium,
* 4 = high,
* 5= very high.
o SSz: Screen Size of the device. The following values are defined:
* 0 if no information/update is required to be sent,
* 1= very small,
* 2= small,
* 3= medium,
* 4= big,
* 5= very big.
o MStat: User activity and mobility status. The following values
are defined:
* 0 if no information/update is required to be sent
* 1 = static,
* 2 = weak mobility (e.g., walking),
* 3= regular mobility (e.g., running),
* 4 = high mobility (e.g., in train)
Moustafa, et al. Expires May 14, 2015 [Page 9]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
o Location: Gives the user location. This field takes a value 0 if
no information/update is required to be sent.
The FEEDBACK option response has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option code=TBA|Reserved Option| Option Length= 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP Server Notification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRPW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRPH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLS | SSz |MStat| Location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEEDBACK Option Response
The field PCP Server Notification shows the response status for the
sent request:
o 0= request cannot be satisfied,
o 1= the request can be partially satisfied,
o 2= the request can be satisfied,
o 3= the request can be fully satisfied.
The content of the remaining fields are echoed from the request.
6. Security Consideration
The security consideration for PCP in RFC 6887 [RFC6887] and the PCP
client authentication [PCPAuthentication] are sufficient to ensure
security and host authorization for the proposed PCP extension in
this document.
7. IANA Consideration
IANA is requested to assign a new PCP option called FEEDBACK in the
IANA registry for PCP [pcp-iana].
8. Acknowledgements
Thanks for Wu-Chi Feng and Muthaiah Venkatachalam who provided
valuable comments on this work. And thanks for Tirumaleswar Reddy
Moustafa, et al. Expires May 14, 2015 [Page 10]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
for all his comments and guidelines to prepare this version of the
draft.
9. References
9.1. Normative References
[I-D.ietf-pcp-server-selection]
Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
Reddy, "PCP Server Selection", draft-ietf-pcp-server-
selection-06 (work in progress), August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6887] Wing, D., "Port Control Protocol (PCP)", RFC 6887, April
2013.
9.2. Informative References
[Flowdata]
Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option",
draft-wing-pcp-flowdata-00 (work in progress), July 2013.
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-15 (work in
progress), October 2014.
[PCPAuthentication]
Wasserman, M., Hartman, S., and D. Zhang, "Port Control
Protocol (PCP) Authentication Mechanism", draft-ietf-pcp-
authentication-02 (work in progress), October 2013.
[PCPProxy]
Boucadair, M., Penno, R., and D. Ding, "Port Control
Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-03
(work in progress), June 2013.
[RFC2616] Fielding, R., "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2616, June 1999.
[RFC3840] Rosenberg, J., "Indicating User Agent Capabilities in
Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4566] Handley, M., "SDP: Session Description Protocol", RFC
4566, July 2006.
Moustafa, et al. Expires May 14, 2015 [Page 11]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
[ServiceFunctions]
Liu, W., Li, H., Huang, O., Boucadair, M., Leymann, N.,
Cao, Z., and J. Hu, "Service Function Chaining Use Cases",
draft-liu-sfc-use-cases-00 (work in progress), October
2013.
Moustafa, et al. Expires May 14, 2015 [Page 12]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
Appendix A. Existing Protocols of Relevance to User's Feedback
Information and their Limitations
Some existing protocols can convey devices characteristics and
information on the user, however with limited applicability.
Examples are:
o SIP [RFC3840]
* Provides a specification for capabilities and characteristics
in SIP User Agent (UA). Capabilities and characteristics
information is carried as parameters of the Contact header
field and can be used within REGISTER requests and responses,
OPTIONS responses, and requests and responses creating dialogs
(such as INVITE).
* SIP limitation for the explained use-cases: i) the need of
adding the SIP protocol stack in video streaming servers, ii)
SIP does not rely on network entities and is mainly an
application specific protocol, and iii) SIP is not appropriate
for "live" real-time control with no network priority to SIP
controls.
* Other Signalling protocols such as IAX are used to establish
media sessions.
o HTTP 1.1 [RFC2616] and HTTP2.0 [I-D.ietf-httpbis-http2]
* HTTP can incorporate information on the device and the user in
its headers (e.g. Accept or Use-Agent headers), however this
will not be a generic solution to any underlying transport
protocol.
* Also, HTTP by its nature is a stateless protocol and activating
HTTP proxy functionality impacts the performance of the network
which limits the communication through proxies.
o SDP [RFC4566]
* SDP is meant to provide a standard representation for session
description without incorporating a transport protocol, without
a focus on user's feedback information
* SDP is used for the session negotiation at the beginning of the
session and so for the devices characteristics and the user
information could not be directly signaled in real-time
Moustafa, et al. Expires May 14, 2015 [Page 13]
Internet-DraftPCP Extension for Signaling Feedback InformatNovember 2014
* SDP uses protocols as SIP and RTSP that are not intercepted by
middle nodes in the network which limits its applicability.
* SDP is not used in some non-SIP deployement contexts.
Authors' Addresses
Hassnaa Moustafa
Intel Corporation
Hillsboro, OR 97124
USA
EMail: hassnaa.moustafa@intel.com
Danny Moses
Intel Corporation
EMail: danny.moses@intel.com
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Moustafa, et al. Expires May 14, 2015 [Page 14]
