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

["Reinaldo Penno (repenno)" <[e-mail]>]

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