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

[<[e-mail]>]

Hi Eric,

The way to document the support of the OC mechanisms in existing applications is up to the people managing the document defining the given application (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various ways. They can even decide to create a completely new application if it is preferred. For me, it is out of the scope of the definition of the mechanism itself and then not part of the requirement.

>From a Diameter point of view, the important point is that the foreseen solution has to be designed to be used along or over existing applications. And when used over existing applications, the required changes must not imply the creation of a new application (as clarified in the proposal). The solution designers can rely on the RFC 6733 and the draft Diameter Applications Design Guidelines<http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-16> to see if the solution meets this requirement.

Regards,

Lionel

De : Eric McMurry [mailto:[e-mail]]
Envoyé : mardi 11 décembre 2012 15:00
À : MORAND Lionel OLNC/OLN
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [e-mail]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

Hi Lionel,

I'm not arguing against changing the language in req 2.  This discussion has made it quite clear that needs to happen.

The alternate proposals I have seen do not say the same thing though and are weaker requirements.  It is important for the resulting OC mechanism to work without requiring changes to the specification of an application.  Perhaps you have a better way of saying this.  For example, I would expect the OC mechanism to work between an MME and HHS without touching 29.272.  Can you propose alternate language that captures this?

Thanks!

Eric



On Dec 11, 2012, at 3:46 , [e-mail]<mailto:[e-mail]> wrote:


Hi Eric,

Just on this point:
"Use of the unqualified term 'application' is causing confusion, at least for me."

As I said, it is the use of 'specification' that causes confusion in REQ2.
I can understand that some new folks may encounter some difficulties in understanding the wording used in Diameter specifications e.g. RFC3588, RFC 6733, all the related RFCs specifying Diameter 'applications' or even the title of the draft Diameter Applications Design Guidelines<http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-16> ...
But I don't think that it is a reason to change the definition or even introduce more confusion.

Based on this discussion, I'm more and more convinced that the correct wording for the REQ2 should be something based on my proposal:

OLD:

   REQ 2:   The overload [control] mechanism MUST be useable with any existing or
            future Diameter application.  It MUST NOT require
            specification changes for existing Diameter applications.

NEW:

   REQ 2:   The overload [control] mechanism MUST be useable with any existing or
            future Diameter application.  Support of this mechanism over existing
            Diameter applications MUST NOT require major changes that would lead
            to the need to define a new Diameter application.

Regards,

Lionel


De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] De la part de Eric McMurry
Envoyé : lundi 10 décembre 2012 21:43
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

Hi JJaques,

please see comments inline.

Thanks,

Eric


On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]<mailto:[e-mail]>> wrote:



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.


I believe the requirements in this doc apply to the definition of a standard for an overload control mechanism.  They are not direct requirements on any implementation that may follow that standard.  This is a key distinction.  An implementation may do things that are not in a standard and can still be compliant with that standard depending on how the standard was crafted.

So, as I see it, these comments make sense when talking about implementations and I am in agreement with them.  However, the requirements are about standards definition.  I think for purposes of discussion of req 2, we need to think in terms of application implementation and application specification.  Use of the unqualified term 'application' is causing confusion, at least for me.






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.

that is a good point.  I agree with changing req 7 like this.  Assuming others do as well, I'll look though for other examples at the same time.




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?

Each of the current mechanism proposals in place have defined defaults for algorithm and I think we're all on the same page that a minimal set (one or two) should be supported as default.




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)?

I think that should be sufficient.  If we start doing something normative here, we restrict the flexibility of applications to define their own behavior.  do you think there are things we can do here that will be in common for all possible applications?


[...]

_________________________________________________________________________________________________________________________



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,

France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.

Thank you.


_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.