Subject: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 04 May 2016 04:13:23 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I fully agree with all discuss comments made by Ben and Alissa. However,
the summary here might be that this information might simply be not very
useful for the uses cases described. And there might be other mechanisms
that do not require any trust and that can address the uses cases easier
and more appropriate such a simply prioritization of a certain
application in the request handler/request agent or relative priorities
within one application (on sent-out). 

However, the one part that does actually concern me is:
"When using DRMP priority information, Diameter nodes MUST use the
   default priority for transactions that do not have priority specified
   in a DRMP AVP."
This part seems dangerous and I would proposed to instead basically have
to different queues: one if a priority is defined and another one for
requests without priority indication to make sure that requests out of
the second queue will be served at some point in time and cannot be
starved by other low priority requests completely.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Why do you need 15 different priority levels? Wouldn't be two enough for
all or your use cases?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 4 May 2016 12:37:46 +0100

Hi Mirja,

> On 4 May 2016, at 12:13, Mirja Kuehlewind <[email-masked]> wrote:
> 

I think I disagree with you: default priority handling is orthogonal to the number of queues used. Some implementations would use one queue per priority, so you are effectively suggesting that no priority is treated as its own priority. I think this is an implementation detail.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 4 May 2016 13:45:59 +0200

Hi Alexey,

> Am 04.05.2016 um 13:37 schrieb Alexey Melnikov <[email-masked]>:
> 
> Hi Mirja,
> 
Yes, queues are implementation details. That was just meant as an illustration. My point it, I don’t think all requests without priority should get an default priority assigned (and especially not a very low priority). Further it has to be ensured that requests that don’t assign a priority do not get starved (as they might be important).

Mirja

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 May 2016 13:03:16 +0100

Hi Mirja,

On Wed, May 4, 2016, at 12:45 PM, Mirja Kuehlewind (IETF) wrote:
> Yes, queues are implementation details. That was just meant as an
> illustration. My point it, I don’t think all requests without priority
> should get an default priority assigned

Why not? Why not assigning a priority any different than assigning a
unique priority?

(SMTP Priority extension RFC which I edited made the same choice:
https://tools.ietf.org/html/rfc6710)

> (and especially not a very low
> priority).

True, but the default is mid range.

> Further it has to be ensured that requests that don’t assign a
> priority do not get starved (as they might be important).

That I agree with. However the whole point of priorities is that higher
priority messages can starve lower priority messages. Using emergency
services as an example: during normal operations all messages will have
default priority (no priority). During an emergency, some messages will
have high priority which might starve no priority messages (regular
traffic).

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 4 May 2016 16:31:05 +0200

Hi Alexey,

see below.

> Am 04.05.2016 um 14:03 schrieb Alexey Melnikov <[email-masked]>:
> 
> Hi Mirja,
> 

The point is, if you explicitly indicate that you have a lower priority, you are okay to be starved. However, if you don’t indicate anything (maybe just because you have not been aware that it is possible to do so), you might have the same or even a higher priority, and in this case it’s not okay to be starved.

Mirja

---

From: "Gunn, Janet P" <[email-masked]>
Date: Wed, 4 May 2016 15:45:43 +0000

My comment below.
Janet

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind (IETF)
Sent: Wednesday, May 04, 2016 10:31 AM
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>
Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

Hi Alexey,

see below.

Mirja
<JPG> If a message comes in without a priority, into a system which serves messages based on priority (regardless of the specific mechanisms)you have two options
1- Discard the message (Not a good idea in most systems)
2 - Assign the message an ARBITRARY priority (we call this arbitrary value the "default priority")

You can (and probably will) argue 'til the cows come home on what that arbitrary/default value SHOULD BE.  And different sytems/applications might have different "default values".

But I don't think there should be any argument that, if a message comes in without a priority, you need to assign it a priority.

</JPG>

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 4 May 2016 17:50:49 +0200

Hi Janet,

there are clearly more options than the two mention below.

E.g. one option is the one explained in my initial comment: hhaving two queues, that are both served with a certain rate.

I’m sure there are more (and potentially more complex) solutions to this problem as well.

Assigning an arbitrary priority is not the right option from my point of view and can actually hurt the systems.

Mirja

> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P <[email-masked]>:
> 
> My comment below.
> Janet
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 May 2016 11:28:54 -0500

I agree with Alexey.  I don't see the issue with the default value. 
Alexey has done a better job of explaining why than I could.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 May 2016 11:33:30 -0500

Mirja,

Your example of having two queues is just one way of implementing a 
default priority.

Yes, as pointed out by Alexey, use of priority can result in starving of 
lower priority messages.  This is by design and an explicit requirement 
of networks that handle emergency services.

I'm not seeing the issue here.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 May 2016 11:38:23 -0500

Mirja had a question on the number or priority levels:

As a starting point, most priority schemes for emergency services have 
at least five priority levels.   If we assume, based on this, that 
emergency services need five values then this would be the minimum 
number of priority levels.  We increased the number of priority values 
to reflect that there are multiple use cases specified.  Other values 
would be used for the differentiated services and application specific 
priorities use cases.

Steve

---

From: "Gunn, Janet P" <[email-masked]>
Date: Wed, 4 May 2016 16:54:09 +0000

Conceptually, that (2 queues) approach DOES correspond to assigning a default priority.

In that particular case, you are assigning the "unknown priority" messages to  particlar priority value( a value that is not used by the messages with "known priority") and then establishing a separate queue  for THAT priority value.

I am not sure whether it is a "good idea" or not, but it certainly fits within the constraints of a "default priority".

Janet

-----Original Message-----
From: Mirja Kuehlewind (IETF) [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2016 11:51 AM
To: Gunn, Janet P <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>
Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

Hi Janet,

Mirja

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 May 2016 13:21:40 +0100

On Wed, May 4, 2016, at 05:54 PM, Gunn, Janet P wrote:
> In that particular case, you are assigning the "unknown priority"
> messages to  particlar priority value( a value that is not used by the
> messages with "known priority") and then establishing a separate queue 
> for THAT priority value.

+1.

> I am not sure whether it is a "good idea" or not, but it certainly fits
> within the constraints of a "default priority".

Mirja, I don't think you articulated your concern well. What the
document suggests is what other similar system use. I never heard about
any problems. Which of course doesn't mean that there are no problems
;-).

> Cc: Alexey Melnikov <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]; The
> IESG <[email-masked]>
> E.g. one option is the one explained in my initial comment: hhaving two
> queues, that are both served with a certain rate.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 May 2016 13:26:29 +0100

Hi Mirja,

> view and can actually hurt the systems.

Can you please explain? (The default priority is not really arbitrary,
so I want to understand why assigning a value in the middle of the
allowed range is not Ok).

Thank you,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 May 2016 13:32:10 +0100

Hi Mirja,

> view and can actually hurt the systems.

I hope this will help to clarify things:

One point of assigning default priority is that as this is an extension,
there is a desire to avoid upgrading all clients on the network, as that
would be effectively trying to deploy a new protocol. Consider a network
where proxies and servers understand this extension and none of the
clients do. Then default priority would be assigned to all traffic and
the behaviour of the system is unchanged from the case when the
extension is not deployed. The default priority only makes a difference
if there is a mixture of clients implementing this extension and clients
that don't.

Best Regards,
Alexey

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 10 May 2016 10:46:35 -0400

Hi all,

sorry for my late reply.

I think the part with the two queues was a little confusing. Sorry for that as well. I originally meant to describe this to illustrate the problem rather than describing a solution. However, using two queues (which fully is an implementation detail) does not even match the problem correctly that I wanted to describe… the actually point would be about the scheduling that one would need to implement to serve the queues. Here my thinking was that, instead of implementing a strict priority scheduling, you could also implement a scheme that guarantees a certain minimum serving rate for the non-priority-defined requests to avoid full starvation. However, I don’t want to confuse you even more here. So let me try to phase my concern again (I’ve also edited my discuss text):

I don’t think it is a good idea to assign a default priority to non-priority-defined requests at all. If you have high priority traffic that does not support this extension (yet) this traffic could be starved by lower priority traffic when assigning a middle range priority. I don’t think that is what you want to achieve.

I think this point is even more true with respect to the discussion that went on with Alissa and Ben. There, you said, you’d need to define a priority scheme for a certain application before you could use it. Given that it does not make sense to define a default priority value to for all uses because depending of with priority range you select to use in your scheme, the default might be a low, high, or midrange value.

To make it even more clear I would like to propose the following text change in the doc:

OLD:
   Diameter nodes MUST have a default priority to apply to transactions
   that do not have an explicit priority set in the DRMP AVP.

   Diameter nodes SHOULD use the PRIORITY_10 priority as this default
   value.

NEW:
   Diameter nodes MAY set a default priority to apply to transactions
   that do not have an explicit priority set in the DRMP AVP if it is
   known that the transactions that define a higher priority than the default
   are always higher priority than the transactions that do not define 
   a priority explicitly. The default value will depend on the used priority 
   range in a given deployment setup. 

   Diameter node SHOULD not assign
   a default priority if no additional information about the transaction
   that do not define an explicit priority is known. In this case the
   diameter node SHOULD provide a minimum serving rate for transaction that do
   not define an explicit priority to avoid full starvation of these
   transactions the may or may not have a higher priority than other 
   transactions that provide information about their priority.

I hope that makes sense to you. Please propose edits (if not)!

Mirja 

> Am 05.05.2016 um 08:32 schrieb Alexey Melnikov <[email-masked]>:
> 
> Hi Mirja,
>

---

From: ken carlberg <[email-masked]>
Date: Tue, 10 May 2016 12:10:08 -0400

Hi Mirja,

> On May 10, 2016, at 10:46 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> 

I think your concern is quite valid, and my apologies if I missed something in the thread, but I think one thing that hasn’t been brought up is the notion of local policy and its separation from labels or priority values.  A number of years ago, the IETF community had some significant back and forth on the topic in the context of Emergency Telecommunications Service.  Specifically, in RFC-3689 we stated the following:

   3) Policy

      Policy MUST be kept separate from label(s).  This topic has
      generated a fair amount of debate, and so we provide additional
      guidance from the following:

      A set of labels may be defined as being related to each other.
      Characteristics (e.g., drop precedence) may also be attributed to
      these labels.  [11] is an example of a related set of labels based
      on a specific characteristic.

      However, the mechanisms used to achieve a stated characteristic
      MUST NOT be stated in the definition of a label.  Local policy
      determines mechanism(s) used to achieve or support a specific
      characteristic.  This allows for the possibility of different
      mechanisms to achieve the same stated characteristic.

      The interaction between unrelated labels MUST NOT be embedded
      within the definition of a label.  Local policy states the actions
      (if any) to be taken if unrelated labeled traffic merges at a
      node.

      Finally, labels may have additional characteristics added to them
      as a result of local policy.

Hence, the local policy associated with priority(s) *may* state that a weighted round robin in the servicing of queues *must* be used to ensure that no queue is ever starved.  Or, a more draconian position could be taken that does allow starvation.  It would be up to the operator/manager of the service to decide on the what is the local policy.  This is the way its been implemented and deployed in a few systems that I’m aware of that support prioritization.

-ken

(qualifier: just expressing my own personal opinion.  YMMV, consult doctor before use :-)

---

From: Steve Donovan <[email-masked]>
Date: Tue, 10 May 2016 16:04:40 -0500

Mirja,

Please see my comments inline.

Regards,

Steve

> I don’t think it is a good idea to assign a default priority to non-priority-defined requests at all. If you have high priority traffic that does not support this extension (yet) this traffic could…
SRD> Actually, this is what we want to achieve.  It is an requirement 
that messages explicitly marked as high priority get treated even if it 
results in starving lower priority messages.  The starving of lower 
priority messages is not an problem, it is a requirement.
> I think this point is even more true with respect to the discussion that went on with Alissa and Ben. There, you said, you’d need to define a priority scheme for a certain application before you co…
SRD> I don't understand the statement that it doesn't makes sense to 
define a default priority value.  When defining a priority 
scheme/profile to be used within a Diameter network, all applications 
will need to take the "universal" default value into consideration.  
That default value will then be used in the handling of requests where 
either the application does not yet have a defined priority scheme or 
when the node originating the messages does not yet support the 
applications priority scheme.
>     range in a given deployment setup.
SRD> One of the goals of the default priority value is to keep nodes 
like Diameter relays from needing to understand application semantics.  
This requirement would break those Diameter relays as application level 
knowledge is required to know if a message without an explicit priority 
value is of a higher priority.

SRD> In addition, there is only one priority range, as defined in the 
document.  It is important that the range be the same across all 
applications for the mechanism to work, especially in nodes handling 
messages for multiple applications.
>     transactions that provide information about their priority.
SRD> This is explicitly NOT a requirement.  It is acceptable to starve 
lower priority messages.
> I hope that makes sense to you. Please propose edits (if not)!
SRD> I don't yet see a reason to change the original wording.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 10 May 2016 17:59:13 -0400

See below.

> Am 10.05.2016 um 17:04 schrieb Steve Donovan <[email-masked]>:
> 
> Mirja,
> 
> SRD> Actually, this is what we want to achieve.  It is an requirement that messages explicitly marked as high priority get treated even if it results in starving lower priority messages.  The starving of lower priority messages is not an problem, it is a requirement.

I think we are still talking past each other. If you explicitly assign a priority, starvation might be okay. However, if you don’t have a priority explicitly signaled, the transaction might have a very high priority but you just don’t know and by assigning a random mid-range priority this important request could get starved.

Mirja

> SRD> I don't understand the statement that it doesn't makes sense to define a default priority value.  When defining a priority scheme/profile to be used within a Diameter network, all applications will need to take the "universal" default value into consideration.  That default value will then be used in the handling of requests where either the application does not yet have a defined priority scheme or when the node originating the messages does not yet support the applications priority scheme.
>> 
> SRD> One of the goals of the default priority value is to keep nodes like Diameter relays from needing to understand application semantics.  This requirement would break those Diameter relays as application level knowledge is required to know if a message without an explicit priority value is of a higher priority.
> 
> SRD> In addition, there is only one priority range, as defined in the document.  It is important that the range be the same across all applications for the mechanism to work, especially in nodes handling messages for multiple applications.
>> 
> SRD> This is explicitly NOT a requirement.  It is acceptable to starve lower priority messages.
>>

---

From: <[email-masked]>
Date: Wed, 11 May 2016 00:34:11 +0000

Hi Mirja,

I think that we need to go back to the initial requirement.
Today, it is not possible to give a priority handling to any Diameter message, except if there is an explicit handling defined by the application using the commands or by operator policies and this specific handling can only be applied by clients, proxies and servers, not by relays.

With the proposed solution, it is possible to include a explicit priority indication in Diameter messages that can be used by any node, whatever the type, as soon as they are upgraded to support this priority mechanism.

Now, in heteregenous networks, it is required to handle any type of message, with or without priority indication. Messages without priority indication will be handled as today, without any specific priority handling except defined otherwise (as described above).

In this context, defining a default priority handling for the messages without explicit priority indication makes sense. If it is required that some messages have a higher priority handling, it will be required to upgrade the clients to enable them to include the priority indication. Otherwise, it will be understood that these messages could be deprioritized compared to others with explicit priority indication.

Moreover, the priority handling will be applied ONLY when needed, when not all the messages can be handled. So, in normal situation, no difference will be made between messages with or without priority indication. And when required to prioritize the messages, it is normal to take into account “in priority” the priority indication included in the messages when available. Messages with priority indication will be handled with a best-effort approach when nothing else is defined (by application or operator policy).

For the record, the value 10 is not “assigned” to message without priority indication. The node receiving these messages will behave as if the messages include a priority indication set to the value 10.

Regards,

Lionel

Envoyé depuis Surface

De : Mirja Kuehlewind (IETF)<mailto:[email-masked]>
Envoyé : ‎mercredi‎ ‎11‎ ‎mai‎ ‎2016 ‎00‎:‎01
À : Steve Donovan<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>, Alexey Melnikov<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

See below.

Mirja

_________________________________________________________________________________________________________________________

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.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 10 May 2016 22:47:30 -0400

Hi Lionel,

all you say makes much more sense to me, however, it is not well reflected in the doc. See further below.

> Am 10.05.2016 um 20:34 schrieb [email-masked]:
> 
> Hi Mirja,
> 

This should be stated moe clearly in the doc.

> In this context, defining a default priority handling for the messages without explicit priority indication makes sense. If it is required that some messages have a higher priority handling, it wil…

Not fully sure here because if you don’t know that this extension exists, how can you „[understand] that these messages could be reprioritized“?

> Moreover, the priority handling will be applied ONLY when needed, when not all the messages can be handled. So, in normal situation, no difference will be made between messages with or without prio…

Yes, you can and should take the priority indication into account but you still should not completely starve traffic that does not have a priority indication.

> For the record, the value 10 is not “assigned” to message without priority indication. The node receiving these messages will behave as if the messages include a priority indication set to the valu…

Okay, that is also not stated super clearly but important. And this still does not give an argument for specifying a random default value in this doc… Why is it important that all nodes apply the same  default priority handling?

Mirja

> 
> Regards,
> 
> Lionel
> 
> Envoyé depuis Surface
> 
> De : Mirja Kuehlewind (IETF)
> À : Steve Donovan
> Cc : [email-masked], Alexey Melnikov, [email-masked], [email-masked], [email-masked]
> 
> See below.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 May 2016 06:52:07 -0400

Hi Mirja,

> Yes, you can and should take the priority indication into account but you still should not completely starve traffic that does not have a priority indication.

This can only happen where there is a flood of messages and when it does, this is by design. The whole point of this is that when a flood of messages happens, lower priority messages get less preferential treatment, as opposed to random messages (as it is now without this extension) getting less preferential treatment.

> Okay, that is also not stated super clearly but important. And this still does not give an argument for specifying a random default value in this doc… Why is it important that all nodes apply the s…

Because one would want consistent behaviour across the whole system. Which looks like a desired property.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 May 2016 06:59:56 -0400

Hi Mirja,

On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) <[email-masked]> wrote:

> I think we are still talking past each other.

Most definitely :-).

> If you explicitly assign a priority, starvation might be okay. However, if you don’t have a priority explicitly signaled, the transaction might have a very high priority

So some agent in the system needs to decide that a transaction is important.
> but you just don’t know and by assigning a random mid-range priority this important request could get starved.

Here I disagree with you, because the way to know that a transaction is important is to upgrade client to explicitly assign high priority to it. So default priority is a backward compatibility mechanism, that would work for most common cases. You seem to be suggesting that when this extension is deployed all clients need to be updated at the same time. This is not realistic.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 11 May 2016 07:07:26 -0400

Okay let me go for an example here and see if that can be a use case that we are talking about.

You have a system where some clients run a communication service for emergency doctors as well as for firefighters and then there are also ‚normal‘ users that run some kind of communication service.

Now you actually have an emergency: some part of the system is down and the number of request is high such that the system is overloaded.

Both the emergency doctors have would have two different priority classes, one for important message about instruction (what and where people should do something) and one for communication between the doctors/firefighters which has still higher priority than any other communication of the other people (as you assume doctors and firefighters are more responsible to not misuse this communication channel).

Now only the emergency doctors communication service was upgraded to use this extension, but the firefighter’s administrations is just too slow or they currently have not enough money because they have specialized expensive hardware and software that is not easy to change.

Is it okay in this situation that the private chat of two doctors about their last ski-holidays starves requests to access the network to send instructor message to the firefighters?

(And how do i make sure that that all other other requests actually select a lower priority than 10…? But that’s a different question…)

Mirja

> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov <[email-masked]>:
> 
> Hi Mirja,
>

---

From: "Gunn, Janet P" <[email-masked]>
Date: Wed, 11 May 2016 12:33:51 +0000

This is a very valid concern.  It is important to recognize that "normal" users may include communications that is, in reality, more imprtant that the communications marked as high priority.

But that is a concern addressed by the priority mechanism (e.g., Diameter Overload Indication Conveyance (DOIC) [RFC7683]  or Diameter Overload Rate Control  [draft-ietf-dime-doic-rate-control]).

The concern is orthogonal to the use of a default priority.  Whether you use a default priority or not, if the Firefighters have not upgraded, there is no way for the system to distinguish the firefighters communications from "normal"  communications. So the firefighters won't be treated differently from the "normal" communications.

What is important is that  the priority mechanism protect the "normal" traffic from starvation.

Both DOIC and Rate Control are based on every message having a known priority.  Under those appraoches, If a message doesn't HAVE a priority it won't get served at all (totally starved).  The"arriving unmarked" messages NEED to be assigned a priority in order to be served.  Hence the need for a default priority.

Of course, there are other possible priority mechanisms.  But since those two are the ones that have been produced by the DIME WG for this purpose, it makes sense to put the priority marking process in that context.

Janet

-----Original Message-----
From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
Sent: Wednesday, May 11, 2016 7:07 AM
To: Alexey Melnikov <[email-masked]>
Cc: Steve Donovan <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>; Gunn, Janet P <[email-masked]>
Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

Mirja

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 May 2016 08:02:43 -0500

Mirja,

See my comments inline.

Steve

> This should be stated moe clearly in the doc.
SRD> This is normal Diameter behavior.  A node that doesn't recognize an 
AVP ignores it but, in the case of agents (relays and proxies) leaves 
the AVP in the message when it passes the message on to the next node.

SRD> I can add a reminder to the document that normal Diameter behavior 
applies to this AVP, this just didn't seem needed.
> Not fully sure here because if you don’t know that this extension exists, how can you „[understand] that these messages could be reprioritized“?
SRD> It is understood by the operator of the network that is adding DRMP 
to some but not all clients.  That operator will need to determine which 
nodes get upgraded to support DRMP and in what order.  It is reasonable 
to think that the operator not upgrade a set of clients if they are 
never involved in emergency traffic.  The operator can then know that 
traffic from those clients will get default priority.  If the operator 
wants messages from that client to have a different priority then the 
client must be upgraded to support DRMP.
> Yes, you can and should take the priority indication into account but you still should not completely starve traffic that does not have a priority indication.
SRD> Under normal loads starving won't happen.  Under heavy loads 
starving can happen.  Not only can it happen, it should happen if there 
is enough high priority traffic.  Having the default priority allows the 
operator to put a priority scheme in place that will starve a set of 
messages that the operator considers lower priority than default, giving 
that operator more control.
> Okay, that is also not stated super clearly but important. And this still does not give an argument for specifying a random default value in this doc… Why is it important that all nodes apply the s…
SRD> I'll add clarification to this point.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 May 2016 08:05:45 -0500

Steve

> I think we are still talking past each other. If you explicitly assign a priority, starvation might be okay. However, if you don’t have a priority explicitly signaled, the transaction might have a…
SRD> And if this is why DRMP is needed.   The only method to insure 
these messages get higher priority treatment, including avoiding getting 
starved, is to mark the messages with a priority.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 May 2016 08:06:40 -0500

Inline...

> Because one would want consistent behaviour across the whole system. Which looks like a desired property.
SRD> +1

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 May 2016 08:21:35 -0500

Mirja,

Today, without DRMP, all of the traffic is treated the same by relays as 
relays do not, by design, have application level knowledge.  In many 
cases, servers do not have enough context to determine the priority of a 
message.  In general, the Diameter client is the only one who has that 
knowledge.

You are correct that if the firefighters traffic does not get priority 
marked then the firefighters traffic is thrown into the default bucket 
with all of the other non emergency traffic.

The only way to avoid this is to upgrade the firefighters system. There 
is no way, without a client marking a requests priority, for an agent to 
understand the priority of a message.  Agents don't have application 
level knowledge.  Your proposal of having Diameter nodes understand the 
intrinsic priority of a message without an implicit priority marking is 
not possible in Diameter.  This is why the working group decided on the 
DRMP mechanism.

Steve

---

From: <[email-masked]>
Date: Wed, 11 May 2016 15:29:14 +0000

Hi Mirja,

Thank you for your fedback.

Please see below.

Regards,

Lionel

> -----Message d'origine-----
> De : Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Envoyé : mercredi 11 mai 2016 04:48
> À : MORAND Lionel IMT/OLN
> Cc : Steve Donovan; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Alexey Melnikov
> Objet : Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05:
> (with DISCUSS and COMMENT)
> 
> Hi Lionel,
> 
[LM] I see that at least some clarifications are required :)

> > Today, it is not possible to give a priority handling to any Diameter message,
> except if there is an explicit handling defined by the application using the
> commands or by operator policies and this specific handling can only be
> applied by clients, proxies and servers, not by relays.
> >
> > With the proposed solution, it is possible to include a explicit priority
> indication in Diameter messages that can be used by any node, whatever the
> type, as soon as they are upgraded to support this priority mechanism.
> >
> > Now, in heteregenous networks, it is required to handle any type of
> message, with or without priority indication. Messages without priority
> indication will be handled as today, without any specific priority handling
> except defined otherwise (as described above).
> 

[LM] As I said in a previous mail, one "possible" reproach of this document is that it relies on requirements and prerequisites detailed in the overload documents given in reference.
It is also assumed that readers are familiars with Diameter and Diameter-based networks such 3GPP networks. But it is true for other documents (maybe not an excuse).

> 
> >
> > In this context, defining a default priority handling for the messages
> without explicit priority indication makes sense. If it is required that some
> messages have a higher priority handling, it will be required to upgrade the
> clients to enable them to include the priority indication. Otherwise, it will be
> understood that these messages could be deprioritized compared to others
> with explicit priority indication.
> 
> Not fully sure here because if you don’t know that this extension exists, how
> can you „[understand] that these messages could be reprioritized“?

[LM] Not sure to understand. If you are not supporting this new Diameter extension, there is no standardized re/deprioritization mechanism defined anyway. Messages with priority indication will be handled as any other messages, as today.
It is only for nodes supporting the new mechanism that it is important to define a standard behavior for when receiving messages without priority indication sent by non-supporting nodes.

> 
> >
> > Moreover, the priority handling will be applied ONLY when needed, when
> not all the messages can be handled. So, in normal situation, no difference
> will be made between messages with or without priority indication. And
> when required to prioritize the messages, it is normal to take into account “in
> priority” the priority indication included in the messages when available.
> Messages with priority indication will be handled with a best-effort approach
> when nothing else is defined (by application or operator policy).
> 
> Yes, you can and should take the priority indication into account but you still
> should not completely starve traffic that does not have a priority indication.

[LM] In a system where the priority mechanism is introduced, the idea is actually to give higher priority to messages indicating higher priority.
Networks that will have to support priority handling (low or high) will be upgraded to support this mechanism. Now, when you have to interwork with systems not upgraded, messages received from these systems without priority indication may be handled with a lower priority than other messages. That's a fact. But first, I think that the main use of the priority mechanism is in intra-domain and it is manageable to upgrade homogeneously a given network to support this new mechanism. Now if an application is inter-domain and a specific priority handling is required, the application can be either enhanced to support the priority indication (as for 3GPP inter-domain interfaces) or it is possible to define specific operator policies per interface.

> 
> >
> > For the record, the value 10 is not “assigned” to message without priority
> indication. The node receiving these messages will behave as if the messages
> include a priority indication set to the value 10.
> 
> Okay, that is also not stated super clearly but important. And this still does
> not give an argument for specifying a random default value in this doc… Why
> is it important that all nodes apply the same  default priority handling?

[LM] it is a recommendation to insure consistent handling of priority management across heterogeneous networks. It is more an implementation guidelines for vendors than an operational requirement.
The "SHOULD" is actually use to say "Use 10 except otherwise stated/configured".

> > Envoyé : ‎mercredi‎ ‎11‎ ‎mai‎ ‎2016 ‎00‎:‎01 À : Steve Donovan Cc :
> > [email-masked], Alexey Melnikov, [email-masked],
> > [email-masked], [email-masked]
> >
> > See below.
> >
> > >> I think the part with the two queues was a little confusing. Sorry for that
> as well. I originally meant to describe this to illustrate the problem rather
> than describing a solution. However, using two queues (which fully is an
> implementation detail) does not even match the problem correctly that I
> wanted to describe… the actually point would be about the scheduling that
> one would need to implement to serve the queues. Here my thinking was
> that, instead of implementing a strict priority scheduling, you could also
> implement a scheme that guarantees a certain minimum serving rate for the
> non-priority-defined requests to avoid full starvation. However, I don’t want
> to confuse you even more here. So let me try to phase my concern again
> (I’ve also edited my discuss text):
> > >>
> > >> I don’t think it is a good idea to assign a default priority to non-priority-
> defined requests at all. If you have high priority traffic that does not support
> this extension (yet) this traffic could be starved by lower priority traffic when
> assigning a middle range priority. I don’t think that is what you want to
> achieve.
> > > SRD> Actually, this is what we want to achieve.  It is an requirement that
> messages explicitly marked as high priority get treated even if it results in
> starving lower priority messages.  The starving of lower priority messages is
> not an problem, it is a requirement.
> >
> > I think we are still talking past each other. If you explicitly assign a priority,
> starvation might be okay. However, if you don’t have a priority explicitly
> signaled, the transaction might have a very high priority but you just don’t
> know and by assigning a random mid-range priority this important request
> could get starved.
> >
> > Mirja
> >
> >
> > >>
> > >> I think this point is even more true with respect to the discussion that
> went on with Alissa and Ben. There, you said, you’d need to define a priority
> scheme for a certain application before you could use it. Given that it does
> not make sense to define a default priority value to for all uses because
> depending of with priority range you select to use in your scheme, the
> default might be a low, high, or midrange value.
> define a default priority value.  When defining a priority scheme/profile to be
> used within a Diameter network, all applications will need to take the
> "universal" default value into consideration.  That default value will then be
> used in the handling of requests where either the application does not yet
> have a defined priority scheme or when the node originating the messages
> does not yet support the applications priority scheme.
> > >>
> > > SRD> One of the goals of the default priority value is to keep nodes like
> Diameter relays from needing to understand application semantics.  This
> requirement would break those Diameter relays as application level
> knowledge is required to know if a message without an explicit priority value
> is of a higher priority.
> > >
> document.  It is important that the range be the same across all applications
> for the mechanism to work, especially in nodes handling messages for
> multiple applications.
> > >>
> > >>>> E.g. one option is the one explained in my initial comment:
> > >>>> hhaving two queues, that are both served with a certain rate.
> > >>>>
> > >>>> Assigning an arbitrary priority is not the right option from my
> > >>>> point of view and can actually hurt the systems.
> > >>> One point of assigning default priority is that as this is an
> > >>> extension, there is a desire to avoid upgrading all clients on the
> > >>> network, as that would be effectively trying to deploy a new
> > >>> protocol. Consider a network where proxies and servers understand
> > >>> this extension and none of the clients do. Then default priority
> > >>> would be assigned to all traffic and the behaviour of the system
> > >>> is unchanged from the case when the extension is not deployed. The
> > >>> default priority only makes a difference if there is a mixture of
> > >>> clients implementing this extension and clients that don't.
> > >>>
> > >>> Best Regards,
> > >>> Alexey
> > >>>
> > >>>> Mirja
> > >>>>
> > >>>>
> > >>>>> Subject: Re: [Dime] Mirja Kühlewind's Discuss on
> > >>>>> draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
> > >>>>>
> > >>>>> Hi Alexey,
> > >>>>>
> > >>>>> see below.
> > >>>>>
> > >>>>> The point is, if you explicitly indicate that you have a lower priority,
> you are okay to be starved. However, if you don’t indicate anything (maybe
> just because you have not been aware that it is possible to do so), you might
> have the same or even a higher priority, and in this case it’s not okay to be
> starved.
> > >>>>>
> > >>>>> Mirja
> > >>>>> <JPG> If a message comes in without a priority, into a system
> > >>>>> which serves messages based on priority (regardless of the
> > >>>>> specific mechanisms)you have two options
> > >>>>> You can (and probably will) argue 'til the cows come home on what
> that arbitrary/default value SHOULD BE.  And different sytems/applications
> might have different "default values".
> > >>>>>
> > >>>>> But I don't think there should be any argument that, if a message
> comes in without a priority, you need to assign it a priority.
> > >>>>>
> > >>>>> </JPG>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> This electronic message transmission contains information from
> CSRA that may be attorney-client privileged, proprietary or confidential. The
> information in this message is intended only for use by the individual(s) to
> whom it is addressed. If you believe you have received this message in error,
> please contact me immediately and be aware that any use, disclosure,
> copying or distribution of the contents of this message is strictly prohibited.
> NOTE: Regardless of content, this email shall not operate to bind CSRA to any
> order or other contract unless pursuant to explicit written agreement or
> government initiative expressly permitting the use of email for such purpose.
> > >
> >
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > 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,
> > 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.

---

From: <[email-masked]>
Date: Wed, 11 May 2016 16:07:15 +0000

Hi,

I think that it is important to remind that "Diameter applications" are specific applications of the Diameter protocol in the AAA network, in the core network/back-end infrastructure managed by an operator network.
In the example below, the key point is to characterize the traffic at the entry of the core network by a AAA client in front of a non-Diameter based network. Examples of such AAA client are Network access servers or IP gateway in mobile networks.

A AAA client supporting the new extension will have a set of criteria to determine the priority value to include in every initiated Diameter message. 
They will be then able to make the distinction between priority requirements for each "service" (e.g. emergency doctors/firefighters/voice services etc.).
The determination mechanism is out of scope of this document but an example could be to rely on another priority indication conveyed in signaling planes used in the front-end network, ex. in SIP or directly at the IP layer.

If the AAA client are not upgraded to support the new extension, there is no way for the AAA client to indicate the priority to apply message per message. It will just send the Diameter messages to other Diameter peers as done today.
The other peers can be a Diameter server or a relay/proxy. And these peers can be upgraded or not. If they are upgraded, they will have to cope with messages with or without priority indication. And in such a case, the recommendation is to handle unmarked Diameter messages as if they were included the value 10 when no other information is available. 

Now, if you can identify that the unmarked messages must be handled with a higher priority even if not marked, you can still do it, using operator defined policies or application-specific handling. This can be done per interface or at the Diameter application level, saying message x from application Y has higher priority than message A from application B. But the last example (handling at the Diameter level) illustrates that the nodes handling the message without priority need to be application-aware, i.e. able to understand the semantic of the received messages, and they have to be either a Diameter proxy or a Diameter server (as defined in the RFC 6733), which exclude Diameter relays that are application-agnostic.

The whole purpose of this solution is to define a mechanism that can work with application-agnostic nodes (including relays) and without the resort to specific operator policies. Ad this includes the need for a recommended default handling of unmarked messages.

I hope that it helps to clarify the discussion.

And I agree with the responses provided by Steve, Janet and Alexey.

Regards,

Lionel

> De : Steve Donovan [mailto:[email-masked]]
> Envoyé : mercredi 11 mai 2016 15:22
> À : Mirja Kuehlewind (IETF); Alexey Melnikov
> Cc : [email-masked]; [email-masked]; [email-masked];
> The IESG; Gunn, Janet P
> Today, without DRMP, all of the traffic is treated the same by relays as relays
> do not, by design, have application level knowledge.  In many cases, servers
> do not have enough context to determine the priority of a message.  In
> general, the Diameter client is the only one who has that knowledge.
> 
> You are correct that if the firefighters traffic does not get priority marked
> then the firefighters traffic is thrown into the default bucket with all of the
> other non emergency traffic.
> 
> The only way to avoid this is to upgrade the firefighters system. There is no
> way, without a client marking a requests priority, for an agent to understand
> the priority of a message.  Agents don't have application level knowledge.
> Your proposal of having Diameter nodes understand the intrinsic priority of a
> message without an implicit priority marking is not possible in Diameter.  This
> is why the working group decided on the DRMP mechanism.
> 
> Steve
> 
> > You have a system where some clients run a communication service for
> emergency doctors as well as for firefighters and then there are also ‚normal‘
> users that run some kind of communication service.
> >
> > Now you actually have an emergency: some part of the system is down and
> the number of request is high such that the system is overloaded.
> >
> > Both the emergency doctors have would have two different priority
> classes, one for important message about instruction (what and where
> people should do something) and one for communication between the
> doctors/firefighters which has still higher priority than any other
> communication of the other people (as you assume doctors and firefighters
> are more responsible to not misuse this communication channel).
> >
> > Now only the emergency doctors communication service was upgraded to
> use this extension, but the firefighter’s administrations is just too slow or
> they currently have not enough money because they have specialized
> expensive hardware and software that is not easy to change.
> >
> > Is it okay in this situation that the private chat of two doctors about their
> last ski-holidays starves requests to access the network to send instructor
> message to the firefighters?
> >
> > (And how do i make sure that that all other other requests actually select a
> lower priority than 10…? But that’s a different question…)
> >
> > Mirja
> >
> >
> that messages explicitly marked as high priority get treated even if it results
> in starving lower priority messages.  The starving of lower priority messages is
> >>> If you explicitly assign a priority, starvation might be okay. However, if
> you don’t have a priority explicitly signaled, the transaction might have a very
> high priority
> >>> but you just don’t know and by assigning a random mid-range priority
> this important request could get starved.
> >> Here I disagree with you, because the way to know that a transaction is
> important is to upgrade client to explicitly assign high priority to it. So default
> priority is a backward compatibility mechanism, that would work for most
> common cases. You seem to be suggesting that when this extension is
> deployed all clients need to be updated at the same time. This is not realistic.
> >>
> >>

---

From: Alexe Melnikov <[email-masked]>
Date: Wed, 11 May 2016 13:13:47 -0400

Hi Mirja,

> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 

Yes, this is helpful.
> Now only the emergency doctors communication service was upgraded to use this extension, but the firefighter’s administrations is just too slow or they currently have not enough money because they…

"Doctor, it hurts when I do that..." - "Don't do that!"

I don't think this would be a common deployment case.

I agree that there is an issue in the scenario you specified. Default priority helps with a single application + normal (unupgraded) traffic. I do think it helps with the most common case. So instead of having lots of SHOULDs and MAYs, I suggest we add text describing possible issues and when multiple DIAMETER applications are deployed we either recommend that all clients are upgraded to support this extension at the same time or at least deployments specify compatible policies for different applications.

I can suggest some text.

> Is it okay in this situation that the private chat of two doctors about their last ski-holidays starves requests to access the network to send instructor message to the firefighters?

We can't prevent all problems like this, as the above is really a social problem combined with misconfiguration. But we can warn about it.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 11 May 2016 13:39:03 -0400

Hi Alexey,

yes, please provide some text and maybe a warning.

I’ve cleared my discuss as no actual changes to the spec are needed based on the common understand we have now, however, I would still like to see further text in the doc about points that came up in this discussion.

Thanks!
Mirja

> Am 11.05.2016 um 13:13 schrieb Alexe Melnikov <[email-masked]>:
> 
> Hi Mirja,
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 May 2016 13:28:26 +0100

Hi,
Finally getting back to this.

I think authors did a good job in the latest version by adding sections
1.1 (Applicability) and 10 (Considerations When Defining Application
Priorities).

I would like to suggest the following clarification:

In Section 8:

Unchanged:

OLD:

NEW:
   In order to guaranty consistent handling of messages from nonupgraded
   Diameter clients,
   Diameter nodes SHOULD use the PRIORITY_10 priority as this default
   priority value. PRIORITY_10 is a mid range priority that corresponds
   to "normal" traffic and thus would be a suitable default for most
   deployments,
   while still allowing different Diameter applications to designate
   other
   priorities for lower and higher priority traffic.

Best Regards,
Alexey

On Wed, May 11, 2016, at 06:39 PM, Mirja Kuehlewind (IETF) wrote:
> I’ve cleared my discuss as no actual changes to the spec are needed based
> on the common understand we have now, however, I would still like to see
> further text in the doc about points that came up in this discussion.
> 
> Thanks!
> Mirja
> 
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 30 May 2016 13:34:05 +0200

Hi all,

thanks for adding the Applicability and later Considerations sections! That makes things much more clear to me.

May I propose one tiny edit for the Applicability section, just do make it super clear. If you don’t think this is useful, please withdraw.

OLD:
In order for the DRMP mechanism to work, the	
priorities defined for all messages across all applications used in a	
Diameter administrative domain must be defined in a consistent and	
coordinated fashion.

NEW:
In order for the DRMP mechanism to work, the	
priorities defined for all messages across all applications used in a	
Diameter administrative domain must be defined in a consistent and	
coordinated fashion, taking the default priority into account.

Thanks,
Mirja

> Am 29.05.2016 um 14:28 schrieb Alexey Melnikov <[email-masked]>:
> 
> Hi,

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 May 2016 16:00:34 +0100

Hi Mirja,

> On 30 May 2016, at 12:34, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi all,
> 

I think something like this is a good idea.