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

["Lee, Jay" <[e-mail]>]

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.