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

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

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.
- this deadlock can only be broken by restart of the peer (of no fault
of its own!).

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

---

From: Shrikantm <[email-masked]>
Date: Fri, 02 Jun 2006 10:41:51 +0530

Hi Vishnu,

My comments inline.

-----Original Message-----

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. 

 -----Original Message----- 
From:   Shrikantm [ <mailto:[email-masked]>
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, 

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

Regards, 
Vishnu. 

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