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

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Tue, 5 Jun 2001 13:59:44 -0500

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
...
> > a few things.  How do multihoming and ip aliasing interfere 
> w/this model?
> 
> Not a problem since the peer's identity is used, not IP addresses.

I see.  I missed the point of the whole "Server Identification" thread.

...
> Having said that, for those of you have have seen my comments 
> to the transport
> draft, that spec implies that a AAA protocol MUST allow 
> multiple connections
> between peers for non SCTP transports in order to minimize 
> head of line
> blocking.
> 
> Now that's is completely against what we've been doing in the 
> base protocol
> spec, so what do folks think we should do? Single or multiple 
> connections?

Multiple's ok with me, if it needs to be there.  Would/Should we distinguish
between transports when deciding whether to allow an nth connection, or does
this have to be a Pandora's Box of sorts?  (i.e. is this an "all or nothing"
situation?)

-Brian

---

From: "Kobylarz, Thaddeus" <[email-masked]>
Date: Thu, 7 Jun 2001 13:26:57 -0400

Pat,
	Thanks for your clarification.
Thad

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Thursday, June 07, 2001 11:34 AM
To: Kobylarz, Thaddeus
Cc: 'Pat Calhoun'; Mark Eklund; Cain Brian-BCAIN1; [email-masked];
Molchan, John; Engelhart, Bob
Subject: Re: [AAA-WG]: Support for multi-process

On Thu, Jun 07, 2001 at 11:32:05AM -0400, Kobylarz, Thaddeus wrote:
> 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.

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
> Thad
> 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:
> > 
> > > > 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: Cain Brian-BCAIN1 <[email-masked]>
Date: Thu, 7 Jun 2001 13:57:57 -0500

> Sent: Wednesday, June 06, 2001 6:37 PM
> 
> 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
> So given that SCTP will handle the case where two connections 
> occur simultaneously,

Hmm...yeah, probably.  If that is the case, what should the state machine
look like now?

WRT SCTP handling two simultaneous connections, that would probably only
work if you used DIAMETER's well-known port (I guess it wouldn't necessarily
have to be the well-known one, but whichever one you're listening on) as the
local port on outbound connections, right?  Otherwise I can't see how it
would be able to distinguish b/t this case and any other pair of transport
connections between two machines.

> Sent: Thursday, June 07, 2001 9:05 AM
...
>may exist, and they may be maintained. However, after some time, if the
connection
>is deemed to be unnecessary, it can be closed.
>
>PatC

Along those lines: Maybe implementations should just police their
connections at certain intervals.  If you find two connections with the same
peer "Identity", you arbitrarily disconnect one.  Maybe you would send a
message w/DUPLICATE_CONNECTION_DETECTED or
UNNECESSARY_DUPLICATE_CONNECTION_DETECTED, and wait for a response?

-Brian

---

From: "Kobylarz, Thaddeus" <[email-masked]>
Date: Thu, 7 Jun 2001 15:38:06 -0400

Bernard,
	Thanks for your reply.  I agree with the point of congestion control
problems.
Thad

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, June 07, 2001 1:50 PM
To: Kobylarz, Thaddeus
Cc: 'Pat Calhoun'; Mark Eklund; Cain Brian-BCAIN1; [email-masked];
Molchan, John; Engelhart, Bob
Subject: RE: [AAA-WG]: Support for multi-process

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. 

don't

---

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Mon, 11 Jun 2001 15:50:34 -0500

> From: Jacques Caron [mailto:[email-masked]]
> 
> At 19:38 11/06/01, Pat Calhoun wrote:
> >But what if the remote box was periodically trying to 
> connect to the local
> >box? That would always fail with 'Address already in use', 
> since you'd already
> >bound a file descriptor on port 1812 for listening.
> 
> Nope, it won't fail. It will fail only if there is already a 
> connection 
> between the two machines.

I think that this is a less-popular usage of sockets, but it seems like it should certainly work.  For locally initiated connections, some ephemeral port is usually used.  But, like Jacques says, that's not how it has to be.  I'm under the impression that you would have to enable an option like "SO_REUSEADDR", or something along those lines.  That option (or whichever one it's supposed to be) should allow you to bind to a port that is already used in a listening socket.  If there already is a connection with that particular Diameter Entity (presuming all entities follow the prescribed "make sure you're contacting other hosts from the same port you're listening on"), only then should the attempt to bind fail.

I'd be curious as to what would happen in the "crossing SYN" case for TCP.  Supposedly this would not be an issue for SCTP.

...
> Not a problem. Remember that the uniqueness requirement is on 
> the tuple 
> (local addr, local port, remote addr, remote port), not on 

Don't forget transport protocol!

> (local addr, 
> local port).

---

From: Jacques Caron <[email-masked]>
Date: Mon, 11 Jun 2001 22:55:38 +0200

At 22:50 11/06/01, Cain Brian-BCAIN1 wrote:

>I think that this is a less-popular usage of sockets, but it seems like it 
>should certainly work.  For locally initiated connections, some ephemeral 
>port is usually used.  But, like Jacques says, that's not how it has to 
>be.  I'm under the impression that you would have to enable an option like 
>"SO_REUSEADDR", or something along those lines.  That option (or whichever 
>one it's supposed to be) should allow you to bind to a port that is 
>already used in a listening socket.  If there already is a connection with 
>that particular Diameter Entity (presuming all entities follow the 
>prescribed "make sure you're contacting other hosts from the same port 
>you're listening on"), only then should the attempt to bind fail.

Indeed, SO_REUSEADDR and/or SO_REUSEPORT are quite useful :-) Still have to 
understand the exact distinction between those two, though.
And it should be the attempt to connect, not to bind, that would fail.

>Don't forget transport protocol!

I was talking in the context of TCP of course :-) Other transport protocols 
might have different rules for uniqueness...

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 18 Jun 2001 10:25:24 +0200

See comments.

> From: David Mitton [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 10:14 PM

> Only one process can be listening on a given port number at a 
> time.   When 
> the listening process accepts the connection (at least on Unix) a new 
> socket is created, and typically it is given a new unique 
> ephemeral port 
> number. The original port number is not needed, as the 
> connection has been 
> made.
> 
> The listening process can spawn subprocesses or threads to 
> handle that 
> connection socket, but it still holds the listening well-known socket.

It seems to be still unclear how could 2 servers can connect with each other,
especially in the case of multi-process support. I guess that 
it should be possible for 2 servers to establish several TCP connections
using the same destination IP and port number, whenever the receiver can span 
the connections within its system properly. I understand that it is not desired
when the receiver does not support that functionality, but then it simply has
to reject the extra connections, or configure the initiating servers correctly.

The thing is that I would prefer to have interoperability with such a feature,
i.e. allowing servers to connect with each other with a number of permitted
connections to the same IP and port number in order to allow such a possible
configuration. We should also consider systems having a Load Balancer and a VIP,
in which case it is possible to load balance the connections to several
servers within the cluster, having only one IP and port number. Then, it is quite
obvious that it would be nice to have several connections between 2 servers.

In the actual draft, how should the initiating server be configured for doing so? 
Was the idea of supporting several processes on the same machine intended 
for the same Host identity or not? It seems that the only
way it could work is by defining a different host identity for each of the 
server instance of the machine, am I right?

> If you need to run different server "instances" on the same 
> system, they 
> have to listen to connections with distinct socket numbers, 
> (that's how IP 
> knows where to deliver your packets) or you partion your 
> implementation 
> internally.
> 
> So far, I thought the URI would include the ability to configure a 
> non-default target (listening) port number which would be 
> critical to doing 
> this.
> 
> Dave.

Martin

---

From: "David Mitton" <[email-masked]>
Date: Mon, 18 Jun 2001 11:05:06 -0400

At 6/18/01 04:25 AM -0400, Martin Julien (ECE) wrote:

> > From: David Mitton 
> [<mailto:[email-masked]>mailto:[email-masked]]
>especially in the case of multi-process support.

I'm afraid I don't know what you are unclear on?

>I guess that
>the connections within its system properly.

This is done all the time with any multi-user server.  The classic example 
would be FTP or Web services.  There are well known ports that all 
connections are directed to, and the server manages the multiple 
connections within the process framework of that OS and network stack.

>I understand that it is not desired

Servers should be written to handle more than one connection, where each 
connection is from a different peer.

The only problem we are trying to address, is making sure that one set of 
peers has only one connection between them.

>obvious that it would be nice to have several connections between 2 servers.

The IESG has said No.  This violates the methods of network congestion 
control.  Load balancing across different systems is not the same as 
multiple connections to the same system.

>In the actual draft, how should the initiating server be configured for 

lost me here...

>for the same Host identity or not?

No.  Typically running separate processes on the same machine is done for 
the purpose of hosting _different_ identities.  An ISP or ASP may find it 
easier to build multiple infrastructures using the same code, but different 
configurations.

Or he may have a couple of specific proxy agents that address different 
types of requests.

>It seems that the only

bingo!

Dave.

------------------------------------------------------------
David Mitton                            ESN: 248-4570
Advisor, Nortel Networks                 978-288-4570
Wireless Solutions, IP Mobility
Billerica, MA 01821               [email-masked]