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

[Ben Campbell <[e-mail]>]

> On Dec 16, 2014, at 9:14 AM, Steve Donovan <[e-mail]> wrote:
> 
> 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.

Agreed that it has schedule implications. Schedule is important, but a workable solution is more important. (I concede that we have not yet established consensus that this is non-workable--see below)

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

On reflection, this is a more general problem than just algorithm choices. It's a generalization of the problem with multiple realm-report sources for a single realm. Basically we have a problem when you have more than one reporting node for a given overload scope. (The problem of multiple algorithms for the same "scope" would also apply to the multiple realm-report source issue.)

Basically, I think we've discovered the scope of the multiple reporting-node problem is considerably larger than we thought. That means we at least need to consider whether the decision to defer that solution is still reasonable. Remember that we made that decision at least partly because we thought the problem would not be that common.

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

Do you mean different OLR type, or different algorithm for the same OLR type?

> 
> 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 <[e-mail]> 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:[e-mail]]
>>>> Sent: Wednesday, December 10, 2014 1:41 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
>>>> 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:[e-mail]] On Behalf Of ext Steve Donovan
>>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>>> To: [e-mail]
>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>> 
>