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

Alexey Melnikov <> Wed, 11 May 2016 10:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43BC512D984 for <>; Wed, 11 May 2016 03:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
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: (amavisd-new); dkim=pass (1024-bit key) header.b=PNjGzyAX; dkim=pass (1024-bit key) header.b=bKlMBYHP
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VZ0PW4mAY2AS for <>; Wed, 11 May 2016 03:51:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E66C12D664 for <>; Wed, 11 May 2016 03:51:41 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 1AE7520CA6 for <>; Wed, 11 May 2016 06:46:30 -0400 (EDT)
Received: from frontend2 ([]) by compute3.internal (MEProxy); Wed, 11 May 2016 06:46:30 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; 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=pMjHzWCbEhyVkAFTYWMiNilv6z0=; b=PNjGzy AXcBkWGWMSiaekptRj4WLZ/tyunBBR7a69tgSv1KBTvh3bYbciFYBk0nvujQgFwb PBN3dnWY464si01GNv6VYH5FRgJHIrQy2BbF5QmmdV1ySZceh9+cdqMIFGYJT49f sqBQM0P+3AJBAlF2cx/lYP3Gv7D8Mse+YMs40=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; 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=pMjHzWCbEhyVkAF TYWMiNilv6z0=; b=bKlMBYHPAYbfA+wn3NT5vjbJUetKe5DjBY+uI2IQzvnHWj0 ctJysog5U94exigGg+U+Ujk/HrozkLscxw23lGJjfAxbP6FHN6HeRFH1ya57ZO6g RSBwzh++RmOs1dsjU0napResyZiPaQRcN9dGx3iWBK+6dcw0MhLCSvlQvDus=
X-Sasl-enc: XPRs+k1qXT/Mme2Ld4DB3eNy5aF3tBKowqCpHBl0V4lP 1462963589
Received: from [] ( []) by (Postfix) with ESMTPA id BE468680219; Wed, 11 May 2016 06:46:29 -0400 (EDT)
Content-Type: text/plain; charset="windows-1251"
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <>
Date: Wed, 11 May 2016 06:52:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <10389_1462926852_57327E03_10389_3007_1_6B7134B31289DC4FAF731D844122B36E01E5F82F@OPEXCLILM43.corporate.adroot.infra.ftgroup> <>
To: "Mirja Kuehlewind (IETF)" <>
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 May 2016 10:51:52 -0000

Hi Mirja,

On 10 May 2016, at 22:47, Mirja Kuehlewind (IETF) <> wrote:

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

This can only happen where there is a flood of messages and when it does, this is by design. The whole point of this is that when a flood of messages happens, lower priority messages get less preferential treatment, as opposed to random messages (as it is now without this extension) getting less preferential treatment.

>> 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?

Because one would want consistent behaviour across the whole system. Which looks like a desired property.