Re: [Dime] DOIC: Proposed resolution to issue #35

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Tue, 06 May 2014 14:57 UTC

Return-Path: <maria.cruz.bartolome@ericsson.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 A76F11A035A for <dime@ietfa.amsl.com>; Tue, 6 May 2014 07:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 VMVjpXxWSadk for <dime@ietfa.amsl.com>; Tue, 6 May 2014 07:57:54 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 736441A008D for <dime@ietf.org>; Tue, 6 May 2014 07:57:54 -0700 (PDT)
X-AuditID: c1b4fb25-f798c6d000001521-cc-5368f86d99c2
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 69.5C.05409.D68F8635; Tue, 6 May 2014 16:57:50 +0200 (CEST)
Received: from ESESSMB101.ericsson.se ([169.254.1.79]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Tue, 6 May 2014 16:57:48 +0200
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, ext Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] DOIC: Proposed resolution to issue #35
Thread-Index: AQHPZgm+yrXT2l/wZk6F5wDpr1R4dpsxuVOAgAAwT4CAAWoaQIAAViig
Date: Tue, 06 May 2014 14:57:48 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097C7C22@ESESSMB101.ericsson.se>
References: <53639C5B.1060902@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151E42B1@DEMUMBX014.nsn-intra.net> <E5BF087E-468A-46A0-941F-051C541BE937@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151E4532@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151E4532@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW7ej4xgg3MNnBbzO0+zW8ztXcFm se7tCiYHZo8lS34yecza+YTF4+f6q+wBzFFcNimpOZllqUX6dglcGff+X2UpeCFd8W1jN2sD 4xSxLkZODgkBE4m7/zsYIWwxiQv31rN1MXJxCAkcZZQ4vW0/K4SziFFi+rI9zCBVbAJ2EpdO v2DqYuTgEBFIkvh+yRgkzCygLDF7xwN2EFtYwEri2J8ZTCC2iIC1xKe2l+wQtptE17nbYDaL gIrEp0knwUbyCvhK3Ju/EWrxO0aJJfsmsYHM5xQIkHhwgw2khhHouO+n1jBB7BKXuPVkPhPE 0QISS/acZ4awRSVePv7HCmErSSy6/RmqXkdiwe5PbBC2tsSyha+h9gpKnJz5hGUCo9gsJGNn IWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECY+rglt+qOxgvv3E8xCjA wajEw/vgVUawEGtiWXFl7iFGaQ4WJXHeL7d8goUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw JvQ86uQs7j4ctP9Modl309LS0A9RzuzMJhtMOKzuZ+9nsQ/p2vbr3vRN1w+YLa+LbIxN6WWd tydTRSwkPUf8J9fW6XP+Ttap3GVxh29usK/iw5jpnN/nqord3GFjmhGuoifYXr51toBxwIMu 47gq3/qO0wnap++eZ5OsuOGzsr+91SLVSUWJpTgj0VCLuag4EQAkdIwvigIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ixExvnVWXht6yMUKEwirBP6yezk
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35
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, 06 May 2014 14:57:56 -0000

Dear Ulrich,

Your proposal seems to be generic, i.e. any node, either client or agent, will be able to support "client-specific-throttling". Is this your intention?
If so, I was expecting something different according you your proposal:
> I have outlined a very simple approach:
> -          Reacting nodes indicate in request messages whether they are clients or agents.
> -          Reporting nodes do not do client specific reporting when the reacting node is an agent.

Could you clarify please?
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 06 de mayo de 2014 11:59
To: ext Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Ben,

I don't think we need to add an AVP that contains the diameter identity of the "targeted" reacting-node to the OC-OLR.

Please find proposed modifications attached.

Comments are welcome.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Monday, May 05, 2014 4:09 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

I think the issue needs non-trivial thought, and it wasn't one of our initial requirements. I'm okay if it gets into the base draft, but I'd hate to delay completion of the base draft over it.

Some examples of areas that need further thought: Have we thought through all the use cases for this? Why do we assume we never need "agent-specific" overload reports? Can we do this in a way that doesn't require different normative language for agents and clients when acting as reporting nodes?

My instinct is that the real answer to this is to add a (probably optional) AVP that contains the diameter identity of the "targeted" reacting-node. But we would need to think through use cases first.

On May 5, 2014, at 4:25 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Steve,
>  
> I still believe it is better to address the issue in the base spec rather than with an extension.
> I have outlined a very simple approach:
> -          Reacting nodes indicate in request messages whether they are clients or agents.
> -          Reporting nodes do not do client specific reporting when the reacting node is an agent.
>  
> Ulrich
>  
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Friday, May 02, 2014 3:24 PM
> To: dime@ietf.org
> Subject: [Dime] DOIC: Proposed resolution to issue #35
>  
> All,
> 
> I believe that we reached consensus on issue #35 (client specific overload reports) that this functionality should be deferred to a follow on extension.
> 
> To this end, I propose adding the following to appendix A:
> 
> A.4 Client specific overload reports
> 
> This specification assumes that a reporting node sends a single overload report to all reacting nodes.  This proposed extension would allow a reporting node to send different overload reports, with different reduction percentages (assuming the loss algorithm) to individual clients. 
> 
> If we have agreement on this text, I'll add it to the -03 version of the spec and close this issue.
> 
> Regards,
> 
> Steve
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime