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

Steve Donovan <srdonovan@usdonovans.com> Wed, 11 May 2016 13:21 UTC

Return-Path: <srdonovan@usdonovans.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 BBBC712DABD; Wed, 11 May 2016 06:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkmEq90a55Og; Wed, 11 May 2016 06:21:43 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED06C12D642; Wed, 11 May 2016 06:21:42 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62396 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1b0U53-0011v7-Gw; Wed, 11 May 2016 06:21:42 -0700
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Alexey Melnikov <aamelnikov@fastmail.fm>
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>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <573331DF.2090504@usdonovans.com>
Date: Wed, 11 May 2016 08:21:35 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <6EF5DC36-1BEF-47EE-BB3B-83BE5E115AE3@kuehlewind.net>
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 - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/I-sDdK55SRyLjYHbr9YleJ-l7M8>
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: Wed, 11 May 2016 13:21:46 -0000

Mirja,

Today, without DRMP, all of the traffic is treated the same by relays as 
relays do not, by design, have application level knowledge.  In many 
cases, servers do not have enough context to determine the priority of a 
message.  In general, the Diameter client is the only one who has that 
knowledge.

You are correct that if the firefighters traffic does not get priority 
marked then the firefighters traffic is thrown into the default bucket 
with all of the other non emergency traffic.

The only way to avoid this is to upgrade the firefighters system. There 
is no way, without a client marking a requests priority, for an agent to 
understand the priority of a message.  Agents don't have application 
level knowledge.  Your proposal of having Diameter nodes understand the 
intrinsic priority of a message without an implicit priority marking is 
not possible in Diameter.  This is why the working group decided on the 
DRMP mechanism.

Steve

On 5/11/16 6:07 AM, 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.
>
> 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.
>
> 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?
>
> (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.
>>
>>