Re: [Dime] Two meanings for "default" Re: diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

[Steve Donovan <[e-mail]>]

I will work on wording that hopefully captures Janet's clarification 
based on the current direction that the default value for DEF is ten.

Steve

On 11/3/15 11:48 PM, Lee, Jay wrote:
>
> I was not sure if we converged on this point of discussion, and I 
> thought that this DRMP work should not progress further until we have 
> an agreement on this (per local policy vs deterministic handling). But 
> maybe we are converging.
>
> I believe that we all agree on ‘per local policy’ (for an incoming 
> message/request without indication, if you wat to be specific). The 
> only sticky point is that we want to assign a value to it, and yet we 
> want to state that it can be overwritten per local policy. It is not 
> complicated technical issue, and we should be able to come to an 
> agreement without issue. If we are all reasonable, I am positive that 
> we can find appropriate wording that can satisfy all of us.
>
> Separately, if we want to specify a value (say, 10) to the equipment 
> for manufacturing purpose, I am fine with it, as long as it is clearly 
> stated that this specified number is for such purpose only.
>
> Thanks,
>
> Jay
>
> *From:*[e-mail] [mailto:[e-mail]]
> *Sent:* Tuesday, November 03, 2015 5:32 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; DiME; Lukacs, Donald R; Pollini, Gregory P; Lee, 
> Jay; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DOLLY, MARTIN C; Singh, Ray 
> P; Steve Donovan; Shaikh, Viqar A
> *Subject:* Two meanings for "default" Re: [Dime] diff-serb and two 
> other ideas (was Re: [dime] #92 (drmp): Range of priority levels)
>
> I think part of the confusion is that we are using the same word 
> ("default") to refer to TWO different concepts.
>
> The FIRST is a parameter (I will call it "DEF" for clarity) which is 
> used to determine how to process an incoming message/request which 
> arrives without an explicit priority.
>
> The operator can, as a matter of local policy, set DEF to any value in 
> the range.
>
> The operator can also, as Jean-Jacques points out, use its own local 
> policy in determining which messages to throttle (including ignoring 
> Priority entirely).
>
> The SECOND concept is the "default value" of DEF.  This is the value 
> that "DEF" is set to "out of the box", before the operator configures 
> it according to local policy.  This is the one that "SHOULD" be set to 
>  14 (or whatever the latest WG consensus is).
>
> I know most of us understand the distinction, but sometimes it gets 
> confused in the discussion.  So we should be sure that the final text 
>  is particularly clear on the distinction.
>
> 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: <[e-mail] <mailto:[e-mail]>>
> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
> <[e-mail] 
> <mailto:[e-mail]>>, "DOLLY, MARTIN C" 
> <[e-mail] <mailto:[e-mail]>>, "Shaikh, Viqar A" 
> <[e-mail] <mailto:[e-mail]>>, Steve Donovan 
> <[e-mail] <mailto:[e-mail]>>, "Lee, 
> Jay" <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Cc: "Singh, Ray P" <[e-mail] 
> <mailto:[e-mail]>>, "Lukacs, Donald R" 
> <[e-mail] <mailto:[e-mail]>>, "Pollini, 
> Gregory P" <[e-mail] <mailto:[e-mail]>>
> Date: 11/03/2015 04:36 AM
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
> Sent by: "DiME" <[e-mail] <mailto:[e-mail]>>
>
> ------------------------------------------------------------------------
>
>
>
>
> OK with the first comment. Mea Culpa ☺
>
> Moreover, I can live with the note.
> But the note induces the following additional question: "Can operator 
> defined local policies override the explicit priority level indicated 
> for the request/transaction?"
> And my comment was that handling of priority is always a matter of 
> local policies. It is an indication that may be taken into account 
> when deciding the next step in the request processing.
> You may have further criteria in your prioritization.
>
> The note is correct but could be misleading. I would prefer to have a 
> general statement saying that the priority, if supported and used, 
> must be used as input in the routing/throttling/processing decision 
> but that the final decision may depend on other criteria based on 
> local policies. There is therefore no mandatory direct mapping between 
> the priority indication in the request and the priority with which the 
> request will be handled. It is just an indication of the priority 
> requested by the sender/forwarder of the request.
>
> I hope that this clarifies my comment. Actually, it is more about 
> reassuring operators that they will keep the control of the process of 
> the requests in their own network. After that, it will be only a 
> question of SLA/roaming agreements between network operators.
>
> Lionel
>
> ************************
> De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
> [mailto:[e-mail]]
> Envoyé : mardi 3 novembre 2015 08:20
> À : MORAND Lionel IMT/OLN; DOLLY, MARTIN C; Shaikh, Viqar A; Steve 
> Donovan; Lee, Jay; [e-mail] <mailto:[e-mail]>
> Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P
> Objet : RE: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Hi Lionel
>
> Two remarks on your mail
>
> - The value of the highest priority is  0;  the lowest priority is 15
> - After the Dime session, where SHOULD is retained for the default 
> priority, I think we can keep  this note which is a good clarification
> -       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.
> Best regards
>
> JJacques
>
>
> De : DiME [mailto:[e-mail]] De la part de 
> [e-mail] <mailto:[e-mail]>
> Envoyé : mardi 3 novembre 2015 03:44
> À : DOLLY, MARTIN C; Shaikh, Viqar A; Steve Donovan; Lee, Jay; 
> [e-mail] <mailto:[e-mail]>
> Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P
> Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> If I'm correct, the proposed text for -02 would be:
>
>    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 MAY be treated
>    as having the PRIORITY_10 priority.
>
>       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.
> It seems to have a consensus on the MAY. But I think that we are 
> missing one point: we need to ensure that requests related to e.g. 
> mission critical/emergency services can be handled with the highest 
> priority in any network.
> And we cannot forbid scenarios in which more than one network will be 
> involved in the signaling path. Therefore, the "MAY" is not correct as 
> it allows operators to map the value 15 to requests received with no 
> priority indication. In such a case, there is no way to give the 
> highest priority to emergency call related requests. I'm not saying 
> that such a configuration would be frequent and adequate but it is 
> allowed as per the current text.
>
> I would propose to give a strong recommendation on the value with a 
> SHOULD. Recommending a value would enable to split the range into two 
> clear sub-ranges:
> Set1: 0-10
> Set2: 11-15
>
> In such case, any value in the second set will always be considered 
> with an higher priority than request with priority of the first set or 
> request without indication.
> The correct text would be then:
>
>    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_10 priority.
> About the proposed "NOTE", I think that it is not required as it is 
> already said that the priority indication is… an indication that may 
> be taken into account, as below:
>
>    2.  Agents handing the request - Agents use the priority information
>        when making routing decisions.  This *can* include determining
>        which requests to route first, which requests to throttle and
>        where the request is routed.  For instance, requests with higher
>        priority might have a lower probability of being throttled.  The
>        mechanism for how the agent determines which requests are
>        throttled is *implementation dependent* and is *outside the 
> scope of
>        this document*.  The agent also records the transaction priority
>        in the transaction state.  This will be used when handling the
>        associated answer message for the transaction.
>
>    3.  Request handler - The handler of the request, be it a Diameter
>        Server or a Diameter Client, *can* use the priority information to
>        determine how to handle the request.  This *could* include
>        determining the order in which requests are handled and resources
>        that are applied to handling of the request.
>
> It is never mandated that the priority indicated for a given request 
> MUST be handled as such.
> Please consider this point. This will be discussed during the meeting.
>
> Lionel
>
> De : DiME [mailto:[e-mail]] De la part de DOLLY, MARTIN C
> Envoyé : lundi 2 novembre 2015 21:38
> À : Shaikh, Viqar A; Steve Donovan; Lee, Jay; [e-mail] 
> <mailto:[e-mail]>
> Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P
> Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> I agree
>
> From: DiME [mailto:[e-mail]] On Behalf Of Shaikh, Viqar A
> Sent: Thursday, October 29, 2015 3:59 PM
> To: Steve Donovan <[e-mail] 
> <mailto:[e-mail]>>; Lee, Jay 
> <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] <mailto:[e-mail]>
> Cc: Singh, Ray P <[e-mail] <mailto:[e-mail]>>; 
> Lukacs, Donald R <[e-mail] 
> <mailto:[e-mail]>>; Pollini, Gregory P 
> <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Hello all,
>
> My 2 cents:
>
> Greater than 5 values for DRMP AVP is justified and it appears there 
> is agreement for 16.  However, 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 for DRMP AVP would be useful from an interworking point of view on 
> Diameter interfaces connecting to the EPS.
>
> Regarding the default value - it is based on operator policy and can 
> be overwritten by an operator.  Therefore, we support use of "may" and 
> not "should".
>
> We feel that 15 or 16 values should suffice and there is no need to 
> define an extension bit.  However, I am ok if there is consensus to do so.
>
> We feel there is no need to specify a default as it is per local 
> policy and can be overwritten.  But, if there is consensus to do so, 
> we suggest value 10 or 11 with a note that it can be overwritten based 
> on operator policy.
>
> Thoughts?
>
> Thanks,
> Viqar
>
> ________________________________________
> From: DiME [[e-mail]] on behalf of Steve Donovan 
> [[e-mail]]
> Sent: Wednesday, October 28, 2015 4:06 PM
> To: Lee, Jay; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
> Ten is acceptable to me.
> Steve
> On October 28, 2015 1:36:00 PM "Lee, Jay" <[e-mail] 
> <mailto:[e-mail]>> wrote:
> I also think that we agree on all different points for the 
> finalization, except one point: the value for the default case. Use of 
> the default case as discussed here is rather in the future than in the 
> present for us, so I do not have strong opinion, especially when the 
> default value can be overwritten.
>
> Looking at this objectively and also for the sake of progress, 
> however, it would be prudent to have more than one lower priority 
> cases. In the near future, we may identify additional use cases for 
> lower priority case. Even with one use case identified, this does not 
> necessarily mean one priority level per use case. One use case may 
> require multiple lower priority levels, depending on applications.
>
> Any value from 9 to 12 seems reasonable to me. But, without all use 
> cases identified at the present time, I propose 10 (JJacques’ 
> proposal) or 11.
>
> Thanks,
>
> Jay
>
> From: DiME [mailto:[e-mail]] On Behalf Of TROTTIN, 
> JEAN-JACQUES (JEAN-JACQUES)
> Sent: Monday, October 26, 2015 8:11 AM
> To: [e-mail] <mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Hi
>
> Please see my comments also in line. I think we are close to finalise 
> our choice on the different points  of this thread
>
> Best regards
>
> JJacques
>
> De : DiME [mailto:[e-mail]] De la part de Lee, Jay
> Envoyé : vendredi 23 octobre 2015 18:57
> À : [e-mail] <mailto:[e-mail]>
> Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Please see my comments inline.
>
> From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
> Sent: Friday, October 23, 2015 8:02 AM
> To: [e-mail] <mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Please see my comments inline.
>
> Steve
> On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:
> See inline
>
> From: DiME [mailto:[e-mail]] On Behalf Of Lee, Jay
> Sent: Friday, October 23, 2015 1:59 AM
> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
> <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Some further comments from my side:
>
> */ If we need to assign (but not specify) a value to the default case, 
> we need to make it clear that this value can be overwritten by 
> operators, and the value is for some use cases like e.g., equipment 
> having the same value when leaving the factory, so that there would be 
> no misunderstanding.
> mcd- ok
> SRD> I think the current proposed text makes this clear.
> [JL] Agree that the current text is OK especially when we use ‘May’ in 
> place of ‘Should’
> [JJ] OK
> .
>
> */ Since we agree that the default value is per local policy, ‘May’ is 
> preferred to ‘Should’ in order not to cause confusion.
> mcd-ok
> SRD> I'm okay with making this a MAY.
> [JL]  Agreed
> [JJ] Also in favor of a MAY
>
> */ For assignment of the default value, I am quite open. But any value 
> between 9 – 12 seems reasonable to me.
> mcd- value should allow for assigning lower values, though a carrier 
> can assign what they want in their network, there needs to be a common 
> meaning at the interconnection point
> SRD> I'm open to any value we decide on.  If there are real use cases 
> that require pushing the default value more to the middle then we 
> should do so.  At this point I've heard one use case for the default 
> being something other then the lowest value, thus the proposal to use 
> priority_14 as the default.
> [JJ] Regarding use cases, there may be
> -          The case where for “normal” users, an application use the 
> default value for most of its requests except some which have a lower 
> priority
> -          the case where besides “normal” user (and high priority 
> users), some users have lower priorities, e.g. Some Machine type 
> Communications (MTC) devices.
> So potentially more than one low priority level would be needed.
> We also have chosen a rather large range of values (16) , allowing 
> flexibility for an operator when they define the number of priorities 
> they want , leaving possibility to future additions. If PRIORITY _14 
> is the default, it leaves only one lower priority and an operator 
>  cannot add a second one  except by choosing  a default value other 
> than the 14  value.
> Then as, in practice, we may expect a range of low priority smaller 
> than  the range of high priority values, this is why the default value 
> was proposed to be in the range 9-12  . Then I proposed 10 so to do a 
> proposal but I am open on another value.
>                                                                                                                                                      &! 
> nbsp;&nbs p;
> */  Current proposal of 16 values may be enough now, but I am fine 
> with having an extensibility bit to be future proof.
> mcd-ok
> SRD> I don't see a compelling argument to move beyond 16.
> In addition, it isn't clear to me that there is value in defining an 
> extensibility mechanism beyond what is already supported by Diameter.  
> Doing so would add significant complexity to the DRMP mechanism for 
> something that, in my view, has a low probability of being used.
>
> I propose that we not allow extending the DRMP AVP. Rather we require 
> that any extension require a new AVP. We can then leave it to the 
> document that proposes the extension to deal with determining whether 
> send the DRMP AVP or the newly defined DRMPv2 AVP.
> [JL] When we proposed that the range be extended to 16, we thought 
> that ‘16’ was large enough and future proof.
> I am okay with having an extensibility bit, if other companies want 
> it. That said, I agree that it has a low probability of being used and 
> added complexity.
> [JJ] JJ I also agree that with 16 values , the offered range is large 
> enough in practice. This point is only to check if it would be easy to 
> do an extension, if we have this requirement in the future.  I agree 
> with Steve that for an extensibility, it will require a new AVP in a 
> new document rather than to define a set of reserved values in the 
> DRMP AVP.  A point is that it will require an additional parsing 
> effort for a node to look for this second AVP even if it is not 
> present most of the time.
>
> */ I am not sure of alternative encoding method (say, +9 to -9 per 
> JJacques’ proposal) compared to the current enumerated type of DRMP. 
> It offers a logical way of assigning a value 0 to the default case. 
> But it offers less flexibility to operators, since the default value 
> may not be easily moved to have more higher/lower priority values. 
> Also, we are used to the enumerated type of DRMP and just want to have 
> extension from 5 to 16,  but this may require more deviation from the 
> current design and thinking. For this, I would like to see more on 
> qualitative pros/cons, but, given its little benefit, I am reluctant 
> to accept this alternative.
> SRD> I agree that I don't see value in the +9 to -9 proposal.
> [JL] Agreed
> [J] I presented this second  approach  so to review the possible 
> alternatives as we usually do before selecting the solution, this 
> alternative being already used in a recent RFC.   That being said, I 
> am fine with the enumerated DRMP AVP.
>
> Best regards
>
> JJacques
>
> From: DiME [mailto:[e-mail]] On Behalf Of TROTTIN, 
> JEAN-JACQUES (JEAN-JACQUES)
> Sent: Thursday, October 22, 2015 9:39 AM
> To: [e-mail] <mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Hi
>
> 1.      PRIORITY_14 as default priority value only allows one level of 
> lower priority (PRIORITY_15)  than the default one; this seems not 
> enough.  As use cases, we may have  some Machine type Communication 
> (LTC) devices that may have lower priorities that normal 
> communications without priority.  Even within a Diameter application, 
> some commands may have a lower priority as having a secundary importance.
>
> Then which default  value ?
> -        it could be PRIORITY_8 in the middle, or if we prefer to have 
> a  larger range for higher priorities  than for lower priorities,  the 
> default value could be  e.g. PRIORITY_10,  giving 9 higher priorities 
> and 5 lower priorities than the default one. I would have a preference 
> for this value PRIORITY_10.
>
> 2.      About extensibility, the current range of 16 values is already 
> large, but we can have  a reserved value to indicate a further 
> extension. With  an enumerated AVP, there is no possibility to add new 
> values.
>
> 3.      I also had a look to some other IETF RFCs addressing 
> priorities that Ken mentioned, so to see if we can benefit from these 
> approaches although done for different contexts.
> -        in RFC 4412 (Resource-Priority Header in SIP), wps and ets 
> namespaces have a range of 5 values (0 to 4) with 0 as the highest 
> priority  . But I have not found some indication  (I may have missed 
> it) about the default priority  (I mean a SIP request without  
> Resource-Priority Header compared  to a SIP request with the Header). 
> Implicitly, I would assume a SIP request without Resource-Priority 
> Header corresponds to  the lowest priority.  DRMP has a similar 
> approach but with  a larger range and also lower priorities.
>
> -        RFC  6710 (priority for SMTP),  uses another encoding of the 
> priority values with an integer between -9 and +9. Lower priorities 
>  are negative an higher priority being positive. When a value 
> increases, it means a higher priority, so the opposite  to DRMP, wps 
> or ets.  But the value 0 is here naturally the default value. So this 
> is an encoding alternative  to the  Enumerated type of the DRMP AVP 
> which avoids the question of the default value.
> Note: RFC  6710 also defines some Priority Assignment Policies using a 
> subset of the range.
>
> RFC 6710 has also this guideline :
>    SMTP servers compliant with this specification are not
>    required to support all 19 distinct priority levels (i.e., to treat
>    each priority value as a separate priority), ….  That is, an
>    implementation that only supports N priority levels (where N < 19)
>    will internally round up a syntactically valid priority value that
>    isn't supported to the next higher supported number (or to the
>    highest supported priority, if the value is higher than any 
> supported priority).
> -        This raises the question to have this type of  guideline if 
> considered useful.
>
> So to have your feedback
>
> Best regards
>
> JJacques
>
> De : DiME [mailto:[e-mail]] De la part de DOLLY, MARTIN C
> Envoyé : jeudi 15 octobre 2015 12:33
> À : Lee, Jay; ken carlberg; Steve Donovan
> Cc : [e-mail] <mailto:[e-mail]>
> Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> A couple thoughts:
> 1.      There needs to be a default value defined by the standard, so 
> that equipment have the same value leaving the factory
> 2.      This value can be over written based on local policy
> 3.      Should have an extensibility bit in order to and more values 
> in the future
>
>
> From: DiME [mailto:[e-mail]] On Behalf Of Lee, Jay
> Sent: Thursday, October 15, 2015 6:16 AM
> To: ken carlberg <[e-mail] <mailto:[e-mail]>>; 
> Steve Donovan <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> From my side, some more discussion on Steve’s mail may be needed.
>
> ‘Should’ vs. ‘Must’:
> One can say that ‘Should’ is not mandatory. But, in practice, this is 
> a fairly strong statement, and often taken as required. So in this 
> sense, the proposed Note is certainly helpful. But, since we allow 
> operators to override the value, I don’t see the reason why we use 
> ‘Should’. My suggestion is using ‘May’.
>
> PRIORITY_14 priority:
> Since operators can overwrite it, I was not too concerned about it. 
> But if we want to put some value, why ‘14’? A value lower than 14 is 
> suggested in order to allow more rooms for lower priorities.
>
> Jay
>
> From: DiME [mailto:[e-mail]] On Behalf Of ken carlberg
> Sent: Wednesday, October 14, 2015 8:40 AM
> To: Steve Donovan
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> with respect to the diff-serv example brought up below, some thing to 
> add to that discussion is that it starts off with separate and 
> distinct forwarding behavior whose marked packets provide segmentation 
> of other IP traffic.  The availability of only 6 bits to play with 
> (along with the headaches of transitive trust) also discouraged a line 
> of thought to define end-to-end priority handling versus a per 
> diff-serv domain treatment.  RFC-4594 did provide configuration 
> guidelines, but that’s a different story.
>
> So back to a couple of ideas to consider.
>
> 1) reserved space.  if we go back to the diff-serv model, the 
> diff-serv working group agreed to set aside a set of values that was 
> reserved for experimental use that could be re-assigned some time in 
> the future.  I’m not suggesting that there should be space set side 
> for experiments, but rather it may be prudent to set aside a reserved 
> set of bits/values so that one doesn't need to define a new AVP if in 
> the future there was a need to define added values beyond the 5 (plus 
> some fudge factor) already mentioned on the list.
>
> 2) sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized 
> that there can be several sets of users/services that are distinct 
> from each other and yet need to prioritize the traffic.  I bring this 
> up because the draft already identifies two sets of users in sections 
> 5.1 and 5.2 (note: I’m assuming that the latter is aimed at the 
> general public and related to 911/112/999 type calls, which should 
> probably be more specific in the draft).  And there is also the 
> potential of Firstnet users in the US.
>
> As a side note, the distinction and separation of general public and 
> other prioritized users in public phone infrastructures is not 
> exclusive to the US, so the group should not be concerned that this is 
> a US centric effort.  There has been GTPS in the UK, as well as other 
> systems in other countries.  The RFC is a bit dated, but feel free to 
> go over rfc-4190 for added background.
>
> and just to reiterate.  I’m not making recommendations in the above — 
> just bringing up some food for thought.
>
> -ken
>
>
> On Oct 14, 2015, at 10:12 AM, Steve Donovan <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
> 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] <mailto:[e-mail]>
> Sent: Tuesday, October 13, 2015 10:55 AM
> To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
> Cc: DiME; [e-mail] <mailto:[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] <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
>
>
> _______________________________________________
> 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,
> France Telecom - 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 authorization.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange shall not be liable 
> if this message was modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> DiME mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
>
>
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime