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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 01 June 2016 10:19 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCEE12D157; Wed, 1 Jun 2016 03:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level:
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNWUJQ8XfzTe; Wed, 1 Jun 2016 03:19:13 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BEC12D136; Wed, 1 Jun 2016 03:19:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49FECBE2C; Wed, 1 Jun 2016 11:19:11 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVC2UjZKA_JD; Wed, 1 Jun 2016 11:19:11 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9B0E8BE29; Wed, 1 Jun 2016 11:19:10 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464776351; bh=iw4C8eQCObCHQ8E+qO5Z8vQXqNiXt6zjtFuwRRWXnIs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=2TSMh4Egj6sZKupHxlSoNi/ZOVxT/L0MBK4uAOtzvNOnn4XJZwKpzDUYoUtWzk4AM mbIrDQhAKL88spWW3bl86X0oIa+SXHMv1OX5K55ZuMOl4kB042TgRPE9/LTjhSUE9G CxWAmGUZYDYt1XkyTWBfW1gxQNQkA9L+/+sMWlcY=
To: Steve Donovan <srdonovan@usdonovans.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <A8821F45-B9BA-4ACF-8EBF-01B64C100359@fastmail.fm> <B4F433FB-B2A2-4EDA-8ECF-5812BCB7517A@kuehlewind.net> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <e6d1ab6472f14ec3b4b6b024563150ff@CSRRDU1EXM025.corp.csra.com> <F0C35A63-ADCA-4502-AC3B-C2DF5FA6EDFD@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net> <57324CE8.6040109@usdonovans.com> <74E6ECC0-283D-4A14-AF19-66E76EBAA743@kuehlewind.net> <B348BA8A-5A92-4E44-8ECA-76E4F3E03426@fastmail.fm> <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net> <993A9C1D-1B91-4A6D-B7DA-F5E829763E17@fastmail.fm> <A37DCA0E-8C6D-4056-9B0C-63A25C6C37DA@kuehlewind.net> <1464524906.507204.621875065.5A6A91A2@webmail.messagingengine.com> <b6afc0ef-bab5-0d6e-ad5c-3b5a96ae86d3@usdonovans.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <574EB69E.8020509@cs.tcd.ie>
Date: Wed, 1 Jun 2016 11:19:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <b6afc0ef-bab5-0d6e-ad5c-3b5a96ae86d3@usdonovans.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040401030007070503080306"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/sgmZHjdl8mEgCN72BN_K_IHZ_AM>
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 10:19:16 -0000

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 <aamelnikov@fastmail.fm>fm>:
>>>>
>>>> Hi Mirja,
>>>>
>>>>> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF)
>>>>> <ietf@kuehlewind.net> 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
>>>>>> <aamelnikov@fastmail.fm>fm>:
>>>>>>
>>>>>> Hi Mirja,
>>>>>>
>>>>>> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF)
>>>>>> <ietf@kuehlewind.net> 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.
>