[Dime] Definition of host report

Steve Donovan <srdonovan@usdonovans.com> Mon, 07 April 2014 13:41 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 832821A0159 for <dime@ietfa.amsl.com>; Mon, 7 Apr 2014 06:41:02 -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 MSvSNb--NwZO for <dime@ietfa.amsl.com>; Mon, 7 Apr 2014 06:40:58 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id E21501A0411 for <dime@ietf.org>; Mon, 7 Apr 2014 06:40:56 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53048 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1WX9my-0007nS-UR for dime@ietf.org; Mon, 07 Apr 2014 06:40:50 -0700
Message-ID: <5342AAD9.9030803@usdonovans.com>
Date: Mon, 07 Apr 2014 14:40:41 +0100
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" <dime@ietf.org>
Content-Type: multipart/alternative; boundary="------------010100050102000701020908"
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: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4qtzOwcN-vcOeS0CJRRrBM4xrYM
Subject: [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: Mon, 07 Apr 2014 13:41:02 -0000

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