Re: [Dime] Ulrich's suggested change @12

Steve, Ben,

I'm in favour of 2).
Actually I do not understand 3) as it talks about overload reports, while the issue is about capability anouncement.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: Tuesday, December 16, 2014 4:15 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change @12

Ben,

I see a two or three options here:

1) We add a new attribution AVP and all of the text associated with it.  
This has obvious schedule implications.

2) We treat this the same way as we treated the issue with multiple 
sources of OC-OLR AVPs and add text somewhere in the draft saying that 
if agents are selecting abatement algorithms then care must be taken to 
make sure that all agents that handle traffic for the same Diameter node 
must select the same algorithm for all transactions involving that 
Diameter node.

3) Number two plus reacting node behavior statements saying that the 
reacting node SHOULD ignore overload reports for a node that has an 
active OCS if the received overload report is of a different type then 
stored in the active OCS.

I vote for number 3.

Regards,

Steve

On 12/11/14, 12:38 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:03 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>>
>> Ulrich,
>>
>> I see your concern.  To summarize, if we have the following configuration:
>>
>>     ----A1----
>>    /          \
>>   C            S
>>    \          /
>>     ----A2----
>>
>> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 indicates rate then there is ambiguity.
>>
>> I agree, this warrants a warning statement somewhere in the document.
>>
>> If there is general agreement on this then I'll propose wording and location.
>>
> What sort of guidance should we give here? IMO, this is a worse problem than for realm reports, or at least having it for both realm and host reports makes it considerably worse than before. I think variations on this will happen for almost any Diameter network of non-trivial size.
>
> I also think it's reasonable that A1 and A2 might select different algorithms towards C. For example, lets say C, A1, and S all support rate, but A2 does not. S might select rate towards A1, but loss towards A2.
>
> If we can't handle this, I think the entire solution breaks down.
>
> I propose that the best way to handle this is to add source-attribution into OLRs, and guidance for what C should do if it gets different capabilities for the same host or realm from different paths. This _might_ also help solve the "different reports for same realm" problem and the "can't tell if an intervening agent supports DOIC" problem.
>
>
>> Steve
>>
>> On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>>   
>>> yes, it's about capability announcement, and my concern in with announcing the selected algorithm in answer messages (while no OLRs are sent). Multiple  agents modifying the selected algorithm in the Supported-Features AVPs in answer messages may  result in ambiguity in DOIC behaviour for downstream DOIC nodes.
>>>   
>>> Ulrich
>>>   
>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>>> Sent: Wednesday, December 10, 2014 1:41 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>>> Subject: Re: [Dime] Ulrich's suggested change @12
>>>   
>>> Ulrich,
>>>
>>> This paragraph is talking about capability announcement.  We deal with the issues related to multiple sources of overload reports already elsewhere in the document.
>>>
>>> I still do see the need for a change.
>>>
>>> Steve
>>>
>>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>> I agree, my comment and proposal do not hit the mark.
>>>   
>>> The intention was to say that known issues exist if there are multiple agents on multiple paths between client and server. The agents may not be able to ensure that there is no ambiguity in DOIC behaviour for the client. E.g. from the client's point of view the answer to a first request (which was modified by agent A1) could indicate: DOIC is supported, currenty no overload, once in overload loss will be selected; and the answer to the next request (which was modified by agent A2) could indicate: DOIC is supported, some?? reduction is requested using rate. The client, however, may not be prepared for rate.
>>>   
>>> Maybe a warning note could be added to say that the agent may not always be able to ensure that there is no ambiguity.
>>>   
>>> Ulrich
>>>   
>>>   
>>>   
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change @12
>>>   
>>> Ulrich,
>>>
>>> For your suggested change #12:
>>>
>>> Section 4.1.3, last paragraph:
>>> Existing text:
>>>     When making changes to the OC-Supported-Features AVP the Diameter
>>>     Agent needs to ensure that there is no ambiguity in DOIC behavior for
>>>     both upstream and downstream DOIC nodes.
>>>   
>>> Comment: while that is true, in addition problems similar to those
>>> identified in the note in section 3.3 may result from making changes.
>>>   
>>> Proposal: Add the note:
>>>        Note: Known issues exist if multiple sources for overload reports
>>>        which apply to the same Diameter entity exist.  Reacting nodes
>>>        have no way of determining the source and, as such, will treat
>>>        them as coming from a single source.  Variance in sequence numbers
>>>        between the two sources can then cause incorrect overload
>>>        abatement treatment to be applied for indeterminate periods of
>>>        time.
>>> I don't understand how these are related.  The change to the OC-Supported-Features AVP made by the agent apply only to the transaction.  In addition, this paragraph doesn't mention overload reports.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>
>>>
>>>   
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>