Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 30 May 2016 11:34 UTC
Return-Path: <ietf@kuehlewind.net>
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 567AD12D5B4 for <dime@ietfa.amsl.com>; Mon, 30 May 2016 04:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 CfLHwnpe6ets for <dime@ietfa.amsl.com>; Mon, 30 May 2016 04:34:06 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EB612D52A for <dime@ietf.org>; Mon, 30 May 2016 04:34:05 -0700 (PDT)
Received: (qmail 5568 invoked from network); 30 May 2016 13:34:02 +0200
Received: from p5dec239a.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.35.154) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 30 May 2016 13:34:02 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <1464524906.507204.621875065.5A6A91A2@webmail.messagingengine.com>
Date: Mon, 30 May 2016 13:34:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BA6D8B1-7212-41E5-8FD6-7BD7391440BE@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>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/8R6O9tQNbAkQYvLiua6hk2mNxhg>
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
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: Mon, 30 May 2016 11:34:09 -0000
Hi all, thanks for adding the Applicability and later Considerations sections! That makes things much more clear to me. May I propose one tiny edit for the Applicability section, just do make it super clear. If you don’t think this is useful, please withdraw. OLD: In order for the DRMP mechanism to work, the priorities defined for all messages across all applications used in a Diameter administrative domain must be defined in a consistent and coordinated fashion. NEW: In order for the DRMP mechanism to work, the priorities defined for all messages across all applications used in a Diameter administrative domain must be defined in a consistent and coordinated fashion, taking the default priority into account. Thanks, Mirja > Am 29.05.2016 um 14:28 schrieb Alexey Melnikov <aamelnikov@fastmail.fm>: > > 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>: >>> >>> 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>: >>>>> >>>>> 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. >>>> >>> >> >
- [Dime] Mirja Kühlewind's Discuss on draft-ietf-di… Mirja Kuehlewind
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Gunn, Janet P
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Gunn, Janet P
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- [Dime] Mirja Kühlewind's Discuss on draft-ietf-di… Mirja Kuehlewind
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… ken carlberg
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… lionel.morand
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Gunn, Janet P
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… lionel.morand
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… lionel.morand
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexe Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Alexey Melnikov
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Stephen Farrell
- Re: [Dime] Mirja Kühlewind's Discuss on draft-iet… Steve Donovan