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

"Bill Ver Steeg (versteb)" <versteb@cisco.com> Wed, 06 November 2013 22:53 UTC

Return-Path: <versteb@cisco.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29D021E8159 for <pcp@ietfa.amsl.com>; Wed, 6 Nov 2013 14:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.449
X-Spam-Level:
X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Luf2Mv62hdL5 for <pcp@ietfa.amsl.com>; Wed, 6 Nov 2013 14:53:21 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DF01A21E812A for <pcp@ietf.org>; Wed, 6 Nov 2013 14:53:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12353; q=dns/txt; s=iport; t=1383778401; x=1384988001; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6ioPTgf7IfGNgHVAwUxdgEjXRftOeoFtlkgb8LfiWyk=; b=MSW8xWimQOLNTYt2YA51ntgYf9Wd9w+P8O6dzot+Py1YsdaAQOLo+Bzw eTRxm8+Hwpkp6Q8Q79ONGbP8u893OCO4bGB645JcF5Qu+EmfhDriYgaE+ McxKTu4Bpf6W1Unjkn9+nCcGB75pCrxtJVLLWfuWN13v2CPA7TguoYObz 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4GADHHelKtJV2d/2dsb2JhbABbgwc4TQa/LYEnFnSCJQEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCAGHcgYIBb8LjgqBHjEHBoMagRADmTuLJoU1gyaCKg
X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="281666102"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 06 Nov 2013 22:53:20 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA6MrJnb005485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 22:53:19 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.196]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 16:53:19 -0600
From: "Bill Ver Steeg (versteb)" <versteb@cisco.com>
To: "Moustafa, Hassnaa" <hassnaa.moustafa@intel.com>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt
Thread-Index: AQHO20FA3qQ5kE8Dck6wfwgBNXLH8ZoZMREA//+cYDA=
Date: Wed, 06 Nov 2013 22:53:18 +0000
Message-ID: <AE7F97DB5FEE054088D82E836BD15BE920137BF3@xmb-aln-x05.cisco.com>
References: <F893BEC192403B489DBA38999068CF19059498E0@ORSMSX102.amr.corp.intel.com> <CEA003BD.144DB%eckelcu@cisco.com> <F893BEC192403B489DBA38999068CF1905949F31@ORSMSX102.amr.corp.intel.com>
In-Reply-To: <F893BEC192403B489DBA38999068CF1905949F31@ORSMSX102.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.97.111]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Moses, Danny" <danny.moses@intel.com>
Subject: Re: [pcp] New Submission: draft-mou-pcp-application-network-feedback-00.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 22:53:27 -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: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Moustafa, Hassnaa
Sent: Wednesday, November 06, 2013 2:43 PM
To: Charles Eckel (eckelcu); Tirumaleswar Reddy (tireddy); pcp@ietf.org
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:eckelcu@cisco.com]
Sent: Wednesday, November 06, 2013 2:40 PM
To: Moustafa, Hassnaa; Tirumaleswar Reddy (tireddy); pcp@ietf.org
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" <hassnaa.moustafa@intel.com> 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:tireddy@cisco.com]
>Sent: Tuesday, November 05, 2013 7:58 PM
>To: Moustafa, Hassnaa; pcp@ietf.org
>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:hassnaa.moustafa@intel.com]
>> Sent: Monday, November 04, 2013 6:33 PM
>> To: pcp@ietf.org
>> 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> 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
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp

_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp