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

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

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
>