Subject: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Jan 2013 10:06:23 +0200

Hi all, 

I have a remark regarding requirement 2:
"
 REQ 2:   The mechanism MUST allow Diameter nodes to support overload
          control regardless of which Diameter applications they
          support.
"

While this sounds completely right there is also a question about what
do to in case of overload. The current requirements document focuses
largely on the task of conveying overload information to other Diameter
nodes and does not really say what should happen in case of overload.
One can imagine that load is moved from one server to the other one but
that only works in a limited extend. So, what happens if there is a real
overload situation? 

In this case the AAA client needs to start take some actions that
are application specific. For example, for certain Diameter applications
it may be OK to suppress certain messages and thereby to gracefully
reduce functionality or to reject some requests from certain end hosts
altogether. What the right action is heavily depends on the specific
Diameter application. In that case the specification of the Diameter
application needs to be extended with information about what to do in
overload situations. This is of course in contradiction with the
requirement above but certainly appears useful to think about what to do
in those cases. Just dropping Diameter messages by a Diameter
intermediary is not particularly useful since this may lead to timeouts
and retransmissions (depending on what is specified in a given Diameter
application).

In order for a Diameter node to do something useful in situations of
overload it may need to have some additional information about what the
problem is. This may get fairly complicated pretty quickly. Even for a
simple load balancing scenario, for example, it does not make sense to
forward requests to a new server when a shared backend database is not
reachable. 

So, I am wondering where to draw the line here. The requirements
document stops fairly early and is silent about this issue. The solution documents on
the other hand tend to look more sophisticated already and contain
functionality that is not mentioned at all in the requirements draft. As
an example, take a look at the concept of "scopes" in
http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope is
essentially a way to provision the Diameter routing table of a different
Diameter node.

Ciao
Hannes

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 24 Jan 2013 08:15:28 -0500

I would have thought that was covered by the concept of "local policy", 
and would be out of scope for THIS draft.  Possibly the topic for a 
different draft or drafts?  I agree it needs to be addressed.

Janet

[email-masked] wrote on 01/24/2013 03:06:23 AM:

> From: Hannes Tschofenig <[email-masked]>
> To: [email-masked]
> Date: 01/24/2013 03:07 AM
> Subject: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
> Sent by: [email-masked]
> 
> Hi all, 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Thu, 24 Jan 2013 15:27:20 +0000

Hello all

Please find below our remarks on draft draft-ietf-dime-overload-reqs-03 about Diameter Overload Control Requirements

These remarks address topics we have already addressed over Dime but for which we think some enhancements to the text is needed.

We hope to converge quickly as we believe that based on these small enhancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved forward into the IETF standardization process.

1.    REQ 2:   The mechanism MUST allow Diameter nodes to support overload

            support. The mechanism MUST allow Diameter applications

to be aware of an overload situation.

We believe that a proper handling of a Diameter server overload is to report it at the level of its Diameter client applications in order for them to take proper decisions. This may mean to send signalling towards non Diameter entities.

This may relate with the comment made by Hannes.

2.       We recommend to add following requirement:

REQ xx:  The overload control mechanism MUST allow networks to properly support Diameter signalling related with emergency and/or priority users.

This aspect is mentioned in Req 26 but only as a general guidance while this is a strong operational requirement.

"For example, it may be more beneficial to process messages for

            existing sessions ahead of new sessions, or to give priority

            to requests associated with emergency sessions or with high

            priority users."

3.    REQ 35:  The mechanism SHOULD provide a method for exchanging

            overload and load information between elements that are

            connected by intermediaries that do not support the

            mechanism.

We recommend to replace "The mechanism SHOULD provide a method" by "The mechanism MUST provide a method"  as it is a key requirement for deployments especially via intermediate networks.

4.       We recommend to add following requirement

REQ yy:  The mechanism MUST support a default overload algorithm. This will facilitate interoperability especially between Networks.

5.    REQ 33:  There are multiple situations where a Diameter node may be

            overloaded for some purposes but not others.  For example,

            this can happen to an agent or server that supports multiple

            applications, or when a server depends on multiple external

            resources, some of which may become overloaded while others

            are fully available.  The mechanism MUST allow Diameter

            nodes to indicate overload with sufficient granularity to

            allow clients to take action based on the overloaded

            resources without forcing available capacity to go unused.

            The mechanism MUST support specification of overload

            information with granularities of at least "Diameter node",

            "realm", "Diameter application", and "Diameter session", and

            SHOULD allow extensibility for others to be added in the

            future.

a.       We recommend to replace "SHOULD allow extensibility" by "MUST allow extensibility" .

b.       We are not sure that the granularity at Diameter session is really required and suggest to remove it from this Req 33.

Best Regards

Laurent
ALCATEL-LUCENT

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Hannes Tschofenig
Envoyé : jeudi 24 janvier 2013 09:06
À : [email-masked]
Objet : [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi all,

"

          support.

"

overload situation?

application).

reachable.

Diameter node.

Ciao

Hannes

DiME mailing list

[email-masked]

---

From: Eric McMurry <[email-masked]>
Date: Thu, 24 Jan 2013 12:50:24 -0600

Hi Hannes,

These are good observations.  I think the answer to your first point about there being application specific behavior required to deal is overload is exactly right. As Janet pointed out, what this behavior should be is up to the specific application and local policies.  The goal of this was just to provide a mechanism for exchanging information.

You are also correct about the need to be able to share information with more granularity to minimize the impacts of overload and overload mitigation.  You are also right that it can get complicated quickly :-).

This was a consideration for the requirements and is called out (and this resulted in what you saw in draft-roach-dime-overload-ctrl).  The shared back-end case you mentioned was one of many that were considered when looking at scoping for that mechanism draft.  For the requirements, the use of scopes for specifying granularity of overload information was required in Req 33.  There is still a bit of debate over which scopes should be mandatory though.

Thanks,

Eric

---

From: Eric McMurry <[email-masked]>
Date: Thu, 24 Jan 2013 13:04:36 -0600

Thanks Laurent.

comments inline.

Eric

> This may relate with the comment made by Hannes.

As in the current draft, do you think this requirement can be interpreted to say that a diameter stack should handle overload without application intervention and that implementations of overload control mechanisms are required to act in that fashion?

I'm struggling a bit with this since I'm reading it as a requirement on implementations of the overload control mechanism (as opposed to requirements on the specification of the mechanism).  Is it reasonable to require a stack to not handle overload control by itself?

> “For example, it may be more beneficial to process messages for
>             priority users.”

What does this mean for a mechanism?  How would it be done?

> We recommend to replace “The mechanism SHOULD provide a method” by “The mechanism MUSTprovide a method”  as it is a key requirement for deployments especially via intermediate networks.
>  
>  

Personally, I'm on the fence here.  The main issue I have is that any end to end, or end to information source method that passes through intermediaries that don't support the mechanism brings with it an absolute requirement for end to end security.  Given the state of end to end security, this will cause substantial delay to deployment of overload control.  There is a middle ground where a mechanism that could support end to end is required to only be used hop by hop without end to end security in place.  That may be compatible with the suggested change to the requirement but it will have to be considered.

There is also the consideration that a mechanism that requires hop-by-hop action for overload control could be a reasonable or necessary approach, given the potential complexity of the networks involved and the implications of that on what the overload information contains.

At any rate, if the change is made, we must also add the additional security requirement ensuring that the mechanism is not used without end to end security (this is implied by REQ 28, but it needs to be made explicit).

> REQ yy:  The mechanism MUST support a default overload algorithm. This will facilitate interoperability especially between Networks.

I think this would make explicit what is implicit now.  I don't see any issue with adding it.  Others should certainly feel free to contradict me on that.

> a.       We recommend to replace “SHOULD allow extensibility” by “MUST allow extensibility” .

sounds okay to me.
> b.       We are not sure that the granularity at Diameter session is really required and suggest to remove it from this Req 33.

Keep in mind that the requirements are on the specification of the mechanism and not on implementations, so it is reasonable for the specification to include the definition of a scope that is not required to implement.  That said, I don't have any real issue with this.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jan 2013 14:59:53 -0600

> These are good observations.  I think the answer to your first point about there being application specific behavior required to deal is overload is exactly right. As Janet pointed out, what this b…

Hmm--I think it was a bit more than just communication. We've got some requirements [7 and 34]  and discussion [section 6] that imply that the mechanism may or should have some default algorithm. I take that to mean actual behavior, not just communication. We should probably have an explicit requirement for that, one way or another.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jan 2013 16:54:40 -0600

Hi Hannes, some comments inline:

> that only works in a limited extend. So, what happens if there is a real

I think there's some implication that the overload control mechanism should specify at least some default behavior (i.e. algorithm) on the part of the node that consumed the overload information. I'm pretty sure both of the mechanism drafts that have been submitted define one or more such mechanism. As I mentioned separately, we might should consider an explicit requirement one way or another about that. (We have a requirement that such an algorithm be extensible, but I'm not sure we have an expressed requirement that it _exist_ :-)

> and retransmissions (depending on what is specified in a given Diameter

We tried to draw a bright line between Diameter and whatever client application protocol depends on it in section one, with behavior in the client application beyond the scope of the work. It probably would make sense for any overload control mechanism draft to elaborate on that to some degree--but I think the best we can do is to say that if a client is forced to drop Diameter requests, it has to also do the right thing in the client protocol (for example, deny network attach request). I agree that part is application specific. One would hope that any given application specification says something about what a client does when it can't complete a given Diameter application.  

> forward requests to a new server when a shared backend database is not

As Eric mentioned, that's one of the intents behind the "scope" concept. Maybe we could be more explicit about the possibility of a single overloaded scope impacting more than one client-selectable destination. (or at least require the mechanism to offer guidance).

> essentially a way to provision the Diameter routing table of a different

The scope concept in that draft was derived from Req 33. (or maybe "provoked by" would be a better choice of words :-)  )

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jan 2013 17:48:29 -0600

Hi, please see comments inline. 

(Apologies for the late response--I'm catching up on email after vacation.)

> I'm struggling a bit with this since I'm reading it as a requirement on implementations of the overload control mechanism (as opposed to requirements on the specification of the mechanism).  Is it…

My personal opinion is that the draft should not talk about software architecture--just protocol behavior. 

OTOH, I'm not sure if Laurent meant to refer to the separation between the Diameter application and stack on a Diameter node, or the client application that Diameter is supporting.  If the second, I agree putting a few words to that effect could be useful.  (For example, if the Diameter client at a NAS cannot successfully perform an authorization, it might have to cleanly reject a network attachment attempt. The details of that rejection would be out of scope for the overload control mechanism, but the client would still need to Do the Right Thing)
> What does this mean for a mechanism?  How would it be done?

This seems to me to be more like a more application specific requirement than a generic Diameter requirement. If so, I think that would be better specified in whatever document might exist to specify how a particular application might incorporate the overload control mechanism. (For example, in a 3GPP document.)

> At any rate, if the change is made, we must also add the additional security requirement ensuring that the mechanism is not used without end to end security (this is implied by REQ 28, but it needs…

I think I concur with Eric here--there's a potential for some surprises here.  I think we need more analysis of the security and architectural implications of true hop-by-hop vs allowing non-adjacent nodes to communicate overload information. I wonder if we can delegate that to the actual mechanism work, or a separate document than this one? 

> I think this would make explicit what is implicit now.  I don't see any issue with adding it.  Others should certainly feel free to contradict me on that.

I concur. (that we should add the explicit statement, not that people should contradict you :-)  )

[...]