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

["DOLLY, MARTIN C" <[e-mail]>]

Yes, I can support this.

From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 3:49 PM
To: [e-mail]
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

I believe there are two proposals here.

First, to increase the number of priority levels to 16.

Second, to make the default priority the middle of the range, so this would presumably make the default value 8.

Is this correct?

Are there objections to these changes?

Regards,

Steve
On 9/25/15 9:31 AM, [e-mail]<mailto:[e-mail]> wrote:
As discussed in another issue report, I also think that it should be possible to create levels allowing requests with lower priority than regular requests and other with higher priority. With requests without priority indication being handled as if there had a priority in the middle of the range.

Regards,

Lionel

Envoyé depuis mon mobile Orange

----- Reply message -----
De : "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]><mailto:[e-mail]>
Pour : "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Objet : [Dime] [dime] #92 (drmp): Range of priority levels
Date : jeu., sept. 24, 2015 12:15

Hi Janet, Martin

Thanks  for your feedback

I understand the difference with cases dealing with resources with long holding times (eg ARPs in 3GPP) driving to your conclusion that 5 levels should be enough.

I would like to pursue the discussion on the following points


-       A Priority level may be associated to a certain type of UE/user ( e.g. public safety with firemen or first responders, governmental users or gold/ silver customers of the operator). It can also depend of the type of request in an application, some requests having a  higher or lower priority. This multiples the number of cases. That being said, a given level of priority may correspond  to a high priority  user with lower priority request and a lower priority user with higher  priority request.  This is a matter of operator policy out the IETF scope. We only have to state if the number  of  priority levels is sufficient according to  operator views. It would be good to have some other operator views.



-       For requests without priority DRMP AVP which correspond to the existing client situation (the "normal" traffic) and which may continue to coexist with clients supporting DRMP for a while, we have to state if this default case correspond to a given level of priority with the two following discussed possibilities:

o   The default case has the lowest priority but this exclude to introduce lower priorities (eg for some MTC devices)

o   The default case correspond to an intermediate value (cf Lionel's mail). If we have  5 levels (0,1,2,3,4) and the value 2  is default one, it would mean only two higher DRMP priority levels than the default one. Is it sufficient?



-       About the case with no DRMP AVP in the request, the mapping to a given DRMP level may be something  optional as a Diameter node  can do some further analysis at application level (eg if it finds a Session-Priority AVP in a Cx message or a Reservation-Priority in a RX message or another criteria) to decide the request handling .

Thanks for your feedback

Best regards

JJacques

De : Janet P Gunn [mailto:[e-mail]]
Envoyé : mercredi 23 septembre 2015 16:45
À : DOLLY, MARTIN C
Cc : [e-mail]<mailto:[e-mail]>; DiME; [e-mail]<mailto:[e-mail]>; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Richard F Kaczmarek; [e-mail]<mailto:[e-mail]>
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

I have consulted with a couple of other people here, and we agree that 5 is probably sufficient  for this.

You typically only need more priority levels when you are dealing with resources with long holding times (which includes some of the resources ARP is used for).

With regard to the situation where the priority value is not present, assigning a "default priority" within the existing levels seems to work well .

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:        "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date:        09/23/2015 10:00 AM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <[e-mail]<mailto:[e-mail]>>
________________________________



I have stated previously that I believe 5 levels are adequate, as I do not see action on more than that.

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of dime issue tracker
Sent: Wednesday, September 23, 2015 9:49 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Dime] [dime] #92 (drmp): Range of priority levels

#92: Range of priority levels

The ietf-dime-drmp draft currently mentions 5 levels of priorities which  appear to be not enough. In 3GPP, levels of priorities are also defined  outside Diameter with, in particular, sixteen levels in Policy Control for  the ARP (Allocation and Retention Priority)information element. So it  would be better that the DRMP AVP also allow 16 values which is future  proof and leaves more flexibility on their allocation.
Another point also addressed in #91 ticket is that the range can contain  priorities which are higher or lower than the normal priority  corresponding to the case where the DRMP AVP is not present (existing  situation); this also drives to consider a larger range of levels with an  intermediate value corresponding to the normal priority.

--
-------------------------------------+----------------------------------
-------------------------------------+---
Reporter:  jean-jacques.trottin     |      Owner:  draft-ietf-dime-
 @alcatel-lucent.com                |  [e-mail]<mailto:[e-mail]>
    Type:  defect                   |     Status:  new
Priority:  major                    |  Milestone:
Component:  drmp                     |    Version:
Severity:  Active WG Document       |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/92>
dime <http://tools.ietf.org/wg/dime/>

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




_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

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