Re: [Dime] Dime: Diameter Overload IETF requirements, review

["TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]>]

Hi all

About this long discussion on REQ2, I hereafter give some additional comments


1)      Regarding Lionel's remark,  the fact to add related overload AVPs to existing commands of a given Diameter application means these AVPs are now part of the Diameter application which should deal with them, so impacting the application.


On another side, in REQ13, piggybacking is mentioned as an example of a solution for this REQ13 .  With  piggybacking, the message is only used as transporter of the related overload AVPs.   As messages from different Diameter applications may be transferred over the same connection,  from my understanding, we may have a solution where  the overload AVPs are transported in any message of any application and relate or are specific to the same Diameter application as the message one or to another application or be application independent. Here  can we say these transported AVPs are sometimes  part of the Diameter Application and sometimes no?



Although this is a solution level discussion, it directly relates to the REQ2 sentence: "It MUST NOT require specification changes for existing Diameter applications".

I am rather in favor of Lionel's remark and on the text he proposes. When an AVP is conveyed in a command of an application, it is part of this Diameter application. The same AVPs may be used by different Diameter applications. Then it is a matter of implementation: these overload  AVPS or some of them may be processed by a separate application-independent function in a node, so to minimize  impact on existing applications, but it is implementation.



2)      In Req1 it is stated that the overload mechanism objective is "to provide a communication method ...to exchange the overload information", so no more , no less from my understanding.  Then there are requirements on the Diameter node behaviors. I have  no issue with the many  REQs for managing and optimizing well this information exchange (eg REQ 9, 13, 14, 19...) by nodes . It is another topic on how the exchanged information is then used by nodes. I am also OK with the REQs starting with "the mechanism MUST allow nodes to ... (REQ7) , "...MUST provide a way to (REQ 22)' as we are still speaking of the exchanged information  which  allows nodes to... . I think we should also use this type of wording for a few requirements  eg for REQ 7  "the mechanism  must ensure  that the system remains stable" as it is not the exchanged information  which stabilize the system, but the nodes behavior on the basis of information exchanges.



3)      This document does not address any overload algorithm which will be key on how the exchanged information is then used by nodes.   From a 3GPP angle, the approach ALU foresees is to use the Dime method to exchange the overload information, eventually by extending the information exchanged (REQ 33, 34),   and to specify nodes behaviors about overload handling according to the Diameter application (corresponding to a 3GPP interface) and the overload algorithm.

Eric's mail mentions a basic operation of an overload control mechanism, which should correspond to an overload algorithm. Has Dime the intent to specify some general overload algorithms?



4)      I remind the question of priority  given to some users that 3GPP will have to handle. Generally, it is the client that should  manages such priorities and signals it to the server but the intermediate Diameter agents are not neutral there and should have the relevant information to behave correctly (eg to not drop a message for a priority user). On Req 26 ,we proposed  an additional wording "" For example, it may be more beneficial to process messages for existing sessions ahead of new sessions and to give priority to requests associated with emergency sessions or with high priority users". Do you think it is sufficient, or should we have a normative statement (not only an example)?


Best regards

JJacques


From: [e-mail] [mailto:[e-mail]] On Behalf Of Eric McMurry
Sent: lundi 10 décembre 2012 04:55
To: THIEBAUT, LAURENT (LAURENT)
Cc: [e-mail]
Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review

Thanks for clarifying your thoughts Laurent.

I think we're all on the same page that some changes are likely to happen to support overload control in the application specifications and that this is the right level to consider priorities and other application specific behaviors.  Where we seem to be getting wrapped up though is whether those changes will be required to use an overload control mechanism.  I agree changes at the application specifications are a good idea, but I do not think they are required for basic operation of an overload control mechanism.  I don't see why a mechanism (including the two proposals) could not be used without any changes to application specifications.

In your example with an end point implemented as a stack and and application layer, handling of an overload control protocol could be done in either place.  Decisions about what to do would make sense at the application level, but the implementation could do that in an interoperable fashion  without needing a new specification, for protocol or behavior, with, for example, a drop or throttle algorithm that made no consideration of priority.

I think it is important for the design of an overload control mechanism to support operation without application specification changes.  It will allow some overload control to be implemented even before application specifications are updated.  It will also ensure that the mechanism can be used for application specifications that will not be, or do not need to be, updated.  Having a basic overload control mechanism in place will be an improvement over current conditions.  We can then further improve this, by updating application specifications, to cover cases like those you mention for S6a.

Thanks,


Eric


On Dec 9, 2012, at 15:02 , "THIEBAUT, LAURENT (LAURENT)" <[e-mail]<mailto:[e-mail]>> wrote:




Hello all
I'd like to highlight the comment from Tom that touches the topic we wanted to address via our (unfortunate as it raised (too) much discussion) comment on REQ 2

Let's Consider a Diameter end point SW is split up into 2 parts:
*         a base Diameter stack
*         an application SW
Even though the application *protocol* is NOT touched by Diameter overload (thanks to * [AVP]), it seems questionable that only the base Diameter stack would handle the changes due to the Diameter overload control we are defining (and that thus the application SW would be untouched). Said otherwise something will have to change in the Behaviour of the source application.

One of the reasons is that only the application knows the relative priority of the various procedures and of the various users: e.g. taking the 3GPP S6a as an example (= MME as a kind of authenticator accessing the subscriber database i.e. the HSS), only the MME SW (as opposed to the Diameter stack or diameter agent en route between the S6a client and server) knows that
o        an Update location is of higher priority than a Purge
o        User Lionel is a high priority user while user Laurent is low tier user
o        a request is associated with an emergency
o        etc...

So the application behaviour/SW is likely to be changed

May be a solution is to change second part of the REQ2 into "It MUST NOT require protocol specification changes for existing Diameter applications" (hinting that a behaviour change is possible)
Best regards
Laurent
ALCATEL-LUCENT

Disclaimer: this mail is not meant to promote any of the 2 solutions on the table. It is JUST about requirements.

-----Message d'origine-----
De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] De la part de Tom Taylor
Envoyé : samedi 8 décembre 2012 04:17
À : [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

Ben, I think the problem is that a Diameter implementation can be
thought of as a base part and an application-specific part. A message
comes in, gets processed by the Diameter base part, then the application
is passed the type of message and the parts not consumed by base. So
some extra information is tacked on in that optional AVP part. Either
the base recognizes it and deals with it, or the application does. If
the application is to handle it, the application has to expect it --
that is, the specification of the application includes the additional data.

On 07/12/2012 11:19 AM, [e-mail]<mailto:[e-mail]> wrote:
>
>
> -----Message d'origine----- De : Ben Campbell
> [mailto:[e-mail]<http://nostrum.com>] Envoyé : vendredi 7 décembre 2012 16:47 À :
> MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT
> (LAURENT); [e-mail]<mailto:[e-mail]> Objet : Re: [Dime] Dime: Diameter Overload
> IETF requirements, review
>
>
> On Dec 7, 2012, at 9:24 AM, [e-mail]<mailto:[e-mail]> wrote:
>
>>> [em] One solution uses existing messages as a carrier,
>>> piggybacking on them.  This can be done by an implementation
>>> without any change in the specification of the messages that are
>>> being used.
>>>
>>> [LM] It is exactly the issue for me! :) I think that you want to
>>> say that existing commands can be extended with changing the CCF
>>> specification and it is true. The application (and its related
>>> specification/documentation) using this command will change! And
>>> it is what I highlight in my comment and in the proposed change.
>>
...
_______________________________________________
DiME mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dime