<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-mou-pcp-application-network-feedback-02"
     ipr="trust200902">
  <front>
    <title>PCP Extension for Signaling Feedback Information from the End-User
    Application to the Application Sever and to the Network</title>

    <author fullname="Hassnaa Moustafa" initials="H." surname="Moustafa">
      <organization>Intel Corporation</organization>

      <address>
        <postal>
          <street></street>

          <city>Hillsboro, OR</city>

          <code>97124</code>

          <country>USA</country>
        </postal>

        <email>hassnaa.moustafa@intel.com</email>
      </address>
    </author>

    <author fullname="Danny Moses" initials="D." surname="Moses">
      <organization>Intel Corporation</organization>

      <address>
        <email>danny.moses@intel.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date year="2014" />

    <area>Internet</area>

    <workgroup>PCP Working Group</workgroup>

    <keyword>PCP</keyword>

    <keyword>UserNetworkFeedback</keyword>

    <keyword>ApplicationNetworkFeedback</keyword>

    <abstract>
      <t>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.</t>

      <t>This document extends the Port Control Protocol (PCP) <xref
      target="RFC6887">RFC 6887</xref> 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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>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.</t>

      <t>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.</t>

      <t>This document defines an extension to the Port Control Protocol (PCP)
      <xref target="RFC6887">RFC 6887</xref> 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.</t>

      <t>Motivations to undertake this effort are discussed in <xref
      target="UseCases"></xref> through a number of use cases, while justifications for the use of PCP are
      elaborated in <xref target="Motivation"></xref>.</t>
    </section>

    <section title="Terminology">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section anchor="UseCases" title="Use Cases">
      <t>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 <xref
      target="ServiceFunctions"></xref>, 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:</t>

      <section title="Real-time Transcoding for Video Delivery Optimization">
        <t>
          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.
          <list style="symbols">
            <t>
              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.
            </t>
            <t>
              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.
            </t>

          </list>
        </t>
      </section>

      <section title="Content Adaptation during Content Mirroring to External Display">
        <t>
          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.
          <list style="symbols">
            <t>
              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).
            </t>
          </list>
        </t>
      </section>

      <section title="Optimization Examples">
        <t>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. <?rfc subcompact="yes" ?><list
            style="symbols">
            <t>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.</t>

            <t>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.</t>

            <t>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.</t>

            <t>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.</t>

      </list></t>
      </section>
    </section>

    <section anchor="Motivation" title="Why PCP?">
      <t>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 <xref
      target="RFC6887">RFC 6887</xref>, 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 <xref
      target="Flowdata"></xref> 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.</t>

      <t>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.</t>

      <t>Further advantages for PCP motivating its use are as follows: <?rfc subcompact="yes" ?><list
          style="symbols">
          <t>PCP can be used to install state in upstream devices such as NAT,
          firewalls or other flow-aware devices.</t>

          <t>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.</t>

          <t>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.</t>

          <t>PCP can be used to notify the network with the flow
          characteristics so as to enforce policies at the access segment.</t>

          <t>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.</t>

          <t>PCP can be extended easily to allow reporting capabilities to a
          remote server.</t>

          <t>Extending PCP with the FEEDBACK feature avoids making assumptions
          on how media streams are exchanged (e.g., RTP, IAX mini-frames,
          etc.).</t>

          <t>PCP extension does not require an OS support. The feature can be
          managed at the application level.<?rfc subcompact="no" ?></t>
        </list></t>
    </section>

    <section anchor="PCPExtension" title="FEEDBACK PCP Option">
      <t>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 <xref target="Flowdata"></xref>. This means
      that the PCP client sends both FLOWDATA and the FEEDBACK options in the
      same requests.</t>

      <t>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 <xref target="UseCases"></xref>.</t>

      <t>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. </t>

      <t>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 <xref
      target="I-D.ietf-pcp-server-selection"></xref>.</t>

      <t>A PCP Proxy <xref target="PCPProxy"></xref> functionality can be
      enabled in intermediate nodes (e.g., Customer Premise Equipment (CPE))
      on the path between the PCP client and the PCP server.</t>

      <t>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.</t>

      <t>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 <xref
      target="Flowdata"></xref>.</t>

      <t>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.</t>

      <section anchor="RequestsandResponses" title="PCP Request and Responses">
        <t>The PCP client follows the steps of generating the PEER and MAP
        opcodes request and response as described in <xref
        target="Flowdata"></xref>. The FEEDBACK option is included in the
        request and response according to the format described in this
        section. <?rfc subcompact="yes" ?><list style="empty">
            <t>Option Name: FEEDBACK</t>

            <t>Number: to be assigned by IANA</t>

            <t>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.</t>

            <t>Valid for opcodes: PEER and MAP</t>

            <t>Length: 16 Octets</t>

            <t>May appear in: request. May appear in response only if it
            appeared in the associated request</t>

            <t>Maximum occurrences: 1<?rfc subcompact="no" ?></t>
          </list></t>

        <t>The FEEDBACK option request has the following format: <figure
            anchor="format" title="FEEDBACK Option Request">
            <artwork type="inline"><![CDATA[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                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ]]></artwork>
          </figure> The fields are described as follows: <?rfc subcompact="yes" ?><list
            style="symbols">
            <t>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.</t>

            <t>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.</t>

            <t>BLS: Battery Level Status. The following values are
            defined:<list style="symbols">
                <t>0 if no information/update is required to be sent</t>

                <t>1= fading,</t>

                <t>2= weak,</t>

                <t>3= medium,</t>

                <t>4 = high,</t>

                <t>5= very high.</t>
              </list></t>

            <t>SSz: Screen Size of the device. The following values are
            defined:<list style="symbols">
                <t>0 if no information/update is required to be sent,</t>

                <t>1= very small,</t>

                <t>2= small,</t>

                <t>3= medium,</t>

                <t>4= big,</t>

                <t>5= very big.</t>
              </list></t>

         <t>MStat: User activity and mobility status. The following values
            are defined:<list style="symbols">
                <t>0 if no information/update is required to be sent</t>

                <t>1 = static,</t>

                <t>2 = weak mobility (e.g., walking),</t>

                <t>3= regular mobility (e.g., running),</t>

                <t>4 = high mobility (e.g., in train)</t>
              </list></t>

            <t>Location: Gives the user location. This field takes a value 0
            if no information/update is required to be sent.<?rfc subcompact="no" ?></t>
          </list></t>

        <t>The FEEDBACK option response has the following format:</t>

        <figure anchor="responseformat" title="FEEDBACK Option Response">
          <artwork type="inline"><![CDATA[  
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                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ]]></artwork>
        </figure>

        <t>The field PCP Server Notification shows the response status for the
        sent request:<?rfc subcompact="yes" ?><list style="symbols">
            <t>0= request cannot be satisfied,</t>

            <t>1= the request can be partially satisfied,</t>

            <t>2= the request can be satisfied,</t>

            <t>3= the request can be fully satisfied.<?rfc subcompact="no" ?></t>
          </list></t>

        <t>The content of the remaining fields are echoed from the
        request.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Consideration">
      <t>The security consideration for PCP in <xref target="RFC6887">RFC
      6887</xref> and the PCP client authentication <xref
      target="PCPAuthentication"></xref> are sufficient to ensure security and
      host authorization for the proposed PCP extension in this document.</t>
    </section>

    <section anchor="IANA" title="IANA Consideration">
      <t>IANA is requested to assign a new PCP option called FEEDBACK in the
      IANA registry for PCP [pcp-iana].</t>
    </section>

    <section title="Acknowledgements">
      <t>
        Thanks for Wu-Chi Feng and Muthaiah Venkatachalam who provided valuable comments on this work. And thanks for Tirumaleswar Reddy for all his comments and guidelines to prepare
        this version of the draft.
      </t>

    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC6887">
        <front>
          <title abbrev="Port Control rotocol">Port Control Protocol
          (PCP)</title>

          <author fullname="Dan Wing" initials="D." surname="Wing">
            <organization>Cisco</organization>
          </author>

          <date month="April" year="2013" />
        </front>

        <seriesInfo name="RFC" value="6887" />
      </reference>

      <?rfc include='reference.I-D.ietf-pcp-server-selection'?>

      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement
          Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />
        </front>

        <seriesInfo name="BCP" value="14" />

        <seriesInfo name="RFC" value="2119" />
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="PCPAuthentication">
        <front>
          <title>Port Control Protocol (PCP) Authentication Mechanism</title>

          <author fullname="Margaret Wasserman" initials="M."
                  surname="Wasserman"></author>

          <author fullname="Sam Hartman" initials="S." surname="Hartman"></author>

          <author fullname=" Dacheng Zhang" initials="D." surname="Zhang"></author>

          <date month="October" year="2013" />
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-pcp-authentication-02" />
      </reference>

      <reference anchor="PCPProxy">
        <front>
          <title>Port Control Protocol (PCP) Proxy Function</title>

          <author fullname="Mohamed Boucadair" initials="M."
                  surname="Boucadair"></author>

          <author fullname="Reinaldo Penno" initials="R." surname="Penno"></author>

          <author fullname="Dan Wing" initials="D." surname="Ding"></author>

          <date month="June" year="2013" />
        </front>

        <seriesInfo name="Internet-Draft" value="draft-ietf-pcp-proxy-03" />
      </reference>


      <reference anchor="Flowdata">
        <front>
          <title>PCP Flowdata Option</title>

          <author fullname="Dan Wing" initials="D." surname="Wing"></author>

          <author fullname="Reinaldo Penno" initials="R." surname="Penno"></author>

          <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy"></author>

          <date month="July" year="2013" />
        </front>

        <seriesInfo name="Internet-Draft" value="draft-wing-pcp-flowdata-00" />
      </reference>

	   <reference anchor="ServiceFunctions">
        <front>
          <title>Service Function Chaining Use Cases</title>

          <author fullname="Will Liu" initials="W." surname="Liu"></author>

          <author fullname="Hongyu Li" initials="H." surname="Li"></author>

          <author fullname="Olivier Huang" initials="O." surname="Huang"></author>
		  
		  <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"></author>

          <author fullname="Nicolai Leymann" initials="N." surname="Leymann"></author>

          <author fullname="Zhen Cao" initials="Z." surname="Cao"></author>
		  
		 <author fullname="Jie Hu" initials="J." surname="Hu"></author>

          <date month="October" year="2013" />
        </front>

        <seriesInfo name="Internet-Draft" value="draft-liu-sfc-use-cases-00" />
      </reference>

      <reference anchor="RFC3840">
        <front>
          <title abbrev="Session Initiation Protocol (SIP)">Indicating User
          Agent Capabilities in Session Initiation Protocol (SIP)</title>

          <author fullname="Jonathan Rosenberg" initials="J."
                  surname="Rosenberg">
            <organization>Dynamicsoft</organization>
          </author>

          <date month="August" year="2004" />
        </front>

        <seriesInfo name="RFC" value="3840" />
      </reference>

      <reference anchor="RFC2616">
        <front>
          <title abbrev="Hybertext Transport Protocol (HTTP)/1.1">Hypertext
          Transfer Protocol -- HTTP/1.1</title>

          <author fullname="Roy Fielding" initials="R." surname="Fielding">
            <organization>University of California, Irvine</organization>
          </author>

          <date month="June" year="1999" />
        </front>

        <seriesInfo name="RFC" value="2616" />
      </reference>

      <reference anchor="RFC4566">
        <front>
          <title abbrev="Session Description Protocol">SDP: Session
          Description Protocol</title>

          <author fullname="Mark Handley" initials="M." surname="Handley">
            <organization>University College London</organization>
          </author>

          <date month="July" year="2006" />
        </front>

        <seriesInfo name="RFC" value="4566" />
      </reference>

   	     <?rfc include='reference.I-D.ietf-httpbis-http2'?>
    </references>
	
    <section title="Existing Protocols of Relevance to User&rsquo;s Feedback  Information and their Limitations">
      <t>Some existing protocols can convey devices characteristics and
      information on the user, however with limited applicability. Examples
      are:<list style="symbols">
          <t>SIP <xref target="RFC3840"></xref><list style="symbols">
              <t>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). </t>

              <t>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 &ldquo;live&rdquo; real-time control with no network
              priority to SIP controls. </t>

              <t>Other Signalling protocols such as IAX are used to establish
              media sessions.</t>
            </list></t>

          <t>HTTP 1.1 <xref target="RFC2616"></xref> and HTTP2.0 <xref
          target="I-D.ietf-httpbis-http2"></xref><list style="symbols">
              <t>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. </t>

              <t>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. </t>
            </list></t>

          <t>SDP <xref target="RFC4566"></xref><list style="symbols">
              <t>SDP is meant to provide a standard representation for session
              description without incorporating a transport protocol, without
              a focus on user&rsquo;s feedback information </t>

              <t>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 </t>

              <t>SDP uses protocols as SIP and RTSP that are not intercepted
              by middle nodes in the network which limits its applicability.
              </t>

              <t>SDP is not used in some non-SIP deployement contexts.</t>
            </list></t>
        </list></t>
    </section>
  </back>
</rfc>
