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

Alexey Melnikov <> Wed, 11 May 2016 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6849512D66A for <>; Wed, 11 May 2016 04:02:07 -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=iGyuVGs/; dkim=pass (1024-bit key) header.b=SkcZGPi9
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ADdlYCM7vrHA for <>; Wed, 11 May 2016 04:02:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B36C012D9A7 for <>; Wed, 11 May 2016 04:01:40 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A148B20BA5 for <>; Wed, 11 May 2016 06:54:18 -0400 (EDT)
Received: from frontend2 ([]) by compute1.internal (MEProxy); Wed, 11 May 2016 06:54:18 -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=+ByskY2yFz3qGlNgJcyhdHd9FV0=; b=iGyuVG s/sQvRU31TfexWV/O2ynlvN58tDrr8wXpMcfRSiPGDroOJ6zzuudUDdemUvyybWS JGMiUPHkTchcJt7DzOFJRqO/Q0IDsRryYT0BmUMn8DYJS7lo3j8pqQQgk4GpJjNZ OhxbAlHpo46d4G5MSav23TMSsTU7uNAF1lyCc=
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=+ByskY2yFz3qGlN gJcyhdHd9FV0=; b=SkcZGPi9dwhhtKNpzZ9tf6uHV90FTlnTzUN9BkBJ9I62oQb F/Br+CHAUHAoB/azIZW7qqdr8AlSUwcedEA0qoa3ej5eFm6a/Gx31HQxAAAn3Riu UcpAmdgOge+GhUVzT2XDg0rF3ba4JdU+RCrgauYy9OsmptLqi24wcYTrU0gw=
X-Sasl-enc: H4umvkd/uPQtV4tk2q4PIOdzI2oMhTpZFnCdvxXO8XsG 1462964058
Received: from [] ( []) by (Postfix) with ESMTPA id 4F81368021F; Wed, 11 May 2016 06:54:18 -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:59:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: "Mirja Kuehlewind (IETF)" <>
Archived-At: <>
Cc:,,, The IESG <>
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 11:02:07 -0000

Hi Mirja,

On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) <> 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.