Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 2 Nov 2015 20:38:17 +0000

I agree

From: DiME [mailto:[email-masked]] On Behalf Of Shaikh, Viqar A
Sent: Thursday, October 29, 2015 3:59 PM
To: Steve Donovan <[email-masked]>; Lee, Jay <[email-masked]>; [email-masked]
Cc: Singh, Ray P <[email-masked]>; Lukacs, Donald R <[email-masked]>; Pollini, Gregory P <[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Hello all,

My 2 cents:

Greater than 5 values for DRMP AVP is justified and it appears there is agreement for 16.  However, note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined. Having 15 rather than 16 for DRMP AVP would be useful from an interworking point of view on Diameter interfaces connecting to the EPS.

Regarding the default value - it is based on operator policy and can be overwritten by an operator.  Therefore, we support use of "may" and not "should".

We feel that 15 or 16 values should suffice and there is no need to define an extension bit.  However, I am ok if there is consensus to do so.

We feel there is no need to specify a default as it is per local policy and can be overwritten.  But, if there is consensus to do so, we suggest value 10 or 11 with a note that it can be overwritten based on operator policy.

Thoughts?

Thanks,

Viqar

________________________________
From: DiME [[email-masked]] on behalf of Steve Donovan [[email-masked]]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Ten is acceptable to me.

Steve

On October 28, 2015 1:36:00 PM "Lee, Jay" <[email-masked]<mailto:[email-masked]>> wrote:
I also think that we agree on all different points for the finalization, except one point: the value for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have strong opinion, especially when the default value can be overwritten.

Looking at this objectively and also for the sake of progress, however, it would be prudent to have more than one lower priority cases. In the near future, we may identify additional use cases for lower priority case. Even with one use case identified, this does not necessarily mean one priority level per use case. One use case may require multiple lower priority levels, depending on applications.

Any value from 9 to 12 seems reasonable to me. But, without all use cases identified at the present time, I propose 10 (JJacques' proposal) or 11.

Thanks,

Jay

From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Hi

Please see my comments also in line. I think we are close to finalise our choice on the different points  of this thread

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Lee, Jay
Envoyé : vendredi 23 octobre 2015 18:57
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Please see my comments inline.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Please see my comments inline.

Steve
On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:
See inline

From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Some further comments from my side:

*/ If we need to assign (but not specify) a value to the default case, we need to make it clear that this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leaving the factory, so that there would be no misunderstanding.
mcd- ok
SRD> I think the current proposed text makes this clear.
[JL] Agree that the current text is OK especially when we use 'May' in place of 'Should'
[JJ] OK
.

*/ Since we agree that the default value is per local policy, 'May' is preferred to 'Should' in order not to cause confusion.
mcd-ok
SRD> I'm okay with making this a MAY.
[JL]  Agreed
[JJ] Also in favor of a MAY

*/ For assignment of the default value, I am quite open. But any value between 9 - 12 seems reasonable to me.
mcd- value should allow for assigning lower values, though a carrier can assign what they want in their network, there needs to be a common meaning at the interconnection point
SRD> I'm open to any value we decide on.  If there are real use cases that require pushing the default value more to the middle then we should do so.  At this point I've heard one use case for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.
[JJ] Regarding use cases, there may be

-          The case where for "normal" users, an application use the default value for most of its requests except some which have a lower priority

-          the case where besides "normal" user (and high priority users), some users have lower priorities, e.g. Some Machine type Communications (MTC) devices.
So potentially more than one low priority level would be needed.
We also have chosen a rather large range of values (16) , allowing flexibility for an operator when they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves only one lower priority and an operator  cannot add a second one  except by choosing  a default value other than the 14  value.
Then as, in practice, we may expect a range of low priority smaller than  the range of high priority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am open on another value.
                                                                                                                                                     &! nbsp;&nbs p;
*/  Current proposal of 16 values may be enough now, but I am fine with having an extensibility bit to be future proof.
mcd-ok
SRD> I don't see a compelling argument to move beyond 16.
In addition, it isn't clear to me that there is value in defining an extensibility mechanism beyond what is already supported by Diameter.  Doing so would add significant complexity to the DRMP mechanism for something that, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require that any extension require a new AVP.  We can then leave it to the document that proposes the extension to deal with determining whether send the DRMP AVP or the newly defined DRMPv2 AVP.
[JL] When we proposed that the range be extended to 16, we thought that '16' was large enough and future proof.
I am okay with having an extensibility bit, if other companies want it. That said, I agree that it has a low probability of being used and added complexity.
[JJ] JJ I also agree that with 16 values , the offered range is large enough in practice. This point is only to check if it would be easy to do an extension, if we have this requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new document rather than to define a set of reserved values in the DRMP AVP.  A point is that it will require an additional parsing effort for a node to look for this second AVP even if it is not present most of the time.

*/ I am not sure of alternative encoding method (say, +9 to -9 per JJacques' proposal) compared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. But it offers less flexibility to operators, since the default value may not be easily moved to have more higher/lower priority values. Also, we are used to the enumerated type of DRMP and just want to have extension from 5 to 16,  but this may require more deviation from the current design and thinking. For this, I would like to see more on qualitative pros/cons, but, given its little benefit, I am reluctant to accept this alternative.
SRD> I agree that I don't see value in the +9 to -9 proposal.
[JL] Agreed
[J] I presented this second  approach  so to review the possible alternatives as we usually do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enumerated DRMP AVP.

Best regards

JJacques

From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Hi

1.      PRIORITY_14 as default priority value only allows one level of lower priority (PRIORITY_15)  than the default one; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities that normal communications without priority.  Even within a Diameter application, some commands may have a lower priority as having a secundary importance.

Then which default  value ?

-        it could be PRIORITY_8 in the middle, or if we prefer to have a  larger range for higher priorities  than for lower priorities,  the default value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 5 lower priorities than the default one. I would have a preference for this value PRIORITY_10.

2.      About extensibility, the current range of 16 values is already large, but we can have  a reserved value to indicate a further extension. With  an enumerated AVP, there is no possibility to add new values.

3.      I also had a look to some other IETF RFCs addressing priorities that Ken mentioned, so to see if we can benefit from these approaches although done for different contexts.

-        in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as the highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP request without  Resource-Priority Header compared  to a SIP request with the Header). Implicitly, I would assume a SIP request without  Resource-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also lower priorities.

-        RFC  6710 (priority for SMTP),  uses another encoding of the priority values with an integer between -9 and +9. Lower priorities  are negative an higher priority being positive. When a value increases, it means a higher priority, so the opposite  to DRMP, wps or ets.  But the value 0 is here naturally the default value. So this is an encoding alternative  to the  Enumerated type of the DRMP AVP which avoids the question of the default value.

Note: RFC  6710 also defines some Priority Assignment Policies using a subset of the range.

RFC 6710 has also this guideline :
   SMTP servers compliant with this specification are not
   required to support all 19 distinct priority levels (i.e., to treat
   each priority value as a separate priority), ....  That is, an
   implementation that only supports N priority levels (where N < 19)
   will internally round up a syntactically valid priority value that
   isn't supported to the next higher supported number (or to the
   highest supported priority, if the value is higher than any supported priority).

-        This raises the question to have this type of  guideline if considered useful.

So to have your feedback

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de DOLLY, MARTIN C
Envoyé : jeudi 15 octobre 2015 12:33
À : Lee, Jay; ken carlberg; Steve Donovan
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

A couple thoughts:

1.      There needs to be a default value defined by the standard, so that equipment have the same value leaving the factory

2.      This value can be over written based on local policy

3.      Should have an extensibility bit in order to and more values in the future

From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <[email-masked]<mailto:[email-masked]>>; Steve Donovan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

>From my side, some more discussion on Steve's mail may be needed.

'Should' vs. 'Must':
One can say that 'Should' is not mandatory. But, in practice, this is a fairly strong statement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the value, I don't see the reason why we use 'Should'. My suggestion is using 'May'.

PRIORITY_14 priority:
Since operators can overwrite it, I was not too concerned about it. But if we want to put some value, why '14'? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

Jay

From: DiME [mailto:[email-masked]] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

with respect to the diff-serv example brought up below, some thing to add to that discussion is that it starts off with separate and distinct forwarding behavior whose marked packets provide segmentation of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust) also discouraged a line of thought to define end-to-end priority handling versus a per diff-serv domain treatment.  RFC-4594 did provide configuration guidelines, but that's a different story.

So back to a couple of ideas to consider.

1) reserved space.  if we go back to the diff-serv model, the diff-serv working group agreed to set aside a set of values that was reserved for experimental use that could be re-assigned some time in the future.  I'm not suggesting that there should be space set side for experiments, but rather it may be prudent to set aside a reserved set of bits/values so that one doesn't need to define a new AVP if in the future there was a need to define added values beyond the 5 (plus some fudge factor) already mentioned on the list.

2) sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized that there can be several sets of users/services that are distinct from each other and yet need to prioritize the traffic.  I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm assuming that the latter is aimed at the general public and related to 911/112/999 type calls, which should probably be more specific in the draft).  And there is also the potential of Firstnet users in the US.

As a side note, the distinction and separation of general public and other prioritized users in public phone infrastructures is not exclusive to the US, so the group should not be concerned that this is a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC is a bit dated, but feel free to go over rfc-4190 for added background.

and just to reiterate.  I'm not making recommendations in the above - just bringing up some food for thought.

-ken

On Oct 14, 2015, at 10:12 AM, Steve Donovan <[email-masked]<mailto:[email-masked]>> wrote:

Jay,

The current text is a SHOULD level requirement:

   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_14 priority.

As such, operators can choose to either not implement a priority or define a different value for their network.

I propose adding the following note after this paragraph to further explain why it is a SHOULD and not a MUST:

      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.

This leaves the ability for there to be deterministic behavior in Diameter networks that require a default to be defined and are happy with the specified default.  It also gives operators the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network.

Does this address your concerns?

Regards,

Steve
On 10/14/15 2:59 AM, Lee, Jay wrote:
Regarding the issue of whether we need to specify a default value or not, there are pros and cons.

If we specify a value for the default case, we can see the benefits in scenarios between different operator networks, but we take away important options on what operators can do with priority values. On the other hand, if we do not specify the default value, operators may have more options, but there is a question of what to do for this inter-PLMN cases when the networks may use different default values.

In practice, this issue can be addressed at the edge of the network, where Diameter edge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the proper handling. One may argue that this is not as good as the 'deterministic' case, but operator should be able handle this in a reasonable way. We are fully aware of the fact that, in case of this 'non-deterministic' case, the default value can differ from one operator network to another, and it becomes difficult to guarantee the intended priority handling. Despite this, we still prefer giving options to operators by not specifying the default value.

What we are saying here, however, is not anything new. This is the typical way of handling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good example of this - Internet QoS, more specifically DiffServ.

In order to guarantee end-to-end QoS for a specific service, IETF could have specified a value (DiffServ codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. Instead, DiffServ simply provided a framework for operators to have its own  classification and differentiated treatment of the services. To guarantee end-to-end QoS across different networks, then, operators need to do packet inspection, (re)classification, QoS mapping, use of SLA and possibly others at the edge of network (edge router). Therefore, in the DiffServ architecture, intelligence was pushed to the edge of the network. While the end results may not be guaranteed as well as in the case of predetermined handling, it was still a preferred way to give flexibility to operators. My point is that we went through all these troubles to give options of priority handling to operators.

By the way, if we are thinking of possibility of specifying the default value, are we assuming that all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren't there other operators who are not interested in this feature? I know that at least there is one - Verizon. We have no interest in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is NOT specified. But we are certainly not happy if DIME is trying to impose this on us.

Jay

From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; [email-masked]<mailto:[email-masked]>; Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Assuming that we define a range of 3 values,
Assuming that 0 is the lowest priority and 2 the highest,
Assuming that an agent receives 4 messages at the same time while being in overload control:
*       1) ULR with Prio-0
*       2) ULR with Prio-1
*       3) ULR with Prio-2
*       4) ULR with no priority AVP

Assuming that the default is locally defined as proposed below,

How do you know that the ULR with priority 2 will be handled with a higher priority  than the request without priority indication?
And what about ULR message with priority 1 with two levels of highest priority e.g. emergency/Important and government/very important?

Sorry if the answer is obvious but I fail to understand.

Lionel

De : Shaikh, Viqar A [mailto:[email-masked]]
Envoyé : samedi 3 octobre 2015 01:21
À : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; [email-masked]<mailto:[email-masked]>; Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels

Hello all,

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

Having 15 rather than 16 would be useful from an interworking point of view on Diameter interfaces connecting to the EPS.

Also, my understanding has been that the default value is per local policy.

My 2 cents....
Viqar
________________________________
From: DiME [[email-masked]<mailto:[email-masked]>] on behalf of [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
Hi,

I think that the case "no Priority indication in request" is the default situation today.
So if we agree that it should be possible to explicitly indicate a request with a lower priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 17 values: [0-7][8][9-16].
If any operator can freely fix the default value, there would be no way to ensure the sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority indication.

Therefore, for a deterministic handling mechanism, I think that it is then more relevant to define a standard value for the default value.

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Janet P Gunn
Envoyé : mercredi 30 septembre 2015 22:53
À : DOLLY, MARTIN C
Cc : DiME; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

Same here.  The "default priority" should be a matter of local policy.

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:        "DOLLY, MARTIN C" <[email-masked]<mailto:[email-masked]>>
To:        Steve Donovan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        09/30/2015 04:40 PM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <[email-masked]<mailto:[email-masked]>>
________________________________

Me as well

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

I'm okay with Jay's proposal on not specifying a default value.

Steve
On 9/30/15 3:27 PM, Lee, Jay wrote:
Hi Steve and all,

For the first proposal, as I indicated, I support increasing the number of priority levels up to 16.

I am also fine with the second proposal. My question is: do we need to mandate this feature, as individual operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP AVP, this correspond to 'normal traffic' without a particular high or low priority. Then each operator can map this default to a value (e.g., 8 or something else) that they feel appropriate.

Thanks,

Jay

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime
 _______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
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,

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, 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,

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, Orange is not liable for messages that have been modified,

changed or falsified.

Thank

you.

_______________________________________________

DiME mailing

list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________

DiME mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]<mailto:DiME%40ietf.org>
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Tue, 3 Nov 2015 02:44:10 +0000

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.

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

De : DiME [mailto:[email-masked]] De la part de DOLLY, MARTIN C
Envoyé : lundi 2 novembre 2015 21:38
À : Shaikh, Viqar A; Steve Donovan; Lee, Jay; [email-masked]
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)

I agree

From: DiME [mailto:[email-masked]] On Behalf Of Shaikh, Viqar A
Sent: Thursday, October 29, 2015 3:59 PM
To: Steve Donovan <[email-masked]<mailto:[email-masked]>>; Lee, Jay <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Singh, Ray P <[email-masked]<mailto:[email-masked]>>; Lukacs, Donald R <[email-masked]<mailto:[email-masked]>>; Pollini, Gregory P <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Hello all,

My 2 cents:

Thoughts?

Thanks,

Viqar

Ten is acceptable to me.

Steve

Thanks,

Jay

Hi

Best regards

JJacques

Steve

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

'Should' vs. 'Must':

PRIORITY_14 priority:

Jay

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Ce message et

pas etre

a l'expediteur

Orange decline

Merci.

This message

may be protected by law;

they should

authorisation.

If you have

As emails may

changed or falsified.

Thank

you.

Ce message et

pas etre

a l'expediteur

Orange decline

Merci.

This message

may be protected by law;

they should

authorisation.

If you have

As emails may

changed or falsified.

Thank

you.

DiME mailing

list

DiME mailing list

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 3 Nov 2015 07:20:00 +0000

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:[email-masked]] De la part de [email-masked]
Envoyé : mardi 3 novembre 2015 03:44
À : DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; [email-masked]
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)

Lionel

À : Shaikh, Viqar A; Steve Donovan; Lee, Jay; [email-masked]<mailto:[email-masked]>

I agree

Hello all,

My 2 cents:

Thoughts?

Thanks,

Viqar

Ten is acceptable to me.

Steve

Thanks,

Jay

Hi

Best regards

JJacques

Steve

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

'Should' vs. 'Must':

PRIORITY_14 priority:

Jay

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Ce message et

pas etre

a l'expediteur

Orange decline

Merci.

This message

may be protected by law;

they should

authorisation.

If you have

As emails may

changed or falsified.

Thank

you.

Ce message et

pas etre

a l'expediteur

Orange decline

Merci.

This message

may be protected by law;

they should

authorisation.

If you have

As emails may

changed or falsified.

Thank

you.

DiME mailing

list

DiME mailing list

Thank you.

---

From: <[email-masked]>
Date: Tue, 3 Nov 2015 09:35:21 +0000

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:[email-masked]] 
Envoyé : mardi 3 novembre 2015 08:20
À : MORAND Lionel IMT/OLN; DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; [email-masked]
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

JJacques 

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:

Lionel

I agree

Hello all,
 
My 2 cents:

 

Thoughts?
 
Thanks,
Viqar
 
________________________________________
From: DiME [[email-masked]] on behalf of Steve Donovan [[email-masked]]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)
Ten is acceptable to me.
Steve
On October 28, 2015 1:36:00 PM "Lee, Jay" <[email-masked]> wrote:
I also think that we agree on all different points for the finalization, except one point: the value for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have strong opinion, especially when the default value can be overwritten. 

Any value from 9 to 12 seems reasonable to me. But, without all use cases identified at the present time, I propose 10 (JJacques’ proposal) or 11. 
 
Thanks,
 
Jay
 
To: [email-masked]
 
Hi

Best regards
 
JJacques 
 
À : [email-masked]

To: [email-masked]

Steve
 
From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <[email-masked]>; [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

*/ If we need to assign (but not specify) a value to the default case, we need to make it clear that this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leaving the factory, so that there would be no misunderstanding.
mcd- ok
SRD> I think the current proposed text makes this clear.
[JL] Agree that the current text is OK especially when we use ‘May’ in place of ‘Should’
[JJ] OK 
.
 
*/ Since we agree that the default value is per local policy, ‘May’ is preferred to ‘Should’ in order not to cause confusion.
mcd-ok 
SRD> I'm okay with making this a MAY.
[JL]  Agreed
[JJ] Also in favor of a MAY
 
*/ For assignment of the default value, I am quite open. But any value between 9 – 12 seems reasonable to me.
mcd- value should allow for assigning lower values, though a carrier can assign what they want in their network, there needs to be a common meaning at the interconnection point
SRD> I'm open to any value we decide on.  If there are real use cases that require pushing the default value more to the middle then we should do so.  At this point I've heard one use case for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  
[JJ] Regarding use cases, there may be
-          The case where for “normal” users, an application use the default value for most of its requests except some which have a lower priority
-          the case where besides “normal” user (and high priority users), some users have lower priorities, e.g. Some Machine type Communications (MTC) devices. 
So potentially more than one low priority level would be needed. 
We also have chosen a rather large range of values (16) , allowing flexibility for an operator when they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves only one lower priority and an operator  cannot add a second one  except by choosing  a default value other than the 14  value. 
Then as, in practice, we may expect a range of low priority smaller than  the range of high priority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am open on another value. 
                                                                                                                                                     &! nbsp;&nbs p;                                                                                                  
*/  Current proposal of 16 values may be enough now, but I am fine with having an extensibility bit to be future proof.
mcd-ok 
SRD> I don't see a compelling argument to move beyond 16. 
In addition, it isn't clear to me that there is value in defining an extensibility mechanism beyond what is already supported by Diameter.  Doing so would add significant complexity to the DRMP mechanism for something that, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require that any extension require a new AVP.  We can then leave it to the document that proposes the extension to deal with determining whether send the DRMP AVP or the newly defined DRMPv2 AVP.  
[JL] When we proposed that the range be extended to 16, we thought that ‘16’ was large enough and future proof. 
I am okay with having an extensibility bit, if other companies want it. That said, I agree that it has a low probability of being used and added complexity.
[JJ] JJ I also agree that with 16 values , the offered range is large enough in practice. This point is only to check if it would be easy to do an extension, if we have this requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new document rather than to define a set of reserved values in the DRMP AVP.  A point is that it will require an additional parsing effort for a node to look for this second AVP even if it is not present most of the time.  
 
*/ I am not sure of alternative encoding method (say, +9 to -9 per JJacques’ proposal) compared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. But it offers less flexibility to operators, since the default value may not be easily moved to have more higher/lower priority values. Also, we are used to the enumerated type of DRMP and just want to have extension from 5 to 16,  but this may require more deviation from the current design and thinking. For this, I would like to see more on qualitative pros/cons, but, given its little benefit, I am reluctant to accept this alternative. 
SRD> I agree that I don't see value in the +9 to -9 proposal.
[JL] Agreed
[J] I presented this second  approach  so to review the possible alternatives as we usually do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enumerated DRMP AVP.
 
Best regards
 
JJacques  
 
To: [email-masked]
 
Hi

 

 
   each priority value as a separate priority), ….  That is, an
 
So to have your feedback 
 
Best regards
 
JJacques 
 
Cc : [email-masked]
 
A couple thoughts:

From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <[email-masked]>; Steve Donovan <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)
 
From my side, some more discussion on Steve’s mail may be needed.
 
‘Should’ vs. ‘Must’:
One can say that ‘Should’ is not mandatory. But, in practice, this is a fairly strong statement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the value, I don’t see the reason why we use ‘Should’. My suggestion is using ‘May’.
 
PRIORITY_14 priority:
Since operators can overwrite it, I was not too concerned about it. But if we want to put some value, why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.
 
Jay
 
Cc: [email-masked]
 
with respect to the diff-serv example brought up below, some thing to add to that discussion is that it starts off with separate and distinct forwarding behavior whose marked packets provide segmentation of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust) also discouraged a line of thought to define end-to-end priority handling versus a per diff-serv domain treatment.  RFC-4594 did provide configuration guidelines, but that’s a different story.

1) reserved space.  if we go back to the diff-serv model, the diff-serv working group agreed to set aside a set of values that was reserved for experimental use that could be re-assigned some time in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prudent to set aside a reserved set of bits/values so that one doesn't need to define a new AVP if in the future there was a need to define added values beyond the 5 (plus some fudge factor) already mentioned on the list. 
 
2) sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized that there can be several sets of users/services that are distinct from each other and yet need to prioritize the traffic.  I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assuming that the latter is aimed at the general public and related to 911/112/999 type calls, which should probably be more specific in the draft).  And there is also the potential of Firstnet users in the US.

and just to reiterate.  I’m not making recommendations in the above — just bringing up some food for thought.
 
-ken

On Oct 14, 2015, at 10:12 AM, Steve Donovan <[email-masked]> wrote:
 
Jay,

Regards,

Steve

In practice, this issue can be addressed at the edge of the network, where Diameter edge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the proper handling. One may argue that this is not as good as the ‘deterministic’ case, but operator should be able handle this in a reasonable way. We are fully aware of the fact that, in case of this ‘non-deterministic’ case, the default value can differ from one operator network to another, and it becomes difficult to guarantee the intended priority handling. Despite this, we still prefer giving options to operators by not specifying the default value.
 
What we are saying here, however, is not anything new. This is the typical way of handling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good example of this – Internet QoS, more specifically DiffServ.

By the way, if we are thinking of possibility of specifying the default value, are we assuming that all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren’t there other operators who are not interested in this feature? I know that at least there is one – Verizon. We have no interest in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is NOT specified. But we are certainly not happy if DIME is trying to impose this on us.
 
Jay
 
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; [email-masked]; Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
 
Assuming that we define a range of 3 values,
Assuming that 0 is the lowest priority and 2 the highest,
Assuming that an agent receives 4 messages at the same time while being in overload control:
•       1) ULR with Prio-0
•       2) ULR with Prio-1
•       3) ULR with Prio-2
•       4) ULR with no priority AVP

 
 
Lionel

Cc : DiME; [email-masked]; Pollini, Gregory P
 
Hello all,

 
 
My 2 cents....
Viqar 
________________________________________
From: DiME [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; [email-masked]
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
Hi,

 
Regards,
 
Lionel

Cc : DiME; [email-masked]

Janet

From:        "DOLLY, MARTIN C" <[email-masked]> 
To:        Steve Donovan <[email-masked]>, "[email-masked]" <[email-masked]> 
Date:        09/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <[email-masked]>
________________________________________

Me as well 
  
To: [email-masked]

Steve 

I am also fine with the second proposal. My question is: do we need to mandate this feature, as individual operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic’ without a particular high or low priority. Then each operator can map this default to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 

[email-masked] 
[email-masked]
 
Ce message et
 
This message
 
Ce message et
 
This message
 
[email-masked]

[email-masked]

[email-masked]
 
[email-masked]

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 authorization.
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 shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: "Lee, Jay" <[email-masked]>
Date: Tue, 3 Nov 2015 14:48:45 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 03, 2015 5:32 AM
To: [email-masked]
Cc: [email-masked]; 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

From:        <[email-masked]<mailto:[email-masked]>>
To:        "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]<mailto:[email-masked]>>, "DOLLY, MARTIN C" <[email-masked]<mailto:[email-masked]>>, "Shaikh, Viqar A" <[email-masked]<mailto:[email-masked]>>, Steve Donovan <[email-masked]<mailto:[email-masked]>>, "Lee, Jay" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:        "Singh, Ray P" <[email-masked]<mailto:[email-masked]>>, "Lukacs, Donald R" <[email-masked]<mailto:[email-masked]>>, "Pollini, Gregory P" <[email-masked]<mailto:[email-masked]>>
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" <[email-masked]<mailto:[email-masked]>>
________________________________

Lionel

************************
À : MORAND Lionel IMT/OLN; DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; [email-masked]<mailto:[email-masked]>

Hi Lionel

Two remarks on your mail

JJacques

De : DiME [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mardi 3 novembre 2015 03:44
À : DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; [email-masked]<mailto:[email-masked]>
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)

Lionel

I agree

Hello all,

My 2 cents:

Thoughts?

Thanks,
Viqar

Thanks,

Jay

Hi

Best regards

JJacques

Steve

From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

‘Should’ vs. ‘Must’:

PRIORITY_14 priority:

Jay

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar
From: DiME [[email-masked]] on behalf of [email-masked]<mailto:[email-masked]> [[email-masked]]

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Ce message et

This message

Ce message et

This message

---

From: [email-masked]
Date: Tue, 3 Nov 2015 08:32:20 -0500

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:   <[email-masked]>
To:     "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
<[email-masked]>, "DOLLY, MARTIN C" 
<[email-masked]>, "Shaikh, Viqar A" <[email-masked]>, Steve Donovan 
<[email-masked]>, "Lee, Jay" <[email-masked]>, 
"[email-masked]" <[email-masked]>
Cc:     "Singh, Ray P" <[email-masked]>, "Lukacs, Donald R" 
<[email-masked]>, "Pollini, Gregory P" <[email-masked]>
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" <[email-masked]>

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:[email-masked]] 
Envoyé : mardi 3 novembre 2015 08:20
À : MORAND Lionel IMT/OLN; DOLLY, MARTIN C; Shaikh, Viqar A; Steve 
Donovan; Lee, Jay; [email-masked]
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:[email-masked]] De la part de 
[email-masked]
Envoyé : mardi 3 novembre 2015 03:44
À : DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; 
[email-masked]
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)

      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:

       throttled is *implementation dependent* and is *outside the scope 
of

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

De : DiME [mailto:[email-masked]] De la part de DOLLY, MARTIN C
Envoyé : lundi 2 novembre 2015 21:38
À : Shaikh, Viqar A; Steve Donovan; Lee, Jay; [email-masked]
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)

I agree
 
From: DiME [mailto:[email-masked]] On Behalf Of Shaikh, Viqar A
Sent: Thursday, October 29, 2015 3:59 PM
To: Steve Donovan <[email-masked]>; Lee, Jay 
<[email-masked]>; [email-masked]
Cc: Singh, Ray P <[email-masked]>; Lukacs, Donald R 
<[email-masked]>; Pollini, Gregory P <[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)
 
Hello all,
 
My 2 cents:
 
Greater than 5 values for DRMP AVP is justified and it appears there is 
agreement for 16.  However, note that the 3GPP priority, e.g., 
Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the 
highest, 15 the lowest, and value 0 not defined. Having 15 rather than 16 
for DRMP AVP would be useful from an interworking point of view on 
Diameter interfaces connecting to the EPS. 
 
Regarding the default value - it is based on operator policy and can be 
overwritten by an operator.  Therefore, we support use of "may" and not 
"should".  
 
We feel that 15 or 16 values should suffice and there is no need to define 
an extension bit.  However, I am ok if there is consensus to do so.
 
We feel there is no need to specify a default as it is per local policy 
and can be overwritten.  But, if there is consensus to do so, we suggest 
value 10 or 11 with a note that it can be overwritten based on operator 
policy.
 
Thoughts?
 
Thanks,
Viqar
 
________________________________________
From: DiME [[email-masked]] on behalf of Steve Donovan 
[[email-masked]]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)
Ten is acceptable to me.
Steve
On October 28, 2015 1:36:00 PM "Lee, Jay" <[email-masked]> 
wrote:
I also think that we agree on all different points for the finalization, 
except one point: the value for the default case. Use of the default case 
as discussed here is rather in the future than in the present for us, so I 
do not have strong opinion, especially when the default value can be 
overwritten. 
 
Looking at this objectively and also for the sake of progress, however, it 
would be prudent to have more than one lower priority cases. In the near 
future, we may identify additional use cases for lower priority case. Even 
with one use case identified, this does not necessarily mean one priority 
level per use case. One use case may require multiple lower priority 
levels, depending on applications. 
 
Any value from 9 to 12 seems reasonable to me. But, without all use cases 
identified at the present time, I propose 10 (JJacques’ proposal) or 11. 
 
Thanks,
 
Jay
 
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, 
JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)
 
Hi
 
Please see my comments also in line. I think we are close to finalise our 
choice on the different points  of this thread
 
Best regards
 
JJacques 
 
De : DiME [mailto:[email-masked]] De la part de Lee, Jay
Envoyé : vendredi 23 octobre 2015 18:57
À : [email-masked]
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)

Steve
 
From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
<[email-masked]>; [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)

*/ If we need to assign (but not specify) a value to the default case, we 
need to make it clear that this value can be overwritten by operators, and 
the value is for some use cases like e.g., equipment having the same value 
when leaving the factory, so that there would be no misunderstanding.
mcd- ok
SRD> I think the current proposed text makes this clear.
[JL] Agree that the current text is OK especially when we use ‘May’ in 
place of ‘Should’
[JJ] OK 
.
 
*/ Since we agree that the default value is per local policy, ‘May’ is 
preferred to ‘Should’ in order not to cause confusion.
mcd-ok 
SRD> I'm okay with making this a MAY.
[JL]  Agreed
[JJ] Also in favor of a MAY
 
*/ For assignment of the default value, I am quite open. But any value 
between 9 – 12 seems reasonable to me.
mcd- value should allow for assigning lower values, though a carrier can 
assign what they want in their network, there needs to be a common meaning 
at the interconnection point
SRD> I'm open to any value we decide on.  If there are real use cases that 
require pushing the default value more to the middle then we should do 
so.  At this point I've heard one use case for the default being something 
other then the lowest value, thus the proposal to use priority_14 as the 
default.  
[JJ] Regarding use cases, there may be
-          The case where for “normal” users, an application use the 
default value for most of its requests except some which have a lower 
priority
-          the case where besides “normal” user (and high priority users), 
some users have lower priorities, e.g. Some Machine type Communications 
(MTC) devices. 
So potentially more than one low priority level would be needed. 
We also have chosen a rather large range of values (16) , allowing 
flexibility for an operator when they define the number of priorities they 
want , leaving possibility to future additions. If PRIORITY _14 is the 
default, it leaves only one lower priority and an operator  cannot add a 
second one  except by choosing  a default value other than the 14  value. 
Then as, in practice, we may expect a range of low priority smaller than  
the range of high priority values, this is why the default value was 
proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal 
but I am open on another value. 
                                                                                                                                                     &! 
nbsp;&nbs 
p;                                                                                                  

*/  Current proposal of 16 values may be enough now, but I am fine with 
having an extensibility bit to be future proof.
mcd-ok 
SRD> I don't see a compelling argument to move beyond 16. 
In addition, it isn't clear to me that there is value in defining an 
extensibility mechanism beyond what is already supported by Diameter.  
Doing so would add significant complexity to the DRMP mechanism for 
something that, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require 
that any extension require a new AVP.  We can then leave it to the 
document that proposes the extension to deal with determining whether send 
the DRMP AVP or the newly defined DRMPv2 AVP.  
[JL] When we proposed that the range be extended to 16, we thought that 
‘16’ was large enough and future proof. 
I am okay with having an extensibility bit, if other companies want it. 
That said, I agree that it has a low probability of being used and added 
complexity.
[JJ] JJ I also agree that with 16 values , the offered range is large 
enough in practice. This point is only to check if it would be easy to do 
an extension, if we have this requirement in the future.  I agree with 
Steve that for an extensibility, it will require a new AVP in a new 
document rather than to define a set of reserved values in the DRMP AVP. 
 A point is that it will require an additional parsing effort for a node 
to look for this second AVP even if it is not present most of the time.  
 
*/ I am not sure of alternative encoding method (say, +9 to -9 per 
JJacques’ proposal) compared to the current enumerated type of DRMP. It 
offers a logical way of assigning a value 0 to the default case. But it 
offers less flexibility to operators, since the default value may not be 
easily moved to have more higher/lower priority values. Also, we are used 
to the enumerated type of DRMP and just want to have extension from 5 to 
16,  but this may require more deviation from the current design and 
thinking. For this, I would like to see more on qualitative pros/cons, 
but, given its little benefit, I am reluctant to accept this alternative. 
SRD> I agree that I don't see value in the +9 to -9 proposal.
[JL] Agreed
[J] I presented this second  approach  so to review the possible 
alternatives as we usually do before selecting the solution, this 
alternative being already used in a recent RFC.   That being said, I am 
fine with the enumerated DRMP AVP.
 
Best regards
 
JJacques  
 
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, 
JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)
 
Hi
 
1.      PRIORITY_14 as default priority value only allows one level of 
lower priority (PRIORITY_15)  than the default one; this seems not enough. 
 As use cases, we may have  some Machine type Communication (LTC) devices 
that may have lower priorities that normal communications without 
priority.  Even within a Diameter application, some commands may have a 
lower priority as having a secundary importance. 
 
Then which default  value ? 
-        it could be PRIORITY_8 in the middle, or if we prefer to have a 
 larger range for higher priorities  than for lower priorities,  the 
default value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 
5 lower priorities than the default one. I would have a preference for 
this value PRIORITY_10.
 
2.      About extensibility, the current range of 16 values is already 
large, but we can have  a reserved value to indicate a further extension. 
With  an enumerated AVP, there is no possibility to add new values.  
 
3.      I also had a look to some other IETF RFCs addressing priorities 
that Ken mentioned, so to see if we can benefit from these approaches 
although done for different contexts.
-        in RFC 4412 (Resource-Priority Header in SIP), wps and ets 
namespaces have a range of 5 values (0 to 4) with 0 as the highest 
priority  . But I have not found some indication  (I may have missed it) 
about the default priority  (I mean a SIP request without  
Resource-Priority Header compared  to a SIP request with the Header). 
Implicitly, I would assume a SIP request without  Resource-Priority Header 
corresponds to  the lowest priority.  DRMP has a similar approach but 
with  a larger range and also lower priorities. 
 
-        RFC  6710 (priority for SMTP),  uses another encoding of the 
priority values with an integer between -9 and +9. Lower priorities  are 
negative an higher priority being positive. When a value increases, it 
means a higher priority, so the opposite  to DRMP, wps or ets.  But the 
value 0 is here naturally the default value. So this is an encoding 
alternative  to the  Enumerated type of the DRMP AVP which avoids the 
question of the default value. 
Note: RFC  6710 also defines some Priority Assignment Policies using a 
subset of the range. 
 
RFC 6710 has also this guideline : 
   SMTP servers compliant with this specification are not
   required to support all 19 distinct priority levels (i.e., to treat
   each priority value as a separate priority), ….  That is, an
   implementation that only supports N priority levels (where N < 19)
   will internally round up a syntactically valid priority value that
   isn't supported to the next higher supported number (or to the
   highest supported priority, if the value is higher than any supported 
priority).
-        This raises the question to have this type of  guideline if 
considered useful. 
 
So to have your feedback 
 
Best regards
 
JJacques 
 
De : DiME [mailto:[email-masked]] De la part de DOLLY, MARTIN C
Envoyé : jeudi 15 octobre 2015 12:33
À : Lee, Jay; ken carlberg; Steve Donovan
Cc : [email-masked]
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)
 
A couple thoughts:
1.      There needs to be a default value defined by the standard, so that 
equipment have the same value leaving the factory
2.      This value can be over written based on local policy
3.      Should have an extensibility bit in order to and more values in 
the future

From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <[email-masked]>; Steve Donovan 
<[email-masked]>
Cc: [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)

‘Should’ vs. ‘Must’:
One can say that ‘Should’ is not mandatory. But, in practice, this is a 
fairly strong statement, and often taken as required. So in this sense, 
the proposed Note is certainly helpful. But, since we allow operators to 
override the value, I don’t see the reason why we use ‘Should’. My 
suggestion is using ‘May’.
 
PRIORITY_14 priority:
Since operators can overwrite it, I was not too concerned about it. But if 
we want to put some value, why ‘14’? A value lower than 14 is suggested in 
order to allow more rooms for lower priorities.
 
Jay
 
From: DiME [mailto:[email-masked]] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: [email-masked]
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): 
Range of priority levels)
 
with respect to the diff-serv example brought up below, some thing to add 
to that discussion is that it starts off with separate and distinct 
forwarding behavior whose marked packets provide segmentation of other IP 
traffic.  The availability of only 6 bits to play with (along with the 
headaches of transitive trust) also discouraged a line of thought to 
define end-to-end priority handling versus a per diff-serv domain 
treatment.  RFC-4594 did provide configuration guidelines, but that’s a 
different story.

1) reserved space.  if we go back to the diff-serv model, the diff-serv 
working group agreed to set aside a set of values that was reserved for 
experimental use that could be re-assigned some time in the future.  I’m 
not suggesting that there should be space set side for experiments, but 
rather it may be prudent to set aside a reserved set of bits/values so 
that one doesn't need to define a new AVP if in the future there was a 
need to define added values beyond the 5 (plus some fudge factor) already 
mentioned on the list. 
 
2) sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized 
that there can be several sets of users/services that are distinct from 
each other and yet need to prioritize the traffic.  I bring this up 
because the draft already identifies two sets of users in sections 5.1 and 
5.2 (note: I’m assuming that the latter is aimed at the general public and 
related to 911/112/999 type calls, which should probably be more specific 
in the draft).  And there is also the potential of Firstnet users in the 
US.
 
As a side note, the distinction and separation of general public and other 
prioritized users in public phone infrastructures is not exclusive to the 
US, so the group should not be concerned that this is a US centric effort. 
 There has been GTPS in the UK, as well as other systems in other 
countries.  The RFC is a bit dated, but feel free to go over rfc-4190 for 
added background.
 
and just to reiterate.  I’m not making recommendations in the above — just 
bringing up some food for thought.
 
-ken

On Oct 14, 2015, at 10:12 AM, Steve Donovan <[email-masked]> 
wrote:
 
Jay,

As such, operators can choose to either not implement a priority or define 
a different value for their network.

I propose adding the following note after this paragraph to further 
explain why it is a SHOULD and not a MUST:

This leaves the ability for there to be deterministic behavior in Diameter 
networks that require a default to be defined and are happy with the 
specified default.  It also gives operators the ability to define a 
different behavior, most likely with some priority handling/mapping at the 
edge of the network.

Regards,

Steve
On 10/14/15 2:59 AM, Lee, Jay wrote:
Regarding the issue of whether we need to specify a default value or not, 
there are pros and cons.
 
If we specify a value for the default case, we can see the benefits in 
scenarios between different operator networks, but we take away important 
options on what operators can do with priority values. On the other hand, 
if we do not specify the default value, operators may have more options, 
but there is a question of what to do for this inter-PLMN cases when the 
networks may use different default values.
 
In practice, this issue can be addressed at the edge of the network, where 
Diameter edge agent (DEA) can perform some priority mapping based on 
bilateral roaming agreement (or SLA (service level agreement)) and other 
means to insure the proper handling. One may argue that this is not as 
good as the ‘deterministic’ case, but operator should be able handle this 
in a reasonable way. We are fully aware of the fact that, in case of this 
‘non-deterministic’ case, the default value can differ from one operator 
network to another, and it becomes difficult to guarantee the intended 
priority handling. Despite this, we still prefer giving options to 
operators by not specifying the default value.
 
What we are saying here, however, is not anything new. This is the typical 
way of handling priority levels. If anything, specifying the default value 
would be something new. As already mentioned in CT discussion, there is a 
good example of this – Internet QoS, more specifically DiffServ.
 
In order to guarantee end-to-end QoS for a specific service, IETF could 
have specified a value (DiffServ codepoint) for the specific service to 
have predetermined handling of the traffic, but IETF did not. Instead, 
DiffServ simply provided a framework for operators to have its own 
 classification and differentiated treatment of the services. To guarantee 
end-to-end QoS across different networks, then, operators need to do 
packet inspection, (re)classification, QoS mapping, use of SLA and 
possibly others at the edge of network (edge router). Therefore, in the 
DiffServ architecture, intelligence was pushed to the edge of the network. 
While the end results may not be guaranteed as well as in the case of 
predetermined handling, it was still a preferred way to give flexibility 
to operators. My point is that we went through all these troubles to give 
options of priority handling to operators.
 
By the way, if we are thinking of possibility of specifying the default 
value, are we assuming that all operators are interested in this feature 
(default value in the middle, and high and low priorities at other ends)? 
Aren’t there other operators who are not interested in this feature? I 
know that at least there is one – Verizon. We have no interest in this 
feature, and no plan for implementing it. We are OK, if other operators 
are interested in this feature, and the default value is NOT specified. 
But we are certainly not happy if DIME is trying to impose this on us.
 
Jay
 
From: DiME [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; [email-masked]; Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
 
Assuming that we define a range of 3 values,
Assuming that 0 is the lowest priority and 2 the highest,
Assuming that an agent receives 4 messages at the same time while being in 
overload control:
•       1) ULR with Prio-0
•       2) ULR with Prio-1
•       3) ULR with Prio-2
•       4) ULR with no priority AVP

How do you know that the ULR with priority 2 will be handled with a higher 
priority  than the request without priority indication?
And what about ULR message with priority 1 with two levels of highest 
priority e.g. emergency/Important and government/very important?

Lionel

 
Hello all,
 
Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 
29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 
not defined.
 
Having 15 rather than 16 would be useful from an interworking point of 
view on Diameter interfaces connecting to the EPS.  
 
Also, my understanding has been that the default value is per local 
policy. 
 
My 2 cents....
Viqar 
________________________________________
From: DiME [[email-masked]] on behalf 
of [email-masked] [[email-masked]]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; [email-masked]
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
Hi,
 
I think that the case "no Priority indication in request" is the default 
situation today.
So if we agree that it should be possible to explicitly indicate a request 
with a lower priority, we should divide the range of priority values in 
three sub-ranges: [lower priorities][no priority indication][higher 
priorities], e.g. with 17 values: [0-7][8][9-16].
If any operator can freely fix the default value, there would be no way to 
ensure the sender that a request with a specific priority value (e.g. 6) 
will be handled with a lower or higher priority than a request with no 
priority indication.
 
Therefore, for a deterministic handling mechanism, I think that it is then 
more relevant to define a standard value for the default value.
 
Regards,
 
Lionel

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. 

To:        Steve Donovan <[email-masked]>, "[email-masked]" 
<[email-masked]> 

Me as well 

Steve 
  
For the first proposal, as I indicated, I support increasing the number of 
priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we need to 
mandate this feature, as individual operators have different situations? 
Perhaps some flexibility should be allowed? Instead of mandating it, we 
can include the statement that when there is no DRMP AVP, this correspond 
to ‘normal traffic’ without a particular high or low priority. Then each 
operator can map this default to a value (e.g., 8 or something else) that 
they feel appropriate. 
  
Thanks, 
  
Jay 

Ce message et
 
This message
and its attachments may contain confidential or privileged information 
that
may be protected by law;
they should
 
Ce message et
 
This message
and its attachments may contain confidential or privileged information 
that
may be protected by law;
they should

 

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,
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, 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 authorization.
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 shall not be liable if 
this message was modified, changed or falsified.
Thank you.

---

From: "Lee, Jay" <[email-masked]>
Date: Tue, 3 Nov 2015 14:42:52 +0000

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. But maybe we are converging.

Thanks,

Jay

Janet

Lionel

************************

Hi Lionel

Two remarks on your mail

JJacques

Lionel

I agree

Hello all,

My 2 cents:

Thoughts?

Thanks,
Viqar

Thanks,

Jay

Hi

Best regards

JJacques

Steve

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

‘Should’ vs. ‘Must’:

PRIORITY_14 priority:

Jay

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Ce message et

This message

Ce message et

This message

---

From: [email-masked]
Date: Mon, 2 Nov 2015 16:13:14 -0500

I also agree
Janet

To:     "Shaikh, Viqar A" <[email-masked]>, Steve Donovan 
Date:   11/02/2015 03:39 PM

I agree

Hello all,
 
My 2 cents:

 

Thoughts?
 
Thanks,
Viqar

 
 
Thanks,
 
Jay

Hi

Best regards
 
JJacques 

 

Steve

 

require pushing the default value more to the middle then we should do so. 
 At this point I've heard one use case for the default being something 

document rather than to define a set of reserved values in the DRMP AVP. A 
point is that it will require an additional parsing effort for a node to 
look for this second AVP even if it is not present most of the time. 

Best regards
 
JJacques 

Hi

 
 
corresponds to  the lowest priority.  DRMP has a similar approach but with 
 a larger range and also lower priorities. 

 
So to have your feedback 
 
Best regards
 
JJacques 

A couple thoughts:

From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <[email-masked]>; Steve Donovan <
[email-masked]>
Cc: [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
(drmp): Range of priority levels)

‘Should’ vs. ‘Must’:
 
PRIORITY_14 priority:
 
Jay

 

 

-ken

Jay,

Regards,

Steve

 

 
Jay
 
From: DiME [mailto:[email-masked]] On Behalf Of 
[email-masked]
 
Assuming that we define a range of 3 values,
Assuming that 0 is the lowest priority and 2 the highest,
Assuming that an agent receives 4 messages at the same time while being in 
overload control:
·       1) ULR with Prio-0
·       2) ULR with Prio-1
·       3) ULR with Prio-2
·       4) ULR with no priority AVP

 
 
Lionel

 
Hello all,

 
 
My 2 cents....
Viqar 

From: DiME [[email-masked]] on behalf of [email-masked] [
[email-masked]]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; [email-masked]
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
Hi,

 
Regards,
 
Lionel

Janet

To:        Steve Donovan <[email-masked]>, "[email-masked]" <
[email-masked]> 

Me as well 

Steve 

  
Thanks, 
  
Jay 

Ce message et
 
This message
 
Ce message et
 
This message

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 Nov 2015 05:54:05 +0900

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:[email-masked] [mailto:[email-masked]]
> *Sent:* Tuesday, November 03, 2015 5:32 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; 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)
>
> 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 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).
>
> 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: <[email-masked] <mailto:[email-masked]>>
> <[email-masked] 
> <mailto:[email-masked]>>, "DOLLY, MARTIN C" 
> <[email-masked] <mailto:[email-masked]>>, "Shaikh, Viqar A" 
> <[email-masked] <mailto:[email-masked]>>, Steve Donovan 
> <[email-masked] <mailto:[email-masked]>>, "Lee, 
> Jay" <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "Singh, Ray P" <[email-masked] 
> <mailto:[email-masked]>>, "Lukacs, Donald R" 
> <[email-masked] <mailto:[email-masked]>>, "Pollini, 
> Gregory P" <[email-masked] <mailto:[email-masked]>>
> Sent by: "DiME" <[email-masked] <mailto:[email-masked]>>
>
> ------------------------------------------------------------------------
>
>
>
>
> 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.
> 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.
>
> 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:[email-masked]]
> Donovan; Lee, Jay; [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 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.
> 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.
>
> 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.
> already said that the priority indication is… an indication that may 
> be taken into account, as below:
>
> <mailto:[email-masked]>
> To: Steve Donovan <[email-masked] 
> <mailto:[email-masked]>>; Lee, Jay 
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> Cc: Singh, Ray P <[email-masked] <mailto:[email-masked]>>; 
> Lukacs, Donald R <[email-masked] 
> <mailto:[email-masked]>>; Pollini, Gregory P 
> <[email-masked] <mailto:[email-masked]>>
> Greater than 5 values for DRMP AVP is justified and it appears there 
> is agreement for 16.  However, note that the 3GPP priority, e.g., 
> highest, 15 the lowest, and value 0 not defined. Having 15 rather than 
> 16 for DRMP AVP would be useful from an interworking point of view on 
> Regarding the default value - it is based on operator policy and can 
> be overwritten by an operator.  Therefore, we support use of "may" and 
> not "should".
>
> We feel that 15 or 16 values should suffice and there is no need to 
> define an extension bit.  However, I am ok if there is consensus to do so.
>
> We feel there is no need to specify a default as it is per local 
> policy and can be overwritten.  But, if there is consensus to do so, 
> we suggest value 10 or 11 with a note that it can be overwritten based 
> on operator policy.
>
> Thoughts?
>
> Thanks,
> Viqar
>
> To: Lee, Jay; [email-masked] <mailto:[email-masked]>
> On October 28, 2015 1:36:00 PM "Lee, Jay" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> I also think that we agree on all different points for the 
> finalization, except one point: the value for the default case. Use of 
> the default case as discussed here is rather in the future than in the 
> present for us, so I do not have strong opinion, especially when the 
> default value can be overwritten.
>
> Looking at this objectively and also for the sake of progress, 
> however, it would be prudent to have more than one lower priority 
> cases. In the near future, we may identify additional use cases for 
> lower priority case. Even with one use case identified, this does not 
> necessarily mean one priority level per use case. One use case may 
> require multiple lower priority levels, depending on applications.
>
> Any value from 9 to 12 seems reasonable to me. But, without all use 
> cases identified at the present time, I propose 10 (JJacques’ 
> proposal) or 11.
>
> Thanks,
>
> Jay
>
> To: [email-masked] <mailto:[email-masked]>
> Please see my comments also in line. I think we are close to finalise 
> our choice on the different points  of this thread
>
> Best regards
>
> JJacques
>
> À : [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> */ If we need to assign (but not specify) a value to the default case, 
> we need to make it clear that this value can be overwritten by 
> operators, and the value is for some use cases like e.g., equipment 
> having the same value when leaving the factory, so that there would be 
> no misunderstanding.
> mcd- ok
> mcd- value should allow for assigning lower values, though a carrier 
> can assign what they want in their network, there needs to be a common 
> meaning at the interconnection point
> SRD> I'm open to any value we decide on.  If there are real use cases 
> that require pushing the default value more to the middle then we 
> should do so.  At this point I've heard one use case for the default 
> being something other then the lowest value, thus the proposal to use 
> priority_14 as the default.
> -          the case where besides “normal” user (and high priority 
> users), some users have lower priorities, e.g. Some Machine type 
> Communications (MTC) devices.
> flexibility for an operator when they define the number of priorities 
> they want , leaving possibility to future additions. If PRIORITY _14 
> is the default, it leaves only one lower priority and an operator 
>  cannot add a second one  except by choosing  a default value other 
> than the 14  value.
> Then as, in practice, we may expect a range of low priority smaller 
> than  the range of high priority values, this is why the default value 
> was proposed to be in the range 9-12  . Then I proposed 10 so to do a 
> proposal but I am open on another value.
>                                                                                                                                                      &! 
> nbsp;&nbs p;
> */  Current proposal of 16 values may be enough now, but I am fine 
> with having an extensibility bit to be future proof.
> mcd-ok
> document that proposes the extension to deal with determining whether 
> send the DRMP AVP or the newly defined DRMPv2 AVP.
> [JL] When we proposed that the range be extended to 16, we thought 
> that ‘16’ was large enough and future proof.
> I am okay with having an extensibility bit, if other companies want 
> it. That said, I agree that it has a low probability of being used and 
> added complexity.
> enough in practice. This point is only to check if it would be easy to 
> do an extension, if we have this requirement in the future.  I agree 
> with Steve that for an extensibility, it will require a new AVP in a 
> new document rather than to define a set of reserved values in the 
> DRMP AVP.  A point is that it will require an additional parsing 
> effort for a node to look for this second AVP even if it is not 
> present most of the time.
>
> JJacques’ proposal) compared to the current enumerated type of DRMP. 
> It offers a logical way of assigning a value 0 to the default case. 
> But it offers less flexibility to operators, since the default value 
> may not be easily moved to have more higher/lower priority values. 
> Also, we are used to the enumerated type of DRMP and just want to have 
> extension from 5 to 16,  but this may require more deviation from the 
> current design and thinking. For this, I would like to see more on 
> qualitative pros/cons, but, given its little benefit, I am reluctant 
> to accept this alternative.
> alternative being already used in a recent RFC.   That being said, I 
> am fine with the enumerated DRMP AVP.
>
> Best regards
>
> JJacques
>
> To: [email-masked] <mailto:[email-masked]>
> lower priority (PRIORITY_15)  than the default one; this seems not 
> enough.  As use cases, we may have  some Machine type Communication 
> (LTC) devices that may have lower priorities that normal 
> communications without priority.  Even within a Diameter application, 
> some commands may have a lower priority as having a secundary importance.
>
> -        it could be PRIORITY_8 in the middle, or if we prefer to have 
> a  larger range for higher priorities  than for lower priorities,  the 
> default value could be  e.g. PRIORITY_10,  giving 9 higher priorities 
> and 5 lower priorities than the default one. I would have a preference 
> for this value PRIORITY_10.
>
> large, but we can have  a reserved value to indicate a further 
> extension. With  an enumerated AVP, there is no possibility to add new 
> values.
>
> 3.      I also had a look to some other IETF RFCs addressing 
> priorities that Ken mentioned, so to see if we can benefit from these 
> approaches although done for different contexts.
> priority  . But I have not found some indication  (I may have missed 
> it) about the default priority  (I mean a SIP request without  
> Implicitly, I would assume a SIP request without Resource-Priority 
> Header corresponds to  the lowest priority.  DRMP has a similar 
> approach but with  a larger range and also lower priorities.
>
> priority values with an integer between -9 and +9. Lower priorities 
>  are negative an higher priority being positive. When a value 
> increases, it means a higher priority, so the opposite  to DRMP, wps 
> or ets.  But the value 0 is here naturally the default value. So this 
> is an encoding alternative  to the  Enumerated type of the DRMP AVP 
> which avoids the question of the default value.
> Cc : [email-masked] <mailto:[email-masked]>
> 1.      There needs to be a default value defined by the standard, so 
> that equipment have the same value leaving the factory
> To: ken carlberg <[email-masked] <mailto:[email-masked]>>; 
> Steve Donovan <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> One can say that ‘Should’ is not mandatory. But, in practice, this is 
> a fairly strong statement, and often taken as required. So in this 
> sense, the proposed Note is certainly helpful. But, since we allow 
> operators to override the value, I don’t see the reason why we use 
> ‘Should’. My suggestion is using ‘May’.
>
> PRIORITY_14 priority:
> Since operators can overwrite it, I was not too concerned about it. 
> But if we want to put some value, why ‘14’? A value lower than 14 is 
> suggested in order to allow more rooms for lower priorities.
>
> Jay
>
> Cc: [email-masked] <mailto:[email-masked]>
> with respect to the diff-serv example brought up below, some thing to 
> add to that discussion is that it starts off with separate and 
> distinct forwarding behavior whose marked packets provide segmentation 
> of other IP traffic.  The availability of only 6 bits to play with 
> (along with the headaches of transitive trust) also discouraged a line 
> of thought to define end-to-end priority handling versus a per 
> diff-serv domain treatment.  RFC-4594 did provide configuration 
> guidelines, but that’s a different story.
>
> 1) reserved space.  if we go back to the diff-serv model, the 
> diff-serv working group agreed to set aside a set of values that was 
> reserved for experimental use that could be re-assigned some time in 
> the future.  I’m not suggesting that there should be space set side 
> for experiments, but rather it may be prudent to set aside a reserved 
> set of bits/values so that one doesn't need to define a new AVP if in 
> the future there was a need to define added values beyond the 5 (plus 
> some fudge factor) already mentioned on the list.
>
> that there can be several sets of users/services that are distinct 
> from each other and yet need to prioritize the traffic.  I bring this 
> up because the draft already identifies two sets of users in sections 
> 5.1 and 5.2 (note: I’m assuming that the latter is aimed at the 
> general public and related to 911/112/999 type calls, which should 
> probably be more specific in the draft).  And there is also the 
> potential of Firstnet users in the US.
>
> As a side note, the distinction and separation of general public and 
> other prioritized users in public phone infrastructures is not 
> exclusive to the US, so the group should not be concerned that this is 
> a US centric effort.  There has been GTPS in the UK, as well as other 
> systems in other countries.  The RFC is a bit dated, but feel free to 
> go over rfc-4190 for added background.
>
> On Oct 14, 2015, at 10:12 AM, Steve Donovan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Jay,
>
> As such, operators can choose to either not implement a priority or 
> define a different value for their network.
>
> This leaves the ability for there to be deterministic behavior in 
> Diameter networks that require a default to be defined and are happy 
> with the specified default.  It also gives operators the ability to 
> define a different behavior, most likely with some priority 
> handling/mapping at the edge of the network.
>
> scenarios between different operator networks, but we take away 
> important options on what operators can do with priority values. On 
> the other hand, if we do not specify the default value, operators may 
> have more options, but there is a question of what to do for this 
> inter-PLMN cases when the networks may use different default values.
>
> In practice, this issue can be addressed at the edge of the network, 
> where Diameter edge agent (DEA) can perform some priority mapping 
> based on bilateral roaming agreement (or SLA (service level 
> agreement)) and other means to insure the proper handling. One may 
> argue that this is not as good as the ‘deterministic’ case, but 
> operator should be able handle this in a reasonable way. We are fully 
> aware of the fact that, in case of this ‘non-deterministic’ case, the 
> default value can differ from one operator network to another, and it 
> becomes difficult to guarantee the intended priority handling. Despite 
> this, we still prefer giving options to operators by not specifying 
> the default value.
>
> What we are saying here, however, is not anything new. This is the 
> typical way of handling priority levels. If anything, specifying the 
> default value would be something new. As already mentioned in CT 
> discussion, there is a good example of this – Internet QoS, more 
> specifically DiffServ.
>
> In order to guarantee end-to-end QoS for a specific service, IETF 
> could have specified a value (DiffServ codepoint) for the specific 
> service to have predetermined handling of the traffic, but IETF did 
> not. Instead, DiffServ simply provided a framework for operators to 
> have its own  classification and differentiated treatment of the 
> services. To guarantee end-to-end QoS across different networks, then, 
> operators need to do packet inspection, (re)classification, QoS 
> mapping, use of SLA and possibly others at the edge of network (edge 
> router). Therefore, in the DiffServ architecture, intelligence was 
> pushed to the edge of the network. While the end results may not be 
> guaranteed as well as in the case of predetermined handling, it was 
> still a preferred way to give flexibility to operators. My point is 
> that we went through all these troubles to give options of priority 
> handling to operators.
>
> By the way, if we are thinking of possibility of specifying the 
> default value, are we assuming that all operators are interested in 
> this feature (default value in the middle, and high and low priorities 
> at other ends)? Aren’t there other operators who are not interested in 
> this feature? I know that at least there is one – Verizon. We have no 
> interest in this feature, and no plan for implementing it. We are OK, 
> if other operators are interested in this feature, and the default 
> value is NOT specified. But we are certainly not happy if DIME is 
> trying to impose this on us.
>
> Jay
>
> [email-masked] <mailto:[email-masked]>
> Cc: DiME; [email-masked] <mailto:[email-masked]>; Pollini, Gregory P
> How do you know that the ULR with priority 2 will be handled with a 
> higher priority  than the request without priority indication?
> Cc : DiME; [email-masked] <mailto:[email-masked]>; Pollini, Gregory P
> 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 
> 0 not defined.
>
> From: DiME [[email-masked]] on behalf of 
> [email-masked] 
> <mailto:[email-masked]> [[email-masked]]
> Cc: DiME; [email-masked] <mailto:[email-masked]>
> So if we agree that it should be possible to explicitly indicate a 
> request with a lower priority, we should divide the range of priority 
> values in three sub-ranges: [lower priorities][no priority 
> indication][higher priorities], e.g. with 17 values: [0-7][8][9-16].
> If any operator can freely fix the default value, there would be no 
> way to ensure the sender that a request with a specific priority value 
> (e.g. 6) will be handled with a lower or higher priority than a 
> request with no priority indication.
>
> Therefore, for a deterministic handling mechanism, I think that it is 
> then more relevant to define a standard value for the default value.
>
> Regards,
>
> Lionel
>
>
> Cc : DiME; [email-masked] <mailto:[email-masked]>
> 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:        "DOLLY, MARTIN C" <[email-masked] <mailto:[email-masked]>>
> To:        Steve Donovan <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> mandate this feature, as individual operators have different 
> situations? Perhaps some flexibility should be allowed? Instead of 
> mandating it, we can include the statement that when there is no DRMP 
> AVP, this correspond to ‘normal traffic’ without a particular high or 
> low priority. Then each operator can map this default to a value 
> (e.g., 8 or something else) that they feel appropriate.
>
> Thanks,
>
> Jay
>
>
>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> As emails may be altered, France Telecom - Orange shall not be liable 
> if this message was modified, changed or falsified.
> Thank you.
>
> [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 3 Nov 2015 23:29:14 +0000

I'm more than OK with Janet's clarification.

Lionel

Envoyé depuis mon mobile Orange

----- Reply message -----
De : "Steve Donovan" <[email-masked]>
Pour : "[email-masked]" <[email-masked]>
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

Thanks,

Jay

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, November 03, 2015 5:32 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 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)

Janet

From:        <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>

Lionel

************************
De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [<mailto:[email-masked]>mailto:[email-masked]]

Hi Lionel

Two remarks on your mail

JJacques

Lionel

À : Shaikh, Viqar A; Steve Donovan; Lee, Jay; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

I agree

Hello all,

My 2 cents:

Thoughts?

Thanks,
Viqar

________________________________________
From: DiME [[email-masked]<mailto:[email-masked]>] on behalf of Steve Donovan [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)
Ten is acceptable to me.
Steve
On October 28, 2015 1:36:00 PM "Lee, Jay" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
I also think that we agree on all different points for the finalization, except one point: the value for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have strong opinion, especially when the default value can be overwritten.

Thanks,

Jay

Hi

Best regards

JJacques

Steve

From: DiME [mailto:[email-masked]] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

‘Should’ vs. ‘Must’:

PRIORITY_14 priority:

Jay

-ken

On Oct 14, 2015, at 10:12 AM, Steve Donovan <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Jay,

Regards,

Steve

Jay

From: DiME [mailto:[email-masked]] On Behalf Of <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

Lionel

De : Shaikh, Viqar A [<mailto:[email-masked]>mailto:[email-masked]]

Hello all,

My 2 cents....
Viqar
From: DiME [[email-masked]<mailto:[email-masked]>] on behalf of <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]

Regards,

Lionel

Janet

From:        "DOLLY, MARTIN C" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>

Me as well

Steve

Thanks,

Jay

Ce message et

This message

Ce message et

This message

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 4 Nov 2015 21:43:36 +0000

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

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:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 4 novembre 2015 00:29
À : Steve Donovan; [email-masked]<mailto:[email-masked]>
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

----- Reply message -----
De : "Steve Donovan" <[email-masked]<mailto:[email-masked]>>
Pour : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

Steve

Thanks,

Jay

Janet

Lionel

************************

Hi Lionel

Two remarks on your mail

JJacques

Lionel

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 4 Nov 2015 21:20:56 +0000

Dear all

Best regards

JJacques

À : Steve Donovan; [email-masked]

Lionel

----- Reply message -----
De : "Steve Donovan" <[email-masked]<mailto:[email-masked]>>
Pour : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

Steve

Thanks,

Jay

Janet

Lionel

************************

Hi Lionel

Two remarks on your mail

JJacques

Lionel

I agree

Hello all,

My 2 cents:

Thoughts?

Thanks,
Viqar

Thanks,

Jay

Hi

Best regards

JJacques

Steve

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

‘Should’ vs. ‘Must’:

PRIORITY_14 priority:

Jay

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Ce message et

This message

Ce message et

This message

DiME mailing list

Thank you.

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 01:50:48 +0000

Hi All,

I will propose to hold for now on the discussion on the note, waiting for Steve's attempt to cover all the proposed approaches in a single text!

Lionel

De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : mercredi 4 novembre 2015 22:21
À : [email-masked]
Objet : Re: [Dime] Two meanings for "default" Re: diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Dear all

JJacques

Lionel

----- Reply message -----
De : "Steve Donovan" <[email-masked]<mailto:[email-masked]>>
Pour : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

Steve

Thanks,

Jay

Janet

Lionel

************************

Hi Lionel

Two remarks on your mail

JJacques

Lionel

I agree

Hello all,

My 2 cents:

Thoughts?

Thanks,
Viqar

Thanks,

Jay

Hi

Best regards

JJacques

Steve

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

‘Should’ vs. ‘Must’:

PRIORITY_14 priority:

Jay

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Ce message et

This message

Ce message et

This message

DiME mailing list

Thank you.

---

From: "Lee, Jay" <[email-masked]>
Date: Thu, 5 Nov 2015 02:11:31 +0000

Jean Jacques, for 3), we need to wait for Steve’s revised text. We agreed to keep ‘should’ in the existing text at the meeting with further mail discussion later.  If we use ‘should’ for optional feature, appropriate Note should be added to clearly indicate that it is indeed optional.

Jay

From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES
Sent: Wednesday, November 04, 2015 1:21 PM
To: [email-masked]
Subject: Re: [Dime] Two meanings for "default" Re: diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Dear all

JJacques

Lionel

----- Reply message -----
De : "Steve Donovan" <[email-masked]<mailto:[email-masked]>>
Pour : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

Steve

Thanks,

Jay

Janet

Lionel

************************

Hi Lionel

Two remarks on your mail

JJacques

Lionel

I agree

Hello all,

My 2 cents:

Thoughts?

Thanks,
Viqar

Thanks,

Jay

Hi

Best regards

JJacques

Steve

Best regards

JJacques

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

‘Should’ vs. ‘Must’:

PRIORITY_14 priority:

Jay

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Ce message et

This message

Ce message et

This message

DiME mailing list

Thank you.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 5 Nov 2015 07:46:52 +0000

Hi
 
For sure, we will wait for Steve’s proposal. When I mentioned "another proposal" in my mail , I should have indicated it was Steve's one.

Best regards

JJacques  

De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 5 novembre 2015 02:51
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : RE: [Dime] Two meanings for "default" Re: diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Hi All,

Lionel

Dear all

JJacques 

Lionel

----- Reply message -----

Steve

 
Thanks,
 
Jay

Janet

From:        <[email-masked]> 
To:        "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>, "DOLLY, MARTIN C" <[email-masked]>, "Shaikh, Viqar A" <[email-masked]>, Steve Donovan <[email-masked]>, "Lee, Jay" <[email-masked]>, "[email-masked]" <[email-masked]> 
Cc:        "Singh, Ray P" <[email-masked]>, "Lukacs, Donald R" <[email-masked]>, "Pollini, Gregory P" <[email-masked]> 
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" <[email-masked]> 
________________________________________

Lionel

************************

Hi Lionel

Two remarks on your mail

JJacques 

Lionel