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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Wed, 04 May 2016 11:46 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 EF40512B017 for <dime@ietfa.amsl.com>; Wed, 4 May 2016 04:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 19h6jykhtQ3S for <dime@ietfa.amsl.com>; Wed, 4 May 2016 04:45:59 -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 CADC512D0BB for <dime@ietf.org>; Wed, 4 May 2016 04:45:58 -0700 (PDT)
Received: (qmail 9330 invoked from network); 4 May 2016 13:45:56 +0200
Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 13:45:56 +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: <A8821F45-B9BA-4ACF-8EBF-01B64C100359@fastmail.fm>
Date: Wed, 04 May 2016 13:45:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4F433FB-B2A2-4EDA-8ECF-5812BCB7517A@kuehlewind.net>
References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <A8821F45-B9BA-4ACF-8EBF-01B64C100359@fastmail.fm>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/CI2qVSJzgnn-TWBydTYsuh2E3fY>
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 11:46:02 -0000

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 (and especially not a very low priority). Further it has to be ensured that requests that don’t assign a priority do not get starved (as they might be important).

Mirja