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

Alexey Melnikov <aamelnikov@fastmail.fm> Wed, 04 May 2016 12:03 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 1ED7512D61A for <dime@ietfa.amsl.com>; Wed, 4 May 2016 05:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=K5tZNepY; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=F7R2oWMF
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 3Lv2lbSMLvn0 for <dime@ietfa.amsl.com>; Wed, 4 May 2016 05:03:30 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1167712D60E for <dime@ietf.org>; Wed, 4 May 2016 05:03:17 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 586A220D44 for <dime@ietf.org>; Wed, 4 May 2016 08:03:16 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute2.internal (MEProxy); Wed, 04 May 2016 08:03:16 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=/bbyS5Z9ZlsfXHUBRUpThZgrtfM=; b=K5tZNe pYy60EnFQNrzZpdvhsdZazQQVmZBQKkNRPfAoUtC6yrkt3RCg1FAkMGBFpRIhQT/ Nz+KvEnGx7BtpuFZuRkEm6R96UmHBOnQ8CB1Jn8r2Pq8PpWPefJVtz6QSZzpiy+C Fb81IRk1BBBYf9bzNwRJCcKPkpZA2x70kPRD4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/bbyS5Z9ZlsfXHU BRUpThZgrtfM=; b=F7R2oWMFZ11X7t0+QJ4qixbYH6TvC0S+dVdQb2AO1II/V3J PNMi4u72XQt0sAiV7uXHKujOqjtu3y6dpL/CYNzfb1h5fs1+gD+d78mm7c6lGD+H qzuMEbngO7ZXUezZOTnX+TOHoPd+Jv81dhSZEX/MrGhbc6D7iG8QHH/thX6s=
Received: by web5.nyi.internal (Postfix, from userid 99) id 224B4A71676; Wed, 4 May 2016 08:03:16 -0400 (EDT)
Message-Id: <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com>
X-Sasl-Enc: ZUFeYNxg/jGoIkxxtQL8WVqG7dhxBH3gr4NxuS4G0vEn 1462363396
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Mirja Kuehlewind <ietf@kuehlewind.net> (IETF)
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-2227b085
Date: Wed, 04 May 2016 13:03:16 +0100
In-Reply-To: <B4F433FB-B2A2-4EDA-8ECF-5812BCB7517A@kuehlewind.net>
References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <A8821F45-B9BA-4ACF-8EBF-01B64C100359@fastmail.fm> <B4F433FB-B2A2-4EDA-8ECF-5812BCB7517A@kuehlewind.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/rTBbMPWwgo-G7_Wzl7BqolPZ3go>
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?ime-drmp-05=3A_=28with_DISCUSS_and_COMMENT=29?=
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 12:03:36 -0000

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>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).