Subject: RE: [Dime] CER/CEA on an open connection

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Sat, 8 Apr 2006 12:56:14 +0800

Hi,

Some clarifications and comments on the discussion on this thread:

We would like to clarify the following practical scenarios of this
happenning:
1. there are a list of published applications which the box support
and these are installed in the box. Now, some of them go down/up. This
would
get translated into change in peer capabilities.
2. there is a new application which is getting installed/removed from
the box.

We think that (1) is the most probable scenario. so,
there is value in giving a simple solution assuming that this change (in
capabilities)
is most probably temporary. If this is not the case, we are talking
about (2), which is 
a major change in the box anyways. So in (2), we assume it is ok to
assume that
the connections to be reestablished.

We would like to say that our design goals are:
3. solution should be simple & as backward compatible as possible.
4. minimize the FSM changes.

We suggest:
5. Updating peer capabilities done only using a CER/CEA in the open
state. 
Sender of CER/CEA updates the local capabilities before sending the
message and
hence is a local decision.

6. The rest of the processing of the CER/CEA will be as per the current
RFC. 
Say for example, if there are no
common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION
is sent in the
CEA and the connection is closed.

Problems in the email thread under discussion & some comments:
7. Cross over and sequencing of CER/CEA exchange. We dont think there is
a problem
here. Cant find any race condition.

8. Mutual agreement to bring down applications will not work due to
possible relays 
in between as Tolga has pointed out in the mailing list.

9. The DPR solution in the suggested text is not a good idea. Because
DPR cannot
advertise the latest local applications to the peer. This may cause the
race condition 
and sequencing problem. This problem can be avoided by using the
approach which 
we suggested in (5).

Regards,
Vishnu.

Motorola India Electronics Pvt Ltd
+91 9844178052
[*] Motorola Internal Use Only

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 6:44 PM
To: [email-masked]
Subject: RE: [Dime] CER/CEA on an open connection

Hi Victor,

Once there is the assumption that shutting down applications is
completely decided in a local way -which as far as I understand
everybody agrees(?)-, I don't see a need for any type of serialization.
If you see a problem scenario, could you provide message flow for it,
otherwise IMHO there is no need to complicate things.

Furthermore, there is also no need to do something special based on the
result code of CEA, if we want to honor "complete local decision for
application shutdown" principle. Regardless of CEA result, application
will be shut down -actually even wothout waiting for CEA-.

Probably what we need to say is just that renegotiations are limited to
advertise new set of supported applications.

    Thanks,
    Tolga

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 9:25 AM
> To: Tina TSOU
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Dime] CER/CEA on an open connection
>
>
> Hi Tina,
>
> Comments inline:
> > Hi,
> > I think the schema is ok but for simultaneous renegotiation 
> > serialization - "A Diameter node that receives a CER from a peer 
> > from which it has sent its own pending CER MUST be able serialize 
> > the simultaneous renegotiation. If the Diameter node is acting as a 
> > responder (see Sec
> > 5.6) then it MUST give precedence to the renegotiation initiated by 
> > its peer and send a CEA accordingly. If the Diameter node is acting 
> > as an initiator (see Sec 5.6) then it MUST delay the renegotiation 
> > initiated by its peer (the responder) and send a CEA
> > with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to
retain
> > the current state between them. The receiver of this CEA (the
> > responder) SHOULD retain its current state and proceed with the
ongoing
> > renegotiation initiated by its peer. It SHOULD retransmit its own
CER to
> > initiate another renegotiation after the current renegotiation
> > completes. Both renegotiations SHOULD be treated as separate and
> > sequential."
> >
> > Does any one understand why this spl. handling is needed in the 
> > event of a renegotiation cross over? Even without this, I think each

> > CER will be treated atomically by the receiver.
> Maybe I'm wrong but I'm not clear on how multiple pending transactions

> can be resolved automatically without serialization or extra logic 
> (i.e., election process in the rfc). Anyway, the basic idea of the 
> text was to "assist" a diameter node in making sure serialization does

> occur. "Assistance" here implies that a diameter node need not be 
> burdened with extra state/logic of handling simultaneous renegotiation

> since such renegotiation will be serialized. I don't have a strong 
> opinion on this but if we get a consensus that we do not need to 
> specify this behavior and let the implementations deal with it in 
> their own way then we can make this text optional.
>
> hope this helps,
> victor
> >
> > Tina
> >
> > ----- Original Message ----- From: <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Thursday, April 06, 2006 11:11 AM
> > Subject: RE: [Dime] CER/CEA on an open connection
> >
> >
> > Hi all,
> >
> >
> >>>> DIAMETER_APPLICATION_UNSUPPORTED.
> >>>>
> >>>> What is proposed is that a node initiating the change
> >> request should
> >>>> not terminate the supported application until the
> >> corresponding peer agrees.
> >>>> If the peer does not agree, the node initiating the change 
> >>>> request has an alternative to gracefully terminate of the
> >> connection with the
> >>>> peer if it chooses to. Otherwise, it must honor its commitment to

> >>>> keep the application support.
> >>>>
> >>> [TOLGA]AFAICS, the moment you introduce some intelligence to that 
> >>> procedure, e.g. receiver of CER aggreing with the
> >> application getting
> >>> down, you need to be sure that you are communicating with your 
> >>> application level peer. CER/CEA is hop-to-hop, it probably
> >> won't do it
> >>> for a generic solution, where we have relay agents etc..
> >> between the endpoints.
> >>>
> >> renegotiation is done between peers (one hope) not between 
> >> end-points and the decision on wether to continue support for an 
> >> application is local to a node. how a node will deal with not 
> >> supporting an application anymore is up to the application itself.
> >
> > I agree with Victor.
> >
> > John
> >
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Timothy Smith <[email-masked]>
Date: Sat, 8 Apr 2006 12:40:17 -0400

Hi Vishnu,

Good summary!  I agree with most of your points.  I'm not sure, however, 
that I distinguish between (1) and (2).  I think whether temporary or not, 
we should handle CER/CEA exchanges in the same manner.

I agree with your design goals (3) ,(4), and suggestions (5) , (6) , (8), 
and (9).

Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont think 
there is a problem here. Cant find any race condition."  I thought that 
there was a subtle problem here, but I think you are right.  Given that 
the connection insures sequencing, the latest CER or CEA that you receive 
is what you should use as the list of negotiated App Ids. 

Should there be some discussion on the retry mechanism?  You send a CER, 
and no response is received.  Does this mean that the peer just doesn't 
know how to renegotiate?  Should we ignore and retry every n seconds? 
Bring down the connection?  Or do we just continue to use the apps from 
the initial negotiation? My preference on this is that we should require a 
CEA response to the CER.  If the CEA is not received, we shutdown the 
connection and start over.  This would address compatibility issues with 
existing implementations.  It would also be consistent with the processing 
of the initial CER/CEA.

Best Regards,
Timothy Smith

[email-masked]
(919) 254-4723

"Ram O V Vishnu-A14676" <[email-masked]> 
04/08/2006 12:56 AM

To
<[email-masked]>
cc
Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Subject
RE: [Dime] CER/CEA on an open connection

Hi,

We suggest:

Regards,
Vishnu.

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 6:44 PM
To: [email-masked]
Subject: RE: [Dime] CER/CEA on an open connection

Hi Victor,

    Thanks,
    Tolga

retain
ongoing
CER to

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 07 Apr 2006 21:45:28 -0400

Hi,

> the connections to be reestablished.
Scenario (1) you mentioned above is what we are targeting. If scenario 
(2) means your going to reboot the box so renegotiation does not apply.
> 4. minimize the FSM changes.
I agree.
> 5. Updating peer capabilities done only using a CER/CEA in the open
ok.
> hence is a local decision.
This certainly simplifies things but it also implies that the sender of 
the CER mandates a change and the receiver has no choice but to accept 
it. In some sense, the scheme is no longer a re-negotiation but merely 
notifying the peer of a change. The proposed text was considering the 
case where the receiver of the CER cannot comply with the change for 
whatever reason.
> CEA and the connection is closed.
Perhaps regardless of whether scheme (5) is in use, a diameter node 
already knows prior to sending a CER that it will have no common 
application with a peer. To that end, CER/CEA exchange can be skipped in 
favor of formal connection termination.

> here. Cant find any race condition.
Ok :) I guess we have more people favoring to strike this text.
> in between as Tolga has pointed out in the mailing list.
I guess there some confusion in the ml exchange regarding this issue :). 
I think we should really decouple end-to-end application signaling with 
peer-to-peer signaling since (as you say) there maybe intermediary 
nodes. As an example, a peer shutting down an application and notifying 
its immediate peer that it will no longer accept request for that 
application does not necessarily mean that the end-point application 
generating the request which is a few hops away should shutdown. With 
regards to application re-negotiation, the proposed text is commenting 
on the state/pre-existing state of the next hop peer whether it is a 
relay or the actual generator of the request. If the proposed text has 
is not clear on this the pls let me know and we can attempt to clarify.
> and sequencing problem. This problem can be avoided by using the
Hmmm ... DPR/DPA in the proposed text is not used to advertise the 
latest locally supported app. As I mentioned above, a diameter node can 
already determine whether it will not have a common application with a 
peer so there maybe no need to renegotiate. Also, I'm not clear on how 
this will cause a race condition.

Hope this helps,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 07 Apr 2006 22:16:59 -0400

Hi Timothy,

Thanks for the good discussion, this is really helpful.
>
> Good summary!  I agree with most of your points.  I'm not sure, 
> however, that I distinguish between (1) and (2).  I think whether 
> temporary or not, we should handle CER/CEA exchanges in the same manner.
I'm just speculating but I think (2) refers to application change 
requiring a reboot.
>
> I agree with your design goals (3) ,(4), and suggestions (5) , (6) , 
> (8), and (9).
If some are more in favor of scheme (5) ,  maybe we need more opinion on 
whether the receiver of the CEA can always comply with the change 
request regardless of any scenario. I think (6) and (9) can be avoided 
regardless of which scheme we decide to use (see my previous reply).
>
> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont 
> think there is a problem here. Cant find any race condition."  I 
> thought that there was a subtle problem here, but I think you are 
> right.  Given that the connection insures sequencing, the latest CER 
> or CEA that you receive is what you should use as the list of 
> negotiated App Ids.
>
Mmmm... i'm not sure that the connection itself ensures sequencing. 
Anyway, majority rule favors removing this text.
> Should there be some discussion on the retry mechanism?  You send a 
> CER, and no response is received.  Does this mean that the peer just 
> doesn't know how to renegotiate?  Should we ignore and retry every n 
> seconds?  Bring down the connection?  Or do we just continue to use 
> the apps from the initial negotiation? My preference on this is that 
> we should require a CEA response to the CER.  If the CEA is not 
> received, we shutdown the connection and start over.  This would 
> address compatibility issues with existing implementations.  It would 
> also be consistent with the processing of the initial CER/CEA.
>
The current proposal has text mentioning the use of version number of 
initial CER/CEA exchange to determine whether a peer is capable of 
renegotiating. If a node knows that its  peer is not capable of 
re-negotiating then the node should not initiate re-negotiation. In this 
scheme, existing implementations will be spared of any change.

regards,
victor
> Best Regards,
> Timothy Smith
>
> [email-masked]
> (919) 254-4723
>
>
>
> *"Ram O V Vishnu-A14676" <[email-masked]>*
>
> 04/08/2006 12:56 AM
>
> 	
> To
> 	<[email-masked]>
> cc
> ------------------------------------------------------------------------
>

---

From: Timothy Smith <[email-masked]>
Date: Sun, 9 Apr 2006 21:40:37 -0400

Hi Victor,

Thanks for your response.  Comments below"
>regardless of which scheme we decide to use (see my previous reply).

Here is the text from your previous reply:
"This certainly simplifies things but it also implies that the sender of 
the CER mandates a change and the receiver has no choice but to accept 
it. In some sense, the scheme is no longer a re-negotiation but merely 
notifying the peer of a change. The proposed text was considering the 
case where the receiver of the CER cannot comply with the change for 
whatever reason."

I tend to agree with the notion that the sender of the CER is mandating
a change.  The receiver does have a choice just as it has a choice in the
original CER/CEA exchange.  The receiver should respond with the list of
App Ids that is the intersection of what was listed in the CER and of what
App Ids it wishes to support.  It is a renegotiation which may add or
remove App Ids.  But either way, it is telling the other side about its
intentions.  I don't thing the receiving side has any choice but to 
participate
in the renegotiation.  For example, if an app Id is being removed, the 
side
where it is being removed renegotiates with a CER that does not include 
that
App ID.  It doesn't do the receiving side any good to decline this as the 
App 
will be shut down regardless. 

>scheme, existing implementations will be spared of any change.

I'm not sure I picked up the version number.  I don't see a reason to do
something special.  I would simply like to renegotiate.  If the other side
does not respond to the CER, you shut down the connection and restart it
after some period of time.  This is what you would do if your initial CER
did not get a response.  How is this different?

Best Regards,
Timothy Smith

[email-masked]
(919) 254-4723

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 10 Apr 2006 09:36:19 -0400

Timothy Smith wrote:
> intentions. 

In the case where apps are being removed, the receiver seems to have no 
choice.  This is ok with me as long as we clarify that we are more in 
favor of notification instead of re-negotiation. I hope more people can 
comment on this so we get some notion of consensus.

> I don't thing the receiving side has any choice but to participate
> where it is being removed renegotiates with a CER that does not 
> include that
> App ID.  It doesn't do the receiving side any good to decline this as 
> the App

ok. On a side-note, we may also need to say that route table updates 
maybe required due to "mandated" change.

> did not get a response.  How is this different?

Apologies if my response seems to dis-regard one scheme over the 
another. I was thinking more in the case that this (and other) proposed 
text is an addendum to the existing specification. It maybe useful to 
use the version number so that the specification does not seem like a 
moving target. This may apply to changes that entails some behavior not 
present in the existing specification (i.e. re-negotiation as opposed to 
using the CER as a notification or other proposals specifying changes to 
the statemachine). Its not to say that retry will not work as a general 
practice but it is probably best to also use versioning so there's a 
clear demarcation between existing behavior and new behavior.

Hope this helps,
victor