Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

From: <[email-masked]>
Date: Thu, 1 Oct 2015 07:36:46 +0000

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

---

From: "Shaikh, Viqar A" <[email-masked]>
Date: Fri, 2 Oct 2015 23:20:33 +0000

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,

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

---

From: <[email-masked]>
Date: Tue, 13 Oct 2015 17:54:43 +0000

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]; Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels

Hello all,

My 2 cents....
Viqar
________________________________
From: DiME [[email-masked]] on behalf of [email-masked]<mailto:[email-masked]> [[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,

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

Janet

Me as well

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

Thank you.

---

From: "Lee, Jay" <[email-masked]>
Date: Wed, 14 Oct 2015 07:59:37 +0000

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

·       1) ULR with Prio-0

·       2) ULR with Prio-1

·       3) ULR with Prio-2

Lionel

Cc : DiME; [email-masked]<mailto:[email-masked]>; Pollini, Gregory P

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Thank you.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 14 Oct 2015 09:12:25 -0500

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:
> 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
>
> ·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?
>
> *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.
>
> ------------------------------------------------------------------------
>
> *From:*DiME [[email-masked]] on behalf of 
> [email-masked] <mailto:[email-masked]> 
> [[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,
>
> 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
>
> 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]>>
> 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 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] <mailto:[email-masked]>
> [email-masked] <mailto:[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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> [email-masked]

---

From: ken carlberg <[email-masked]>
Date: Wed, 14 Oct 2015 11:39:35 -0400

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]> 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.
> 
>> 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] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
>> Cc: DiME; [email-masked] <mailto:[email-masked]>; Pollini, Gregory P
>> De : Shaikh, Viqar A [mailto:[email-masked] <mailto:[email-masked]>] 
>> Cc : DiME; [email-masked] <mailto:[email-masked]>; Pollini, Gregory P
>> From: DiME [[email-masked] <mailto:[email-masked]>] on behalf of  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> [[email-masked] <mailto:[email-masked]>]
>> Cc: DiME; [email-masked] <mailto:[email-masked]>
>> De : DiME [mailto:[email-masked] <mailto:[email-masked]>] De la part de Janet P Gunn
>> Cc : DiME; [email-masked] <mailto:[email-masked]>
>> From:        "DOLLY, MARTIN C" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> 
>> To:        Steve Donovan < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> 
>> From: DiME [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Steve Donovan
>> To: [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime> 
>>  <https://www.ietf.org/mailman/listinfo/dime>https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime>
>> https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime>
> 
> https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime>

---

From: "Lee, Jay" <[email-masked]>
Date: Wed, 14 Oct 2015 16:28:30 +0000

Steve,

Your suggestion on adding 'Note' is okay with me. It certainly helps and makes things clearer.

Jay

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Wednesday, October 14, 2015 7:12 AM
To: [email-masked]
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Jay,

Regards,

Steve

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

·       1) ULR with Prio-0

·       2) ULR with Prio-1

·       3) ULR with Prio-2

Lionel

Hello all,

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

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Thank you.

Thank you.

DiME mailing list

---

From: "Lee, Jay" <[email-masked]>
Date: Thu, 15 Oct 2015 10:15:51 +0000

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

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,

Regards,

Steve

Jay

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

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Thank you.

Thank you.

DiME mailing list

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 15 Oct 2015 10:32:49 +0000

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':

PRIORITY_14 priority:

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)

-ken

Jay,

Regards,

Steve

Jay

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Thank you.

Thank you.

DiME mailing list

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 19 Oct 2015 17:07:14 +0000

Dear all

To continue on this default value definition, I am a bit questioning to use a MAY instead of a SHOULD in .

A SHOULD is a strong request to be applied  with some exceptions  which are in principal described.
Then there is the hereafter  proposed Note to give additional information
  " Note: there are scenarios where operators might want to
      specify a different default value for transactions that do not
      have an explicit priority"

This Note  is OK for me but corresponds more to a MAY in the normative text than a SHOULD.

In practice operators, will define their priority levels within their networks ; some  with a few number of levels, other with a greater number of levels plus the corresponding values in the DRMP AVP range.   Operators will do this mapping in  their DAs at the edge of their network, this mapping will include the default priority value they will choose for their network. The fact to have a standardized value for the default priority does not avoid the overall mapping.
Nevertheless , if a standardized  default priority value is defined and if an operator has no particular reason to choose another value,  this is better to use this standardized value as a common point.
This  short comment drives more to a MAY than to a SHOULD in the normative text. I am a bit keen to know  arguments /use cases justifying a SHOULD.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Lee, Jay
Envoyé : mercredi 14 octobre 2015 18:29
À : Steve Donovan; [email-masked]
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

Steve,

Jay

Jay,

a

Regards,

Steve

Jay

·         1) ULR with Prio-0

·         2) ULR with Prio-1

·         3) ULR with Prio-2

Lionel

Hello all,

My 2 cents....
Viqar

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

Thank you.

Thank you.

DiME mailing list

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 22 Oct 2015 16:38:47 +0000

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:

To: ken carlberg <[email-masked]<mailto:[email-masked]>>; Steve Donovan <[email-masked]<mailto:[email-masked]>>

'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

Thank you.

Thank you.

DiME mailing list

---

From: "Lee, Jay" <[email-masked]>
Date: Fri, 23 Oct 2015 05:59:23 +0000

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.

*/ Since we agree that the default value is per local policy, 'May' is preferred to 'Should' in order not to cause confusion.

*/ For assignment of the default value, I am quite open. But any value between 9 - 12 seems reasonable to me.

*/  Current proposal of 16 values may be enough now, but I am fine with having an extensibility bit to be future proof.

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

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

So to have your feedback

Best regards

JJacques

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

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

Thank you.

Thank you.

DiME mailing list

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 23 Oct 2015 09:00:58 +0000

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]>; [email-masked]
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

mcd- ok

mcd-ok

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

mcd-ok

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

Thank you.

Thank you.

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Fri, 23 Oct 2015 10:01:53 -0500

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]>; [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.
>
> */ 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.
>
> */ 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.
>
> */  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.
>
> */ 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.
>
> *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.
>
> -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.
>
> each priority value as a separate priority), ….  That is, an
>
> -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.
>
> 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.
>
>     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.
>
>     I propose adding the following note after this paragraph to
>     further explain why it is a SHOULD and not a MUST:
>
>     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.
>
>         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
>         [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
>
>         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?
>
>         *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.
>
>         *From:*DiME [[email-masked]
>         <mailto:[email-masked]>] on behalf
>         [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,
>
>         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
>
>         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:*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 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 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,
>
>         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,
>
>         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: "Lee, Jay" <[email-masked]>
Date: Fri, 23 Oct 2015 16:57:16 +0000

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]><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)

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

[JL]  Agreed

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

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

[JL] Agreed

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

Thank you.

Thank you.

DiME mailing list

DiME mailing list

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 26 Oct 2015 15:11:17 +0000

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)

Steve

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

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

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

Thank you.

Thank you.

DiME mailing list

DiME mailing list

---

From: "Lee, Jay" <[email-masked]>
Date: Wed, 28 Oct 2015 18:34:18 +0000

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

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

Thank you.

Thank you.

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Wed, 28 Oct 2015 15:06:16 -0500

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
>
> 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
>
> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
> <[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
> */ Since we agree that the default value is per local policy, 'May' is 
> preferred to 'Should' in order not to cause confusion.
> mcd-ok
> 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.
> -          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.
> 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.
>
> */  Current proposal of 16 values may be enough now, but I am fine with 
> having an extensibility bit to be future proof.
> mcd-ok
> 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.
> 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.
>
> 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.
> [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
>
> 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.
>
>
> -        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 
> -        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 
> 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.
>
> 1.      There needs to be a default value defined by the standard, so that 
> To: ken carlberg <[email-masked]<mailto:[email-masked]>>; Steve 
> Donovan <[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
>
> 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.
>
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Jay,
>
> 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 
> 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]>
> How do you know that the ULR with priority 2 will be handled with a higher 
> priority  than the request without priority indication?
> 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.
>
> From: DiME [[email-masked]<mailto:[email-masked]>] on behalf 
> of [email-masked]<mailto:[email-masked]> 
> [[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
>
>
> 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.
>
>
>
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" <[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
>
>
>
> 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,
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>
> 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,
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>
> ----------

---

From: "Shaikh, Viqar A" <[email-masked]>
Date: Thu, 29 Oct 2015 19:59:07 +0000

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

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

Hi

Best regards

JJacques

Steve

*/ 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.
                                                                                                                                                     &! nbsp;&nbs p;

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

Hi

So to have your feedback

Best regards

JJacques

A couple thoughts:

>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

-ken

Jay,

Regards,

Steve

Jay

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

Regards,

Lionel

Janet

Me as well

Steve

Thanks,

Jay

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

DiME mailing list

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

---

From: "Lee, Jay" <[email-masked]>
Date: Fri, 30 Oct 2015 10:09:54 +0000

Jay

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

Hello all,

My 2 cents:

[JL] I can see that, if the same number (i.e., 15) is used on both sides, there may be one-to-one mapping. This interworking/mapping should be done as part of 3GPP DRMP WI, starting from next 3GPP CT4 meeting. But the mapping can be both one-to-one and one-to-many (multiple). Even if the same number is used, I don't know at the moment that we can exclude the possibility of one-to-many mapping. So I am not sure that we need to have the same number on both sides.

[JL] Using 'May' is the consensus do far.

[JL] The consensus so far is that it is better not to have the extension bit.

[JL] Initial assumption was that there is no need to specify or even assign a default value, I believe. But then, there was a proposal to specify the default value, making it mandatory. And then, there was also a proposal that, even if the default value is not specified, we need to assign the default value that can be overwritten in order to have common understanding for some reasons.

My personal thought on this matter is that there is no need to specify or assign the number, as you also mentioned, and this 'do nothing' may even be a majority view, since it was the initial assumption. But I am not certain, because not everyone voiced opinion. In this situation, a compromise had to be made. The compromise is that we will assign the value '10' to the default case with the statement that the default value can be overwritten per local policy, and 'May' must be used instead of 'Should' in the current text. I think this compromise is consistent with your view.

Thoughts?

Thanks,

Viqar

To: Lee, Jay; [email-masked]<mailto:[email-masked]>

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.

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 30 Oct 2015 17:14:42 +0000

Hi

>From the email threads about draft-ietf-dime-drmp,  I think we now concluded  on the pending points with still a small  discussion about a range of 15 or 16 values on  which we should conclude.

-          On my side I was OK with the initial  proposal of 16 values. For a mapping between a list A with a range of 15 values and  the DRMP range of 16 values , a simple one is to do 1 to 1 mapping except for the value 15th  and 16 th (lowest priorities) of the DRMP range  which would be mapped to the value  15 of the listA range. That being said, I have no issue to use a  DRMP range of 15 value if some of us prefer.

Regarding the draft  I think  the unique Editor's note in version 1 can be removed and after integration of the conclusions in  new draft, I would be in favour to go towards the last call step.

-          I hereafter give some information to Dime-list about the process on 3GGP side.
Diameter  message Priority is an important requirement for 3GPP which agreed on a Release 13 Work Item supported by many companies. 3GPP also decided  to use the draft-ietf-dime-drmp to fulfill this requirement and already agreed Change Requests to some specifications,  with an editor's note  assuming that  draft-ietf-dime-drmp is stable enough to do so. Further Change Request for other specifications will be submitted in the upcoming 3GPP meeting in November which is the last meeting for the 3GPP Release 13.

Our IETF dime work and conclusions drives me to consider that the draft has become stable -so with my proposal that the updated version be submitted to the last call.  I am not so much familiar with IETF process, I hope my proposal  follows the IETF procedures.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Lee, Jay
Envoyé : vendredi 30 octobre 2015 11:10
À : Shaikh, Viqar A; Steve Donovan; [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)

Jay

To: Steve Donovan; Lee, Jay; [email-masked]<mailto:[email-masked]>

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

---

From: "Lee, Jay" <[email-masked]>
Date: Fri, 30 Oct 2015 18:08:28 +0000

In the case of mapping, one-to many is common, so I have no issues with having the range of 16. The range of 15 is also OK, but with default value of 10, we will have one less lower priority levels.

>From practical point of view, this discussion may not be all that relevant. 15 or 16 is a very large number, which were intended to be future proof. In the foreseeable future, we will not be using all 15 or 16 levels. If exact one-to-one mapping is preferred, it can be achieved without any issues, as only DRMP 3-8 levels would be used in practice. I prefer 16, but 15 is OK, as it will not make any difference to us. Not sure if this point is even worth debating or should be a pending point.

Jay

From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Friday, October 30, 2015 10:15 AM
To: [email-masked]; Shaikh, Viqar A
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

Hi

Best regards

JJacques

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

Jay

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