Subject: [Dime] New Overload Solution Approach

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Jul 2013 09:58:53 +0200

Hi all, 

I submitted a new approach for dealing with overload signaling in Diameter. 

There are three documents: 

- ----------

1) Document with architectural principles and the information model
http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt

2) The Diameter Load Balancing Application (DLBA) that specifically provides the ability to exchange information for load balancing
http://tools.ietf.org/id/draft-tschofenig-dime-dlba-00.txt

3) An mechanism to piggyback overload information from the Diameter server to the Diameter client
http://tools.ietf.org/id/draft-tschofenig-dime-overload-piggybacking-00.txt

- ----------

Probably the most important question is the following: What motivated me to write these documents? The answer is pretty simple: I was unhappy with the complexity introduced by the Tekelec proposal. I wanted to create a simple foundation that can then be extended on a need-by-need basis (as we do with other Diameter applications as well). I was wondering how to simply it. 

Ciao
Hannes

PS: There are various reasons for the complexity in the Tekelec solution proposal. I have captured some of those reasons (but not all) in draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I designed this solution approach in a modular fashion. For example, a deployment may choose not to use the load balancing component (as such it is optional) in case there is no load balancing between different servers (for a given Diameter application) or in case load balancing is accomplished using other techniques. (Needless to say that companies have used load balancing in Diameter before this work has started.)

---

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Tue, 16 Jul 2013 17:17:38 +0200

> I submitted a new approach for dealing with overload signaling in Diameter.
...

>5.2.2 Period-Of-Validity AVP
...
>  The maximum value in this AVP is 5
>  minutes, which is also the default value.  If this AVP is absent in a
>  subsequent message then the indicated value is valid till the next
>  overload report is received.

That seems unclear to me. So if the host doesn't send an overload report for 6 minutes it can effectively achieve a value larger than 5 minutes?
The limit of 5 minutes seems a bit arbitrary to me.

>5.2.3.  Overload AVP
...
>   NO_OVERLOAD                  0  The Diameter server uses this value
>      to indicate that it is currently not overload and that the
>      Diameter client should not reject any request.

I suggest that instead of "reject any request" to use the language used in the other values:

   NO_OVERLOAD                  0  The Diameter server uses this value
      to indicate that it is currently not overloaded and that the
      Diameter client may send further requests.

>5.3.2.  Load AVP
>   The Load AVP (AVP code TBD) is of type Unsigned32.  The indicated
>   value MUST be between 0 and 10.

The range 0..10 seems a bit arbitrary to me. Why not 0..99?

Or 0..2^32-1
The values cannot be compared between servers anyway, the range may not be linear, it may be asympmatic, so why not let servers report as they see fit and only require that 0 means no load, and 2^32-1 means extreme load, and that values between those two extremes means a load between those to extremes (non-descending).

/isj

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 17 Jul 2013 00:00:26 +0300

Hannes,

I got a quick question to understand these documents a bit better.
What is the essential difference to e.g. draft-korhonen-dime-ovl
apart from being a stripped down version of it more or less?

- Jouni

On Jul 16, 2013, at 10:58 AM, Hannes Tschofenig <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi all, 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBCgAGBQJR5P0+AAoJEGhJURNOOiAtwQwH/AltiRpY0rOx0J4KMRM7ZELn
> 13mfj4ctQrn8qTDtlS2xE0V40lGPzfstcbaWQiKhVtiZePB1kFusWYUXyhST6p0A
> grXolprsL4vl+wZifGSkwny62/VJbNkjQ7coiiQrutcInUmXV8IUjsXntK7KjHfX
> sh6r6pCVLNRwh8SaJzbxogItssb2+StpbDgDvryNFVL9TgYhdg8XMRCN/4RgqP7D
> QObBw3/TBORrE3RAYmOo/hF3zPf6qiw8bePh51uW7Ve+hgEzYuuxYdByFFlkSEKq
> sZUUXFMnrEs1sr+uzhLOtg5o9e1z9G78V9Ye1G5it+zU+qoBwdSr6m2/Dzpsqj8=
> =dADz
> -----END PGP SIGNATURE-----
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Jul 2013 11:38:23 +0200

Hi Jouni, 

a very direct question. 

There are two differences: 

1) The load balancing and the overload communication is separated into two independent documents. I believe they are different in their nature. While this may be seen only as a document handling issue many companies already have solutions for load balancing in use today. They are quite likely going to re-use their existing stuff while they may still be interested in the end-to-end overload signaling.

2) The overload signaling uses a piggybacking approach and it more or less extends what is in the base specification. While the functionality in the Diameter base specification is quite simplistic I am not convinced that a minor add-on is not sufficient to solve the overload problems we have seen today. 

As you mentioned, it is also stripped down. While each feature in the OVL draft has a purpose it is nevertheless an optimization. There is a tradeoff between adding benefits because of the optimizations (in the amount of outsourcing of policy decisions from the Diameter server to the Diameter client / Diameter agents) but there is also a price that is paid for it in form of implementation cost (and license costs for IPR). 

Hope that this makes sense. 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Jul 2013 11:56:54 +0200

Hi Ivan, 

thanks for your quick comments. 

Remarks inline: 

> The limit of 5 minutes seems a bit arbitrary to me.

When the Diameter server communicates to the Diameter client that is in an overload situation it also tells the client to reject further requests that have the same pattern (same domain/same application). 

But for how long should this policy persist? It certainly has to time out after some time since otherwise a misconfiguration messes up the entire system (looking much like a denial of service attack). Hence, there has to be a maximum limit. The value of 5 minutes is indeed arbitrary. It is small enough to avoid security problems but enough to be useful from an overload handling point of view. 

So, if a Diameter server decides that it does not attach this value since it wants to go with the default then after 5 minutes the stored policy is gone. If the Diameter server still experiences an overload situation then it will have to mark a future message again with the overload information.

The last sentence is supposed to indicate that the lack of the overload value does not mean that the overload situation has gone away. Instead is just means that nothing has changed. Maybe I should rephrase the sentence to make this more clear.  

>      Diameter client may send further requests.
Sounds good to me. Thanks for text suggestion. 

> The range 0..10 seems a bit arbitrary to me. Why not 0..99?

The range is indeed arbitrary and it does not really matter what the range actually is. 
I personally have no preference. 0-9, 0-99, A-F, high-medium-low, etc.. The group has decide what they like best. 

> The values cannot be compared between servers anyway, the range may not be linear, it may be asympmatic, so why not let servers report as they see fit and only require that 0 means no load, and 2^3…

Also fine with me.

Regarding the remark that the values cannot be compared between the servers: For load balancing the only thing that matters is that they are mapped appropriately into the available range. If a network operator deploys 2 servers with different hardware configuration then for server "A" 100 additional requests may produce 10% additional load vs. for the other only 1%. If they are both report 50% load to the load balancer then the load balancer does not know about the hardware configuration of these two machines. So, it will (for example) just send half of the incoming requests to server A and half of the requests to server B. What it will then quickly learn is that the load of server  "A", the weaker machine, will increase much faster than with server B. So, it will shift the load over to server B (assuming such an policy at the load balancer). 

Does this make sense? 

Ciao
Hannes

---

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Thu, 18 Jul 2013 12:51:18 +0200

> The last sentence is supposed to indicate that the lack of the overload value does not mean that the overload situation has gone away. Instead is just means that nothing has changed. Maybe I should…

How about:
    The maximum value in this AVP is 5
    minutes, which is also the default value.  If this AVP is absent in a
    subsequent message then the indicated value is valid till the next
    overload report is received or 5 minutes, whichever comes first.

> Regarding the remark that the values cannot be compared between the servers: For load balancing the only thing that matters is that they are mapped appropriately into the available range. If a netw…

Yes.

My main concern about a small value range is that if a load-balancer uses only that then it may result it non-neglible "route flapping". Yes, this is a matter of quality-of-implementation, but let's not give them any excuses.
My other concern was when I considered how to implement such a mapping for the system I work on. It can detect when there is no load, when it is overloaded, and when it is somewhere inbetween. The problem is "somewhere inbetween" where I can only guess (due to large variations in the deployments). That made me question the range 0..10.
I can live the range with 0..10, but I'd prefer the full 2^32 range.

/isj

---

From: Eric McMurry <[email-masked]>
Date: Thu, 18 Jul 2013 06:40:46 -0500

Hi Hannes,

comments inline.

Thanks,

Eric

> 1) The load balancing and the overload communication is separated into two independent documents. I believe they are different in their nature. While this may be seen only as a document handling is…

I see your point here, however, balancing is not orthogonal to overload control.  Also, more importantly, load information is useful for proactive overload control.  How can you do proactive overload control without that sort of information?  Or are you saying that proactive control should be proprietary?

> As you mentioned, it is also stripped down. While each feature in the OVL draft has a purpose it is nevertheless an optimization. There is a tradeoff between adding benefits because of the optimiza…

Of course, engineering is always a balance trying to reduce cost (or other factors) while still meeting requirements.  Have you done a pass through this to see how it maps to requirements?

> iQEcBAEBCgAGBQJR57ePAAoJEGhJURNOOiAtcvoH/0axsXl4bYcZYFFsu3W0NLh7
> +WXnd8zVV6o90kfbDKt+BltMOuF7DEGFs+m6Z5xPDD7uYm3AjLLgimMCYAUC4s7c
> mnNiT9swRIoYgYz2/bqh7bQaH6QRWY1pIhlMb9IsJQXcSGHaCa2bkb4BINKLOG8V
> tPfd40OOmm5cnNp4szyLdln1I8Rend9v9MgRiCF3JB30b/JaIi+QsC/l8KaSDxtc
> nezkWotOtE1J1S1YeV09ViHTAzJOWqxHikilSMg0BKSh+WxcqZVY4lhNfSU2V2h1
> 7OzFXJJFYBVPhSvuoAweDtTqlU0dT9ATWxI37wTjouo4XwHPyUsRv1DSAKmXpyc=
> =4goN

---

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

<no chair hat now>

> Of course, engineering is always a balance trying to reduce cost (or other factors) while still meeting requirements.  Have you done a pass through this to see how it maps to requirements?

A meta question. Does the xyz solution draft need to meet all requirement i.e. if a 
solution is just a subset could it skip e.g. some MUSTs if they plain are not part
of the solution proposal?

- Jouni

---

From: Eric McMurry <[email-masked]>
Date: Thu, 18 Jul 2013 07:28:46 -0500

> of the solution proposal?

Well, wasn't the point of the requirements to figure out and define what solutions need to do?  (Notice I put an 's' on there.  It's possible to use more than one, although that may cause other issues). The net is that the general consensus of all the various experts and stakeholders that contributed to and reviewed the requirements was that the MUST levels were needed for resulting solutions.

So, I think the short answer to your question is no, we should not throw out proposals that don't meet all of the requirements.  However, we should evaluate them against the requirements and understand where they are deficient and how the remaining requirements would be met (or why the requirements were incorrect, in which case I think this would need to be pretty well supported, given the time we have spent on those.  For example, see Ben's analysis draft of one of the SHOULD level requirements).

Thanks,

Eric

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Jul 2013 14:32:29 +0200

That's a good question, Jouni. 

There has to be some minimum level of functionality needed for interoperability and then there might be extra functionality that is optional to implement. 

You are asking me actually two types of questions: 

1) Do both (minimum & extra functionality) need to be described in the same document? 
2) What is the minimum level of functionality?

My response to (1) is that they should be described in different documents (as we are likely going to see different features being proposed over time anyway as people gain more experience with the technology). 

I made a minimalistic proposal for (2). I guess it will be hard to have even less functionality since you are then quickly with the functionality provided in the Diameter base specification (DIAMETER_TOO_BUSY). 

Maybe this is actually a decision that the chairs have to make about how the document management is done. 

I would hope that vendors who have to implement this stuff have some ideas about what the minimum should be. From the mailing list discussion so far I do not have clear view what the different companies are willing to implement. Maybe folks are not that far yet in their company-internal investigations. It is also sometimes hard to say with companies participating in the 3GPP since the standardization people are different from the product people and what is being standardized now may (if things work out great) get implemented in 3-5 years by a completely different set of people.

It might also be worthwhile to point out that more optimizations typically translates to more patents. We have already to deal with the Tekelec patents and who knows what other things are lurking around the corner...

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Jul 2013 14:41:47 +0200

Hi Eric, 

On Jul 18, 2013, at 2:28 PM, Eric McMurry wrote:

> Well, wasn't the point of the requirements to figure out and define what solutions need to do?

The problem with the requirements draft is that it does not give an answer to a number of questions, in particular as far as the level of optimizations goes. As you can see from your own solution proposal there is a lot of complexity sneaks in when you want to support various scopes (as you call them).

Of course, a requirements document does not describe document handling issues either since those are largely the decision of the chairs (IMHO). 

Ciao
Hannes

---

From: Eric McMurry <[email-masked]>
Date: Thu, 18 Jul 2013 08:05:43 -0500

Hi Hannes,

> The problem with the requirements draft is that it does not give an answer to a number of questions, in particular as far as the level of optimizations goes. As you can see from your own solution p…

I agree that optimization is not in there, nor should it have been.  Those are considerations for the solution, and for the implementations.  Any time optimization is done though, it is within constraints.  In this case there have been constraints generally agreed to.

> Of course, a requirements document does not describe document handling issues either since those are largely the decision of the chairs (IMHO). 

I'm pretty sure those requirements didn't describe any document handling issues.  Any statements I made were, of course, my own opinions.  As are any made here when not wearing a hat :-).

thanks,

Eric

---

From: Tom Taylor <[email-masked]>
Date: Thu, 18 Jul 2013 15:51:05 -0400

> of the solution proposal?

[PTT] It seems clear that all agreed requirements must be met 
eventually. The corollary to that is that any partial solution must not 
preclude extension to a solution that meets all of the requirements.

The two issues I see here are:

1) Is it permissible at design time (i.e., within the WG) to roll out a 
complete solution in phases?

2) Is it permissible to devise a solution that can be deployed in 
phases, where the initial phase does not meet all the requirements?

Tom

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Jul 2013 16:17:58 -0500

> The problem with the requirements draft is that it does not give an answer to a number of questions, in particular as far as the level of optimizations goes. As you can see from your own solution p…

Hannes, do you disagree with the requirements draft? If so, it would be helpful to see the details of that sooner than later. The draft has been through WGLC, and is in AD review. It will likely be up for IETF last call soon.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Jul 2013 16:33:13 -0500

On Jul 18, 2013, at 2:51 PM, Tom Taylor <[email-masked]> wrote:

[...]

> [PTT] It seems clear that all agreed requirements must be met eventually. The corollary to that is that any partial solution must not preclude extension to a solution that meets all of the requirements.
> 
> 1) Is it permissible at design time (i.e., within the WG) to roll out a complete solution in phases?
> 

I think that's absolutely reasonable.

> 2) Is it permissible to devise a solution that can be deployed in phases, where the initial phase does not meet all the requirements?

Also reasonable. But you still need to know what requirements you are covering or not. And you need a plan for how to extend things to cover those requirements in the future.

For example, it  (hypothetically) might make sense to separate load balancing and overload control, so that you can deploy the load balancing now, and add the overload control later. But there's a difference between saying " we will phase in the requirements" than there is in saying "we will ignore substantial requirements now and hope we can figure them out (or stop caring) in the future"

And even if we take a modular approach to requirements, evaluating how each component meets requirements would be helpful to select between competing proposals.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Jul 2013 16:38:51 -0500

> I see your point here, however, balancing is not orthogonal to overload control.  Also, more importantly, load information is useful for proactive overload control.  How can you do proactive overlo…

I was going to respond similarly to the draft itself. It may or may not make sense to separate the how you communicate load and overload information. But load info is very important to make sure overload mitigation actions don't just move the problem around, or lead to cascade failures.

---

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

Hi Hannes,

I've got some comments and questions, organized by draft.

draft-tschofenig-dime-overload-arch-00:

-- Section 3:

I actually with most of the architectural principles, although I suspect we might quibble over what's really "premature" or "real-world".

 I'm not sure about the applicability of the "advances in information technology" paragraph. It seems  focus on NFV and orchestration. Operators are certainly thinking about NFV approaches to handling dynamic changes in load. But it don't think we're going to see anything soon that can adapt fast enough to avoid the need to push back against offers load. However, I think this argues even more for the ability to rapidly report changes in overload state due to dynamic changes in capacity. It's also likely to add complexity to the load balancing problem.

I agree that delegation of rejection policy creates complexity. That's where a lot of the question of scope comes from in some of the earlier drafts. OTOH, a "request rejection policy language" seems like jumping off into that complexity with both feet.  I also don't see anything about that in the data elements.

-- section 4:

Did you intentionally exclude a scenario for where an agent becomes the "PEP"?

-- Section 5: 

I'm a bit confused by mixing fairly abstract architectural principles with concrete AVPs.

draft-tschofenig-dime-dlba-00:

-- Section 1, last paragraph:

By "prevent", did you mean "allow"?

-- section 4:

The use of PPID is interesting. I wonder if that's an alternative for declaring that a message contains overload information in either of the piggybacked proposals.

draft-tschofenig-dime-overload-piggybacking:

-- As others have mentioned, I'd like to see your thoughts on how this meets the requirements, and what our plan to handle any non-covered requirements might be if we select this approach.

-- section 1: 

Am I correct to understand this is client-server only? That is, an agent could not take action to abate overload?

-- 3.1:

The Supported-Features AVP might be useful for non-adjacent overload capabilities exchange. I seem to remember that coming up in the past, but that it was only defined for certain applications? I guess we can always make it required if you support Overload Control.

-- 3.2:

In non-trivial topologies, the client can rarely identify "all traffic bound to server A". How does it know which requests to apply the rejection policy to?

ALso, how does this scale to large numbers of clients?

More inline:

[...]

[...]

Am I correct in that your complain is at least somewhat targeted to the overload scope concept? Have you had a chance to read my draft on that subject? I am concerned that, without some ability to express the set of requests an abatement policy applies to, you're likely to either reduce all traffic without discrimination, or you are likely to just chase problems around the network.

The operators I have spoken with are extremely worried about an overload solution that results in oscillation or cascade failures. 

> PS: There are various reasons for the complexity in the Tekelec solution proposal. I have captured some of those reasons (but not all) in draft-tschofenig-dime-overload-arch-00.txt. To reduce compl…

I'm not necessarily opposed to modularity. But I do expect that we would evaluate an overload control module proposal against all the relevent overload control (as opposed to load balancing)requirements, or at least want to understand the mechanisms for extending it to support more of the requirements.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 29 Jul 2013 15:36:56 +0300

Hannes,

> 2) The overload signaling uses a piggybacking approach and it more or less extends what is in the base specification. While the functionality in the Diameter base specification is quite simplistic…

Ok. So you are leaning away from a specific overload control application. I also recon you define a new Supported-Features AVP. Is this anyhow aligned (or to be aligned) with 3GPP TS29.229 Supported-Features AVP?

- Jouni

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 31 Jul 2013 22:44:40 -0400

I am just commenting on the architecture document, and then only on the 
overload part- not the load sharing part.

This draft seems to miss the point that, in order to avoid congestion 
collapse, the server must ask the client to reduce the number of messages 
sent BEFORE it becomes overloaded - not wait until it IS overloaded to 
either reject messages or send requests for load reduction to the clients.

I agree that overload conditions are, we hope, rare events.  None the 
less, it is DURING these overload events that a working AAA system may be 
most important.

In section 3, the draft seems to suggest that a choice to “return reject 
responses without engaging in heavy application specific processing” is a 
viable option.  It is exactly the processing needed to “return reject 
responses” that leads to congestion collapse, as has been shown, among 
other places, in the SIP Overload Modeling.   (It may sometimes be more 
effective to just consider an overall “server overload”, rather than 
calculating separate overload controls for each “application”, etc.)

Similarly, in section 4.1, the draft suggests that use of 
DIAMETER_TOO_BUSY is a viable approach to handling overload.  As I 
understand it, this approach suffers from the same weaknesses as the SIP 
503 response (w or w/o “retry after”), and will rapidly lead to congestion 
collapse in sustained overloads.  In fact, section 5.2 of the requirements 
draft goes into some depth explaining why DIAMETER_TOO_BUSY is not a 
viable solution to DIME Overload.

This draft proposes only four options for Overload Control:

NO_OVERLOAD ( do not reject any requests)

INCREASING_OVERLOAD (calculate your sending rate over the last 10 minutes, 
and limit your new rate to 50% of that)

DECREASING_OVERLOAD (calculate your sending rate over since the last 
overload message, limit your new rate to 110% of that)

OVERLOADED (STOP sending any requests)

In the absence of lab tests or simulation results to the contrary, this 
seems to have several shortcomings
·       If a client is inactive much of the time, this approach may shut 
it down completely
o       If a particular client, for whatever reasons, transmitted 0 (zero) 
requests in the last 10 minutes, the INCREASING_OVERLOAD will pin it at 0 
(probably unnecessarily) until there is NO_OVERLOAD.
o       If a particular client, for whatever reasons, transmitted 0 (zero) 
requests since the last overload message, the DECREASING_OVERLOAD will 
still pin it at 0  (110% of  0 = 0) (probably unnecessarily).  Each 
subsequent DECREASING_OVERLAOD will still pin it at 0, until there is 
NO_OVERLOAD
·       If overload is building gradually, then a 50% cut is probably 
overkill, and is likely to lead to (possibly unstable) oscillations, in 
the load at the server.  If the server only NEEDS a 10% reduction in load 
to stay in the “stable” zone, this approach  will need  7 message (cut by 
50% once, then increase by 10% six times -  if I am calculating correctly 
-  assuming a constant load coming into the client) to get the needed 
correction.
·       If overload is increasing rapidly the 10 minute lead time is WAY 
too long ( for the kinds of “events” I regularly analyze – Tornados, 
Earthquakes, Boston Bombing- the various loads typically increase by more 
than an order of magnitude in less than 5 minutes.  Maybe there is 
something about DIAMETER that makes it immune to these bursts, but I doubt 
it).
·       As has been discussed many times on both on this list and the SIP 
Overload list, there are many applications/architectures/contexts in which 
it is far more effective to instruct the client to honor a specific rate 
(X messages per second) rather than a percent reduction (whether as a 
percent of incoming messages, or as a percent of your recent historical 
rate).

participating remotely,
Janet

From:   Hannes Tschofenig <[email-masked]>
To:     [email-masked]
Date:   07/16/2013 03:59 AM
Subject:        [Dime] New Overload Solution Approach
Sent by:        [email-masked]

Hi all, 

I submitted a new approach for dealing with overload signaling in 
Diameter. 

- ----------

2) The Diameter Load Balancing Application (DLBA) that specifically 
provides the ability to exchange information for load balancing
http://tools.ietf.org/id/draft-tschofenig-dime-dlba-00.txt

3) An mechanism to piggyback overload information from the Diameter server 
to the Diameter client
http://tools.ietf.org/id/draft-tschofenig-dime-overload-piggybacking-00.txt

- ----------

Probably the most important question is the following: What motivated me 
to write these documents? The answer is pretty simple: I was unhappy with 
the complexity introduced by the Tekelec proposal. I wanted to create a 
simple foundation that can then be extended on a need-by-need basis (as we 
do with other Diameter applications as well). I was wondering how to 
simply it. 

Ciao
Hannes

PS: There are various reasons for the complexity in the Tekelec solution 
proposal. I have captured some of those reasons (but not all) in 
draft-tschofenig-dime-overload-arch-00.txt. To reduce complexity I 
designed this solution approach in a modular fashion. For example, a 
deployment may choose not to use the load balancing component (as such it 
is optional) in case there is no load balancing between different servers 
(for a given Diameter application) or in case load balancing is 
accomplished using other techniques. (Needless to say that companies have 
used load balancing in Diameter before this work has started.)