Subject: RE: [AAA-WG]: Support for multi-process

From: Mark Eklund <[email-masked]>
Date: Wed, 6 Jun 2001 19:34:19 -0400 (EDT)

Brian,

Thanks for the comments.  I think this state table will work
well for TCP, but Tony Johansson demonstrated that this state
table may not work well for SCTP (see Issue #67: How to deal
with CER and CEA in the case of SCTP).  I'll have to think about
that.

As to your comment about waiting until all state machines know
the identity of the peer they're connected to, I think that
could cause a deadlock.  If you have two peers (P1 and P2)
attempting to connect at exactly the same time, you will have an
initiated and responding state machine for each.  P1-I sends a
CER and P1-R has just received a CER.  P2-I sends a CER and P1-R
has just received a CER.  The state machine of P1-I does not
know the Diameter-Identifier of P2 so an election can't happen
on P1.  The same thing is happening on P2.  Deadlock.

Let me try to explain the logic behind the locking mechanism.
Consider the following time-line.

     ________Conversation A________  ________Conversation B________		   
Time P1-I          P2-R              P1-R            P2-I           
 1                                                   Start         
 2                                   Rcv-Conn-Req                  
 3   Start                                           Rcv-Conn-Ack  
 4                                   Rcv-CER                       
 5                                   Locked                        
 6                 Rcv-Conn-Req      Elect                         
 7   Rcv-Conn-Ack                    No-Contest                    
 8                 Rcv-CER *                         Rcv-CEA *     
 9                 Elect            	             Elect                

This is the point where there is a problem without locking.  Both P2-R
and P2-I are not aware that the other has made a connection at exactly
the same time.  Since they will be changing the same state machine at exactly
the same time, who knows what will happen.

As far as I can tell, there is only one minor way this could go wrong
without locking.  That is when they both think they succeeded.  If
that happens, P2 could assume that there are two simultaneous
connections.  This should only last a brief moment.  After P2-R sends
the CEA, P1-I will have an election and disconnect one of the
connections.

Maybe this is an implementation detail and doesn't need to be a part
of the state machine.  Maybe some text warning of this is
sufficient without the need of a state machine.  Do you have an
opinion?

-mark						   

On Wed, 6 Jun 2001, Cain Brian-BCAIN1 wrote:

> > -----Original Message-----
> > From: Mark Eklund [mailto:[email-masked]]
> > Sent: Wednesday, June 06, 2001 9:40 AM
> >
> > Brian,
> ...
> > process and are listed below.  Could you give your O.K. on
> > those?
>
> Hmmm..I never got a chance to go over the last version in detail, so here's
> my comments on the revised version:
>
> I'm relieved to say that it seems simpler than the previous version (the one
> w/"Wait-R-DRI/Elect", etc., not your previous suggestion).
>
> I like the new election scheme, it answers some questions I had.  I think
> the only suggestion I could offer would be some text that would advise
> Election implementations to wait until all state machines know the identity
> of the peer they're connected to (i.e. wait until they've received the Cap.
> Exchange) before returning a "No Contest" verdict.  Maybe it's restating the
> obvious (or overstepping the bounds of the doc), maybe not...
>
> Why do we lock on the Election?  Am I correct in assuming that each
> transport connection/state machine performs its own election?  Why is it bad
> to have two concurrent elections?  This kinda makes sense, but I must just
> be missing something.  (Does it relate to the above comment about waiting
> for the CE message, maybe?)
>
> PS - Terminology update: Device Reboot -> Capabilities Exchange
> (s/DR(R|A)/CE$1/g). (Also pertains to "*-Non-DRI" events, etc.)
>
> -Brian
>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 6 Jun 2001 16:36:56 -0700

On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote:
[lots of great stuff deleted]
> Do you have an

I do. We seem to be going out of our way to ensure that we only have a single
connection, but both Bernard, and others, have indicated that multiple connections
MAY be necessary (at least for TCP).

So given that SCTP will handle the case where two connections occur simultaneously,
is this all now overkill?

:(

PatC

---

From: Mark Eklund <[email-masked]>
Date: Thu, 7 Jun 2001 09:52:43 -0400 (EDT)

Pat, 

> MAY be necessary (at least for TCP).

Are you talking about a connection to two different processes on
the same server?

Are you saying that there will be two (or more) connections to
the same process on the same server?  

Is this for redundancy?  I.E. connect through two interfaces so
if one goes down, the connection still exists.

> is this all now overkill?

This helps distinguish two things for TCP.
1. Server A and Server B simultaneously connecting to each  other.
2. Multiple processes connecting to Server B.

Depending upon the answers to my previous questions, this may be
overkill.  Or it might be the wrong state table that needs to be
replaced by a new one that is equally complex.

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 7 Jun 2001 07:05:14 -0700

> if one goes down, the connection still exists.

No. For TCP, they want to simulate streams by opening multiple connections.
People have stated on the list that they want this functionality, as has Bernard
and it is included in the transports draft.

> replaced by a new one that is equally complex.

So the way that the transport draft is written is that multiple connections
may exist, and they may be maintained. However, after some time, if the connection
is deemed to be unnecessary, it can be closed.

PatC