Subject: Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-ha-01.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 8 Aug 2014 08:22:28 +0000

Hi Suresh,

Comments:

[1] What is the reason for updating the reserved field in the PCP Common Request Packet Format ?
A new PCP option can also be defined to signal if it's a critical flow or not.

[1b] It may help the client to know if the flow is check pointed or not, this way the client can make a decision to prioritize the flows accordingly when multiple interfaces with associated PCP servers are involved.

[1c] Success or fail response ((e.g. Quota exceeded) from PCP server can also help the client to remove check pointing for some of the existing flows so as to check point new flows.

[2] This document describes a mechanism for a host to signal various
   network functions' High Availability (HA) module to checkpoint
   interested connections through PCP.

Comment> The above line is not clear. 

[3]   Internet service continuity is critical in service provider
        environment.  To achieve this, most service providers have active-
        backup systems.

Comment> Enterprise networks also typically deploy Active-Standby. 

[4] For service continuity of those connections on backup
   when active fail, that corresponding state had to be checkpointed on
   the backup.

Nit> Replace "fail" with "fails"

[5]   Typically, this is addressed by identifying long lived connections
        and checkpointing state of only those connections that lived long
         enough, to the backup for service continuity.

Comment> You may want to add that identification is also done by DPI, which fails with encrypted traffic.

[6]   2.  A connection may not be long lived but critical like shorter
       phone conversations.

Comment> Replace "phone conversation" with "VOIP conversation"

[7]     3.  Similarly not every long lived connection need to be critical,
       say a free-service connection of a hosted service need not be
       checkpointed while a paid-service connection has to be
       checkpointed.

Comment> Why would the application client differentiate and not signal that it's a critical flow in both the cases. Are you envisioning that the application client software makes this decision internally or it involves human intervention from some UI to signal to the network that it's a critical flow.

[8] How would this work when PCP authentication is used ?
(I mean will authentication related info be also check pointed or client will have to authenticate afresh when backup becomes active and other related issues.)

[9]   1.  Disruption in a phone connection is not desired.  Application
       that is initiating a phone connection MUST mark connection HA bit
       in the header, while initiating a PCP request for checkpointing.

Comment> Are you referring to VoIP signaling connection ?

[10]   2.  Similarly disruption in media streaming is not desired.  A user
       hosting a media service, MUST mark HA bit in the header while
       initiating a mapping request, and MAY mark connection associated
       with that mapping, depending on whether the connection is from a
       paid subscriber or from a free subscriber through a PEER request.
       So checkpointing mapping doesn't result in auto checkpointing of
       connections, as it gives flexibility to the end user to pick
       specific connections only to checkpoint.

Comment> I am not sure why this distinction is required b/w free and paid VoIP calls, free call could also be an emergency call or high-priority call.

6.   In conjunction with NAT, other network functions that MAY maintain
   state for each conneciton such as Stateful Firewall, IPSec, Load
   balancing etc..., MAY register to PCP server, and MAY be triggered
   for checkpointing respective state of that connection.

Comment1> Are there stateless firewalls ?
Comment 2> I did not understand this draft usage with load balancers and IPSec.

Cheers,
-Tiru

> 
> On 6/13/14 4:19 PM, "Suresh Kumar Vinapamula Venkata"
> <[email-masked]> wrote:
> 
> >Hi
> >
> >This new version of draft address review comments received on the
> >previous version. Kindly review.
> >Sorry for the delay.
> >
> >Thanks
> >Suresh
> >
> >On 6/13/14 4:14 PM, "[email-masked]"
> ><[email-masked]>
> >wrote:
> >
> >>
> >>A new version of I-D, draft-vinapamula-flow-ha-01.txt has been
> >>successfully submitted by Suresh Vinapamula and posted to the IETF
> >>repository.
> >>
> >>Name:		draft-vinapamula-flow-ha
> >>Revision:	01
> >>Title:		Flow high availability through PCP
> >>Document date:	2014-06-13
> >>Group:		Individual Submission
> >>Pages:		6
> >>URL:
> >>http://www.ietf.org/internet-drafts/draft-vinapamula-flow-ha-01.txt
> >>Status:
> >>https://datatracker.ietf.org/doc/draft-vinapamula-flow-ha/
> >>Htmlized:       http://tools.ietf.org/html/draft-vinapamula-flow-ha-01
> >>Diff:
> >>http://www.ietf.org/rfcdiff?url2=draft-vinapamula-flow-ha-01
> >>
> >>Abstract:
> >>   This document describes a mechanism for a host to signal various
> >>   network functions' High Availability (HA) module to checkpoint
> >>   interested connections through PCP.
> >>
> >>
> >>
> >>
> >>
> >>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
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/pcp

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Mon, 11 Aug 2014 18:36:25 +0000

Thanks for your comments. Please see inline.

>A new PCP option can also be defined to signal if it's a critical flow or

Suresh> Yes, a PCP option can also be used and we thought about it. We
were debating if option would be an overkill, as there is nothing
negotiated unlike other options, while indicating checkpointing. We are
debating on the use cases where bit is not sufficient and an option is
required. Please let us know if you think of cases where bit will not work.
>
>[1b] It may help the client to know if the flow is check pointed or not,
>this way the client can make a decision to prioritize the flows
>accordingly when multiple interfaces with associated PCP servers are
>involved.

Suresh> A reserve bit in the PCP response can indicate that PCP server
honored PCP checkpoint request or not. Will update the draft.
>
>[1c] Success or fail response ((e.g. Quota exceeded) from PCP server can
>also help the client to remove check pointing for some of the existing
>flows so as to check point new flows.
Suresh> Would response to 1b handle it?
>Comment> The above line is not clear.

Suresh> Not sure what is not clear, What I meant to say here is, this
document provides a mechanism to signal any network functions' (firewall
NAT IPSec etcŠ) high availability module for checkpointing interested
connections by host. If this is still not clear, can you please be more
specific?

>Comment> Enterprise networks also typically deploy Active-Standby.
Suresh> Ok will update document.
>Nit> Replace "fail" with "fails"
Suresh> ok.
>which fails with encrypted traffic.
Suresh> ok
>Comment> Replace "phone conversation" with "VOIP conversation"
Suresh> ok
>Comment> Why would the application client differentiate and not signal
>that it's a critical flow in both the cases. Are you envisioning that the
>application client software makes this decision internally or it involves
>human intervention from some UI to signal to the network that it's a
>critical flow.
Suresh> Human intervention may or may not be required. What involves in
signaling is out of scope and is left for implementation. For example, a
hosted service knows if the subscriber is a free subscriber or a paid
subscriber. A policy may be enforced to automatically trigger checkpoint
if the service requested is from a paid subscriber and not trigger if the
service requested is from a free subscriber. As another example, a human
may be given a choice for signaling, just like human intervention when a
location based services app is launched. Or in some cases application may
decide. And, one may come up with an even smarter way of when to signal.
So, what involves in signaling is left for implementation and is of scope
of this document. However, I can mention the above as examples, if
required.
>(I mean will authentication related info be also check pointed or client
>will have to authenticate afresh when backup becomes active and other
>related issues.)
Suresh> I would not expect another authentication to happen. The
implementation should ensure all the necessary state is check pointed on
backup so that it doesn¹t need to re authenticate.
>Comment> Are you referring to VoIP signaling connection ?
Suresh> I am referring to VOIP signaling and data.
>Comment> I am not sure why this distinction is required b/w free and paid
>VoIP calls, free call could also be an emergency call or high-priority
>call.
Suresh> In this context, media streaming refers to streaming services like
netflix, hulu, yupptv, spotify or some privately owned services etcŠ Yes,
emergency calls are free and are high priority and implementor can always
initiate checkpointing for those calls. And, I am not sure why you are
relating them here? Am I missing something?
>Comment1> Are there stateless firewalls ?
Suresh> Yes, simple packet filters or ASIC based firewall etcŠ

>Comment 2> I did not understand this draft usage with load balancers and
Suresh> Suppose IPSec as a gateway service along with firewall and NAT.
IPSec may register with PCP, such that IPSec's HA module will be triggered
by PCP server to checkpoint state associated with a flow, when a PCP
request for that flow with HA bit set is received.
Similarly for load balancing.

---

From: <[email-masked]>
Date: Mon, 18 Aug 2014 09:03:30 +0000

Hi all,

I do agree with Tiru that an option would be more appropriate than associating a meaning with a reserved bit. 

For example: when used with PREFER_FAILURE, a client can be aware if its request has been honored by the server. This can be used for example to trigger counter measures by the PCP client such duplicating entries when several servers are available, shorten the lifetime for this mapping, etc. 

Cheers,
Med

>-----Message d'origine-----
>De : pcp [mailto:[email-masked]] De la part de Tirumaleswar Reddy
>(tireddy)
>Envoyé : vendredi 8 août 2014 10:22
>À : Suresh Kumar Vinapamula Venkata
>Cc : [email-masked]
>Objet : Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-
>ha-01.txt
>
>Hi Suresh,
>
>Comments:
>
>this way the client can make a decision to prioritize the flows accordingly
>when multiple interfaces with associated PCP servers are involved.
>
>Comment> Why would the application client differentiate and not signal that
>it's a critical flow in both the cases. Are you envisioning that the

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Mon, 18 Aug 2014 18:40:41 +0000

Hi Med, 

PCP server can always communicate a failure in checkpointing to end
client, by not setting a corresponding reserved bit in the corresponding
PCP response of a PCP request. When checkpointing is successful, this bit
MUST be set in the response. But, I agree an option can always help in
future extensions, not sure what they would be, and a bit may not be as
versatile as extensions.

You brought an interesting point with PREFER_FAILURE. For a PREFER_FAILURE
request, if PCP resources are available but for some reason, checkpointing
failed, does that mean we should fail the request? I mean should
PREFER_FAILURE be carried over to checkpointing? I feel, in this case
where mappings could be allocated but checkpointing failed, a succeed the
request by sending allocated resources and also indicating that
checkpointing failed.

This way application knows about both status, and takes necessary action.

Thanks
Suresh

On 8/18/14 2:03 AM, "[email-masked]"
<[email-masked]> wrote:

>Hi all,
>
>I do agree with Tiru that an option would be more appropriate than
>associating a meaning with a reserved bit.
>
>For example: when used with PREFER_FAILURE, a client can be aware if its
>request has been honored by the server. This can be used for example to
>trigger counter measures by the PCP client such duplicating entries when
>several servers are available, shorten the lifetime for this mapping,
>etc. 
>
>Cheers,
>Med
>
>>accordingly
>>Comment> You may want to add that identification is also done by DPI,
>>which
>>fails with encrypted traffic.
>>
>>that
>>> >>Htmlized:    
>>>http://tools.ietf.org/html/draft-vinapamula-flow-ha-01
>>> >>Diff: