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

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Mon, 10 Apr 2006 14:38:10 +0800

Hi Victor/Timothy,

1. Comments on Retry mechanism <to Timothy>:
To summarize, we are sending CER in open state because our capabilities
(supported apps) are changing 
and we would like to update the peer about it. We will maintain open
state. 

we may not receive a CEA due to the following possible reasons: 
1.1) The peer does not support CER in open state. In such a case, peer
might still originate unsupported app messages towards us which will
result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can leave
it to the peer implementation to "correct this error" as mentioned in
sec 7.1.3 of RFC 3588. This will take care of the case where there is
relay/proxy in between. 
1.2) Connection is lost with the peer, in which case the DWR/DWA
mechanism should step in.

The solution suggested by Timothy (to wait for for CEA & timer) will
need changes to FSM, even though we agree that this is consistent with
the initial CER/CEA scenario.

Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in
added (unecessary traffic) incase the peer/proxy is not clever enough to
correct its behaviour. This can be avoided by using the version number
exchange as Victor pointed out. So, we will not
attempt the CER in open state to such a peer which doesnt support CERs
in open state, and can go for a reconnection. 

2. Comments on "re-negotiation" <to Victor>
We think that what we need is an advertisement mechanism and not a
negotiation mechanism. The CER/CEA in open state allows us to do that.
We are proposing that the receiver of the CER takes the decision on the
disconnection. Thus we are able to delay the disconnection (assuming
that the point mentioned in my email before that the app changes are
temporary).
Since CER allows us to convey the latest set of supported apps to the
peer, we favour the CER to the DPR.

Following is a scenario where sending CER/CEA is better than the DPR
mechanism. 
(Apologies if the figure is mangled due to tab settings).
 
Initial exchanged app list: 
A: 1,2,3               B:2
2 went down 3 came up just when 2 went down on A
________            ________
|A     |----DPR---> |B     |
|      |            |      |
|      |<---CER---- |      |
|______|    [3]     |______|
        <---DPA----

this in our understanding will result in reconnection even thou there 
is 3 in common.

Initial exchanged app list: 
A: 1,2,3             B:2
2 went down 3 came up just when 2 went down on A
________              ________
|A      |----CER---> |B      |
|       | [1,3]      |       |
|       |<---CER---- |       |
|_______| [2,3]      |_______|
         ----CEA---->
          [1,3]
         <---CEA-----
          [2,3]
This will avoid a reconnection, because 3 is in common.

Regards,
Vishnu.

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

-----Original Message-----
From: Timothy Smith [mailto:[email-masked]] 
Sent: Monday, April 10, 2006 7:11 AM
To: Victor Fajardo
Cc: [email-masked]; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676
Subject: Re: [Dime] CER/CEA on an open connection

Hi Victor, 

Thanks for your response.  Comments below" 
>>
>> 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).
> 

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.   

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

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 

Vishnu wrote: 
> 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. 

[email-masked]
(919) 254-4723

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

---

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

Hi All,
> and we would like to update the peer about it. We will maintain open
ok.
> sec 7.1.3 of RFC 3588. This will take care of the case where there is

Good point.

> negotiation mechanism. The CER/CEA in open state allows us to do that.

This is was was reading from your proposal :).

> 2 went down 3 came up just when 2 went down on A

Good point.

> 2 went down 3 came up just when 2 went down on A

I see. This seems like a better idea. Let see if other people have 
comments on this scheme.

best regards,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 10 Apr 2006 10:03:07 -0400

I believe in general now we all have a good understanding about what the
issues are for renegotiation. It could be an idea to have a new iteration of
the proposed text, and to continue the discussions on the new version.

A few more comments/questions below.

    Thanks,
    Tolga

> From: Ram O V Vishnu-A14676 [mailto:[email-masked]]
> Sent: Monday, April 10, 2006 2:38 AM
> To: [email-masked]
> Cc: Nakhjiri Madjid-MNAKHJI1
> Subject: RE: [Dime] CER/CEA on an open connection
>
>
> Hi Victor/Timothy,
>
[TOLGA]The problem case of a node not being clever enough to take action
based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to
renegotiations. This could happen in existing systems developed according to
RFC3588 as well. I would expect a node, whose
DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by its neighbor to
drop the connection, but as said this is not limited to renegotiation case.
For cases, where the neighbor does not support renegotiation, what would be
the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say that such a
result code in CEA should indicate that the neighbor does not support
renegotiations and sender of CER should/may drop/reestablish the connection.
Please note that with a properly behaving neighbor, dropping connection is
probably not necessary because the first DIAMETER_APPLICATION_UNSUPPORTED
should update its tables properly. I don't know whether we need to
standardize how a node determines whether a neighbor honors
DIAMETER_APPLICATION_UNSUPPORTED result code.
> (Apologies if the figure is mangled due to tab settings).
[TOLGA]Although the example case below is a race condition which probably
won't happen very often -it relies on changing supported application set on
two nodes more or less simultaneously-, I also prefer relying on CER in such
a situation, so that there is a single way of handling renegotiations in
terms of advertising changes to the neighbors.

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 10 Apr 2006 10:43:05 -0400

Hi All,

> the proposed text, and to continue the discussions on the new version.

To that end, I'll plan on generating a new set of text maybe next week 
as we let people digest and hopefully comment on the latest round of 
discussion for the next couple of days.

best regards,
victor

---

From: Tina TSOU <[email-masked]>
Date: Wed, 12 Apr 2006 14:59:49 +0800

Hi all,
Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or proxy) for authentication & authorization. 
In the roaming case, the WLAN AN is communicating with a 3GPP AAA Proxy in the visited network over the Wa reference point. The 3GPP AAA proxy is connected to the 3GPP Server in the home network over the Wd reference point.  The 3GPP AAA Proxy among its many functions will enforce local policies on access based on agreement with the 3GPP Home Network and with the WLAN operator. It will also send per user charging information for the session to the Offline Charging system. This necessitates the proxy to maintain the session state information and hence remain in-path for the entire session. 
How to assure proxies can remain in the path of all requests in a session?

B. R.
Tina
Messengers: 
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]
 _______________________________________________

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 12 Apr 2006 09:22:12 -0400

> Consider the WLAN 3GPP IP access [23.234]. The WLAN Access
> Network (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA
> server (or proxy) for authentication & authorization.
> In the roaming case, the WLAN AN is communicating with a 3GPP AAA
> Proxy in the visited network over the Wa reference point. The
> 3GPP AAA proxy is connected to the 3GPP Server in the home
> network over the Wd reference point.  The 3GPP AAA Proxy among
> its many functions will enforce local policies on access based on
> agreement with the 3GPP Home Network and with the WLAN operator.
> It will also send per user charging information for the session
> to the Offline Charging system. This necessitates the proxy to
> maintain the session state information and hence remain in-path
> for the entire session.
[TOLGA]By proper configuration of the routing tables in the nodes + proper
routing logic to select the same next hop for messages of the same session
(?). I believe the key point is not to establish a transport connection
between endpoints after the first transaction of a session.