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.

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
• 2. Terminology
• 3. Use Cases
• 3.1. Real-time Transcoding for Video Delivery Optimization
• 3.2. Content Adaptation during Content Mirroring to External Display
• 3.3. Optimization Examples
• 4. Why PCP?
• 5. FEEDBACK PCP Option
• 5.1. PCP Request and Responses
• 6. Security Consideration
• 7. IANA Consideration
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Existing Protocols of Relevance to User’s Feedback Information and their Limitations

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].

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.

• 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.
• 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 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.

• 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.

• 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.
• 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.
• 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.
• 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 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:

• PCP can be used to install state in upstream devices such as NAT, firewalls or other flow-aware devices.
• 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.
• 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.
• PCP can be used to notify the network with the flow characteristics so as to enforce policies at the access segment.
• 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.
• PCP can be extended easily to allow reporting capabilities to a remote server.
• Extending PCP with the FEEDBACK feature avoids making assumptions on how media streams are exchanged (e.g., RTP, IAX mini-frames, etc.).
• 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.

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

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                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  

  
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                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+