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

[<[e-mail]>]

Hi,

I think that we should not misuse "application" and "specification" here. The problem is not about change in the specification but about change in the Diameter application. 

In my understanding, the intention of the second sentence of REQ2 is to say that the support of OC mechanism must not imply major extensions of existing Diameter Applications, which would cause the definition of a new application and the allocation of a new Application-id, as per RFC6733.

But of course, if required, existing applications can be slightly enhanced to support OC without major impacts (e.g. using optional AVPs), and then no need for new Application-id, and then the related specification will have to be updated to describe how to support this new feature.

If my understanding is correct, would the following change be agreeable?

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.


By the way, I think that we are working on a mechanism to control overload and not a mechanism for overload, right. Should "overload mechanism" be replaced by "overload control mechanism" all over the document?


Lionel

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Ben Campbell
Envoyé : jeudi 6 décembre 2012 17:03
À : THIEBAUT, LAURENT (LAURENT)
Cc : [e-mail]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review


On Dec 6, 2012, at 9:48 AM, "THIEBAUT, LAURENT (LAURENT)" <[e-mail]> wrote:

>  
>  
> Hello all
> About Req2, we understand that based on the usage of the *[ AVP ], there is no need to update the ""ABNF"" of the protocol describing the various Diameter applications!  Nevertheless the behaviour of the application, i.e. the SW using that "unchanged protocol" will have to be changed anyhow to support Diameter overload control. Can we reword Req2 into
> The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications *but is likely to require a change of the behaviour of an entity supporting a Diameter application and the Diameter overload mechanism.*
>  
> This "is likely" is NOT an IETF normative wording (MUST, SHOULD,.) as the part of the sentence that is being added is more of an explanatory / clarification nature (I hope).

I have mixed feelings about this, and I think it has to do with the definition of "application".  If we do this right, the _base_ Diameter overload control behavior should come to any application, old or new, for "free", assuming the definition of that application included the *[ AVP ] construction. That's in the strict sense of what constitutes a "Diameter Application". If the application would benefit from more application specific behaviors, they can always add them.

OTOH, the definition of an "interface" that uses one or more "applications" is highly likely to change, if for no reason that to require support of OC.

I propose an indented paragraph with a couple of sentences to explain this, rather than making it part of the same sentence as the normative requirement.

> Best regards
> Laurent 
> ALCATEL-LUCENT
> De : [e-mail] [mailto:[e-mail]] De la part de Eric McMurry
> Envoyé : jeudi 6 décembre 2012 15:05
> À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Cc : [e-mail]
> Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review
>  
> Thanks for the comments!
>  
> responses inline.
>  
> Eric
>  
>  
> On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]> wrote:
> 
> 
> Dear all
>  
>  
> In the objective of relying on IETF specifications to handle Diameter overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of thedraft-ietf-dime-overload-reqs-01.
>  
> We consider the list of REQs described in the IETF draft as quite extensive and all REQs relevant. We have the few additional comments to submit to the upcoming Dime review:
>  
> 	. We suggest to put more emphasis in REQ1 on the fact this is both for load (preventive) and overload (reactive). A possible writing:
> REQ 1:   The overload mechanism MUST provide a communication method for Diameter nodes to exchange load andoverload information.
>  
>  
> sounds reasonable to me.
> 
> 
> 	. About REQ 2 ("The overload mechanism MUST be useable with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications"), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 "allowing for the possibility of increased feedback for information piggybacked"as the piggybacking mechanism may impact the application. May be a solution is to suppress this second part of the REQ2 (" It MUST NOT require specification changes for existing Diameter applications") or review the wording.
>  
> The intent of this was not to say that applications can not be changed to make use of overload control, just that they won't be required to.  I think with either of the proposed mechanisms based on these requirements, this would be met.  They can be used without any alteration to applications.  That said, overload control will work better with consideration for how each application can be impacted and how it should respond.  
>  
> The second part of REQ 13 is only commentary on the scaling properties of existing messaging, but in general piggybacking can be done without impacting applications.  This requires a * [ AVP ] in the applications messages though.  Adam did a survey of all the applications he could find when he was writing the proposed mechanism and did not find any examples where this was not the case (and this is recommended by the base protocol).
> 
> 
>  
> 	. On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of the "which message types might be desirable to send or process over others during times of overload" should be left for each application to define (for " .  Diameter specific considerations). If this reading of REQ 26 is shared, apossible rewording could be:
> REQ 26:  The generic specification for the overload mechanism SHOULD offer overall guidance on which message types might be desirable to send or process over others during times of overload, based on Diameter-specific considerations.  For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. A precise specification of the relative priorities of message types in case of overload would anyhow be under the responsibility of each application.
>  
> I believe that was the point it was trying to get across.  I think your last sentence would add some clarity.
>  
> 
> 
>  
> 	. We expressed the point that overload handling should take into account that some messages may have a high priority (eg when related to an emergency or a high priority user").  This handling would  be application dependent and so entering the REQ 26 as an overall guidance but it could be mentioned in REQ 26 as an example with the possible 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"
>  
> I don't have any issue with that.  What was there was intended as only the simplest example.  There are many ways to do this.  Adding one more example shouldn't hurt, but we probably don't want to go down the path of listing possibilities here.
> 
> 
>  
> 	. Last sentence of REQ 35 appears unclear, wording may be reviewed or this sentence may be suppressed.
>  
> We can probably strike that.  What do you think, Ben?
> 
> 
>  
> .
> Best regards
>  
> JJacques Trottin
> Alcatel-Lucent delegate to 3GPP CT4
>  
>  
>  
> _______________________________________________
> 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,
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.