Re: [Dime] Two meanings for "default" Re: diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

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

Dear all

From the IETF 94 discussion in Yokohama, I noted the following agreements
1) range of 16 values
2)  Default value of 10
3) Default value with a should and not a may
4)  a V02 integrating these points
5) then V02 for WGLC

For point 1) I think we can keep the existing v01 text of the draft defining  the DRMP AVP values (section 8.1)

For points 2) and 3) I think we can keep the v01 existing text but with PRIORITY_10 as hereafter

   When there is a mix of transactions specifying priority in request
   messages and transactions that do not have the priority specified,
   transactions that do not have a specified priority SHOULD be treated
   as having the PRIORITY_10 priority.

It is still  under discussion  about some additional text, being a note or not. Steve, before IETF 94, proposed  this note :

     Note: There are scenarios where operators might want to
      specify a different default value for transactions that do not
      have an explicit priority.  In this case, the operator defined
      local policy would override the use of PRIORITY_10 as
      the default priority.

There is still some discussion about the additional text to propose taking into account last Lionel, Jannet and Jay comments.
To try to progress , I would propose the following text (not a note):
There are scenarios where operators might want to define the priority values they will use according to local policies, and in particular to use another value than PRIORITY_10  for transactions that do not have an explicit priority

Another possibility is to reuse  some text from a Lionel comment to which I would add above text :

A priority level, if supported and used, MUST be used as input in the routing/throttling/processing decision but the final decision MAY depend on other criteria based on local policies. There are scenarios where operators might want to define the priority values they will use according to local policies, and in particular to use another value than PRIORITY_10 for transactions that do not have an explicit priority.

It would be good to quickly agree on an acceptable  text such as  one of the above  or on another proposal,  so  that Steve can produce a version 2 of the draft integrating points 1) 2) and 3) . It would be good to have a version  2 in the coming days ,  possibly before the upcoming 3GPP meeting  Nov 16th-20th.  where many change requests referring to the IETF draft-dime-drmp will be submitted for the 3GPP release 13 .    As I said in another mail, 3GPP has a strong requirement to introduce  a Diameter message priority mechanism in the 3GPP release 13 and  also decided to rely on the IETF draft-dime-drmp.
Best regards

JJacques

De : DiME [mailto:[e-mail]] De la part de [e-mail]<mailto:[e-mail]>
Envoyé : mercredi 4 novembre 2015 00:29
À : Steve Donovan; [e-mail]<mailto:[e-mail]>
Objet : Re: [Dime] Two meanings for "default" Re: diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)
.
I'm more than OK with Janet's clarification..

Lionel

Envoyé depuis mon mobile Orange

----- Reply message -----
De : "Steve Donovan" <[e-mail]<mailto:[e-mail]>>
Pour : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : [Dime] Two meanings for "default" Re: diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)
Date : mer., nov. 4, 2015 05:54

I will work on wording that hopefully captures Janet's clarification based on the current direction that the default value for DEF is ten.

Steve
On 11/3/15 11:48 PM, Lee, Jay wrote:
I was not sure if we converged on this point of discussion, and I thought that this DRMP work should not progress further until we have an agreement on this (per local policy vs deterministic handling). But maybe we are converging.

I believe that we all agree on ‘per local policy’ (for an incoming message/request without indication, if you wat to be specific). The only sticky point is that we want to assign a value to it, and yet we want to state that it can be overwritten per local policy. It is not complicated technical issue, and we should be able to come to an agreement without issue. If we are all reasonable, I am positive that we can find appropriate wording that can satisfy all of us.

Separately, if we want to specify a value (say, 10) to the equipment for manufacturing purpose, I am fine with it, as long as it is clearly stated that this specified number is for such purpose only.

Thanks,

Jay


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Tuesday, November 03, 2015 5:32 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; DiME; Lukacs, Donald R; Pollini, Gregory P; Lee, Jay; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DOLLY, MARTIN C; Singh, Ray P; Steve Donovan; Shaikh, Viqar A
Subject: Two meanings for "default" Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

I think part of the confusion is that we are using the same word ("default") to refer to TWO different concepts.

The FIRST is a parameter (I will call it "DEF" for clarity) which is used to determine how to process an incoming message/request which arrives without an explicit priority.

The operator can, as a matter of local policy, set DEF to any value in the range.

The operator can also, as Jean-Jacques points out, use its own local policy in determining which messages to throttle (including ignoring Priority entirely).

The SECOND concept is the "default value" of DEF.  This is the value that "DEF" is set to "out of the box", before the operator configures it according to local policy.  This is the one that "SHOULD" be set to  14 (or whatever the latest WG consensus is).

I know most of us understand the distinction, but sometimes it gets confused in the discussion.  So we should be sure that the final text  is particularly clear on the distinction.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        <[e-mail]<mailto:[e-mail]>>
To:        "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]<mailto:[e-mail]>>, "DOLLY, MARTIN C" <[e-mail]<mailto:[e-mail]>>, "Shaikh, Viqar A" <[e-mail]<mailto:[e-mail]>>, Steve Donovan <[e-mail]<mailto:[e-mail]>>, "Lee, Jay" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc:        "Singh, Ray P" <[e-mail]<mailto:[e-mail]>>, "Lukacs, Donald R" <[e-mail]<mailto:[e-mail]>>, "Pollini, Gregory P" <[e-mail]<mailto:[e-mail]>>
Date:        11/03/2015 04:36 AM
Subject:        Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)
Sent by:        "DiME" <[e-mail]<mailto:[e-mail]>>
________________________________



OK with the first comment. Mea Culpa ☺

Moreover, I can live with the note.
But the note induces the following additional question: "Can operator defined local policies override the explicit priority level indicated for the request/transaction?"
And my comment was that handling of priority is always a matter of local policies. It is an indication that may be taken into account when deciding the next step in the request processing.
You may have further criteria in your prioritization.

The note is correct but could be misleading. I would prefer to have a general statement saying that the priority, if supported and used, must be used as input in the routing/throttling/processing decision but that the final decision may depend on other criteria based on local policies. There is therefore no mandatory direct mapping between the priority indication in the request and the priority with which the request will be handled. It is just an indication of the priority requested by the sender/forwarder of the request.

I hope that this clarifies my comment. Actually, it is more about reassuring operators that they will keep the control of the process of the requests in their own network. After that, it will be only a question of SLA/roaming agreements between network operators.

Lionel

************************
De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[e-mail]]
Envoyé : mardi 3 novembre 2015 08:20
À : MORAND Lionel IMT/OLN; DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; [e-mail]<mailto:[e-mail]>
Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P
Objet : RE: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Hi Lionel

Two remarks on your mail

- The value of the highest priority is  0;  the lowest priority is 15
- After the Dime session, where SHOULD is retained for the default priority, I think we can keep  this note which is a good clarification
-       Note: There are scenarios where operators might want to
      specify a different default value for transactions that do not
      have an explicit priority.  In this case, the operator defined
      local policy would override the use of PRIORITY_14 as
      the default priority.
Best regards

JJacques


De : DiME [mailto:[e-mail]] De la part de [e-mail]<mailto:[e-mail]>
Envoyé : mardi 3 novembre 2015 03:44
À : DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; [e-mail]<mailto:[e-mail]>
Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

If I'm correct, the proposed text for -02 would be:

   When there is a mix of transactions specifying priority in request
   messages and transactions that do not have the priority specified,
   transactions that do not have a specified priority MAY be treated
   as having the PRIORITY_10 priority.

      Note: There are scenarios where operators might want to
      specify a different default value for transactions that do not
      have an explicit priority.  In this case, the operator defined
      local policy would override the use of PRIORITY_14 as
      the default priority.
It seems to have a consensus on the MAY. But I think that we are missing one point: we need to ensure that requests related to e.g. mission critical/emergency services can be handled with the highest priority in any network.
And we cannot forbid scenarios in which more than one network will be involved in the signaling path. Therefore, the "MAY" is not correct as it allows operators to map the value 15 to requests received with no priority indication. In such a case, there is no way to give the highest priority to emergency call related requests. I'm not saying that such a configuration would be frequent and adequate but it is allowed as per the current text.

I would propose to give a strong recommendation on the value with a SHOULD. Recommending a value would enable to split the range into two clear sub-ranges:
Set1: 0-10
Set2: 11-15

In such case, any value in the second set will always be considered with an higher priority than request with priority of the first set or request without indication.
The correct text would be then:

   When there is a mix of transactions specifying priority in request
   messages and transactions that do not have the priority specified,
   transactions that do not have a specified priority SHOULD be treated
   as having the PRIORITY_10 priority.
About the proposed "NOTE", I think that it is not required as it is already said that the priority indication is… an indication that may be taken into account, as below:

   2.  Agents handing the request - Agents use the priority information
       when making routing decisions.  This *can* include determining
       which requests to route first, which requests to throttle and
       where the request is routed.  For instance, requests with higher
       priority might have a lower probability of being throttled.  The
       mechanism for how the agent determines which requests are
       throttled is *implementation dependent* and is *outside the scope of
       this document*.  The agent also records the transaction priority
       in the transaction state.  This will be used when handling the
       associated answer message for the transaction.

   3.  Request handler - The handler of the request, be it a Diameter
       Server or a Diameter Client, *can* use the priority information to
       determine how to handle the request.  This *could* include
       determining the order in which requests are handled and resources
       that are applied to handling of the request.

It is never mandated that the priority indicated for a given request MUST be handled as such.
Please consider this point. This will be discussed during the meeting.

Lionel