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

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

>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]
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]<mailto:[e-mail]>] on behalf of [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[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