Re: [pcp] TR: I-D Action: draft-vinapamula-flow-ha-05.txt

[Suresh Kumar Vinapamula Venkata <[e-mail]>]

Thanks Reinaldo. 

Will incorporate these examples.

On 10/21/14 12:22 PM, "Reinaldo Penno (repenno)" <[e-mail]> wrote:

>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"
><[e-mail]> 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)" <[e-mail]>
>>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"
>>><[e-mail]> 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)" <[e-mail]>
>>>>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, "[e-mail]"
>>>>><[e-mail]> 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:[e-mail]] De la part
>>>>>>de
>>>>>>[e-mail]
>>>>>>Envoyé : mardi 21 octobre 2014 08:06
>>>>>>À : [e-mail]
>>>>>>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
>>>>>>[e-mail]
>>>>>>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
>>>>>>[e-mail]
>>>>>>https://www.ietf.org/mailman/listinfo/pcp
>>>>>
>>>>>_______________________________________________
>>>>>pcp mailing list
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/pcp
>>>>
>>>>_______________________________________________
>>>>pcp mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/pcp
>>>
>>
>