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

Steve Donovan <srdonovan@usdonovans.com> Wed, 04 May 2016 16:39 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 BC3DC12D6FC; Wed, 4 May 2016 09:39:20 -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 ROyiQVvUNu8T; Wed, 4 May 2016 09:39:19 -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 81C3A12DCEB; Wed, 4 May 2016 09:29:01 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60072 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 1axzfT-000tTF-1k; Wed, 04 May 2016 09:28:59 -0700
To: 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>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <572A2346.5050801@usdonovans.com>
Date: Wed, 04 May 2016 11:28:54 -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: <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com>
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/0ymm3zmTo9S5E4UvZBZVRyQOs8E>
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, 04 May 2016 16:39:21 -0000

I agree with Alexey.  I don't see the issue with the default value. 
Alexey has done a better job of explaining why than I could.

Steve

On 5/4/16 7:03 AM, Alexey Melnikov wrote:
> Hi Mirja,
>
> On Wed, May 4, 2016, at 12:45 PM, Mirja Kuehlewind (IETF) wrote:
>> Hi Alexey,
>>
>>
>>> Am 04.05.2016 um 13:37 schrieb Alexey Melnikov <aamelnikov@fastmail.fm>:
>>>
>>> Hi Mirja,
>>>
>>>> On 4 May 2016, at 12:13, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>>>>
>>>> However, the one part that does actually concern me is:
>>>> "When using DRMP priority information, Diameter nodes MUST use the
>>>>   default priority for transactions that do not have priority specified
>>>>   in a DRMP AVP."
>>>> This part seems dangerous and I would proposed to instead basically have
>>>> to different queues: one if a priority is defined and another one for
>>>> requests without priority indication to make sure that requests out of
>>>> the second queue will be served at some point in time and cannot be
>>>> starved by other low priority requests completely.
>>> I think I disagree with you: default priority handling is orthogonal to the number of queues used. Some implementations would use one queue per priority, so you are effectively suggesting that no priority is treated as its own priority. I think this is an implementation detail.
>>>
>>>
>> Yes, queues are implementation details. That was just meant as an
>> illustration. My point it, I don’t think all requests without priority
>> should get an default priority assigned
> Why not? Why not assigning a priority any different than assigning a
> unique priority?
>
> (SMTP Priority extension RFC which I edited made the same choice:
> https://tools.ietf.org/html/rfc6710)
>
>> (and especially not a very low
>> priority).
> True, but the default is mid range.
>
>> Further it has to be ensured that requests that don’t assign a
>> priority do not get starved (as they might be important).
> That I agree with. However the whole point of priorities is that higher
> priority messages can starve lower priority messages. Using emergency
> services as an example: during normal operations all messages will have
> default priority (no priority). During an emergency, some messages will
> have high priority which might starve no priority messages (regular
> traffic).
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime