Re: [Dime] Definition of host report

Steve Donovan <srdonovan@usdonovans.com> Tue, 08 April 2014 15:34 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 2515B1A03C1 for <dime@ietfa.amsl.com>; Tue, 8 Apr 2014 08:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 VkAx9TJZklpM for <dime@ietfa.amsl.com>; Tue, 8 Apr 2014 08:34:32 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 207301A01C9 for <dime@ietf.org>; Tue, 8 Apr 2014 08:34:32 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60367 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1WXY2b-0005eX-MO; Tue, 08 Apr 2014 08:34:30 -0700
Message-ID: <53441701.1070502@usdonovans.com>
Date: Tue, 08 Apr 2014 10:34:25 -0500
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, "dime@ietf.org" <dime@ietf.org>
References: <5342AAD9.9030803@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------000003040109010708070001"
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 - 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: srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K3uHXmogM3AGOALzEjFnJ5HFLLc
Subject: Re: [Dime] Definition of host report
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, 08 Apr 2014 15:34:34 -0000

Ulrich,

Please see inline.

Steve

On 4/8/14 2:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> I tend to agree.
>
> However, wouldn't this mean that also the current definition of realm
> report (which actually is RRR) needs to be enhanced?
>
>  
>
> e.g. replace
>
> The Destination-Host AVP is absent in the request.
>
>  
>
> with something like
>
> "The reacting node does not know to which Diameter Host the request
> will be routed." 
>
SRD> How about "The reacting node does not know to which Diameter Host
within the Realm the request will be routed."
>
>  
>
> I was also wondering if there may be cases where
>
> a) the reacting node selects the host, detects that it has a direct
> connection to that host and therefore does not include the
> Destination-Host AVP in the request. The selected host, however, when
> receiving the Destination-Host-less request decides to forward the
> request to another host. Or
>
SRD> Why would the receiving host decide to forward the request?  If it
does, it's either an agent or there is some new application layer
behavior that the reacting node can't predict.
>
> b) the reacting node does not select a host and therefore does not
> include a Destination-Host AVP, but sends the request to the next hop,
> which happens to be a Host that decides to handle the request.
>
SRD> But the reacting node will know if the next hop matches an active
overload report based on the ID of the host on the other end of the
connection used.  This is the case I'm addressing with my proposal. 
>
>  
>
>  
>
> Are those cases valid and covered?
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, April 07, 2014 3:41 PM
> *To:* dime@ietf.org
> *Subject:* [Dime] Definition of host report
>
>  
>
> All,
>
> I believe that the current definition of the host report needs to be
> enhanced.
>
> The following is what is currently in the -02 draft:
>
>    0  A host report.  The overload treatment should apply to requests
>       for which all of the following conditions are true:
>  
>       The Destination-Host AVP is present in the request and its value
>       matches the value of the Origin-Host AVP of the received message
>       that contained the OC-OLR AVP.
>  
>       The value of the Destination-Realm AVP in the request matches the
>       value of the Origin-Realm AVP of the received message that
>       contained the OC-OLR AVP.
>  
>       The value of the Application-ID in the Diameter Header of the
>       request matches the value of the Application-ID of the Diameter
>       Header of the received message that contained the OC-OLR AVP.
>
>
> The second paragraph says that only requests that contain a
> Destination-Host AVP can be used for overload treatment.
>
> This does not address the case where there is no agent between the
> reacting and reporting nodes.  In other words, the reacting node has a
> direct connection to the reporting node.  In this case the reacting
> node should include all messages that would be sent to the reporting
> node, including those that do not contain a Destination-Host AVP and
> those that the reacting node would sent to the reporting node through
> normal route selection for requests that do not contain a
> Destination-Host AVP.
>
> I propose that the second paragraph be changed to the following:
>
> "The reacting node knows that the request will be routed to the
> overloaded Diameter node identified by the Diameter ID in the OLR. 
> This is the value of the Origin-Host AVP in the message that carried
> the OLR.  There are two cases where the reacting node will know that
> the request will be routed to the overloaded node.  The first is the
> request contains a Destination-Host AVP that matches the Diameter ID
> contained in the OLR.  The second is when the reacting node selects a
> route that is a direct connection to the overloaded Diameter node."
>
> Regards,
>
> Steve
>