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

["Moustafa, Hassnaa" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, November 06, 2013 3:25 PM
To: Moustafa, Hassnaa; Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [e-mail]
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:[e-mail]]
Sent: Wednesday, November 06, 2013 3:06 PM
To: Bill Ver Steeg (versteb); Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [e-mail]
Cc: Moses, Danny
Subject: RE: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

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

Regards,
Hassnaa

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

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. 

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.

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 ?

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.

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. 

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.


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.

Bvs - agreed, 100%. 

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.

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: [e-mail] [mailto:[e-mail]] On Behalf Of Moustafa, Hassnaa
Sent: Wednesday, November 06, 2013 2:43 PM
To: Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); [e-mail]
Cc: Moses, Danny
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt

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:[e-mail]]
Sent: Wednesday, November 06, 2013 2:40 PM
To: Moustafa, Hassnaa; Tirumaleswar Reddy (tireddy); [e-mail]
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" <[e-mail]> wrote:

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

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.
>How is FEEDBACK option useful with uCDN/dCDN ?
>
>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:[e-mail]]
>Sent: Tuesday, November 05, 2013 7:58 PM
>To: Moustafa, Hassnaa; [e-mail]
>Cc: Moses, Danny
>Subject: RE: [pcp] New Submission:
>draft-mou-pcp-application-network-feedback-00.txt
>
>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.
>
>> -----Original Message-----
>> From: Moustafa, Hassnaa [mailto:[e-mail]]
>> Sent: Monday, November 04, 2013 6:33 PM
>> To: [e-mail]
>> Cc: Moses, Danny
>> Subject: [pcp] New Submission:
>> draft-mou-pcp-application-network-feedback-
>> 00.txt
>> 
>> 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: [e-mail] [mailto:[e-mail]]
>> 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
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp

_______________________________________________
pcp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcp