Re: [Dime] Issue#35 conclusion

Steve Donovan <srdonovan@usdonovans.com> Fri, 21 February 2014 15:53 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 662A71A031C for <dime@ietfa.amsl.com>; Fri, 21 Feb 2014 07:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6cJOnXQa87am for <dime@ietfa.amsl.com>; Fri, 21 Feb 2014 07:53:06 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id BC5FC1A01BE for <dime@ietf.org>; Fri, 21 Feb 2014 07:53:06 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54947 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1WGsPJ-0001FD-RT for dime@ietf.org; Fri, 21 Feb 2014 07:53:02 -0800
Message-ID: <53077659.1030909@usdonovans.com>
Date: Fri, 21 Feb 2014 09:52:57 -0600
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.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------040000060801090100000403"
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/n_mqVnmQeQ0jtdaFnZAZFFmrr9c
Subject: Re: [Dime] Issue#35 conclusion
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: Fri, 21 Feb 2014 15:53:08 -0000

Ulrich,

I have a couple of concerns with this approach, as currently outlined. 

First, how do we handle the case where there are multiple DOIC
supporting agents between the non supporting client and the reporting
node.  This, I guess, is a general question, not just applying to this
proposal.  I suggest we capture in the agent behavior section that is
currently missing wording indicating that the first supporting agent
that receives the request must be the reacting node for that
non-supporting client.  Subsequent DOIC supporting agents must not be
the reacting node for the non-supporting client.

We need to think through the ramifications of having multiple agents
being the reacting node for the same non supporting clients, as this
could easily happen in networks where multiple agents are involved in a
single transaction.  On the surface it doesn't seem to be an issue for
the loss algorithm, but this might not be the case with other algorithms.

My other concern is that this puts a lot of extra onus on the agent even
for the case where the reporting node does not want to differentiate
overload reports.  To this end I suggest we add an indication in the OLR
marking the reports that are specific to just the Origin-Host in the
request.  Absence of the "single-client-only" AVP would mean that the
report applies to all clients.  Presence of the AVP would indicate that
the OLR applies to the Origin-Host.

Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ben,
>
> the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
> Now you seem to address two points:
> a) There is no dependency to DOIC support of the client.
> To address this I would like to propose rewording of the clarifying text for 5.5. as follows:
>
> When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 
>
> This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.
>
> b) There is no binding of the OLR to the orig-host of the client
> Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
> 1. ignore the 3GPP requirement
> 2. introduce new report types as originally proposed in #35
> 3. introduce the binding between OLR and orig-host of the client.
>
> So far I understood that people favoured option 3.
>
> See also inline.
>
> Ulrich
>
>
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com] 
> Sent: Thursday, February 20, 2014 11:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] Issue#35 conclusion
>
>
> On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
>
>> #35: additional report types are proposed
>>  
>> Dear all,
>>  
>> I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>>  
>> When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.
> I do not agree.
>
> You proposal implies that the server's OLR only applies to that client.
> <Ulrich>exactly, that was the intention</Ulrich>
>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
> <Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>
>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
> <Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>
>
>  Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>