Re: [pcp] TR: I-D Action: draft-vinapamula-flow-ha-05.txt
<mohamed.boucadair@orange.com> Thu, 23 October 2014 09:00 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993231A8945 for <pcp@ietfa.amsl.com>; Thu, 23 Oct 2014 02:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCdlPJprYXUk for <pcp@ietfa.amsl.com>; Thu, 23 Oct 2014 02:00:08 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FF41A8925 for <pcp@ietf.org>; Thu, 23 Oct 2014 02:00:07 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id CD59F37433A; Thu, 23 Oct 2014 11:00:05 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 93A85158090; Thu, 23 Oct 2014 11:00:05 +0200 (CEST)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.21]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 11:00:05 +0200
From: mohamed.boucadair@orange.com
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, "Prashanth Patil (praspati)" <praspati@cisco.com>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] TR: I-D Action: draft-vinapamula-flow-ha-05.txt
Thread-Index: AQHP7S3QZRNhohXfuUSkYfgN+OnwDpw6ZceAgABViAD//7otAIAAV2EAgAKXgZA=
Date: Thu, 23 Oct 2014 09:00:04 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300C87DF@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <D06BF17D.47A1%repenno@cisco.com> <D06BF274.53F30%sureshk@juniper.net> <D06BFE62.47AE%repenno@cisco.com>
In-Reply-To: <D06BFE62.47AE%repenno@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.24.114819
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5FmPDr3Hs_kEoo3uTghSCch5Fow
Subject: Re: [pcp] TR: I-D Action: draft-vinapamula-flow-ha-05.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 23 Oct 2014 09:00:12 -0000
Hi Reinaldo, Prashanth, An updated version integrating this discussion is available online: see this diff: http://www.ietf.org/rfcdiff?url1=draft-vinapamula-flow-ha-05&url2=draft-vinapamula-flow-ha-06 I hope this is now better. Cheers, Med -----Message d'origine----- De : Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Envoyé : mardi 21 octobre 2014 21:23 À : Suresh Kumar Vinapamula Venkata; Prashanth Patil (praspati); BOUCADAIR Mohamed IMT/OLN; pcp@ietf.org Objet : Re: [pcp] TR: I-D Action: draft-vinapamula-flow-ha-05.txt Thanks Suresh, your examples clear up a few things: 1 - There might be form of quota per PCP Client/Circuit/Subscriber 2 - There might be some form of authorization that needs to built around this functionality. It could be ISP driven (“subscriber A is gold”) or device driven. Personally these examples seem to represent the functionality better than the ones in “typical usages section”. I would suggest incorporating the text. BTW, I agree that keeping the priority option out of the draft was the right decision. It would complicate things needlessly. Thanks, Reinaldo On 10/21/14, 12:09 PM, "Suresh Kumar Vinapamula Venkata" <sureshk@juniper.net> wrote: >Hi Reinaldo, > >It is not application alone, along with application it is also end user >where ever necessary will help in identifying which flows are critical. >Let me give couple of examples. > >Example 1: >Consider Netflix app is the application that has ability to support this >functionality. >The same app is installed in three UEs A B and C. For A it is critical and >doesn’t want interruption and for B it is not, and for C only some >programs are critical. >At the time of installing this App, this can be provisioned. When netflix >starts streaming >1) It may request user for checkpointing only in case of C. >2) Incase of A all flows are critical. Limiting number of flows to >checkpoint will ensure that UE doesn’t exceed his limit. >3) In case of B it is not an issue as none of these flows are critical for >checkpointing. > >Example 2: >Suppose end user is providing a media streaming service. Subscriptions >could be like gold, silver, bronze. >To provide best quality of service, policies are configured such that >1) all the flows associated with gold subscription should be check >pointed. >2) Only some flows associated with silver subscription is check pointed. >3) None of the flows associated with bronze subscription is check pointed. >When a user logs in for streaming service, based on login credentials he >may fall into one of those buckets, and according to the configured >policy, his associated streaming flows are automatically check pointed. > >Example 3: >Similarly a phone app may provide ability to checkpoint flows associated >with phone calls. >No matter what is configured, some calls are always check pointed, say >call to 911. Application has to identify such calls. > >In short the point I wanted to make is, > >1) Application has ability to checkpoint. >2) Application has some default setting and should be programmable. >3) Exposing and enforcing these features is application specific. >4) If applications don’t honor this, they are treated as rogue >applications. >5) To ensure users don’t exceed their quota (knowingly/unknowingly) limits >are enforced. > >Please let me know if the above makes sense. > >Thanks >Suresh > > >On 10/21/14 11:19 AM, "Reinaldo Penno (repenno)" <repenno@cisco.com> >wrote: > >>In all fairness this does not quite answers the question. What precludes >>every single appellation from requesting their flows to be checkpointerd >>and defeating the original purpose of the new option. >> >>On 10/21/14, 11:13 AM, "Suresh Kumar Vinapamula Venkata" >><sureshk@juniper.net> wrote: >> >>>Hi Prashanth, >>> >>>Thanks for your comment. >>> >>>It is not just the application alone, it is application and end user of >>>that application(where ever applicable) decides if a flow associated >>>with >>>that application is business critical. >>>An application may have a default setting, and may be programmable by >>>end >>>user. Way to program the application is application specific, such as, >>> >>>1) Change default settings while installing that application. >>>2) Popup window to confirm when ever an application is launched. >>>3) Some of them are critical and will not be altered. Say for example a >>>call to 911 is critical. >>>Etc... >>> >>>Configuration of these settings are very similar to configuration of >>>location services by various apps in your iPhone, options to handle >>>popup >>>windows in browsers etc... >>> >>>-Suresh >>> >>> >>>On 10/21/14 5:52 AM, "Prashanth Patil (praspati)" <praspati@cisco.com> >>>wrote: >>> >>>>My concern with the proposal is that that an application will always >>>>choose to checkpoint its flows. Why would an application ever consider >>>>otherwise i.e. consider its flow not critical? >>>>The draft suggests "Administration SHOULD restrict the number of >>>>connections that can be elected to be backed up and the rate of >>>>check-pointing on per PCP client.", which doesn¹t really address the >>>>above >>>>problem. >>>> >>>> >>>>-Prashanth >>>> >>>>On 10/21/14 12:22 PM, "mohamed.boucadair@orange.com" >>>><mohamed.boucadair@orange.com> wrote: >>>> >>>>>Dear all, >>>>> >>>>>An updated version is available online. (comments received during the >>>>>interim meeting were addressed in a previous version) >>>>> >>>>>This version is ready for adoption. >>>>> >>>>>Cheers, >>>>>Med >>>>> >>>>>-----Message d'origine----- >>>>>De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >>>>>internet-drafts@ietf.org >>>>>Envoyé : mardi 21 octobre 2014 08:06 >>>>>À : i-d-announce@ietf.org >>>>>Objet : I-D Action: draft-vinapamula-flow-ha-05.txt >>>>> >>>>> >>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. >>>>> >>>>> >>>>> Title : Application-Initiated Flow High Availability >>>>>Awareness through PCP >>>>> Authors : Suresh Vinapamula >>>>> Senthil Sivakumar >>>>> Mohamed Boucadair >>>>> Tirumaleswar Reddy >>>>> Filename : draft-vinapamula-flow-ha-05.txt >>>>> Pages : 9 >>>>> Date : 2014-10-20 >>>>> >>>>>Abstract: >>>>> This document specifies a mechanism for a host to signal via Port >>>>> Control Protocol (PCP) which connections should be protected >>>>>against >>>>> network failures. These connections will be elected to be subject >>>>>to >>>>> high availability mechanisms enabled at the network side. >>>>> >>>>> This approach assumes that applications/users have more visibility >>>>> about sensitive connections rather than any heuristic that can be >>>>> enabled at the network side to guess which connections should be >>>>> secured. >>>>> >>>>> >>>>> >>>>>The IETF datatracker status page for this draft is: >>>>>https://datatracker.ietf.org/doc/draft-vinapamula-flow-ha/ >>>>> >>>>>There's also a htmlized version available at: >>>>>http://tools.ietf.org/html/draft-vinapamula-flow-ha-05 >>>>> >>>>>A diff from the previous version is available at: >>>>>http://www.ietf.org/rfcdiff?url2=draft-vinapamula-flow-ha-05 >>>>> >>>>> >>>>>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. >>>>> >>>>>Internet-Drafts are also available by anonymous FTP at: >>>>>ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>>_______________________________________________ >>>>>I-D-Announce mailing list >>>>>I-D-Announce@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>>_______________________________________________ >>>>>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 >>> >>>_______________________________________________ >>>pcp mailing list >>>pcp@ietf.org >>>https://www.ietf.org/mailman/listinfo/pcp >> >
- [pcp] TR: I-D Action: draft-vinapamula-flow-ha-05… mohamed.boucadair
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… Prashanth Patil (praspati)
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… Suresh Kumar Vinapamula Venkata
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… Reinaldo Penno (repenno)
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… Suresh Kumar Vinapamula Venkata
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… Reinaldo Penno (repenno)
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… Suresh Kumar Vinapamula Venkata
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… Tirumaleswar Reddy (tireddy)
- Re: [pcp] TR: I-D Action: draft-vinapamula-flow-h… mohamed.boucadair