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

[<[e-mail]>]

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