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

[<[e-mail]>]

Hi,

I think that two points are mixed:

1) For efficiency, a DOIC-enabled client should be able to mitigate (possible) overload situation even if explicit indication is not received from the network.
2) DOIC-enabled clients having a different behavior regarding support or not of DOIC by server.

if I agree with the first one, I disagree with the second one. The basic assumption is that a DOIC client will not throttle the traffic in absence of overload indication (explicit or implicit). And throttling will be performed as soon as an indication is received (explicit or implicit) if the client is designed for that (it supports DOIC or/and default behavior has been defined on reception of TOO_BUSY or non-response).

It is the only thing that matters today.

Regards,

Lionel

De : DiME [mailto:[e-mail]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : vendredi 14 février 2014 13:18
À : ext Steve Donovan; [e-mail]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Steve,
For my clarification:
Your proposal is to mark OC-Supported-Feature AVPs when inserted to answer messages by an agent?

If so, the reacting node can associate unmarked Supported-Features AVPs with the server (orig-host) and can discard marked Supported-Features AVPs.

Is that understanding correct?

Ulrich


From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
Sent: Thursday, February 13, 2014 2:01 PM
To: [e-mail]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

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



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.