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

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Mon, 5 Jun 2006 15:30:13 +0800

Shrikant,

Thanks for your clarifications. But I think still there is a need to
clarify the mapping between Disconnect-Cause AVP and the reconnect
behaviour. Please see my comments.

[Shrikant]: I think still you haven't read the section 5.4 clearly...It
clearly says, " If a peer receives a DPR, then it shouldn't reconnect.
However if peer has a valid reason (e.g., message to be forwarded) it
can reconnect."
Vishnu>> What happens in a high-traffic scenario? The peer (the client)
will always have something to sent/forward. Hence it will always
reconnect. This nullifies the DPR/DPA procedure. Hence there should be
some DPR Disconnect causes which helps the peer to understand that now I
should not reconnect. Say for example: if the Disconnect-Cause AVP is
REBOOTING then reconnect. Else if the Disconnect-Cause AVP is BUSY ||
DO_NOT_WANT_TO_TALK_TO_YOU then do not reconnect.
Please note that this is very similar to the scenario which
Rajith/Victor described in another email thread where DPA with failure
is sent.

[Shirkant]: I think we may be having the list of the scenarios which
tells, when the peer can re-connect to a node after receiving DPR.
Vishnu>> All what we are saying is that such a list should contain
certain conditions based on the DPR Disconnect causes as well. If you
leave it to the peer alone to decide when to reconnect, there would be
cases in which (say, in a high-traffic scenario) DPR is of no use and a
BUSY node is swamped with reconnect attempts.

Regards,
Vishnu.

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

-----Original Message-----
From: Shrikantm [mailto:[email-masked]] 
Sent: Friday, June 02, 2006 10:42 AM
To: Ram O V Vishnu-A14676; [email-masked]
Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts

Hi Vishnu,

My comments inline...

-----Original Message-----
From: Ram O V Vishnu-A14676 [mailto:[email-masked]] 

That's what I thought too, till I read the para-1 of section 5.4 a
little more carefully. Ideally, we would like to get comments from the
authors.
This is potentially a problem in deployments because of the following
scenario: 
- A node (especially servers) does not initiate connections but expects
peers (read clients) to know about it & connect to it. Such behaviour
may be justified by the fact that dynamic peer discovery is not
supported and that static configuration of large number of peers is
considered unwieldy.
- As per what you are saying such a node cannot send DPR, because if it
does, the peers (read clients) will not attempt reconnection. This will
result in a scenario where there is no connection at all & neither party
is attempting too.
[Shrikant]: I think still you haven't read the section 5.4 clearly...It
clearly says, " If a peer receives a DPR, then it shouldn't reconnect.
However if peer has a valid reason (e.g., message to be forwarded) it
can reconnect."
-          this deadlock can only be broken by restart of the peer (of
no fault of its own!). 
[Shrikant]:: No need to restart the peer.If peer wants to communite for
valid reson,then it can re-connect to a node neglecting DPR/DPA.

I think we may be having the list of the scenarios which tells, when the
peer can re-connect to a node after receiving DPR.

Thanks,
Shrikant

-           Out intent to clarify the mapping between Disconnect-Cause
AVP and the reconnect behaviour was to solve these kind of problems.
Regards, 
Vishnu. 
Motorola India Electronics Pvt Ltd 
+91 9844178052 
[*] Motorola Internal Use Only 

 -----Original Message----- 
From:   Shrikantm [mailto:[email-masked]] 
Sent:   Thursday, June 01, 2006 11:26 AM 
To:     Ram O V Vishnu-A14676; [email-masked] 
Subject:        RE: [Dime] Disconnect-Peer-Request and connection
reattempts 
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, 
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