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

ken carlberg <carlberg@g11.org.uk> Tue, 10 May 2016 16:10 UTC

Return-Path: <carlberg@g11.org.uk>
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 D085612D515; Tue, 10 May 2016 09:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=g11.org.uk
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 Ni-3bubhgKWP; Tue, 10 May 2016 09:10:20 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=g11.org.uk; 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 [166.170.30.214] (port=51696 helo=[172.20.10.2]) by portland.eukhosting.net with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <carlberg@g11.org.uk>) 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 <carlberg@g11.org.uk>
In-Reply-To: <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net>
Date: Tue, 10 May 2016 12:10:08 -0400
Message-Id: <0AAC49EE-FEB8-4D94-996E-0FA4015E8C35@g11.org.uk>
References: <20160504111323.8242.20592.idtracker@ietfa.amsl.com> <A8821F45-B9BA-4ACF-8EBF-01B64C100359@fastmail.fm> <B4F433FB-B2A2-4EDA-8ECF-5812BCB7517A@kuehlewind.net> <1462363396.2794286.597809745.0662E7A7@webmail.messagingengine.com> <033661D5-7963-4726-81C0-854E25C659D3@kuehlewind.net> <e6d1ab6472f14ec3b4b6b024563150ff@CSRRDU1EXM025.corp.csra.com> <F0C35A63-ADCA-4502-AC3B-C2DF5FA6EDFD@kuehlewind.net> <1462451530.3147432.598960497.7062C294@webmail.messagingengine.com> <4B86AEB1-415C-4AE3-82F7-368C38B19560@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
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 - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Get-Message-Sender-Via: portland.eukhosting.net: authenticated_id: carlberg@g11.org.uk
X-Authenticated-Sender: portland.eukhosting.net: carlberg@g11.org.uk
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/6TIGP-MEOTHA6anw6w9LVAqRKf8>
Cc: draft-ietf-dime-drmp@ietf.org, Alexey Melnikov <aamelnikov@fastmail.fm>, 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: Tue, 10 May 2016 16:10:24 -0000

Hi Mirja,

> On May 10, 2016, at 10:46 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> 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
      node.

      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.

-ken

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