Subject: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Mon, 4 Nov 2013 13:02:46 +0000

Hi All,

Draft (draft-mou-pcp-application-network-feedback) is a new draft that is submitted today on (PCP Extension for Signaling Feedback Information from the End-User Application to the Application Sever and to the Network). 

The draft is available at :             http://www.ietf.org/internet-drafts/draft-mou-pcp-application-network-feedback-00.txt

This draft addresses the need for more intelligence in the network and service infrastructure for better content delivery to optimize the network and devices resources. In this view, the draft proposes using PCP to signal information for: i)  Knowledge in the network and service platform about the available device and network conditions for the end-user and ii) Knowledge in the network about the content requirements in terms of devices and  network resources for content stored either in the network or in the application server.

The abstract of the draft is as follows:
" Abstract:    Nowadays users consumption style for video and multimedia  applications is strongly changing.  Users are heavily counting on  wireless and mobile devices for video streaming and interactive video
   and multimedia applications.  This can be implemented for instance by having more intelligence in the service and the network infrastructure to better suit a differentiated users consumption  style.  This 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."

Looking forward to having your feedback and more discussion on this draft.

Regards,
Hassnaa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 04, 2013 4:06 AM
To: Mohamed Boucadair; Moustafa, Hassnaa; Moses, Danny
Subject: New Version Notification for draft-mou-pcp-application-network-feedback-00.txt

A new version of I-D, draft-mou-pcp-application-network-feedback-00.txt
has been successfully submitted by Hassnaa Moustafa and posted to the IETF repository.

Filename:	 draft-mou-pcp-application-network-feedback
Revision:	 00
Title:		 PCP Extension for Signaling Feedback Information from the End-User Application to the Application Sever and to the Network
Creation date:	 2013-11-04
Group:		 Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-mou-pcp-application-network-feedback-00.txt
Status:          http://datatracker.ietf.org/doc/draft-mou-pcp-application-network-feedback
Htmlized:        http://tools.ietf.org/html/draft-mou-pcp-application-network-feedback-00

Abstract:
   Nowadays users consumption style for video and multimedia
   applications is strongly changing.  Users are heavily counting on
   wireless and mobile devices for video streaming and interactive video
   and multimedia applications.  This can be implemented for instance by
   having more intelligence in the service and the network
   infrastructure to better suit a differentiated users consumption
   style.  This 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.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 5 Nov 2013 20:59:05 +0000

Comments:

Certain things on this draft do not make much sense to me, for example,
battery level, light environment. Are there video servers that plan on
adapting its streaming resolution due to these changing conditions? Why
would they make that decision on behalf of the user.

Some of these attributes can already be gathered today through smartphone
APIs and conveyed to streaming servers. For example, when I stream Netflix
on my smartphone it knows my screen resolution through smartphone SDKs and
pass that to the server. Why the method in this draft is better or worse?

Geolocation. Same thing.

Having said that, I know of implementations where the device pass static
metadata such as device-type, manufacturer type to the network for
analytics or inventory purpose.

I believe we need further discussion, a presentation would be helpful.

On 11/4/13 5:02 AM, "Moustafa, Hassnaa" <[email-masked]> wrote:

>Hi All,
>
>Draft (draft-mou-pcp-application-network-feedback) is a new draft that is
>submitted today on (PCP Extension for Signaling Feedback Information from
>the End-User Application to the Application Sever and to the Network).
>
>The draft is available at :
>http://www.ietf.org/internet-drafts/draft-mou-pcp-application-network-feed
>back-00.txt
>
>This draft addresses the need for more intelligence in the network and
>service infrastructure for better content delivery to optimize the
>network and devices resources. In this view, the draft proposes using PCP
>to signal information for: i)  Knowledge in the network and service
>platform about the available device and network conditions for the
>end-user and ii) Knowledge in the network about the content requirements
>in terms of devices and  network resources for content stored either in
>the network or in the application server.
>
>" Abstract:    Nowadays users consumption style for video and multimedia
>having more intelligence in the service and the network infrastructure to
>better suit a differentiated users consumption  style.  This 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
>application, the network and the service platform is needed to provide
>information helping the content delivery and adaptation decisions.  This
>document 
>[RFC6887] to allow: (i) the users application to notify the network and
>application server about its available resources in terms of
>about the user (e.g., location, mobility status) and (ii) the application
>server to notify the network about the requirements of
>new PCP option, denoted the FEEDBACK, is specified to allow such feedback
>notification signaling.  This option is used with both PEER
>   and MAP Opcodes."
>
>Subject: New Version Notification for
>draft-mou-pcp-application-network-feedback-00.txt
>
>
>Title:		 PCP Extension for Signaling Feedback Information from the
>End-User Application to the Application Sever and to the Network
>URL:             
>http://www.ietf.org/internet-drafts/draft-mou-pcp-application-network-feed
>back-00.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-mou-pcp-application-network-feedback
>Htmlized:        
>http://tools.ietf.org/html/draft-mou-pcp-application-network-feedback-00
>
>
>Abstract:
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Secretariat
>

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Tue, 5 Nov 2013 21:14:50 +0000

Thanks Reinaldo for your feedback.
Please find my replies to clarify more (In the presentation that we prepared for the draft we illustrate the motivation for that and hope to find time in the session for presenting it):
- About battery level: currently there are several work looking into power efficient video streaming for mobile devices and the need for considering that (The MPEG green standard mentions the as use-case the Dynamic Adaptive Streaming over HTTP (DASH) and the need to consider battery level during the video adaptation for power efficient video) --> video adaptation in a power efficient way by the end-server of a middle box node saves also in the network bandwidth by a significant percent.
- About the "light of the environment": According to different experiments that we did on smartphones and tablets for video streaming, it is shown that the screen consumes a very big percentage of the device battery and so if the video is adapted in a way to reduce the brightness for example this can save power.
- About the attributes (e.g. screen size, location, ...) gathering by smartphones API: yes this surely happens now and our idea is to continue to use the same way of gathering them by smart phones API for example but to convey them through PCP signaling to either the application server or an intelligent network node (here is the challenge --> how to intercept this information by a network node to do intelligent decision --> we need a signaling protocol like PCP for doing that).

Hope that things are clearer now and hope to have time for more exchange through a presentation.

Regards,
Hassnaa

-----Original Message-----
From: Reinaldo Penno (repenno) [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 12:59 PM
To: Moustafa, Hassnaa; [email-masked]
Cc: Dave Thaler; [email-masked]; Moses, Danny
Subject: Re: New Submission: draft-mou-pcp-application-network-feedback-00.txt

Comments:

Certain things on this draft do not make much sense to me, for example, battery level, light environment. Are there video servers that plan on adapting its streaming resolution due to these changing conditions? Why would they make that decision on behalf of the user.

Some of these attributes can already be gathered today through smartphone APIs and conveyed to streaming servers. For example, when I stream Netflix on my smartphone it knows my screen resolution through smartphone SDKs and pass that to the server. Why the method in this draft is better or worse?

Geolocation. Same thing.

Having said that, I know of implementations where the device pass static metadata such as device-type, manufacturer type to the network for analytics or inventory purpose.

On 11/4/13 5:02 AM, "Moustafa, Hassnaa" <[email-masked]> wrote:

>Hi All,
>
>Draft (draft-mou-pcp-application-network-feedback) is a new draft that 
>is submitted today on (PCP Extension for Signaling Feedback Information 
>from the End-User Application to the Application Sever and to the Network).
>
>network and devices resources. In this view, the draft proposes using 
>PCP to signal information for: i)  Knowledge in the network and service 
>end-user and ii) Knowledge in the network about the content 
>requirements in terms of devices and  network resources for content 
>stored either in the network or in the application server.
>
>   and multimedia applications.  This can be implemented for instance 
>by having more intelligence in the service and the network 
>style.  This can be achieved
>need for  changing the current infrastructure and in a generalized way 
>to all
>information helping the content delivery and adaptation decisions.  
>This document

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 5 Nov 2013 21:26:49 +0000

On 11/5/13 1:14 PM, "Moustafa, Hassnaa" <[email-masked]> wrote:

>Please find my replies to clarify more (In the presentation that we
>prepared for the draft we illustrate the motivation for that and hope to
>find time in the session for presenting it):
>- About battery level: currently there are several work looking into
>power efficient video streaming for mobile devices and the need for
>considering that (The MPEG green standard mentions the as use-case the
>Dynamic Adaptive Streaming over HTTP (DASH) and the need to consider
>battery level during the video adaptation for power efficient video) -->
>video adaptation in a power efficient way by the end-server of a middle
>box node saves also in the network bandwidth by a significant percent.

[RP] Can you include this MPEG reference in the draft? I personally
believe more details are needed.

>- About the "light of the environment": According to different
>experiments that we did on smartphones and tablets for video streaming,
>it is shown that the screen consumes a very big percentage of the device
>battery and so if the video is adapted in a way to reduce the brightness
>for example this can save power.

[RP] Smartphones and tablets already have auto brightness. How much extra
savings you can get?

>- About the attributes (e.g. screen size, location, ...) gathering by
>smartphones API: yes this surely happens now and our idea is to continue
>to use the same way of gathering them by smart phones API for example but
>to convey them through PCP signaling to either the application server or
>an intelligent network node (here is the challenge --> how to intercept
>this information by a network node to do intelligent decision --> we need
>a signaling protocol like PCP for doing that).

[RP] If you have several applications on a smartphone, will each one
implement a PCP Client in oder to convey these metadata or there are plans
on some kernel implementation that expose some API?

>Subject: Re: New Submission:
>APIs and conveyed to streaming servers. For example, when I stream
>Netflix on my smartphone it knows my screen resolution through smartphone
>SDKs and pass that to the server. Why the method in this draft is better
>or worse?
> 
>
>Geolocation. Same thing.
>

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Tue, 5 Nov 2013 21:38:09 +0000

Please find the answer to your questions.

[RP] Can you include this MPEG reference in the draft? I personally believe more details are needed.
	Hassnaa: Sure, we will include the MPEG version in the next version of the draft. It is mentioned currently in our presentation slides.

[RP] Smartphones and tablets already have auto brightness. How much extra savings you can get?
Hassnaa: Yes but when the device does the auto brightness this consumes a lot of its device resources.

[RP] If you have several applications on a smartphone, will each one implement a PCP Client in oder to convey these metadata or there are plans on some kernel implementation that expose some API?
Hassnaa: The current thought is to use one PCP client on each device for any metadata transmission and not per application (we mention in the draft that this proposed PCP extension through the Feedback option is meant to work with the flowdata option)

Thanks.
Hassnaa
-----Original Message-----
From: Reinaldo Penno (repenno) [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 1:27 PM
To: Moustafa, Hassnaa; [email-masked]
Cc: Dave Thaler; [email-masked]; Moses, Danny
Subject: Re: New Submission: draft-mou-pcp-application-network-feedback-00.txt

On 11/5/13 1:14 PM, "Moustafa, Hassnaa" <[email-masked]> wrote:

>prepared for the draft we illustrate the motivation for that and hope 
>to find time in the session for presenting it):
>battery level during the video adaptation for power efficient video) 
>--> video adaptation in a power efficient way by the end-server of a 
>middle box node saves also in the network bandwidth by a significant percent.

[RP] Can you include this MPEG reference in the draft? I personally believe more details are needed.

>it is shown that the screen consumes a very big percentage of the 
>device battery and so if the video is adapted in a way to reduce the 
>brightness for example this can save power.

[RP] Smartphones and tablets already have auto brightness. How much extra savings you can get?

>smartphones API: yes this surely happens now and our idea is to 
>continue to use the same way of gathering them by smart phones API for 
>example but to convey them through PCP signaling to either the 
>application server or an intelligent network node (here is the 
>challenge --> how to intercept this information by a network node to do 
>intelligent decision --> we need a signaling protocol like PCP for doing that).

[RP] If you have several applications on a smartphone, will each one implement a PCP Client in oder to convey these metadata or there are plans on some kernel implementation that expose some API?

>Some of these attributes can already be gathered today through 
>smartphone APIs and conveyed to streaming servers. For example, when I 
>stream Netflix on my smartphone it knows my screen resolution through 
>smartphone SDKs and pass that to the server. Why the method in this 
>draft is better or worse?
> 
>
>Geolocation. Same thing.
>
>Having said that, I know of implementations where the device pass 
>static metadata such as device-type, manufacturer type to the network 
>for analytics or inventory purpose.
>
>>is submitted today on (PCP Extension for Signaling Feedback 
>>Information from the End-User Application to the Application Sever and 
>>to the Network).
>>
>>http://www.ietf.org/internet-drafts/draft-mou-pcp-application-network-
>>f
>>eed
>>back-00.txt
>>
>>PCP to signal information for: i)  Knowledge in the network and 
>>service platform about the available device and network conditions for 
>>the end-user and ii) Knowledge in the network about the content 
>>(ii) a knowledge in the network about the content requirements in 
>>terms of devices
>>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
>>A new version of I-D, 
>>http://www.ietf.org/internet-drafts/draft-mou-pcp-application-network-
>>f
>>eed
>>back-00.txt
>>Status:          
>>http://datatracker.ietf.org/doc/draft-mou-pcp-application-network-feed
>>bac
>>k
>>Htmlized:        
>>http://tools.ietf.org/html/draft-mou-pcp-application-network-feedback-
>>0
>>0
>>
>>
>>Abstract:

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 5 Nov 2013 21:41:58 +0000

Okay, let me see if I can get this:

If user moves from an environment from high to low lighting, do you
increase or decrease resolution? What if auto-brightness kicks in? Or not?

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Tue, 5 Nov 2013 22:59:20 +0000

The video encoding resolution here does not have a specific impact, since the native screen resolution is what counts at the end. So the adaptation would not be done regarding the resolution.
We mention specific examples (in the optimization examples in section 3.5 in the draft that shows how the knowledge of the light level can help when it is used by an external entity "end-server or other middle node" can be of help than being done locally). Among the mentioned examples in Section 3.5, an example that can clarify the point in question is the following: 
- If the user is in a bright/sunny environment and the battery level is not high, content can be sent with higher brightness but with lower bitrate to compensate the power consumed from content brightness. --> Here the brightness settings can be done locally also however a bitrate adjustment can be done at the source as explained in the example to save battery.

And generally, modifying the pixel luminance of the video at the source based on the lighting environment of the user is expected to improve the user quality and potentially reduce the network bandwidth.

-----Original Message-----
From: Reinaldo Penno (repenno) [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 1:42 PM
To: Moustafa, Hassnaa; [email-masked]
Cc: Dave Thaler; [email-masked]; Moses, Danny
Subject: Re: New Submission: draft-mou-pcp-application-network-feedback-00.txt

If user moves from an environment from high to low lighting, do you increase or decrease resolution? What if auto-brightness kicks in? Or not?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 6 Nov 2013 03:58:12 +0000

Hi,

My initial comments:

1) If the client learns that the battery conditions, light levels have changed - 
a) why can't the client request subsequent chunk with different encoding from the URL in the manifest file ?
b) why can't the client be intelligent enough to pick the subsequent chunk with appropriate bit-rate based on endpoint device conditions ?

2) use case in section 3.2 of the draft; uCDN (upstream CDN) based on location of the client and other parameters queries available dCDN (Downstream CDN) to selects the dCDN for serving content to the client. 

How is FEEDBACK option useful with uCDN/dCDN ?

-Tiru.

> From: Moustafa, Hassnaa [mailto:[email-masked]]
> Sent: Monday, November 04, 2013 6:33 PM
> To: [email-masked]
> Cc: Moses, Danny
> Subject: [pcp] New Submission: draft-mou-pcp-application-network-feedback-
> 00.txt
> 
> Hi All,
> 
> submitted today on (PCP Extension for Signaling Feedback Information from the
> End-User Application to the Application Sever and to the Network).
> 
> The draft is available at :             http://www.ietf.org/internet-
> drafts/draft-mou-pcp-application-network-feedback-00.txt
> 
> This draft addresses the need for more intelligence in the network and service
> infrastructure for better content delivery to optimize the network and devices
> resources. In this view, the draft proposes using PCP to signal information
> for: i)  Knowledge in the network and service platform about the available
> device and network conditions for the end-user and ii) Knowledge in the
> network about the content requirements in terms of devices and  network
> resources for content stored either in the network or in the application
> server.
> 
> applications is strongly changing.  Users are heavily counting on  wireless
> and mobile devices for video streaming and interactive video
> better suit a differentiated users consumption  style.  This 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
>    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."
> 
> Title:		 PCP Extension for Signaling Feedback Information from the End-
> User Application to the Application Sever and to the Network
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Wed, 6 Nov 2013 05:55:35 +0000

Thanks Tiru for your comments.
Please find my answers:
1) If the client learns that the battery conditions, light levels have changed -
a) why can't the client request subsequent chunk with different encoding from the URL in the manifest file ?
b) why can't the client be intelligent enough to pick the subsequent chunk with appropriate bit-rate based on endpoint device conditions ?

Hassnaa: this is possible for HTTP adaptive streaming where the client controls the video selection, but could not be done in RTP video streaming and video conferencing applications in which the server should take the adaptation decision based on some information known from the client. And even for HTTP adaptive streaming, the client does not have a full view of the network (but only the throughput for his connectivity) and if the adaptation is done by the network itself it will consider the global bandwidth.

Hassnaa: This use-case in this current version of the draft does not consider CDN-I (CDN Interco) but it is a very good point to consider a use-case doe CDN-I in the next version of the draft. What the current use-case considers is simply a controller node that controls the multiple Application servers in the service platform. And here the feedback option is useful as it allows the controller to do a selection of the application server having content matching the "user location looking for proximity, user devices resources that are available, .."

Hope that this clarifies your questions and looking forward to more discussion.

Regards,
Hassnaa

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 7:58 PM
To: Moustafa, Hassnaa; [email-masked]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hi,

My initial comments:

-Tiru.

> Subject: [pcp] New Submission: 
> Information from the End-User Application to the Application Sever and to the Network).
> 
> PCP to signal information
> for: i)  Knowledge in the network and service platform about the 
> available device and network conditions for the end-user and ii) 
> Knowledge in the network about the content requirements in terms of 
> devices and  network resources for content stored either in the 
> network or in the application server.
> 
> infrastructure to better suit a differentiated users consumption  style.  This can be achieved
> (ii) a knowledge in the network about the content requirements in terms of devices
> no need for changing the current infrastructure and in a generalized way to all
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 6 Nov 2013 22:39:45 +0000

On 11/5/13 9:55 PM, "Moustafa, Hassnaa" <[email-masked]> wrote:

>b) why can't the client be intelligent enough to pick the subsequent
>chunk with appropriate bit-rate based on endpoint device conditions ?
>
>Hassnaa: this is possible for HTTP adaptive streaming where the client
>controls the video selection, but could not be done in RTP video
>streaming and video conferencing applications in which the server should
>take the adaptation decision based on some information known from the
>client.

For RTP traffic, using RTCP tmmbr seems an appropriate alternative.

Cheers,
Charles
 
> And even for HTTP adaptive streaming, the client does not have a full
>view of the network (but only the throughput for his connectivity) and if
>the adaptation is done by the network itself it will consider the global
>bandwidth.
>
>2) use case in section 3.2 of the draft; uCDN (upstream CDN) based on
>location of the client and other parameters queries available dCDN
>(Downstream CDN) to selects the dCDN for serving content to the client.
>Hassnaa: This use-case in this current version of the draft does not
>consider CDN-I (CDN Interco) but it is a very good point to consider a
>use-case doe CDN-I in the next version of the draft. What the current
>use-case considers is simply a controller node that controls the multiple
>Application servers in the service platform. And here the feedback option
>is useful as it allows the controller to do a selection of the
>application server having content matching the "user location looking for
>proximity, user devices resources that are available, .."
>
>
>Subject: RE: [pcp] New Submission:
>b) why can't the client be intelligent enough to pick the subsequent
>chunk with appropriate bit-rate based on endpoint device conditions ?
>
>2) use case in section 3.2 of the draft; uCDN (upstream CDN) based on
>location of the client and other parameters queries available dCDN
>(Downstream CDN) to selects the dCDN for serving content to the client.
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Wed, 6 Nov 2013 22:42:40 +0000

Hi Charles,

But how to let RTP intercepted by middle nodes in the network? The main idea behind this draft is looking for a signaling mechanism that can push feedback information into the network by the end-user application and by the service platform.

Looking forward to more discussions.

Regards,
Hassnaa
-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2013 2:40 PM
To: Moustafa, Hassnaa; Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

On 11/5/13 9:55 PM, "Moustafa, Hassnaa" <[email-masked]> wrote:

>a) why can't the client request subsequent chunk with different 
>encoding from the URL in the manifest file ?
>streaming and video conferencing applications in which the server 
>should take the adaptation decision based on some information known 
>from the client.

Cheers,
Charles
 
>view of the network (but only the throughput for his connectivity) and 
>if the adaptation is done by the network itself it will consider the 
>global bandwidth.
>
>use-case considers is simply a controller node that controls the 
>multiple Application servers in the service platform. And here the 
>feedback option is useful as it allows the controller to do a selection 
>of the application server having content matching the "user location 
>looking for proximity, user devices resources that are available, .."
>
>
>a) why can't the client request subsequent chunk with different 
>encoding from the URL in the manifest file ?
>> Draft (draft-mou-pcp-application-network-feedback) is a new draft 
>>that  is submitted today on (PCP Extension for Signaling Feedback  
>> This draft addresses the need for more intelligence in the network 
>> and service infrastructure for better content delivery to optimize 
>> the network and devices resources. In this view, the draft proposes 
>> using PCP to signal information
>>    through having: (i) a knowledge in the network and service 
>>end-user and
>>    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
>>    the content it stores in terms of devices and network resources.  
>> A new PCP option, denoted the FEEDBACK, is specified to allow such

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 6 Nov 2013 22:53:18 +0000

The network has use for flow metadata that is abstract enough to be useful to the network. Things like target bandwidth, requirements for delay/loss/jitter and the like seem to be interesting to the network. 

The application-specific details like screen size, light level, weight of the device do not have any apparent use. If the network is aware of the target bandwidth, desired delay/loss/jitter, what additional functionality is enabled by having the network (as opposed to the hosts) knowing the light level ?

Once again, the client and the server have a different set of requirements in this area than the network. The bulk of the information should flow opaquely between the client and the server. Only the information that is useful to the network should be exposed to the network. There are complexity reasons for this, security/privacy reasons for this, efficiency reasons, and just good layering techniques.

I am not arguing against flow and network metadata - just that we need to define a pretty concise set of metadata. The metadata definition methods need to be extensible to cover emerging requirements, but IMHO the initial definition of the data conveyed should be quite constrained.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moustafa, Hassnaa
Sent: Wednesday, November 06, 2013 2:43 PM
To: Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hi Charles,

Regards,
Hassnaa
-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 2:40 PM
To: Moustafa, Hassnaa; Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Cheers,
Charles

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Wed, 6 Nov 2013 23:05:39 +0000

Hi Bill,
Thanks for your detailed feedback.
Please see inline my replies.

Regards,
Hassnaa

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2013 2:53 PM
To: Moustafa, Hassnaa; Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hassnaa: Yes, I agree. But this is mainly for the QoS management. What we are looking for is QoE which requires more metadata than the target BW, delay/loss/jitter. QoE related metadata needs to work with the QoS related metadata an does not mean to replace it.

Hassnaa: it do has for QoE, and if the session time permits for the presentation of this draft, I will show some experimental results on that. The additional functionality that could be in the network is "real-time transcoding as a service function in the network". Light information can help here in adapting the pixels luminance, but "light" is not the only metadata that we are building this draft on it.

Hassnaa: Involving the network in the knowledge of information between the client and the server is promising in optimizing the video delivery, monetizing bandwidth, having the operator control on their networks, better management for QoS, ...As for security, security considerations for PCP applies, that what is mentioned in the draft. And also if we think of the network middle boxes as entities owned by the operator, then there is much more trust here and the same security (authentication policy) between the operator and the client should apply.

Hassnaa: I agree that there is a need to define a concise set for metadata and I am looking forward to more discussion in that direction.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moustafa, Hassnaa
Sent: Wednesday, November 06, 2013 2:43 PM
To: Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hi Charles,

Regards,
Hassnaa
-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 2:40 PM
To: Moustafa, Hassnaa; Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Cheers,
Charles

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 6 Nov 2013 23:24:36 +0000

In line with BVS -----

Bvs

-----Original Message-----
From: Moustafa, Hassnaa [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2013 3:06 PM
To: Bill Ver Steeg (versteb); Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hi Bill,

Regards,
Hassnaa

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 2:53 PM
To: Moustafa, Hassnaa; Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Bvs ---- I would argue that if there is real-time transcoding in the network, that transcoding element would need to be considered more like a host than a network element. The appropriate signaling between the host/decoder and the server/encoder would be to use the (potentially encrypted) feedback mechanism such as RTCP. Once the endpoints decided on a new set of flow characteristics, they could optionally signal the network with the new flow metadata using PCP-like methods. 

Bvs - agreed, 100%. 

Hassnaa: I agree that there is a need to define a concise set for metadata and I am looking forward to more discussion in that direction.
Bvs ---- Yup, this is a good discussion, and we should continue to fine-tune the notion of flow metadata. Some of this discussion is PCP specific, but most of it could be applied to signaling protocols like PCP/ICE/Netconf/whatever. There is a BOF this evening, and perhaps we could have a talk there........

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moustafa, Hassnaa
Sent: Wednesday, November 06, 2013 2:43 PM
To: Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hi Charles,

Regards,
Hassnaa
-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 2:40 PM
To: Moustafa, Hassnaa; Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Cheers,
Charles

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Thu, 7 Nov 2013 00:53:24 +0000

Hi Bill,

I think that we agree on most of the points.

Only, regarding this point:
" Bvs ---- I would argue that if there is real-time transcoding in the network, that transcoding element would need to be considered more like a host than a network element. The appropriate signaling between the host/decoder and the server/encoder would be to use the (potentially encrypted) feedback mechanism such as RTCP. Once the endpoints decided on a new set of flow characteristics, they could optionally signal the network with the new flow metadata using PCP-like methods. "

--> Hassnaa: I am not sure if we can consider the network element as a host/decoder. The network element sits as a middle between the client (host/decoder) and the (application server). 

Yes I am aware of the BoF on metadata and will be happy to discuss more.

Regards,
Hassnaa
-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2013 3:25 PM
To: Moustafa, Hassnaa; Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

In line with BVS -----

Bvs

-----Original Message-----
From: Moustafa, Hassnaa [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 3:06 PM
To: Bill Ver Steeg (versteb); Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hi Bill,

Regards,
Hassnaa

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 2:53 PM
To: Moustafa, Hassnaa; Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Bvs - agreed, 100%. 

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moustafa, Hassnaa
Sent: Wednesday, November 06, 2013 2:43 PM
To: Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Hi Charles,

Regards,
Hassnaa
-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 2:40 PM
To: Moustafa, Hassnaa; Tirumaleswar Reddy (tireddy); [email-masked]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

Cheers,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 7 Nov 2013 01:13:38 +0000

On 11/6/13 2:42 PM, "Moustafa, Hassnaa" <[email-masked]> wrote:

>Hi Charles,
>
>But how to let RTP intercepted by middle nodes in the network?

That is a different use case than the one I thought we were discussing.
I understood the use case to be that the client wanted to signal to an RTP
video streaming or conferencing server to reduce the amount of bandwidth
it receives. I am saying there are existing application level signaling
mechanisms to accomplish this. In the case of RTCP tmmbr, the RTCP message
would be from the client to the application server, and it is not intended
for the network to glean information from it.

>The main idea behind this draft is looking for a signaling mechanism that
>can push feedback information into the network by the end-user
>application and by the service platform.

Yes, and this idea seems reasonable to me in general, just not for the use
case above as I understood it.

Cheers,
Charles

>Subject: Re: [pcp] New Submission:
>>>by