Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for the reacting node to know whether or not a server supports DOIC, since the reacting node should be able to mitigate this server overload as well when this server does not support DOIC.

In fact, we have already included this as a requirement  in our 3GPP TR:

6.3.3	Implicit Overload Indication
6.3.3.1	Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of implicit indications and the inadequacy of this approach for large, diverse networks.
However, a Diameter client may receive some overload indications as defined in Diameter base specification IETF RFC 6733 [2] and then it is recommended that the client uses them to mitigate overload situation. This may happen even if involved server and client support the new CN Overload mechanism under definition, but client handling of such indications is even more important when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
-	DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the receipt of a protocol error DIAMETER_TOO_BUSY response should affect future Diameter messages in any way, then it may be relevant for some applications to define the behavior that best mitigate the overload situation, taking into account application specifics, operator deployments.... For example, MME may implement a mitigation procedure based on the rate of received DIAMETER_TOO_BUSY protocol error from HSS.
-	Lack of response:
In case of overload the server may react dropping the requests without any Diameter error message being returned, what may imply retransmissions in the client side, negatively impacting overload. Therefore, for each application, it should be analyzed how to mitigate overload in this situation. For example, the client may consider avoiding retransmissions when a number of messages have not been answered.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> 1) I want the reacting node to be able to learn if a (potentially) 
> reporting node supports DOIC, even when that node is not in overload. 
> I don't want to specify any particular behavior for that knowledge, 
> but I suspect implementations may want to treat DOIC compliant servers 
> in some way differently than they do non-DOIC servers. For example, I 
> might have a configured rate limit for non-DOIC peers, but use a 
> higher (or no) limit for peers that are known to support DOIC (and can 
> thus speak for themselves.) <Ulrich>sounds like a new requirement; 
> where does it come from? I would have thought that there is no need to 
> distinguish between
> a) DOIC not supported and therefore no traffic reduction requested, 
> and
> b) DOIC supported, but not in overload and therefore no traffic 
> reduction requested</Ulrich>
> 

At one point, I thought we agreed as a group that a reacting node should be able to identify if a (potential) reporting node supported the mechanism. But in any case, we have a requirement that the mechanism must work in a mixed environment, where some nodes support it and some don't. It's much _easier_ to meet that requirement if we can tell what nodes support it and what don't. 

In general, a reacting node can assume that a server that supports DOIC, but hasn't reported overload is not overloaded. It can make no such assumption about a server that doesn't support DOIC. If it does not know the difference between a non-overloaded server and a non-supporting server, it must assume all such servers are non-supporting. It ends up simply knowing that some servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime