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

From: Steve Donovan <[email-masked]>
Date: Tue, 09 Dec 2014 07:44:31 -0600

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 9 Dec 2014 16:46:54 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:45 PM
To: [email-masked]
Subject: [Dime] Ulrich's suggested change @12

Ulrich,

Existing text:

Proposal: Add the note:

      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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 10 Dec 2014 06:41:00 -0600

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:
> 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:[email-masked]] *On Behalf Of *ext Steve 
> Donovan
> *Sent:* Tuesday, December 09, 2014 2:45 PM
> *To:* [email-masked]
> *Subject:* [Dime] Ulrich's suggested change @12
>
> Ulrich,
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Dec 2014 17:20:34 -0600

> On Dec 10, 2014, at 6:41 AM, Steve Donovan <[email-masked]> wrote:
> 
> 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.
> 

Those sentences seem contradictory, at least in town. Did you mean to say you do _not_ see the need for a change?

>> 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.
>>  
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 11 Dec 2014 13:31:01 +0000

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:[email-masked]]
Sent: Wednesday, December 10, 2014 1:41 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Ulrich's suggested change @12

Ulrich,

Steve

Steve,

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:45 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dime] Ulrich's suggested change @12

Ulrich,

Existing text:

Proposal: Add the note:

      time.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 07:54:54 -0600

Yes, I meant I do NOT see the need for a change.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 08:03:02 -0600

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.

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:[email-masked]]
> *Sent:* Wednesday, December 10, 2014 1:41 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
> *Subject:* Re: [Dime] Ulrich's suggested change @12
>
> Ulrich,
>
>     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.
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>     Steve Donovan
>     *To:* [email-masked] <mailto:[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Dec 2014 12:38:32 -0600

> On Dec 11, 2014, at 8:03 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ulrich,
> 
> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 indicates rate then there is ambiguity.  
> 
> 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. 

>> 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: Steve Donovan <[email-masked]>
Date: Tue, 16 Dec 2014 09:14:34 -0600

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2014 09:35:41 -0600

> On Dec 16, 2014, at 9:14 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ben,
> 
> 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?

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Dec 2014 09:17:25 +0000

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:[email-masked]] 
Sent: Tuesday, December 16, 2014 4:15 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Ulrich's suggested change @12

Ben,

I vote for number 3.

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 19 Dec 2014 18:08:52 +0000

Dear all,

In favor of 2),  unless 3) could be clarified, not clear to me neither.
Thanks
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: jueves, 18 de diciembre de 2014 10:17
To: ext Steve Donovan; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ulrich's suggested change @12

Steve, Ben,

I'm in favour of 2).

Ulrich

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

Ben,

I vote for number 3.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 22 Dec 2014 08:33:11 -0600

Number 3 is badly phrased.  It was supposed to be from the reporting 
node perspective.

Either way, I believe this issue is addressed by Ben's proposal in the 
DOIC WGLC: Changing Algorithms thread.

Regards,

Steve