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)" <jean-jacques.trottin@ALCATEL-LUCENT.COM> 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
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime