IETF Logo Mail Archive

Re: [Dime] Diameter load control inputs

Steve Donovan <srdonovan@usdonovans.com> Tue, 20 January 2015 21:12 UTC

Return-Path: <srdonovan@usdonovans.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 89FCF1B2B7B for <dime@ietfa.amsl.com>; Tue, 20 Jan 2015 13:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level:
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no
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 W2pO6Mvzq9OU for <dime@ietfa.amsl.com>; Tue, 20 Jan 2015 13:12:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (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 720491B2B6C for <dime@ietf.org>; Tue, 20 Jan 2015 13:12:16 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60961 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1YDg5t-0006Xd-Rf for dime@ietf.org; Tue, 20 Jan 2015 13:12:15 -0800
Message-ID: <54BEC4AD.5030405@usdonovans.com>
Date: Tue, 20 Jan 2015 15:12:13 -0600
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: dime@ietf.org
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> <38472D36-663B-4222-B613-900A6EB160F5@nostrum.com>
In-Reply-To: <38472D36-663B-4222-B613-900A6EB160F5@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/SX0jYqqLvgtPR9pgICk-rJS-49k>
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:12:17 -0000

I also disagree with the suggestion that load for agents be separated 
out.  The reason agent overload was separated was to optimize work to 
get it done in time for release 12.  We have no such schedule constraint 
for load.

Steve

On 1/20/15 3:07 PM, Ben Campbell wrote:
>> 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
>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

v2.23.0 | Report a Bug | By Email