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

[Steve Donovan <[e-mail]>]

Jay,

The current text is a SHOULD level requirement:

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

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

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

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

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

Does this address your concerns?

Regards,

Steve

On 10/14/15 2:59 AM, Lee, Jay wrote:
>
> Regarding the issue of whether we need to specify a default value or 
> not, there are pros and cons.
>
> If we specify a value for the default case, we can see the benefits in 
> scenarios between different operator networks, but we take away 
> important options on what operators can do with priority values. On 
> the other hand, if we do not specify the default value, operators may 
> have more options, but there is a question of what to do for this 
> inter-PLMN cases when the networks may use different default values.
>
> In practice, this issue can be addressed at the edge of the network, 
> where Diameter edge agent (DEA) can perform some priority mapping 
> based on bilateral roaming agreement (or SLA (service level 
> agreement)) and other means to insure the proper handling. One may 
> argue that this is not as good as the ‘deterministic’ case, but 
> operator should be able handle this in a reasonable way. We are fully 
> aware of the fact that, in case of this ‘non-deterministic’ case, the 
> default value can differ from one operator network to another, and it 
> becomes difficult to guarantee the intended priority handling. Despite 
> this, we still prefer giving options to operators by not specifying 
> the default value.
>
> What we are saying here, however, is not anything new. This is the 
> typical way of handling priority levels. If anything, specifying the 
> default value would be something new. As already mentioned in CT 
> discussion, there is a good example of this – Internet QoS, more 
> specifically DiffServ.
>
> In order to guarantee end-to-end QoS for a specific service, IETF 
> could have specified a value (DiffServ codepoint) for the specific 
> service to have predetermined handling of the traffic, but IETF did 
> not. Instead, DiffServ simply provided a framework for operators to 
> have its own  classification and differentiated treatment of the 
> services. To guarantee end-to-end QoS across different networks, then, 
> operators need to do packet inspection, (re)classification, QoS 
> mapping, use of SLA and possibly others at the edge of network (edge 
> router). Therefore, in the DiffServ architecture, intelligence was 
> pushed to the edge of the network. While the end results may not be 
> guaranteed as well as in the case of predetermined handling, it was 
> still a preferred way to give flexibility to operators. My point is 
> that we went through all these troubles to give options of priority 
> handling to operators.
>
> By the way, if we are thinking of possibility of specifying the 
> default value, are we assuming that all operators are interested in 
> this feature (default value in the middle, and high and low priorities 
> at other ends)? Aren’t there other operators who are not interested in 
> this feature? I know that at least there is one – Verizon. We have no 
> interest in this feature, and no plan for implementing it. We are OK, 
> if other operators are interested in this feature, and the default 
> value is NOT specified. But we are certainly not happy if DIME is 
> trying to impose this on us.
>
> Jay
>
> *From:*DiME [mailto:[e-mail]] *On Behalf Of 
> *[e-mail]
> *Sent:* Tuesday, October 13, 2015 10:55 AM
> *To:* Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
> *Cc:* DiME; [e-mail]; Pollini, Gregory P
> *Subject:* Re: [Dime] [dime] #92 (drmp): Range of priority levels
>
> Assuming that we define a range of 3 values,
>
> Assuming that 0 is the lowest priority and 2 the highest,
>
> Assuming that an agent receives 4 messages at the same time while 
> being in overload control:
>
> ·1) ULR with Prio-0
>
> ·2) ULR with Prio-1
>
> ·3) ULR with Prio-2
>
> ·4) ULR with no priority AVP
>
> Assuming that the default is locally defined as proposed below,
>
> How do you know that the ULR with priority 2 will be handled with a 
> higher priority  than the request without priority indication?
>
> And what about ULR message with priority 1 with two levels of highest 
> priority e.g. emergency/Important and government/very important?
>
> Sorry if the answer is obvious but I fail to understand.
>
> Lionel
>
> *De :*Shaikh, Viqar A [mailto:[e-mail]]
> *Envoyé :* samedi 3 octobre 2015 01:21
> *À :* MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
> *Cc :* DiME; [e-mail] <mailto:[e-mail]>; Pollini, Gregory P
> *Objet :* RE: [Dime] [dime] #92 (drmp): Range of priority levels
>
> Hello all,
>
> Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 
> 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 
> 0 not defined.
>
> Having 15 rather than 16 would be useful from an interworking point of 
> view on Diameter interfaces connecting to the EPS.
>
> Also, my understanding has been that the default value is per local 
> policy.
>
> My 2 cents....
>
> Viqar
>
> ------------------------------------------------------------------------
>
> *From:*DiME [[e-mail]] on behalf of 
> [e-mail] <mailto:[e-mail]> 
> [[e-mail]]
> *Sent:* Thursday, October 01, 2015 3:36 AM
> *To:* Janet P Gunn; DOLLY, MARTIN C
> *Cc:* DiME; [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [Dime] [dime] #92 (drmp): Range of priority levels
>
> Hi,
>
> I think that the case "no Priority indication in request" is the 
> default situation today.
>
> So if we agree that it should be possible to explicitly indicate a 
> request with a lower priority, we should divide the range of priority 
> values in three sub-ranges: [lower priorities][no priority 
> indication][higher priorities], e.g. with 17 values: [0-7][8][9-16].
>
> If any operator can freely fix the default value, there would be no 
> way to ensure the sender that a request with a specific priority value 
> (e.g. 6) will be handled with a lower or higher priority than a 
> request with no priority indication.
>
> Therefore, for a deterministic handling mechanism, I think that it is 
> then more relevant to define a standard value for the default value.
>
> Regards,
>
> Lionel
>
> *De :*DiME [mailto:[e-mail]] *De la part de* Janet P Gunn
> *Envoyé :* mercredi 30 septembre 2015 22:53
> *À :* DOLLY, MARTIN C
> *Cc :* DiME; [e-mail] <mailto:[e-mail]>
> *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" <[e-mail] <mailto:[e-mail]>>
> To: Steve Donovan <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Date: 09/30/2015 04:40 PM
> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
> Sent by: "DiME" <[e-mail] <mailto:[e-mail]>>
>
> ------------------------------------------------------------------------
>
>
>
>
> Me as well
>
> *From:*DiME [mailto:[e-mail]] *On Behalf Of *Steve Donovan*
> Sent:* Wednesday, September 30, 2015 4:38 PM*
> To:* [e-mail] <mailto:[e-mail]>*
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
>
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime