IETF Logo Mail Archive

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

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Mon, 05 May 2014 09:25 UTC

Return-Path: <ulrich.wiehe@nsn.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 398201A0045 for <dime@ietfa.amsl.com>; Mon, 5 May 2014 02:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 fu6przEayH_y for <dime@ietfa.amsl.com>; Mon, 5 May 2014 02:25:17 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBB01A0043 for <dime@ietf.org>; Mon, 5 May 2014 02:25:16 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s459PCal016665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 May 2014 09:25:12 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s459PC1f000795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 11:25:12 +0200
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 5 May 2014 11:25:11 +0200
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.33]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0181.006; Mon, 5 May 2014 11:25:11 +0200
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] DOIC: Proposed resolution to issue #35
Thread-Index: AQHPZgm+yrXT2l/wZk6F5wDpr1R4dpsxuVOA
Date: Mon, 05 May 2014 09:25:11 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151E42B1@DEMUMBX014.nsn-intra.net>
References: <53639C5B.1060902@usdonovans.com>
In-Reply-To: <53639C5B.1060902@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.117]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151E42B1DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 8370
X-purgate-ID: 151667::1399281912-00001564-09CE238E/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/q6RVvVCkJweG05oe9EmKxm20slU
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: Mon, 05 May 2014 09:25:20 -0000

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

v2.23.0 | Report a Bug | By Email