Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Steve Donovan <srdonovan@usdonovans.com> Mon, 24 March 2014 12:21 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 C079C1A01EC for <dime@ietfa.amsl.com>; Mon, 24 Mar 2014 05:21:40 -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 ikxcUfjzFKbu for <dime@ietfa.amsl.com>; Mon, 24 Mar 2014 05:21:38 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 806E11A01E9 for <dime@ietf.org>; Mon, 24 Mar 2014 05:21:38 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54345 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1WS3sh-0004Mf-5n; Mon, 24 Mar 2014 05:21:35 -0700
Message-ID: <5330234A.5080907@usdonovans.com>
Date: Mon, 24 Mar 2014 07:21:30 -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: Dave Dolson <ddolson@sandvine.com>, "'dime@ietf.org'" <dime@ietf.org>
References: <E8355113905631478EFF04F5AA706E9818AD87AF@wtl-exchp-1.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E9818AD87AF@wtl-exchp-1.sandvine.com>
Content-Type: multipart/alternative; boundary="------------000705010703040305040202"
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/QIf3fka8lhxiOHzlAlQqAxCgvxc
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 24 Mar 2014 12:21:41 -0000

Dave,

You are correct, we need to have wording on the interaction between the
report types, thus the last paragraph in my proposal.

This will likely be shown as an open issue in the -02 version of the
draft, unless we come to consensus on wording between now and Thursday. 

Steve

On 3/22/14 6:43 AM, Dave Dolson wrote:
> It is difficult to judge this issue without knowing how the reported
> values are to be resolved when contradictory.
>
> To send a request with both realm and host name, and having reported
> realm and host percentages, what should be done?
>
> Does the client have to keep track of how much it has sent to each
> host, and also the realm as a whole?
>
> This needs to be part of the spec, not left to vendor-specific
> implementation, because the overloaded realm/node needs a model of how
> the client will react.
>
>
> The approach of having feedback for realm-only messages made it easier
> to understand what the client should do.
>
> -Dave
>
>
>  
> *From*: Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent*: Friday, March 21, 2014 05:05 PM
> *To*: dime@ietf.org <dime@ietf.org>
> *Subject*: Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>  
> Ulrich,
>
> The discussion should be captured in the minutes to the meeting.  I
> wasn't able to find them posted yet.
>
> Jouni, Lionel, what is the status of the minutes for the meeting?
>
> My reading of emails prior to the London meeting is different from
> yours.  I believe we had come to the conclusion that we needed host
> and realm (with the definition of realm as outlined below).  We were
> still discussing the need for Realm-Routed-Request reports.
>
> Regards,
>
> Steve
>
> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>
>> Steve,
>>
>>  
>>
>> I don’t know what happend in London.
>>
>> Can you please summarize the technical reasons that led to the London
>> agreement.
>>
>> E-mail discussions prior to London have clearly directed towards a
>> report type that requests throttling of realm routed request messages
>> (i.e. not containing a destination host) rather than a report type
>> that requests throttling of messages routed towards a realm (no
>> matter whether they contain a destination host or not).   
>>
>>  
>>
>> Ulrich
>>
>>  
>>
>> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
>> Donovan
>> *Sent:* Friday, March 21, 2014 3:33 PM
>> *To:* dime@ietf.org
>> *Subject:* [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>  
>>
>> All,
>>
>> Ben and I took the action item to discuss the need for the
>> Realm-Routed-Reports (RRR) report type.
>>
>> As you may recall, the consensus coming out of the DIME WG meeting in
>> London was to support two report types:
>>
>> - Host -- Impacting requests with a Destination-Host AVP matching the
>> host in the overload report (with the host implicitly determined from
>> the Origin-Host AVP of the answer message carrying the overload report).
>>
>> - Realm -- Impacting 100% of the requests with a Destination-Realm
>> AVP matching the realm in the overload report (with the realm
>> implicitly determine from the Origin-Realm of the answer message
>> carrying the overload report).
>>
>> The action Ben and I took was to come back with an opinion on whether
>> RRR reports should also be supported.
>>
>> My summary of the discussion is that we recommend to NOT include RRR
>> reports in the current version of the base DOIC draft. 
>>
>> We still have some concerns with the granularity of control enabled
>> by having just the two report types but the analysis of whether RRR
>> reports are still needed can occur independent of the base DOIC
>> draft.  If there is a determination that RRRs are needed in time to
>> include in the base draft then it can be considered at that time.
>>
>> Based on this, I propose the following
>>
>> - Resolution to issue #23 is to remove RRR reports from the document.
>> - Resolution to issue #55 is to add Realm reports (actually to
>> redefine them per the above definition).
>> - Resolution to issue #57 is that it no longer applies (as it deals
>> with RRRs).
>>
>> There is also need for text describing the interaction between host
>> and the realm reports.  I don't expect we will have consensus on this
>> wording prior to the -02 draft being submitted.  To this end, I'll
>> open a new issue to deal with the need for wording on the interaction.
>>
>> Regards,
>>
>> Steve
>>
>