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

From: "Kobylarz, Thaddeus" <[email-masked]>
Date: Thu, 7 Jun 2001 11:32:05 -0400

Folks,
	I am concerned that a single connection limitation may interfere
with using Diameter as a 3GPP charging protocol.  I hope that either I don't
totally understand this discussion or that no such limitation is planned.
Thad

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 7:37 PM
To: Mark Eklund
Cc: Cain Brian-BCAIN1; Pat Calhoun; [email-masked]
Subject: Re: [AAA-WG]: Support for multi-process

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

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
> 
> -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: Thu, 7 Jun 2001 08:34:22 -0700

> totally understand this discussion or that no such limitation is planned.

I suspect that you don't understand the discussion.

The general idea is to allow two Diameter processes to communicate over several
transport connections. The protocol behavior is the same, and could be used for
3GPP charging, regardless of the outcome of this particular thread. However, what
it would do is reduce the possibility for packets to be held up at the transport
layer waiting for a retransmission from its peer.

Thanks,

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2001 10:50:22 -0700 (PDT)

In transport-03, the intention was to enable a NAS or proxy to
have connections open to multiple servers for the purpose of
failover/failback and load balancing. Enabling two peers to have
multiple connections between them is a different issue -- and in general 
this can cause problems with congestion avoidance.