Re: [Dime] Diameter load control inputs

Ben Campbell <ben@nostrum.com> Tue, 20 January 2015 21:07 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E9B1B2AE8 for <dime@ietfa.amsl.com>; Tue, 20 Jan 2015 13:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 3rc-LejZBOBz for <dime@ietfa.amsl.com>; Tue, 20 Jan 2015 13:07:18 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EB7B41B2ACC for <dime@ietf.org>; Tue, 20 Jan 2015 13:07:17 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0KL7Eox040617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2015 15:07:15 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681523EF2A@DEMUMBX014.nsn-intra.net>
Date: Tue, 20 Jan 2015 15:07:14 -0600
X-Mao-Original-Outgoing-Id: 443480834.398066-93b47e1c93e33f6ef4a1ca54aef3b55b
Content-Transfer-Encoding: quoted-printable
Message-Id: <38472D36-663B-4222-B613-900A6EB160F5@nostrum.com>
References: <E194C2E18676714DACA9C3A2516265D2026F4908@FR712WXCHMBA12.zeu.alcatel-lucent.com> <F1863D26-9049-4A38-9416-39C9E2DE0ECC@nostrum.com> <E194C2E18676714DACA9C3A2516265D2026F4F76@FR712WXCHMBA12.zeu.alcatel-lucent.com> <5BCBA1FC2B7F0B4C9D935572D90006681523EF2A@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/ADYHb0QGiUbX0YhdnNwHeUQ23zc>
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Diameter load control inputs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 20 Jan 2015 21:07:20 -0000

> On Jan 14, 2015, at 4:38 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
> 
> Hi Jean-Jacques,
>  
> I would like to limit Diameter load control to server  (host) load and realm load in a first step and leave agent load for a second step.
> We nearly have completed Diameter Overload control which is limited to server (host) overload and realm overload, while the agent overload draft  is not complete.
>  
> Once Agent Overload control is stable we may consider extending it with agent load control.

I don't agree. The purpose of load information is very different than that of overload. My initial instinct (which may change as we delve deeper) is the simplest way to handle "load" is on a peer-to-peer basis, and that the load info sent by a node is only used by immediate peers of the node. This model does not require differentiation between agents and servers.

This does not fully handle all of JJacque's cases, where for example the client's choice of agent effects the available servers. But nothing prevents an agent from considering, and possibly aggregating, load info from upstream peers into the load value it sends downstream for itself. But I'm not sure that sort of behavior requires standardization on our part.


>  
> Best regards
> Ulrich
>