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

<lionel.morand@orange.com> Wed, 11 May 2016 15:29 UTC

Return-Path: <lionel.morand@orange.com>
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 9A84712D722; Wed, 11 May 2016 08:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.915
X-Spam-Level:
X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 37Y62Ur4iClV; Wed, 11 May 2016 08:29:17 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FEC12D70C; Wed, 11 May 2016 08:29:17 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B9B20C0611; Wed, 11 May 2016 17:29:15 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 689E74008F; Wed, 11 May 2016 17:29:15 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0294.000; Wed, 11 May 2016 17:29:15 +0200
From: lionel.morand@orange.com
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Thread-Topic: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
Thread-Index: AQHRqsu3MGSn2nqArkOEVymcyKpnwZ+yiAMAgAAPPoCAAEzT+4AAA7kAgADXmlA=
Date: Wed, 11 May 2016 15:29:14 +0000
Message-ID: <9074_1462980555_57334FCB_9074_8739_4_6B7134B31289DC4FAF731D844122B36E01E605A1@OPEXCLILM43.corporate.adroot.infra.ftgroup>
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> <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> <C2B8FB6D-F575-4587-954A-8F7282209F25@kuehlewind.net>
In-Reply-To: <C2B8FB6D-F575-4587-954A-8F7282209F25@kuehlewind.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/ZNUTSyBT_pItS3xZ_VVnGkJEjGg>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, "draft-ietf-dime-drmp@ietf.org" <draft-ietf-dime-drmp@ietf.org>, "dime-chairs@ietf.org" <dime-chairs@ietf.org>, "dime@ietf.org" <dime@ietf.org>, "iesg@ietf.org" <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: Wed, 11 May 2016 15:29:21 -0000

Hi Mirja,

Thank you for your fedback.

Please see below.

Regards,

Lionel

> -----Message d'origine-----
> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
> Envoyé : mercredi 11 mai 2016 04:48
> À : MORAND Lionel IMT/OLN
> Cc : Steve Donovan; draft-ietf-dime-drmp@ietf.org; dime-chairs@ietf.org;
> dime@ietf.org; iesg@ietf.org; Alexey Melnikov
> Objet : Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05:
> (with DISCUSS and COMMENT)
> 
> Hi Lionel,
> 
> all you say makes much more sense to me, however, it is not well reflected in
> the doc. See further below.
> 
[LM] I see that at least some clarifications are required :)

> > Am 10.05.2016 um 20:34 schrieb lionel.morand@orange.com:
> >
> > Hi Mirja,
> >
> > I think that we need to go back to the initial requirement.
> > Today, it is not possible to give a priority handling to any Diameter message,
> except if there is an explicit handling defined by the application using the
> commands or by operator policies and this specific handling can only be
> applied by clients, proxies and servers, not by relays.
> >
> > With the proposed solution, it is possible to include a explicit priority
> indication in Diameter messages that can be used by any node, whatever the
> type, as soon as they are upgraded to support this priority mechanism.
> >
> > Now, in heteregenous networks, it is required to handle any type of
> message, with or without priority indication. Messages without priority
> indication will be handled as today, without any specific priority handling
> except defined otherwise (as described above).
> 
> This should be stated moe clearly in the doc.

[LM] As I said in a previous mail, one "possible" reproach of this document is that it relies on requirements and prerequisites detailed in the overload documents given in reference.
It is also assumed that readers are familiars with Diameter and Diameter-based networks such 3GPP networks. But it is true for other documents (maybe not an excuse).

> 
> >
> > In this context, defining a default priority handling for the messages
> without explicit priority indication makes sense. If it is required that some
> messages have a higher priority handling, it will be required to upgrade the
> clients to enable them to include the priority indication. Otherwise, it will be
> understood that these messages could be deprioritized compared to others
> with explicit priority indication.
> 
> Not fully sure here because if you don’t know that this extension exists, how
> can you „[understand] that these messages could be reprioritized“?

[LM] Not sure to understand. If you are not supporting this new Diameter extension, there is no standardized re/deprioritization mechanism defined anyway. Messages with priority indication will be handled as any other messages, as today.
It is only for nodes supporting the new mechanism that it is important to define a standard behavior for when receiving messages without priority indication sent by non-supporting nodes.

> 
> >
> > Moreover, the priority handling will be applied ONLY when needed, when
> not all the messages can be handled. So, in normal situation, no difference
> will be made between messages with or without priority indication. And
> when required to prioritize the messages, it is normal to take into account “in
> priority” the priority indication included in the messages when available.
> Messages with priority indication will be handled with a best-effort approach
> when nothing else is defined (by application or operator policy).
> 
> Yes, you can and should take the priority indication into account but you still
> should not completely starve traffic that does not have a priority indication.

[LM] In a system where the priority mechanism is introduced, the idea is actually to give higher priority to messages indicating higher priority.
Networks that will have to support priority handling (low or high) will be upgraded to support this mechanism. Now, when you have to interwork with systems not upgraded, messages received from these systems without priority indication may be handled with a lower priority than other messages. That's a fact. But first, I think that the main use of the priority mechanism is in intra-domain and it is manageable to upgrade homogeneously a given network to support this new mechanism. Now if an application is inter-domain and a specific priority handling is required, the application can be either enhanced to support the priority indication (as for 3GPP inter-domain interfaces) or it is possible to define specific operator policies per interface.

> 
> >
> > For the record, the value 10 is not “assigned” to message without priority
> indication. The node receiving these messages will behave as if the messages
> include a priority indication set to the value 10.
> 
> Okay, that is also not stated super clearly but important. And this still does
> not give an argument for specifying a random default value in this doc… Why
> is it important that all nodes apply the same  default priority handling?

[LM] it is a recommendation to insure consistent handling of priority management across heterogeneous networks. It is more an implementation guidelines for vendors than an operational requirement.
The "SHOULD" is actually use to say "Use 10 except otherwise stated/configured".

> 
> Mirja
> 
> 
> >
> > Regards,
> >
> > Lionel
> >
> > Envoyé depuis Surface
> >
> > De : Mirja Kuehlewind (IETF)
> > Envoyé : ‎mercredi‎ ‎11‎ ‎mai‎ ‎2016 ‎00‎:‎01 À : Steve Donovan Cc :
> > draft-ietf-dime-drmp@ietf.org, Alexey Melnikov, dime-chairs@ietf.org,
> > dime@ietf.org, iesg@ietf.org
> >
> > See below.
> >
> > > Am 10.05.2016 um 17:04 schrieb Steve Donovan
> <srdonovan@usdonovans.com>:
> > >
> > > 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.
> >
> > 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
> <aamelnikov@fastmail.fm>:
> > >>>
> > >>> 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
> <Janet.Gunn@csra.com>:
> > >>>>>
> > >>>>> My comment below.
> > >>>>> Janet
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Mirja
> > >>>>> Kuehlewind (IETF)
> > >>>>> Sent: Wednesday, May 04, 2016 10:31 AM
> > >>>>> To: Alexey Melnikov <aamelnikov@fastmail.fm>
> > >>>>> 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)
> > >>>>>
> > >>>>> 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
> > >>>>> DiME@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/dime
> > >>>>>
> > >>>>> 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.
> > >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
> >
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> > Thank you.
> >


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.