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

Steve Donovan <> Wed, 11 May 2016 13:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 910FC12DAAC; Wed, 11 May 2016 06:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TmCRzR3Sj_-f; Wed, 11 May 2016 06:05:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 975F512DAB3; Wed, 11 May 2016 06:05:51 -0700 (PDT)
Received: from ([]:62347 helo=Steves-MacBook-Air.local) by with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <>) id 1b0Tpi-000rVF-Ju; Wed, 11 May 2016 06:05:50 -0700
To: "Mirja Kuehlewind (IETF)" <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Steve Donovan <>
Message-ID: <>
Date: Wed, 11 May 2016 08:05:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Cc:, Alexey Melnikov <>,,, The IESG <>
Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 May 2016 13:05:57 -0000

Please see my comments inline.


On 5/10/16 4:59 PM, Mirja Kuehlewind (IETF) wrote:
> See below.
>> Am 10.05.2016 um 17:04 schrieb Steve Donovan <>:
>> 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.
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.
> 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 <>:
>>>> 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 <>:
>>>>>> My comment below.
>>>>>> Janet
>>>>>> -----Original Message-----
>>>>>> From: DiME [] On Behalf Of Mirja Kuehlewind (IETF)
>>>>>> Sent: Wednesday, May 04, 2016 10:31 AM
>>>>>> To: Alexey Melnikov <>
>>>>>> Cc:;;; The IESG <>
>>>>>> 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
>>>>>> 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.