[Dime] Dime: Diameter Overload IETF requirements, review

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

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 the draft-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 and overload information.

*       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.

*       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, a possible 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.

*       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"

*       Last sentence of REQ 35 appears unclear, wording may be reviewed or this sentence may be suppressed.

.
Best regards

JJacques Trottin
Alcatel-Lucent delegate to 3GPP CT4