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

[<[e-mail]>]

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:[e-mail]>
Envoyé : ‎mercredi‎ ‎11‎ ‎mai‎ ‎2016 ‎00‎:‎01
À : Steve Donovan<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>, Alexey Melnikov<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>

See below.

> Am 10.05.2016 um 17:04 schrieb Steve Donovan <[e-mail]>:
>
> Mirja,
>
> Please see my comments inline.
>
> Regards,
>
> Steve
>
> On 5/10/16 9:46 AM, Mirja Kuehlewind (IETF) wrote:
>> 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.
> 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.
> 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.
>>
>> 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.
> 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.
>>
>>    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.
> 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.
>>
>> Mirja
>>
>>
>>> Am 05.05.2016 um 08:32 schrieb Alexey Melnikov <[e-mail]>:
>>>
>>> Hi Mirja,
>>>
>>> On Wed, May 4, 2016, at 04:50 PM, Mirja Kuehlewind (IETF) wrote:
>>>> 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.
>>> 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
>>>
>>>> Mirja
>>>>
>>>>
>>>>> Am 04.05.2016 um 17:45 schrieb Gunn, Janet P <[e-mail]>:
>>>>>
>>>>> My comment below.
>>>>> Janet
>>>>>
>>>>> -----Original Message-----
>>>>> From: DiME [mailto:[e-mail]] On Behalf Of Mirja Kuehlewind (IETF)
>>>>> Sent: Wednesday, May 04, 2016 10:31 AM
>>>>> To: Alexey Melnikov <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; The IESG <[e-mail]>
>>>>> 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
>>>>> 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
>>>>> [e-mail]
>>>>> 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.
>

_______________________________________________
DiME mailing list
[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.