Subject: [Dime] Wait-Conn-Ack/Elect State

From: "Ran Arad" <[email-masked]>
Date: Thu, 11 Jan 2007 11:16:48 +0200

Good Day
 
In the peer state machine, the Wait-Conn-Ack/Elect State waits for either to outgoing connection to connect, for it to disconnect, for the remote peer to disconnect the active connection, or for a timeout. When timing out, it ignores the perfectly good connection it already has with the peer, and closes it. It would seem that abandoning the outgoing connection and using the active one would be preferable.
 
Take, for example, two peers, and one has a problem in its DNS table. They try to connect to each other, and while the faulty one initiates a connection to some unknown address, the other connects to it. if the faulty peer never receives a response to it's connection request, the peers will not connect - even if they keep trying to connect, until the DNS table updates. In case we change the timeout behavior to be the same as to "I-Rcv-Conn-Nack", the faulty connection will accept the connection from the other peer.
 
Ran
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Thu, 11 Jan 2007 19:55:33 +0530

Hi Ran,
 I think your suggestion is valid. The 'action' column against  Timeout
event in Wait-Conn-Ack/Elect should have been some thing other than
'Error' . The action can be ignore the out-going connection (in fact
there is no connection yet) and probably we also need to send the CEA to
peer.
 
Prasad. 
 
-----Original Message-----
From: Ran Arad [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 2:47 PM
To: [email-masked]
Subject: [Dime] Wait-Conn-Ack/Elect State
 
Good Day
 
In the peer state machine, the Wait-Conn-Ack/Elect State waits for
either to outgoing connection to connect, for it to disconnect, for the
remote peer to disconnect the active connection, or for a timeout. When
timing out, it ignores the perfectly good connection it already has with
the peer, and closes it. It would seem that abandoning the outgoing
connection and using the active one would be preferable.
 
Take, for example, two peers, and one has a problem in its DNS table.
They try to connect to each other, and while the faulty one initiates a
connection to some unknown address, the other connects to it. if the
faulty peer never receives a response to it's connection request, the
peers will not connect - even if they keep trying to connect, until the
DNS table updates. In case we change the timeout behavior to be the same
as to "I-Rcv-Conn-Nack", the faulty connection will accept the
connection from the other peer.
 
Ran

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 11 Jan 2007 10:16:40 -0500

Hi Ran,

Please see below for comments.

  Thanks,
  Tolga

-----Original Message-----
From: Ran Arad [mailto:[email-masked]]
Sent: Thursday, January 11, 2007 4:17 AM
To: [email-masked]
Subject: [Dime] Wait-Conn-Ack/Elect State

Good Day

In the peer state machine, the Wait-Conn-Ack/Elect State waits for either to outgoing connection to connect, for it to disconnect, for the remote peer to disconnect the active connection, or for a timeout. When timing out, it ignores the perfectly good connection it already has with the peer, and closes it. It would seem that abandoning the outgoing connection and using the active one would be preferable.
[TOLGA]I think one should also consider why the timeout occurs, e.g. the peer going down or some other reason like the DNS update problem you mentioned below.

Take, for example, two peers, and one has a problem in its DNS table. They try to connect to each other, and while the faulty one initiates a connection to some unknown address, the other connects to it. if the faulty peer never receives a response to it's connection request, the peers will not connect - even if they keep trying to connect, until the DNS table updates. In case we change the timeout behavior to be the same as to "I-Rcv-Conn-Nack", the faulty connection will accept the connection from the other peer.
[TOLGA]If you consider the peer not being able to accept/reject the connection because it went down case, it may be more desirable not to establish the Diameter connection. Otherwise, we would wrongly assume that we have an active Diameter connection to that peer, which isn't the case. We would need to wait for watchdog mechanism to detect that the connection is actually down, possibly after we already sent quite some messages to that peer.

For wrong DNS entry case, it sounds better to declare the Diameter connection active. OTOH, not establishing the Diameter connection could also be preferred so that the problem gets immeadiate attentioan and somebody deals witht the wrong DNS entry. 

For the "wrong DNS entry" scenario another important factor is the behavior of the peer which initiated/established the connection. I am not sure how long this peer will wait for CEA after sending CEA, but I think it is very likely that it will drop the connection before the transport connection establishment attempt to the wrong destination times out.

The nice thing about this problem seem to be that whatever behavior one chooses locally, it won't break interoperability.

---

From: "Ran Arad" <[email-masked]>
Date: Thu, 11 Jan 2007 17:59:24 +0200

Good Day

I have considered the interoperability issue: if the remote side did not close its outgoing connection during the timeout, it should not have a problem with it being used.

As for the remote side crash: currently, we decide that an error occurred and close both connections. In the suggested scenario, we close one connection, and try to send CEA on the other - if we get an error than, we can close the other connection as well.

Ran

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 11 Jan 2007 11:15:43 -0500

Hi Ran,

> Sent: Thursday, January 11, 2007 10:59 AM
> To: [email-masked]
> Subject: RE: [Dime] Wait-Conn-Ack/Elect State
> 
> 
> Good Day
> 
> I have considered the interoperability issue: if the remote side 
> did not close its outgoing connection during the timeout, it 
> should not have a problem with it being used.
[TOLGA]Yes, this is true, if the connection is not torn down yet it can be used. I also do not see any interoperability issue, whichevery method one picks. It is just a decision based on the expected behavior for certain cases.
> 
> As for the remote side crash: currently, we decide that an error 
> occurred and close both connections. In the suggested scenario, 
> we close one connection, and try to send CEA on the other - if we 
> get an error than, we can close the other connection as well.
[TOLGA]If you send the CEA, the Diameter connection will be seen locally as active, whereas the peer may be actually down. If the peer crashes, it is not very likely to get an error after sending CEA. Not the end of the world but could be nice to avoid that.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 11 Jan 2007 11:41:34 -0500

> [TOLGA]If you consider the peer not being able to accept/reject the connection because it went down case, it may be more desirable not to establish the Diameter connection. Otherwise, we would wron…

Right.

> For wrong DNS entry case, it sounds better to declare the Diameter connection active. 

This maybe a more optimistic and cause more problems that it tries to 
solve. I think the current state machine takes a cautious approach on by 
closing connections on suspect peers given that we cannot tell why the 
outgoing connection failed.

> OTOH, not establishing the Diameter connection could also be preferred so that the problem gets immeadiate attentioan and somebody deals witht the wrong DNS entry. 
>

Right.

regards,
victor