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

[Steve Donovan <[e-mail]>]

This could be addressed by adding the requirement that an
OC-Supported-Features AVP AVP that is inserted by an agent be marked as
such.

Steve

On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> The reacting node (when receiving OC-Supported-Features AVP in an answer) knows that the corresponding request took a path towards the server on which there is a reporting node (which supports DOIC). It does not know whether this reporting node is the server or an agent and it does not know whether subsequent requests will take the same path or a different path on which there may be no reporting node. 
> Consequently the presence of OC-Supported-Features AVP in an answer does not tell you anything usefull on which to base behaviour for subsequent requests targeted to the same server.
>
> -----Original Message-----
> From: DiME [mailto:[e-mail]] On Behalf Of ext Maria Cruz Bartolome
> Sent: Wednesday, February 12, 2014 10:56 AM
> To: [e-mail] list
> Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
> Ulrich,
> Thanks for your response, see comments please
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
> Sent: miércoles, 12 de febrero de 2014 9:14
> To: Maria Cruz Bartolome; [e-mail] list
> Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
> I understand your point but I'm not really convinced.
>
> 1. implicit indications (like answer message with result code TOO_BUSY and without piggybacked OLR or Lack of response) should be taken into account by reacting nodes independent from DOIC-support of the server.
> [MCruz] I agree. But one of the 3GPP requirements is to improve reacting node overload mitigation based on implicit indications (as described by TR), therefore any 3GPP application that will support new "Overload mitigation" feature (or whatever may be the name), shall improve its procedures with this objective. It is expected as well, that this new 3GPP "Overload mitigation" feature makes use of our DOIC, and then it is very beneficial that the reacting node could identify at any moment whether or not the reporting node supports DOIC, since procedures to be implemented could be potentially different.
>
> 2. How would the reacting node know whether the OC-Supported-Features AVP received in an answer indicates the features supported by the server (identified by the origin-host received in the answer) or the features supported by an agent on the path? 
> [MCruz] Reacting node receives reporting node Supported-Features. Regardless the reporting node is either an agent or a server, in case the reacting node needs to treat "implicit indications" (like TOO_BUSY), expected reaction may depend on whether or not reporting node supports DOIC. This information is very beneficial to determine the most appropriate reaction.
>
>
> -----Original Message-----
> From: DiME [mailto:[e-mail]] On Behalf Of ext Maria Cruz Bartolome
> Sent: Tuesday, February 11, 2014 9:21 PM
> To: [e-mail] list
> Subject: 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:[e-mail]] On Behalf Of Ben Campbell
> Sent: martes, 11 de febrero de 2014 16:55
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: [e-mail] 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) <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>