Re: [Dime] Ben's comments on 4.3, third paragraph from end

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 21 January 2015 10:06 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 819441A19F0 for <dime@ietfa.amsl.com>; Wed, 21 Jan 2015 02:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 M00Xpt5Nmn6j for <dime@ietfa.amsl.com>; Wed, 21 Jan 2015 02:06:42 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E5F1A19EF for <dime@ietf.org>; Wed, 21 Jan 2015 02:06:42 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t0LA6eig014273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jan 2015 10:06:40 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0LA6bbZ010340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 11:06:39 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 21 Jan 2015 11:06:37 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 11:06:36 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, ext Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] Ben's comments on 4.3, third paragraph from end
Thread-Index: AdAwqcKKpO0LYTRKTfCB6qzRIWwNRQAEwOaAAARbWgAAJ7oO0ADaT2QAAB/pOMA=
Date: Wed, 21 Jan 2015 10:06:35 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523F884@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681523F07F@DEMUMBX014.nsn-intra.net> <54B7BD25.4040103@usdonovans.com> <5BC32AB7-6DA7-4B27-90E6-40203B3C35D2@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681523F249@DEMUMBX014.nsn-intra.net> <54BE9E0A.7040307@usdonovans.com>
In-Reply-To: <54BE9E0A.7040307@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 4886
X-purgate-ID: 151667::1421834800-000067C4-E333FFD1/0/0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/59F3ohnDTESXS3JXQOrw0yJX2tQ>
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end
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: Wed, 21 Jan 2015 10:06:46 -0000

Steve,
I'm not sure.
My understanding is:
1. Two answer messages (with same application id) sent by a reporting node while not in an overload condition can have different selected overload abatement algorithms in the OC-Feature-Vector AVP.
2. Two answer messages (with same application id) sent by a reporting node while in an (the same) overload condition must have the same selected overload abatement algorithm in the OC-Feature-Vector AVP if the two sets A and B are identical, where A is the intersection of the set of advertized algorithms received in the request that corresponds to the one answer message with the set of algorithms that are supported (at the time the one answer message is sent) by the reporting node, and B is the intersection of the set of advertized algorithms received in the request that corresponds to the other answer message with the set of algorithms that are supported (at the time the other answer message is sent) by the reporting node; And the set of algorithms supported by the reporting node must not change during an overload condition.

This ensures that reacting nodes, while not changing the set of advertized algorithms, will not receive a change of the selected algorithm during an overload condition (without the need for the reporting node to keep history data).

Ulrich


-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: Tuesday, January 20, 2015 7:27 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end

  I have removed the last sentence in the paragraph in question.  The 
before and after for the paragraph is as follows:

Before:

    Reporting nodes can change the overload abatement algorithm indicated
    in the OC-Feature-Vector AVP if the reporting node is not currently
    in an overload condition and sending overload reports.  The reporting
    node is not allowed to change the overload abatement algorithm while
    the reporting node is in an overload condition.

After:

    Reporting nodes can change the overload abatement algorithm indicated
    in the OC-Feature-Vector AVP if the reporting node is not currently
    in an overload condition and sending overload reports.

Ulrich,

I'm not sure I understand your point about the assignment of commonly 
supported algorithms.  Are you ok with this change?

Regards,

Steve
On 1/16/15 4:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ben
>
> The Note at the beginning of 5.1 is about change of announced capabilities in reacting nodes, while the text in 4.2 (and 5.2.1.4) is about change of selected algorithm by reporting nodes.
> I don't think the text in 4.2 (and 5.2.1.4) is totally wrong. Of course, if the reacting node changes the set of announced capabilities, the reporting node may change (or even need to  change) the selected algorithm. What is not allowed to be changed by the reporting node during an overload condition is the deterministic function that assignes to every set of commonly supported algorithms a distinct selected algorithm.
>
>
> Ulrich
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Thursday, January 15, 2015 4:19 PM
> To: Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end
>
> Sorry, that was 4.2.
>
>> On Jan 15, 2015, at 7:14 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>>
>> I agree with Ulrich, I don't see the issue.
>>
>>
>> On 1/15/15 3:58 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Ben wrote:
>>> -- 4.3, third paragraph from end:
>>>   
>>> This still assumes that reporting nodes cannot change algorithms during overload. I thought we agreed to remove that. (The normative text is also still there--see later comment.)
>>>   
>>> <Ulrich> I don't understand. In my copy of -06 the third paragraph from end in 4.3 reads:
>>>     Two types of overload abatement treatment are defined, diversion and
>>>     throttling.  Reacting nodes are responsible for determining which
>>>     treatment is appropriate for individual requests.
>>> How does this text assume that reporting nodes cannot change algorithms during overload?
>>>   
>>>   
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>>
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>