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

"Mirja Kuehlewind (IETF)" <> Tue, 10 May 2016 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 970A412D0E3 for <>; Tue, 10 May 2016 07:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mF5E2sa5KxRW for <>; Tue, 10 May 2016 07:53:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E5A512B008 for <>; Tue, 10 May 2016 07:53:22 -0700 (PDT)
Received: (qmail 24456 invoked from network); 10 May 2016 16:46:39 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 May 2016 16:46:39 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <>
Date: Tue, 10 May 2016 10:46:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Alexey Melnikov <>, "Gunn, Janet P" <>,
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc:,,, 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: Tue, 10 May 2016 14:53:24 -0000

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:

   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

   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)!


> 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.