Re: [Dime] DOIC and terminology

Ben Campbell <ben@nostrum.com> Tue, 03 December 2013 21:35 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 B30C71AE11D for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 13:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 rQvCVB9gdbCw for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 13:35:23 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 606571ADFD9 for <dime@ietf.org>; Tue, 3 Dec 2013 13:35:23 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LZ7Cf038389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:35:09 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <82C71989-401F-4972-8878-7D2B1052CCA0@gmail.com>
Date: Tue, 3 Dec 2013 15:35:07 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <94F425B4-9027-4934-A20A-890691A6C562@nostrum.com>
References: <82C71989-401F-4972-8878-7D2B1052CCA0@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" <dime@ietf.org>
Subject: Re: [Dime] DOIC and terminology
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, 03 Dec 2013 21:35:24 -0000

IMHO, the term "server farm" is useful, but the term SFE is not. In fact, I suspect that people will read more into SFE than intended, and think it means something special, or that we are defining a new architectural element.

On Nov 28, 2013, at 3:51 AM, Jouni Korhonen <jouni.nospam@gmail.com>; wrote:

> Folks,
> 
> In the terminology there is an open issue:
> 
>          [OpenIssue: We used the concept of a server farm and SFE for
>          internal discussions. Do we still need those concepts to explain the
>          mechanism? It doesn't seem like we use them much.]
> 
> The terms server farm and SFE are mainly used within the terminology
> section itself. If we were to remove e.g. SFE only, then the following are
> also in the list for removal:
> 
>   Load Management:
> 
>      This functionality ensures that the consolidated load state for
>      the server farm is collected, and processed.  The exact algorithm
>      for computing the load at the SFE is implementation specific but
>      enough semantic of the conveyed load information needs to be
>      specified so that deterministic behavior can be ensured.
> 
>   Overload Management:
> 
>      The SFE is the entity that understands the consolidated overload
>      state for the server farm.  Just as it is outside the scope of
>      this document to specify how a Diameter server calculates its
>      overload state, it is also outside the scope of this document to
>      specify how an SFE calculates the overload state for the set of
>      servers.  This document describes how the SFE communicates
>      Overload information to Diameter Clients.
> 
>   Server Farm Identity Management:
> 
>      Server Farm Identity Management (SFIM) is a mechanism that can be
>      used by the SFE to present a single Diameter identity that can be
>      used by clients to send Diameter requests to the server farm.
>      This requires that the SFE modifies Origin-Host information in
>      answers coming from servers in the server farm.  An agent that
>      performs SFIM appears as a server from the client's perspective.
> 
> 
> There are also other impacts but those can be reworded with a minor effort.
> 
> 
> Opinions?
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime