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

["Charles Eckel (eckelcu)" <[e-mail]>]

On 11/6/13 2:42 PM, "Moustafa, Hassnaa" <[e-mail]> 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

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