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

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

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