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

Steve Donovan <> Wed, 01 June 2016 10:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EE8E12D0C6; Wed, 1 Jun 2016 03:41:18 -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 N0b4EDywxDJX; Wed, 1 Jun 2016 03:41:16 -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 B08D612D098; Wed, 1 Jun 2016 03:41:16 -0700 (PDT)
Received: from [] (port=57518 helo=Steves-MacBook-Air.local) by with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <>) id 1b83aH-003KPq-Dg; Wed, 01 Jun 2016 03:41:15 -0700
To: Stephen Farrell <>, Alexey Melnikov <>, "Mirja Kuehlewind (IETF)" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Steve Donovan <>
Message-ID: <>
Date: Wed, 01 Jun 2016 05:41:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
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:,,, 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, 01 Jun 2016 10:41:18 -0000

I'll generate a revision later today.


On 6/1/16 5:19 AM, Stephen Farrell wrote:
> Great. And Alissa's discuss is cleared so if you want to
> go ahead and shoot out a revision with these changes then
> I can send the approval and get this shipped off to the
> RFC editor. (If doing a revision is a problem, send me
> the changes in OLD/NEW form and I can enter them as an
> RFC editor note and they'll be done later on.)
> Cheers,
> S.
> On 01/06/16 11:16, Steve Donovan wrote:
>> I'm okay with this suggestion.
>> Regards,
>> Steve
>> On 5/29/16 7:28 AM, Alexey Melnikov wrote:
>>> 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:
>>>      Diameter nodes MUST have a default priority to apply to transactions
>>>      that do not have an explicit priority set in the DRMP AVP.
>>> OLD:
>>>      Diameter nodes SHOULD use the PRIORITY_10 priority as this default
>>>      value.
>>> 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:
>>>> 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 <>:
>>>>> Hi Mirja,
>>>>>> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF)
>>>>>> <> wrote:
>>>>>> Okay let me go for an example here and see if that can be a use
>>>>>> case that we are talking about.
>>>>> Yes, this is helpful.
>>>>>> 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.
>>>>> "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.
>>>>>> (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
>>>>>>> <>:
>>>>>>> Hi Mirja,
>>>>>>> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF)
>>>>>>> <> wrote:
>>>>>>>>>> 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.
>>>>>>> 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.