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

ken carlberg <> Tue, 10 May 2016 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D085612D515; Tue, 10 May 2016 09:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ni-3bubhgKWP; Tue, 10 May 2016 09:10:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CCA812D513; Tue, 10 May 2016 09:10:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: Mime-Version:Content-Type:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0ZOgFqnQ33sS435XUGMu5ui3jn2CjThSBOHcgpFub6Q=; b=OWOfCU/BB3FyMbK7/ZyEB6p/Qa i3KeCLrttEOIJuL5gVWh2U2EwH534bm5vcx92JMrZR9HUOviBldVIM8MeKyfHQHiQ3USm7eXzcqFi Ypb+vK5RuzqAS8/xEDxk1POTMd2jzAgHFSlgZ7hH40nbXJpC02xpXu2xV+r+8mm9OWQA=;
Received: from [] (port=51696 helo=[]) by with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <>) id 1b0AEc-002PPy-GY; Tue, 10 May 2016 17:10:15 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_004FBBB6-49DF-4723-B787-4E4A0B84033B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: ken carlberg <>
In-Reply-To: <>
Date: Tue, 10 May 2016 12:10:08 -0400
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: "Mirja Kuehlewind (IETF)" <>
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Cc:, Alexey Melnikov <>,,, 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: Tue, 10 May 2016 16:10:24 -0000

Hi Mirja,

> On May 10, 2016, at 10:46 AM, 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.

I think your concern is quite valid, and my apologies if I missed something in the thread, but I think one thing that hasn’t been brought up is the notion of local policy and its separation from labels or priority values.  A number of years ago, the IETF community had some significant back and forth on the topic in the context of Emergency Telecommunications Service.  Specifically, in RFC-3689 we stated the following:

   3) Policy

      Policy MUST be kept separate from label(s).  This topic has
      generated a fair amount of debate, and so we provide additional
      guidance from the following:

      A set of labels may be defined as being related to each other.
      Characteristics (e.g., drop precedence) may also be attributed to
      these labels.  [11] is an example of a related set of labels based
      on a specific characteristic.

      However, the mechanisms used to achieve a stated characteristic
      MUST NOT be stated in the definition of a label.  Local policy
      determines mechanism(s) used to achieve or support a specific
      characteristic.  This allows for the possibility of different
      mechanisms to achieve the same stated characteristic.

      The interaction between unrelated labels MUST NOT be embedded
      within the definition of a label.  Local policy states the actions
      (if any) to be taken if unrelated labeled traffic merges at a

      Finally, labels may have additional characteristics added to them
      as a result of local policy.

Hence, the local policy associated with priority(s) *may* state that a weighted round robin in the servicing of queues *must* be used to ensure that no queue is ever starved.  Or, a more draconian position could be taken that does allow starvation.  It would be up to the operator/manager of the service to decide on the what is the local policy.  This is the way its been implemented and deployed in a few systems that I’m aware of that support prioritization.


(qualifier: just expressing my own personal opinion.  YMMV, consult doctor before use :-)