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

[Steve Donovan <[e-mail]>]

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] 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]>
> Pour : "[e-mail]" <[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:
>
> oThe default case has the lowest priority but this exclude to 
> introduce lower priorities (eg for some MTC devices)
>
> oThe 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]; DiME; [e-mail]; 
> TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Richard F Kaczmarek; 
> [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]
> https://www.ietf.org/mailman/listinfo/dime