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

On 1/21/15 4:06 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> 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.

SRD> Correct, one set of answer messages could indicate loss and the 
other rate (for instance).  This would happen if the reporting node 
policy prefers rate but there is a mix of reacting node capabilities.  
In this case where not all reacting nodes support the reporting nodes 
preferred algorithm, the reporting node could also decide to send loss 
to all reacting nodes.

> 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.

SRD> I'm a little lost in your description here.  It is possible for the 
reporting node be in an overload state and be sending loss reports to 
one set of reacting nodes and rate to a second set of reacting nodes.  
Whether or not the reporting node does this is entirely up to the 
implementation at the reporting node.

>
> 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).

SRD> The algorithm sent by the reporting node will be decided based on a 
combination of the advertised algorithms and policy at the reporting 
node.  If there is some change in policy at the reporting node that 
changes the selection then the reacting node needs to be prepared to 
handle the change.  I think you are suggesting we say this cannot happen 
during an active overload at the reporting node.  Is this correct?

SRD> As things stand now, with the changes made in -06 and the coming 
-07, the reacting node will need to be able to handle a change in 
algorithm during an active overload condition.  What is the benefit of 
changing this?  If the algorithm changes during an overload condition 
the reacting node can just treat it as an end of one overload condition 
and the start of another.
>
> 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
>>
>