Subject: [Dime] Diameter Overload - Host vs Connection Scope

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 14 Jul 2013 12:49:13 +0000

Ben,

Is there a need for both Connection and Host Scopes? If so why?

Thanks,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Labs
[email-masked]<mailto:[email-masked]>
+1-609-903-3360

---

From: Ben Campbell <[email-masked]>
Date: Sun, 14 Jul 2013 12:49:49 -0500

> Is there a need for both Connection and Host Scopes? If so why?

I'm on the fence on this one. I think we definitely need Connection. I have mixed feelings about Host.

Many large capacity Diameter implementations are built as clusters of boxes, or blades on a shelf. In my experience, these clusters often present themselves as a single Diameter node. This creates situations where two peers may have many transport connections between them.

On the surface, this seems to argue for "Host", since you could theoretically send a single report on one connection, and have it affect all connections to that host. It might also have an advantage in preventing a node from opening new connections to an already overloaded peer.

On the other hand, it's not always easy to know that two different transport connections actually terminate on the same host. So even if one were to send a report at the Host scope, one is likely to still need to send it on all open  transport connections. If so, then the advantage of Host may go away. The Host scope could also imply a need for all of the blades in a "node" to synchronize their views of peer overload state. I suspect this may be difficult for some implementations.

So I lean towards thinking we need Connection, but that Host may be redundant. But I would like to hear any arguments to the contrary.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 16 Jul 2013 09:23:55 +0000

Hi Ben and all

About Host, as Ben, I also think it is redundant. If a cluster is overloaded, it can send overloaded info on its different connections. I do not see the optimisation brought when sending a Host Scope, of which the overload info would apply to all the connections with this Host, compared to sending overload info on each of the connections.

Best regards

JJacques

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : dimanche 14 juillet 2013 19:50
À : DOLLY, MARTIN C
Cc : [email-masked]
Objet : Re: [Dime] Diameter Overload - Host vs Connection Scope

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

---

From: Eric McMurry <[email-masked]>
Date: Tue, 16 Jul 2013 06:50:54 -0500

Hi JJaques,

The optimization comes into play when there are a large number of connections between elements.  However, it may still be difficult to use, for the reasons that Ben outlined.  So, I tend to agree that at a minimum it shouldn't be mandatory and may not be useful.

I'm curious if others have counterpoints where they think they would use this scope.

Thanks,

Eric

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Jul 2013 15:48:59 +0300

> Many large capacity Diameter implementations are built as clusters of boxes, or blades on a shelf. In my experience, these clusters often present themselves as a single Diameter node. This creates…

Erm.. lets be exact with the terminology here. In the above do you mean
by "two peers may have many transport connections between them" that these
many connections are between exactly two DiameterIdentities?

Anyway, IMHO I assumed that the connection scope could be identified by
IP addresses and the host scope by DiameterIdentities. 

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Jul 2013 09:37:02 -0500

> many connections are between exactly two DiameterIdentities?

Yes. Whether it was intended by the protocols or not, it does occur in the field.

> IP addresses and the host scope by DiameterIdentities. 

The connection scope in draft-roach-dime-overload-ctrl treats the "Connection" scope to mean "this connection". That is, the connection on which you receive the report. That indirectly maps to the 5-tuple of the transport connection, but that's the transport layer's problem to figure out.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 18 Jul 2013 19:07:49 +0000

Hello all,

I think there may be some cases where "host" could be useful, e.g. a client that opens a pool of transport connections (n+k) (then it knows to which host the connections are linked, in fact the pool is managed as a single logical connection) to  a (multiple node) cluster server. In case there is a common resource to all the cluster nodes (e.g. a database) that could get overloaded, it could be useful to simply use "host" scope, since it applies to the whole cluster (and then to the single logical connection). 

But it is true that in this case, we could convey overload/load information to the client to be able to react against this situation using "Connection", or even "Application", then I presume we need to look for the minimum set of scopes, and here minimum would mean that we cannot convey required information without them.  Therefore, I think "host" is not into this "minimum set" of scopes.

Best regards
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: jueves, 18 de julio de 2013 16:37
To: Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] Diameter Overload - Host vs Connection Scope

On Jul 18, 2013, at 7:48 AM, Jouni Korhonen <[email-masked]> wrote:

> Erm.. lets be exact with the terminology here. In the above do you 
> mean by "two peers may have many transport connections between them" 
> that these many connections are between exactly two DiameterIdentities?

> 
> Anyway, IMHO I assumed that the connection scope could be identified 
> by IP addresses and the host scope by DiameterIdentities.
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Jul 2013 23:54:42 +0300

> Yes. Whether it was intended by the protocols or not, it does occur in the field.

No problem with that. Just wanted to make sure the above really refers
to "multiple instances" transport connections.

> The connection scope in draft-roach-dime-overload-ctrl treats the "Connection" scope to mean "this connection". That is, the connection on which you receive the report. That indirectly maps to the…

Ack. It would be slightly more easier to make the distinction between these
two scopes if the actual underlying Diameter functionality were referred. As
far as I understood, connection scope allows me to differentiate a specific
transport layer connection when multiple instances is used. Is this correct?

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Jul 2013 15:48:51 -0500

> transport layer connection when multiple instances is used. Is this correct?

Yes, that is true, although I would say that the Connection scope allows you to specifiy a specific transport layer connection, regardless of the number of connections that might exist with the peer.