Subject: [Dime] Disconnect-Peer-Request and connection reattempts

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Thu, 1 Jun 2006 13:16:31 +0800

Hi All,

We would like to clarify the reconnect behaviour of Diameter peers which
receive DPR. The relevant section in the RFC is 5.4.

Section 5.4 para-1 hints no connection reattempts in the following cases
: 
1. "shortage of internal resources" which  we assume to correspond to
"BUSY" value of Disconnect-Cause AVP  (as in sec 5.4.3). Or  

2. "node in question has no intentions of forwarding any Diameter
messages to the peer in the foreseeable future" which we assume to
correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause
AVP.

But hints connection reattempts in case:
3. "or that the peer has rebooted.  In these cases, the peer may
periodically attempt to reconnect, as stated in Section 2.1" which
corresponds to "REBOOTING" value for Disconnect-Cause AVP.

Is there a need for clarifying the mapping between the value of
Disconnect-Cause AVP and expected behavior? 

Regards,
Vishnu.

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

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

---

From: Rajith R <[email-masked]>
Date: Thu, 01 Jun 2006 11:17:12 +0530

Hi 

	I have some more doubts on section 5.4-para 2 which describes
DPR handling. It says the recipient SHOULD return a DPA with an error
result code if messages are pending on the connection.
	Does this mean that in this case the recipient will not close
the connection? (Because the CM state machine description says on
receiving a DPR, the action is send DPA & Disc) Also when the sender
receives the DPA with result code != DIAMETER_SUCCESS, can we assume it
will also NOT close the connection? (Again, the state machine
description says in closing state, on Rcv-DPA, the action is Disc)

Regards

Rajith

***********************************************************************
This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient's) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: Ram O V Vishnu-A14676 [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 10:47 AM
To: [email-masked]
Subject: [Dime] Disconnect-Peer-Request and connection reattempts

Hi All,

Regards,
Vishnu.

---

From: Shrikantm <[email-masked]>
Date: Thu, 01 Jun 2006 11:25:39 +0530

Hi Ram,

DPR are for graceful disconnect from a node.
So section 5.4 explains about such graceful disconnections.

On the other hand for non-graceful disconnection, other peer cannot know the
reason for the disconnect (because it may not receive any DPR). 
So in such a situations, the peer may periodically attempt to reconnect, as
stated in Section 2.1.  

Thanks,
Shrikant

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: Ram O V Vishnu-A14676 [mailto:[email-masked]] 
Sent: 2006, June 01, Thursday 10:47 AM
To: [email-masked]
Subject: [Dime] Disconnect-Peer-Request and connection reattempts

Hi All,

Regards,
Vishnu.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 01 Jun 2006 09:48:06 -0400

Hi Rajith,
> the connection? 
This seems to be what is implied in 5.4 since it states that the DPR is 
"intent" to disconnect and attempts to provide some leniency to 
in-flight messages. One possible problem with this scheme is that on 
high traffic scenario it is less likely that the DPR/DPA exchange would 
really result in a disconnection. Continuing to exchange subsequent 
DPR/DPA may eventually result in graceful disconnection but I'm not sure 
if this is any better than just closing the connection as described in 
the fsm.

regards,
victor

> (Because the CM state machine description says on

---

From: Rajith R <[email-masked]>
Date: Fri, 02 Jun 2006 11:57:01 +0530

Hi
	
	In my opinion, the intention on DPR/DPA is only to avoid
failbacks for graceful shutdown cases. However the pending requests may
still be subjected to failover.

	I think DP is more suited to be a notification than a
request-response exchange.

Regards

Rajith
************************************************************************
****

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 7:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Disconnect-Peer-Request handling

Hi Rajith,

regards,
victor