Subject: RE: [Dime] Disconnect-Peer-Request handling

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Fri, 2 Jun 2006 10:54:29 +0800

Victor,

We agree with your last sentence. We are not sure about the value in DPA
carrying an error and receivers not disconnecting based on it. Because
in many cases receivers may not be in a position to wait (say, in some
cases of REBOOTING).

Regards,
Vishnu.

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

-----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,
> 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?
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
> 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,
>
> 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
>
>
> _______________________________________________
> 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