Subject: Re: [Dime] DOIC issue #58 Proposal

From: <[email-masked]>
Date: Fri, 1 Aug 2014 10:58:24 +0000

Hi Steve,

I agree with Nirav's view.

Regards,

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

---- Nirav Salot (nsalot) a écrit ----

Steve,

For this issue, I don’t agree to include identity of the DOIC node that sends the report, into the realm reports.

In my view, the issue mentioned below – of two agents not 100% synchronize w.r.t the realm-report – is the related to "how agents synchronized between themselves" and since that is not standardized we should not be developing protocol solution for the case which occurs due to this out-of-standards solution.

Besides, I don’t see any issue due to slight miss-synchronization of the realm-reports between two agents since they should still represent the realm load more or less accurately.

Also if the agents are not synchronized and if they are playing the role of DOIC reacting node then they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the same.

Finally, I don’t see any value-add of using the "identity of the node that sends the realm-report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as well, i.e. when the overload-report of an realm is active, the client is going to ignore all the reports of the same realm which has lower sequence number value. So in essence, when two agents are sending realm-reports, one of the reports is automatically ignored by the client if their sequence numbers differ. So the outcome without including the "identity if the node that sends realm report" is same as
>The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report.

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: [email-masked]
Subject: [Dime] DOIC issue #58 Proposal

All,

Issue #58 deals with the fact that there can be multiple senders of realm overload report for the same realm.

Ulrich proposes one aspect of what is required in the issue description:

"In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01<http://tools.ietf.org/html/draft-donovan-dime-agent-overload-01>). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the DOIC node that sends the report.  This would be an optional AVP only required for realm reports.  It would not be required for host reports as the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to determine if a received report is ignored or used to update existing state.  To this end I propose that we add wording that for the duration of a realm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the realm report that resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report.

Steve

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Dave Dolson <[email-masked]>
Date: Fri, 1 Aug 2014 14:49:46 +0000

I believe Nirav's view requires all hosts in a realm to be the same vendor and use a proprietary communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agents are generating the report, they must similarly be synchronized.

Is seems like including the host name per Ulrich's suggestion is a simple way of avoiding proprietary mechanisms or coupling between hosts and agents.
In some applications, the hosts can be completely decoupled (agnostic about each other). I think it would be poor to add a synchronization requirement just to support DOIC.

-Dave

From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 01, 2014 6:58 AM
To: Steve Donovan; [email-masked]; Nirav Salot (nsalot)
Subject: Re: [Dime] DOIC issue #58 Proposal

Hi Steve,

Regards,

Lionel

---- Nirav Salot (nsalot) a écrit ----

Steve,

For this issue, I don't agree to include identity of the DOIC node that sends the report, into the realm reports.

In my view, the issue mentioned below - of two agents not 100% synchronize w.r.t the realm-report - is the related to "how agents synchronized between themselves" and since that is not standardized we should not be developing protocol solution for the case which occurs due to this out-of-standards solution.

Besides, I don't see any issue due to slight miss-synchronization of the realm-reports between two agents since they should still represent the realm load more or less accurately.

Finally, I don't see any value-add of using the "identity of the node that sends the realm-report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as well, i.e. when the overload-report of an realm is active, the client is going to ignore all the reports of the same realm which has lower sequence number value. So in essence, when two agents are sending realm-reports, one of the reports is automatically ignored by the client if their sequence numbers differ. So the outcome without including the "identity if the node that sends realm report" is same as

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dime] DOIC issue #58 Proposal

All,

Steve

Thank you.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Aug 2014 09:54:58 -0500

+1 (modulo my comment to generalize)

On Aug 1, 2014, at 9:49 AM, Dave Dolson <[email-masked]> wrote:

> I believe Nirav’s view requires all hosts in a realm to be the same vendor and use a proprietary communication protocol to synchronize the host report. Or, if a multiple (redundant or active-active) load-balancing agents are generating the report, they must similarly be synchronized.
>  
> Is seems like including the host name per Ulrich’s suggestion is a simple way of avoiding proprietary mechanisms or coupling between hosts and agents.
> "In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness. "
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 15:58:21 +0000

Hi Dave,

The whole purpose of "Realm" report is to provide a consolidated view of the overload status of all the servers in the realm.
If you are not able to provide such consolidated view for the entire realm, you will not be able to send OLR with the type "Realm".
The synchronization between nodes might not be required but it is required that all the agents providing Realm-based OLR have the means to provide a "common" view, whatever the mechanism used for that.

Lionel

De : Dave Dolson [mailto:[email-masked]]
Envoyé : vendredi 1 août 2014 16:50
À : MORAND Lionel IMT/OLN; Steve Donovan; [email-masked]; Nirav Salot (nsalot)
Objet : RE: [Dime] DOIC issue #58 Proposal

-Dave

Hi Steve,

Regards,

Lionel

---- Nirav Salot (nsalot) a écrit ----

Steve,

Regards,
Nirav.

All,

Steve

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 11:09:30 -0500

Somewhat on on the path toward generalization, we have a second issue 
currently open that can be solved by having the DOIC node that inserts 
an overload report in an answer message include it's own diameter 
identity in the overload report.

I'm referring to issue #66 - Non-Supporting Agent Changing an Origin-Host.

This issue points out that existing non DOIC agents are able to change 
the origin-host in answer messages.  One example of where this is done 
is in topology hiding implementations.

This issue can be addressed through attribution of overload reports.

As such, I propose that we add a required AVP to the OC-OLR group AVP 
that carries the diameter identity of the DOIC node that inserted the 
overload report into the answer message.  Issue #66 points out the need 
in host reports and issue #58 points out the need in realm reports.

Steve

On 8/1/14, 9:54 AM, Ben Campbell wrote:
>> "In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness."
>>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Fri, 1 Aug 2014 16:12:53 +0000

Hi Dave,

On top of what Lionel mentioned, if you look at issue #58, we are already assuming that agents providing report for the same realm are almost synchronized.
> Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ.
The issue we are solving is when there is slight miss-synchronization between those agents - for whatever reason - how does the client handle it.
> To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR.

And that's where we are proposing to use "identity of agent providing realm report". The client receives same report with two different identities (from two different agents) and discard one of them.
> Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness.
My main point was that, the same logic - of discarding report from one of the agent - can be achieved by using sequence number, which is already provided as part of overload report.
So in summary, there is no value in adding "Diameter identity of the agent providing realm-report" for issue #58.

Just to clarify, I am not assuming same vendor providing the agents. And, I guess, that is not relevant to issue #58.

Regards,
Nirav.

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 01, 2014 9:28 PM
To: Dave Dolson; Steve Donovan; [email-masked]; Nirav Salot (nsalot)
Subject: RE: [Dime] DOIC issue #58 Proposal

Hi Dave,

Lionel

De : Dave Dolson [mailto:[email-masked]]
Envoyé : vendredi 1 août 2014 16:50
À : MORAND Lionel IMT/OLN; Steve Donovan; [email-masked]<mailto:[email-masked]>; Nirav Salot (nsalot)
Objet : RE: [Dime] DOIC issue #58 Proposal

-Dave

From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, August 01, 2014 6:58 AM
To: Steve Donovan; [email-masked]<mailto:[email-masked]>; Nirav Salot (nsalot)
Subject: Re: [Dime] DOIC issue #58 Proposal

Hi Steve,

Regards,

Lionel

---- Nirav Salot (nsalot) a écrit ----

Steve,

Regards,
Nirav.

All,

Steve

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 16:16:26 +0000

Hi Steve,

Not sure to understand. If an agent inserts its identity as Origin-host in answers forwarded from servers, the client will see the agent as the server.
What will be the added-value to add the identity of the server inserting the OLR if the client will store this information along the agent id?
Sorry if I've missed something...

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : vendredi 1 août 2014 18:10
Cc : [email-masked]
Objet : [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 12:48:57 -0500

Lionel,

The issue is that there could be multiple/many servers behind the agent 
that is changing the Origin-Host.  If one of them is overloaded and 
generates a host report, clients will apply overload abatement to all 
requests sent through that agent.  The end result would be that the non 
overloaded servers are under utilized.

Steve

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 18:09:25 +0000

Hi Steve,

So the topology hiding is not a relevant example here. Even with an identity inserted in the OLR, the client will never know to which server the request is sent because the only relevant info for the client is the Origin-host received in the answer i.e. the id of the agent.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : vendredi 1 août 2014 19:49
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Lionel,

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Fri, 1 Aug 2014 18:10:31 +0000

Steve,

Can you explain how the inclusion of agent's identity in the host report solves the issue you have mentioned below?

When the client (i.e. reacting node) receives overload report, it associates that with the Origin-Host present in the answer message.
And if I remember correctly, we have had long discussion to arrive at this handling. So I am not sure what would change when you add agent's identity in the host report.

Regards,
Nirav. 

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 11:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Lionel,

The issue is that there could be multiple/many servers behind the agent that is changing the Origin-Host.  If one of them is overloaded and generates a host report, clients will apply overload abatement to all requests sent through that agent.  The end result would be that the non overloaded servers are under utilized.

Steve

On 8/1/14, 11:16 AM, [email-masked] wrote:
> Envoyé : vendredi 1 août 2014 18:10 Cc : [email-masked] Objet : [Dime] 
> Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)
>
> overload report into the answer message.  Issue #66 points out the 
> need in host reports and issue #58 points out the need in realm reports.
>
> Steve
>
>
>>> Finally, I don't see any value-add of using the "identity of the 
>>> node that sends the realm-report" to discard the other report 
>>> related to the same realm. In other words, this same logic can be 
>>> achieved using sequence-numbers as well, i.e. when the 
>>> overload-report of an realm is active, the client is going to ignore 
>>> all the reports of the same realm which has lower sequence number 
>>> value. So in essence, when two agents are sending realm-reports, one 
>>> of the reports is automatically ignored by the client if their 
>>> sequence numbers differ. So the outcome without including the 
>>> "identity if the node that sends realm report" is same as
>>> ____________________________________________________________________
>>> _____________________________________________________
>>>    
>>> Ce message et ses pieces jointes peuvent contenir des informations 
>>> confidentielles ou privilegiees et ne doivent donc pas etre 
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>    
>>> This message and its attachments may contain confidential or 
>>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 13:28:18 -0500

Nirav,

It would not be the agents identity in this case, it would be the 
identity of the server.  This is to fix the fact that the agent is 
putting it's own identity in the origin-host AVP.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 13:29:48 -0500

Lionel,

The agent would not be inserting it's identity in the overload report.  
The proposal is that the DOIC node that inserted the overload report 
includes its diameter identity in the overload report.  As such, it 
would be the server's identity that is in the overload report.

Sorry if I wasn't clear.

Steve

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 18:45:10 +0000

I understood! But what will be the use of this info by the client? As for the client, the server is the identity of the Origin-host of the received answer.

Lionel

---- Steve Donovan a écrit ----

Lionel,

Sorry if I wasn't clear.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 13:47:07 -0500

The question becomes, what happens if the nodes that are sending the 
realm reports lose the ability to stay in synchronization.  We all know 
that communication can be lost between entities.  This is what leads to 
complicated, multiple stage protocols for things like database 
synchronization.

So, lets assume that we mandate that DOIC nodes that send realm reports 
(let's call them realm report generators) MUST be in sync and that 
includes both the sequence number and any abatement algorithm data 
(percentage reduction for the loss algorithm).

A side note -- let's stop assuming that the realm report generator is an 
agent.  There is nothing saying that agents are the only thing that can 
send realm reports.  It is perfectly valid for servers to send realm 
report if they have visibility to the state of the realm as a whole.

Now, assume that the realm report generators lose the ability to 
communicate due to some localized failure.  The realm is known to be 
overloaded so realm reports need to be sent.  Assume also that one of 
the realm report generators thinks a 10% reduction is needed and a 
second thinks a 50% reduction is needed.

A client is going to see both reports types.  The realm report 
generators are going to refresh the reports, sending new reports with 
higher sequence numbers.  The client will honor all reports that have a 
bigger sequence number.

One effect can be a thrashing between 10% reduction and 50% reduction.

This is clearly an edge case.  It is, however, an edge case that is 
easily avoidable by attributing the source of the realm report.

Steve

On 8/1/14, 11:12 AM, Nirav Salot (nsalot) wrote:
>
> Hi Dave,
>
> On top of what Lionel mentioned, if you look at issue #58, we are 
> already assuming that agents providing report for the same realm are 
> almost synchronized.
>
> > Although it is expected that the different reporting nodes report 
> more or less the same content, it cannot be expected that reports are 
> 100% synchronized. Especially sequence numbers may differ.
>
> The issue we are solving is when there is slight miss-synchronization 
> between those agents -- for whatever reason -- how does the client 
> handle it.
>
> > To allow reacting nodes correctly detect outdates/replays/freshness 
> of OLRs in this scenario, it is proposed that realm-routed-request 
> type OLRs are extended to contain the Diameter Identity of the 
> reporting node that inserted the realm-routed-request type OLR.
>
> And that's where we are proposing to use "identity of agent providing 
> realm report". The client receives same report with two different 
> identities (from two different agents) and discard one of them.
>
> > Reacting nodes MUST take the Diameter Identity received within the 
> OLR into account in order to detect outdates/replays/freshness.
>
> My main point was that, the same logic -- of discarding report from 
> one of the agent -- can be achieved by using sequence number, which is 
> already provided as part of overload report.
>
> So in summary, there is no value in adding "Diameter identity of the 
> agent providing realm-report" for issue #58.
>
> Just to clarify, I am not assuming same vendor providing the agents. 
> And, I guess, that is not relevant to issue #58.
>
> Regards,
>
> Nirav.
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Friday, August 01, 2014 9:28 PM
> *To:* Dave Dolson; Steve Donovan; [email-masked]; Nirav Salot (nsalot)
> *Subject:* RE: [Dime] DOIC issue #58 Proposal
>
> Hi Dave,
>
> The whole purpose of "Realm" report is to provide a consolidated view 
> of the overload status of all the servers in the realm.
>
> If you are not able to provide such consolidated view for the entire 
> realm, you will not be able to send OLR with the type "Realm".
>
> The synchronization between nodes might not be required but it is 
> required that all the agents providing Realm-based OLR have the means 
> to provide a "common" view, whatever the mechanism used for that.
>
> Lionel
>
> *De :*Dave Dolson [mailto:[email-masked]]
> *Envoyé :* vendredi 1 août 2014 16:50
> *À :* MORAND Lionel IMT/OLN; Steve Donovan; [email-masked] 
> <mailto:[email-masked]>; Nirav Salot (nsalot)
> *Objet :* RE: [Dime] DOIC issue #58 Proposal
>
> I believe Nirav's view requires all hosts in a realm to be the same 
> vendor and use a proprietary communication protocol to synchronize the 
> host report. Or, if a multiple (redundant or active-active) 
> load-balancing agents are generating the report, they must similarly 
> be synchronized.
>
> Is seems like including the host name per Ulrich's suggestion is a 
> simple way of avoiding proprietary mechanisms or coupling between 
> hosts and agents.
>
> In some applications, the hosts can be completely decoupled (agnostic 
> about each other). I think it would be poor to add a synchronization 
> requirement just to support DOIC.
>
> -Dave
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> *Sent:* Friday, August 01, 2014 6:58 AM
> *To:* Steve Donovan; [email-masked] <mailto:[email-masked]>; Nirav Salot 
> (nsalot)
> *Subject:* Re: [Dime] DOIC issue #58 Proposal
>
> Hi Steve,
>   
> For this issue, I don't agree to include identity of the DOIC node 
> that sends the report, into the realm reports.
>
> In my view, the issue mentioned below -- of two agents not 100% 
> synchronize w.r.t the realm-report -- is the related to "how agents 
> synchronized between themselves" and since that is not standardized we 
> should not be developing protocol solution for the case which occurs 
> due to this out-of-standards solution.
>
> Besides, I don't see any issue due to slight miss-synchronization of 
> the realm-reports between two agents since they should still represent 
> the realm load more or less accurately.
>
> Also if the agents are not synchronized and if they are playing the 
> role of DOIC reacting node then they will apply abatement algorithm 
> based on different values (for the same realm). So it does not matter 
> if the client does the same.
>
> Finally, I don't see any value-add of using the "identity of the node 
> that sends the realm-report" to discard the other report related to 
> the same realm. In other words, this same logic can be achieved using 
> sequence-numbers as well, i.e. when the overload-report of an realm is 
> active, the client is going to ignore all the reports of the same 
> realm which has lower sequence number value. So in essence, when two 
> agents are sending realm-reports, one of the reports is automatically 
> ignored by the client if their sequence numbers differ. So the outcome 
> without including the "identity if the node that sends realm report" 
> is same as
>
> >The effect should be that the reacting node will accept a realm 
> report from anyone when there is no active OLR for the realm but it 
> will only listen to one reporting node when it has an active report.
>
> Regards,
>
> Nirav.
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Steve Donovan
> *Sent:* Friday, August 01, 2014 1:23 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Dime] DOIC issue #58 Proposal
>
> All,
>
> Issue #58 deals with the fact that there can be multiple senders of 
> realm overload report for the same realm.
>
> "In deployments where more than one node is configured to take the 
> role of a reporting node for realm-routed-request reports, reacting 
> nodes may receive in different answer messages different 
> realm-routed-request type OLRs inserted by the different reporting 
> nodes. Although it is expected that the different reporting nodes 
> report more or less the same content, it cannot be expected that 
> reports are 100% synchronized. Especially sequence numbers may differ. 
> To allow reacting nodes correctly detect outdates/replays/freshness of 
> OLRs in this scenario, it is proposed that realm-routed-request type 
> OLRs are extended to contain the Diameter Identity of the reporting 
> node that inserted the realm-routed-request type OLR. (e.g. as already 
> proposed in draft-donovan-dime-agent-overload-01 
> <http://tools.ietf.org/html/draft-donovan-dime-agent-overload-01>). 
> Reporting nodes that insert realm-routed-request type OLRs to answer 
> messages MUST also insert their Diameter Identity. Reacting nodes MUST 
> take the Diameter Identity received within the OLR into account in 
> order to detect outdates/replays/freshness. "
>
> I agree with Ulrich that realm reports must include the identity of 
> the DOIC node that sends the report.  This would be an optional AVP 
> only required for realm reports. It would not be required for host 
> reports as the identity of the sender of the host report is implicitly 
> defined by the origin-host in the answer message.
>
> I also agree that the Diameter Identity of the reporting node be used 
> to determine if a received report is ignored or used to update 
> existing state.  To this end I propose that we add wording that for 
> the duration of a realm report, the reacting node only listens for 
> updates to the realm report from from the DOIC node that sent the 
> realm report that resulted in the realm OCS being stored.
>
> The effect should be that the reacting node will accept a realm report 
> from anyone when there is no active OLR for the realm but it will only 
> listen to one reporting node when it has an active report.
>
> Steve
>

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 13:57:41 -0500

For host reports, the client would always use the identity in the 
report, not the identity in the origin-host AVP.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Aug 2014 14:02:48 -0500

I don't think you can conflate "host that generated this OLR" with "host that is overloaded". It's perfectly valid for them to not be the same thing, even for host reports.  (But I'd be happy to include both.)

On Aug 1, 2014, at 11:09 AM, Steve Donovan <[email-masked]> wrote:

> Somewhat on on the path toward generalization, we have a second issue currently open that can be solved by having the DOIC node that inserts an overload report in an answer message include it's own diameter identity in the overload report.
> 
> This issue points out that existing non DOIC agents are able to change the origin-host in answer messages.  One example of where this is done is in topology hiding implementations.
> 
> As such, I propose that we add a required AVP to the OC-OLR group AVP that carries the diameter identity of the DOIC node that inserted the overload report into the answer message.  Issue #66 points out the need in host reports and issue #58 points out the need in realm reports.
> 
> Steve
> 
>

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 14:53:50 -0500

Yes, it could be either.  The critical point is that the overloaded host 
is indicated by the diameter id in the overload report, not the 
origin-host AVP.

Steve

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 20:27:42 +0000

The question is: how does the client know to which the current request will be sent? As far as I know, the Origin-host is used as identification of the server assigned to the user. So how will the client interpret the I'd into the OLR?

Regards,

Lionel

---- Steve Donovan a écrit ----

Steve

---

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Aug 2014 15:39:37 -0500

On Aug 1, 2014, at 2:53 PM, Steve Donovan <[email-masked]> wrote:

> Yes, it could be either.  The critical point is that the overloaded host is indicated by the diameter id in the overload report, not the origin-host AVP.
> 

Right. My point was solving the "did this new OLR come from the same source as the previous one" problem and the "someone messed with Origin-Host so that I think the wrong thing is overloaded" are separate problems, with separate (but similar) solutions. Both could occur at the same time, with the same OLR.

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 21:07:44 +0000

But the client will never use the identity received in the OLR to check which abatement to apply when sending a request to the server... that is the agent from its point of view.
Therefore the client will never apply the overload abatement.

---- Steve Donovan a écrit ----

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 17:04:46 -0500

True.

So the question is, for this scenario, is it better for the client to 
ignore the overload report - as determined by there being a difference 
in the identity in the overload report and the identity in the 
origin-host AVP - or for the client to apply the overload report to all 
traffic sent through the agent?

If we choose the latter then what happens when the client starts seeing 
overload reports from multiple servers behind the agent?

My instinct is that it is better for the client to ignore the report as 
not doing so could result in a significant reduction in overall traffic 
sent through the non DOIC, origin-host munging agent.

Steve

---

From: <[email-masked]>
Date: Sat, 2 Aug 2014 01:37:37 +0000

In this scenario and other similar scenari, my requirement will be to remove any host-based report and forward only realm-based reports. Any host-based would be useless for clients beyond the agent.

Regards,

Lionel

---- Steve Donovan a écrit ----

True.

Steve

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Sat, 2 Aug 2014 03:37:26 +0000

Hello,

I really don't understand the logic for the host to insert its own identity into the overload report. Wouldn't it be the host to report its own overload report in an answer message to the client? Why we need the agent to do anything in this case?

To say the least, if the host can insert its identity into the message, what's the benefit to have the agent for topology hiding?

Best Regards,
Susan

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Saturday, August 02, 2014 3:54 AM
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Steve

On 8/1/14, 2:02 PM, Ben Campbell wrote:
> I don't think you can conflate "host that generated this OLR" with 
> "host that is overloaded". It's perfectly valid for them to not be the 
> same thing, even for host reports.  (But I'd be happy to include 
> both.)
>
>>>> overload-report of an realm is active, the client is going to 
>>>> ignore all the reports of the same realm which has lower sequence 
>>>> number value. So in essence, when two agents are sending 
>>>> realm-reports, one of the reports is automatically ignored by the 
>>>> client if their sequence numbers differ. So the outcome without 
>>>> including the "identity if the node that sends realm report" is 
>>>> same as
>>>>   Ce message et ses pieces jointes peuvent contenir des 
>>>> informations confidentielles ou privilegiees et ne doivent donc pas 
>>>> etre diffuses, exploites ou copies sans autorisation. Si vous avez 
>>>> recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Sat, 2 Aug 2014 03:49:28 +0000

Hello,

Whatever host-based report and realm-based report is in the same message or not, my understanding is that host based report and realm based report are serving for different purposes. If a message is to be sent to the host, then host report would be applied. If the client is unable to know the destination host of the request, then realm report can be applied. If the client is unable to see the hosts behind the agent, I cannot see the benefit to include report of a specific host behind the agent. How to do the load balancing and cope with overload of some hosts is the responsibility of the agent.

Best Regards,
Susan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, August 02, 2014 9:38 AM
To: Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Regards,

Lionel

---- Steve Donovan a écrit ----

True.

So the question is, for this scenario, is it better for the client to ignore the overload report - as determined by there being a difference in the identity in the overload report and the identity in the origin-host AVP - or for the client to apply the overload report to all traffic sent through the agent?

If we choose the latter then what happens when the client starts seeing overload reports from multiple servers behind the agent?

My instinct is that it is better for the client to ignore the report as not doing so could result in a significant reduction in overall traffic sent through the non DOIC, origin-host munging agent.

Steve

On 8/1/14, 4:07 PM, [email-masked] wrote:
>>> De : Steve Donovan [mailto:[email-masked]] Envoyé : 
>>> vendredi 1 août 2014 19:49 À : MORAND Lionel IMT/OLN Cc : 
>>> [email-masked] Objet : Re: [Dime] Attribution of Overload Reports 
>>> (was Re: DOIC issue #58 Proposal)
>>>
>>> Lionel,
>>>
>>> The issue is that there could be multiple/many servers behind the 
>>> agent that is changing the Origin-Host.  If one of them is 
>>> overloaded and generates a host report, clients will apply overload 
>>> abatement to all requests sent through that agent.  The end result 
>>> would be that the non overloaded servers are under utilized.
>>>
>>> Steve
>>>
>>>> De : DiME [mailto:[email-masked]] De la part de Steve 
>>>> Donovan Envoyé : vendredi 1 août 2014 18:10 Cc : [email-masked] 
>>>> Somewhat on on the path toward generalization, we have a second 
>>>> issue currently open that can be solved by having the DOIC node 
>>>> that inserts an overload report in an answer message include it's 
>>>> own diameter identity in the overload report.
>>>>
>>>> This issue points out that existing non DOIC agents are able to 
>>>> change the origin-host in answer messages.  One example of where 
>>>> this is done is in topology hiding implementations.
>>>>
>>>> As such, I propose that we add a required AVP to the OC-OLR group 
>>>> AVP that carries the diameter identity of the DOIC node that 
>>>> inserted the overload report into the answer message.  Issue #66 
>>>> points out the need in host reports and issue #58 points out the need in realm reports.
>>>>
>>>> Steve
>>>>
>>>>
>>>>>> _________________________________________________________________
>>>>>> ________________________________________________________
>>>>>>
>>>>>> informations confidentielles ou privilegiees et ne doivent donc 
>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>
>>>> ___________________________________________________________________
>>>> ______________________________________________________
>>>>
>> _____________________________________________________________________
>> ____________________________________________________
>>

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 01 Aug 2014 23:08:41 -0500

The issue is that the agent in question is a non DOIC agent.  This is a 
backwards compatibility issue.

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 4 Aug 2014 04:37:18 +0000

I fully agree with Susan below and I don't see any value in adding identity of the host in the overload report.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Shishufeng (Susan)
Sent: Saturday, August 02, 2014 9:07 AM
To: Steve Donovan; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Hello,

Best Regards,
Susan

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]]
Sent: Saturday, August 02, 2014 3:54 AM
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 4 Aug 2014 04:45:42 +0000

Steve,

How would topology hiding is achieved if the OLR has host's identity?
So the solution in this case is to turn-off the topology hiding feature at the agent so that the client receives identity of the host in the Origin-Host and applies abatement accordingly.
The other solution is to turn-off the generation of OLR at the host since the agents - which are supposed to consume the host's OLR in the topology hiding case - are not upgraded to support DOIC (i.e. are non DOIC agent yet).

I don't see inclusion of host's identity in the OLR as the solution for the problem - i.e. when the non DOIC agent is doing topology hiding - we are trying to solve here.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Saturday, August 02, 2014 9:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

The issue is that the agent in question is a non DOIC agent.  This is a backwards compatibility issue.

Steve

On 8/1/14, 8:37 PM, [email-masked] wrote:
> origin-host AVP - or for the client to apply the overload report to 
> all traffic sent through the agent?
>
> If we choose the latter then what happens when the client starts 
> seeing overload reports from multiple servers behind the agent?
>
> My instinct is that it is better for the client to ignore the report 
> as not doing so could result in a significant reduction in overall 
> traffic sent through the non DOIC, origin-host munging agent.
>
> Steve
>
>>>>>>> related to the same realm. In other words, this same logic can 
>>>>>>> be achieved using sequence-numbers as well, i.e. when the 
>>>>>>> ignore all the reports of the same realm which has lower 
>>>>>>> sequence number value. So in essence, when two agents are 
>>>>>>> sending realm-reports, one of the reports is automatically 
>>>>>>> ignored by the client if their sequence numbers differ. So the 
>>>>>>> outcome without including the "identity if the node that sends 
>>>>>>> realm report" is same as
>>>>>>> ________________________________________________________________
>>>>>>> _________________________________________________________
>>>>>>>
>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si 
>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>
>>>>> __________________________________________________________________
>>>>> _______________________________________________________
>>>>>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 4 Aug 2014 04:55:25 +0000

Steve,

In this scenario,
> Now, assume that the realm report generators lose the ability to communicate due to some localized failure.  The realm is known to be overloaded so realm reports need to be sent.  Assume also that one of the realm report generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed.

Can you explain how did you come to this conclusion?
> One effect can be a thrashing between 10% reduction and 50% reduction.

The client will ignore the report with lower sequence number and so I don't see the thrashing between 10% and 50%.

Regards,
Nirav.

From: Steve Donovan [mailto:[email-masked]]
Sent: Saturday, August 02, 2014 12:17 AM
To: Nirav Salot (nsalot); [email-masked]; Dave Dolson; [email-masked]
Subject: Re: [Dime] DOIC issue #58 Proposal

The question becomes, what happens if the nodes that are sending the realm reports lose the ability to stay in synchronization.  We all know that communication can be lost between entities.  This is what leads to complicated, multiple stage protocols for things like database synchronization.

So, lets assume that we mandate that DOIC nodes that send realm reports (let's call them realm report generators) MUST be in sync and that includes both the sequence number and any abatement algorithm data (percentage reduction for the loss algorithm).

A side note -- let's stop assuming that the realm report generator is an agent.  There is nothing saying that agents are the only thing that can send realm reports.  It is perfectly valid for servers to send realm report if they have visibility to the state of the realm as a whole.

Now, assume that the realm report generators lose the ability to communicate due to some localized failure.  The realm is known to be overloaded so realm reports need to be sent.  Assume also that one of the realm report generators thinks a 10% reduction is needed and a second thinks a 50% reduction is needed.

A client is going to see both reports types.  The realm report generators are going to refresh the reports, sending new reports with higher sequence numbers.  The client will honor all reports that have a bigger sequence number.

This is clearly an edge case.  It is, however, an edge case that is easily avoidable by attributing the source of the realm report.

Steve

Regards,
Nirav.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, August 01, 2014 9:28 PM
To: Dave Dolson; Steve Donovan; [email-masked]<mailto:[email-masked]>; Nirav Salot (nsalot)
Subject: RE: [Dime] DOIC issue #58 Proposal

Hi Dave,

Lionel

-Dave

Hi Steve,

Regards,

Lionel

---- Nirav Salot (nsalot) a écrit ----

Steve,

Regards,
Nirav.

All,

Steve

Thank you.

Thank you.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 4 Aug 2014 17:01:21 -0500

On Aug 3, 2014, at 11:55 PM, Nirav Salot (nsalot) <[email-masked]> wrote:

> The client will ignore the report with lower sequence number and so I don’t see the thrashing between 10% and 50%.

I think the example is a bit over simplified, in that you seem to assume one 10% report and one 50% report. What you probably really have is a series of reports from each source. I'm not talking about re-transmissions of the same report, but reports with changes.

For example, assume all of these are realm reports:

source 1: seq 1 10%
source 2: seq 2 50%
source 1: seq 3: 11%
source 2: seq 4: 55%
source 1: seq 5: 0%
source 2: seq 6: 45%

This gives the sort of flapping that Steve referred to. Currently the "source" part is not reported, so from the reacting node's perspective, this is indistinguishable from the following:

source 1: seq 1 10%
source 1: seq 2 50%
source 1: seq 3: 11%
source 1: seq 4: 55%
source 1: seq 5: 0%
source 1: seq 6: 45%

---

From: Ben Campbell <[email-masked]>
Date: Mon, 4 Aug 2014 17:18:34 -0500

> In this scenario and other similar scenari, my requirement will be to remove any host-based report and forward only realm-based reports. Any host-based would be useless for clients beyond the agent.

I agree the host report would be useless in this case. But what node do you expect to remove it? The scenario Steve has in mind assumes the topology-hiding node does not support DOIC in the first place, so how would it know to remove an OLR?

I agree with Steve that it is better to have the reacting node ignore a report that it cannot act on, rather than misinterpret that report to apply to the wrong thing. The former gives you a useless report, the latter gives you a damaging report.

Regardless of how we solve this, not solving it fails requirement 17 in RFC 7068.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 4 Aug 2014 17:32:05 -0500

Let me try to rephrase the problem:

Consider the following scenario:

           S1
         /
C---P--S2
        \
          S3

"P" is a diameter proxy that does _not_ support DOIC, and performs topology hiding.  The client and servers do support DOIC. 

Assume S1 becomes overloaded. It sends an host OLR with a reduction percentage of 100% in an answer to a request sent by C. The answer has an Origin-Host of "S1".

P receives the answer, and changes Origin-Host to "P". Since P does not support DOIC, it treats the OLR as an "unknown AVP", and forwards it unchanged.

C receives the report, and and entirely stops sending traffic to P. (As far as C knows, P is the server.) 

This is not the desired behavior. RFC7068 Req 17 says the following. The behavior in this example clearly violates the MUST NOT:

>    REQ 17: In a mixed environment with nodes that support the solution
>            and nodes that do not, the solution MUST NOT result in
>            materially less useful throughput during overload as would
>            have resulted if the solution were not present.  It SHOULD
>            result in less severe overload in this environment.
> 

If, on the other hand, the OLR internally identified the overloaded node as "S1", C would at least know that it can't do anything useful with the OLR, since it doesn't know about S1 due to the topology hiding at P. In this case, it just ignores the OLR. That still violates the SHOULD, but at least does not violate the MUST NOT.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 4 Aug 2014 17:41:16 -0500

> How would topology hiding is achieved if the OLR has host's identity?

Is your concern that we would leak server identity across the topology hiding proxy? This could be a valid concern in some scenarios. Can you suggest a solution that would not leak that information?

> So the solution in this case is to turn-off the topology hiding feature at the agent so that the client receives identity of the host in the Origin-Host and applies abatement accordingly.

I sincerely doubt an operator is going to be willing to accept that.

> The other solution is to turn-off the generation of OLR at the host since the agents - which are supposed to consume the host's OLR in the topology hiding case - are not upgraded to support DOIC (i…

We have a SHOULD level requirement (req 34) to be able to operate across non-supporting agents. Given that it's a SHOULD, not a MUST, it might be acceptable to only partially meet the requirement (for example, restrict it to non-topology-hiding agents.)

> I don't see inclusion of host's identity in the OLR as the solution for the problem - i.e. when the non DOIC agent is doing topology hiding - we are trying to solve here.

Including the host identity solves the problem of having the client perform abatement on all traffic going to the proxy, when that was not the intent of the OLR. (I demonstrated that in my reply to Susan.) Do you disagree that it accomplish that? If so, then where does it fail?

I agree that including the host identity might leak information that the topology hiding was intended to hide.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 5 Aug 2014 02:15:23 +0000

Hello Ben,

I don't understand how the overload report of the same realm in a short period can have such big jump between each other. My understanding is that the overload of the realm should be almost the same to all the agents having the full view of the realm, though there might be little difference which has minor impact on overload control.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 6:01 AM
To: Nirav Salot (nsalot)
Cc: [email-masked]
Subject: Re: [Dime] DOIC issue #58 Proposal

source 1: seq 1 10%
source 2: seq 2 50%
source 1: seq 3: 11%
source 2: seq 4: 55%
source 1: seq 5: 0%
source 2: seq 6: 45%

source 1: seq 1 10%
source 1: seq 2 50%
source 1: seq 3: 11%
source 1: seq 4: 55%
source 1: seq 5: 0%
source 1: seq 6: 45%

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 5 Aug 2014 02:35:30 +0000

Hello Ben,

Putting S1 node in the OLR would break the principle of topology hiding. If this is what the operator could accept, what's the benefit to have the agent on the route to do the topology hiding?

>From my point of view, there are other ways to solve the problem:

- If the hosts behind the agent can be enhanced to support overload control, the agent should be enhanced to support overload control, or be enhanced to just discard the OLR AVP.
- Or by configuration disable the topology hiding functionality of the agent since it does not make sense if the S1 could indicate its node identity to the client in the OLR.
- Or by configuration, the hosts behind the agent should know that the agent does not support overload control, then don't send OLR to the client.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 6:32 AM
To: Shishufeng (Susan)
Cc: Steve Donovan; [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

           S1
         /
C---P--S2
        \
          S3

On Aug 1, 2014, at 10:37 PM, Shishufeng (Susan) <[email-masked]> wrote:

>> "host that is overloaded". It's perfectly valid for them to not be 
>> the same thing, even for host reports.  (But I'd be happy to include
>> both.)
>> 
>>>>> Subject: Re: [Dime] DOIC issue #58 Proposal  Hi Steve,  I agree 
>>>>> with Nirav's view.
>>>>>  Regards,
>>>>>  Lionel
>>>>>  ---- Nirav Salot (nsalot) a écrit ----  Steve,  For this issue, I 
>>>>> don't agree to include identity of the DOIC node that sends the report, into the realm reports.
>>>>> Subject: [Dime] DOIC issue #58 Proposal  All,
>>>>>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 5 Aug 2014 04:38:33 +0000

On top of what Susan mentioned below, Ben's example assumes that the realm-reports are out of sync but the sequence numbers are magically synchronized such that each report (from different nodes) has monotonously increasing sequence number.

Besides, we are trying to solve non-issue here - that of "how to make the client ignore one of the realm-report when the two reports have big difference between them".
Shouldn't the system administrator (and the operator) need to worry about fixing the main issue here?

Finally, I don't see any issue if a client sees two reports with big jump in their values.
This may be very normal case (or as corner case as we are discussing here of two report generating nodes out-of-sync with each other), e.g. when the client receives 10% report (host/realm) and then there is no communication between the client and the report generator while the report changes from 10% to 50%.
So the client needs to anyway handle this. 

Regards,
Nirav.

-----Original Message-----
From: Shishufeng (Susan) [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 7:45 AM
To: Ben Campbell; Nirav Salot (nsalot)
Cc: [email-masked]
Subject: RE: [Dime] DOIC issue #58 Proposal

Hello Ben,

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 6:01 AM
To: Nirav Salot (nsalot)
Cc: [email-masked]
Subject: Re: [Dime] DOIC issue #58 Proposal

source 1: seq 1 10%
source 2: seq 2 50%
source 1: seq 3: 11%
source 2: seq 4: 55%
source 1: seq 5: 0%
source 2: seq 6: 45%

source 1: seq 1 10%
source 1: seq 2 50%
source 1: seq 3: 11%
source 1: seq 4: 55%
source 1: seq 5: 0%
source 1: seq 6: 45%

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 5 Aug 2014 04:53:11 +0000

Ben,

For my proposal
> The other solution is to turn-off the generation of OLR at the host since the agents - which are supposed to consume the host's OLR in the topology hiding case - are not upgraded to support DOIC (i…

You have an objection considering req 34. And hence your proposal is
> I agree with Steve that it is better to have the reacting node ignore a report that it cannot act on, rather than misinterpret that report to apply to the wrong thing. The former gives you a useles…

What is the difference in the outcome between "host does not generate overload report" v/s "host generates overload report and the reacting MUST ignore it"?

Regards,
Nirav.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 4:11 AM
To: Nirav Salot (nsalot)
Cc: Steve Donovan; [email-masked]; [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

>> ignore the overload report - as determined by there being a 
>> difference in the identity in the overload report and the identity in 
>> the origin-host AVP - or for the client to apply the overload report 
>> to all traffic sent through the agent?
>> 
>>>> The proposal is that the DOIC node that inserted the overload 
>>>> report includes its diameter identity in the overload report.  As 
>>>> such, it would be the server's identity that is in the overload report.
>>>> 
>>>> Sorry if I wasn't clear.
>>>> 
>>>> Steve
>>>> 
>>>>> overloaded and generates a host report, clients will apply 
>>>>> overload abatement to all requests sent through that agent.  The 
>>>>> end result would be that the non overloaded servers are under utilized.
>>>>> 
>>>>> Steve
>>>>> 
>>>>>> Objet : [Dime] Attribution of Overload Reports (was Re: DOIC 
>>>>>> issue
>>>>>> #58 Proposal)
>>>>>> 
>>>>>>>> Finally, I don't see any value-add of using the "identity of 
>>>>>>>> the node that sends the realm-report" to discard the other 
>>>>>>>> report related to the same realm. In other words, this same 
>>>>>>>> logic can be achieved using sequence-numbers as well, i.e. when 
>>>>>>>> the overload-report of an realm is active, the client is going 
>>>>>>>> to ignore all the reports of the same realm which has lower 
>>>>>>>> _______________________________________________________________
>>>>>>>> _ _________________________________________________________
>>>>>>>> 
>>>>>> _ _______________________________________________________
>>>>>> 
>>>>> _ ______________________________________________________
>>>>> 
>>>> _ _____________________________________________________
>>>> 
>>> _ ____________________________________________________
>>> 
>> _ ___________________________________________________
>>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 5 Aug 2014 04:53:44 +0000

+1

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Shishufeng (Susan)
Sent: Tuesday, August 05, 2014 8:06 AM
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Hello Ben,

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, August 05, 2014 6:32 AM
To: Shishufeng (Susan)
Cc: Steve Donovan; [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

           S1
         /
C---P--S2
        \
          S3

---

From: <[email-masked]>
Date: Tue, 5 Aug 2014 07:22:42 +0000

Exactly what I said :-)
Topology hiding is a non-issue. It is just a matter of configuration.

Lionel

---- Nirav Salot (nsalot) a écrit ----

+1

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Shishufeng (Susan)
Sent: Tuesday, August 05, 2014 8:06 AM
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Hello Ben,

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, August 05, 2014 6:32 AM
To: Shishufeng (Susan)
Cc: Steve Donovan; [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

           S1
         /
C---P--S2
        \
          S3

---

From: Steve Donovan <[email-masked]>
Date: Tue, 05 Aug 2014 07:16:43 -0500

How does operator A tell operator B to turn off topology hiding in 
operator B's network?

Keep in mind as well that topology hiding is just one example of a 
feature that would require an agent to change the origin-host in answer 
messages.  There may be others.  We need to solve the general problem 
and, if possible, solve it through signalling, not configuration.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 05 Aug 2014 07:45:27 -0500

Susan,
Nirav,

Don't take Ben's example as being literal.  The reports that change over 
the overload percentage could happen over a  period of time, they don't 
have to be absolutely in sequence.

It is also quite likely that the sequence numbers would overlap in this 
scenario.  Remember how we got here.  The two generators of realm 
reports start with everything in sync, including sequence numbers.  Then 
there is a localized loss of communication between the two sources.  
This could also cause the two sources to have a different view of the 
overload state of the realm.

source 1: seq 1 10%  <-- value used
source 2: seq 1 10%
  .
  .
  .
source 1: seq 100 10%
source 2: seq 100 10%

LOSS OF COMMUNICATION BETWEEN SOURCES

source 1: seq 100 10%
source 2: seq 100 10%
source 1: seq 100 10%
source 2: seq 101 50%  <-- value used
  .
  .
  .
source 1: seq 100 10%
source 2: seq 101 50%
source 1: seq 100 20% (value not used because sequence number <= 
previous seq no)
source 2: seq 101 50%
source 1: seq 102 25% <-- value used
source 2: seq 101 50%
  .
  .
  .
source 1: seq 102 25%
source 2: seq 102 60%
source 1: seq 102 25%
source 2: seq 103 50% <-- value used
  .
  .
  .
AND SO ON

More on Nirav's question about whether this is a bad thing in a separate 
email.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 05 Aug 2014 07:48:51 -0500

All,

We have the following requirement in RFC 7068:

    REQ 7:  The solution and any associated default algorithm(s) MUST
            ensure that the system remains stable.  At some point after
            an overload condition has ended, the solution MUST enable
            capacity to stabilize and become equal to what it would be in
            the absence of an overload condition.  Note that this also
            requires that the solution MUST allow nodes to shed load
            without introducing non-converging oscillations during or
            after an overload condition.

The requirement says the solution MUST not introduce non-converging 
oscillations.

I believe we at least have an oscillation in this scenario.  How do we 
determine if this can result in a non-converging oscillation?

Steve

---

From: <[email-masked]>
Date: Tue, 5 Aug 2014 12:57:31 +0000

H Steve,

I know that topology hiding was onlky one example. But this one was chosen to show that it was needed to add the id in the OLR. And it is clear that it is not the case.

Now, as for topology hiding, I think that any agent that will have to change the Origin-Host of a message sent by a server will have to ensure that such a modification has no impact on the normal process of the message as if the message was sent from the server, whatever the procedure. For instance, if there is any state linked to the origin-host of the server, this agent will have to ensure that this state is correctly managed afterwards when the origin-host is modified. This is true for server selection as well as for overload control.

A lot of things can be done around proxy/agent. But the protocol does not have to support everything.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 5 août 2014 14:17
À : [email-masked]
Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 05 Aug 2014 09:18:16 -0500

inline

> I know that topology hiding was onlky one example. But this one was chosen to show that it was needed to add the id in the OLR. And it is clear that it is not the case.
You're further along than me.  I'm not yet convinced.  There is the 
potential for this to result in one host report causing a reduction of 
traffic across a large number of non overloaded servers.  This warrants 
some consideration.

The proposal is as follows:

-  Add the diameter-id of the host into the overload report and use it 
to indicate the Diameter node that is overloaded.

- Add behavior in the reacting node to compare the value in the OLR and 
the origin-host.  If they are different then the reacting node has two 
options, ignore the report or honor the report.  The behavior taken 
could and probably should be based on local policy. In either case, the 
reacting node should probably log the fact that the mismatch occurred.  
How this is done would be implementation specific.

- We might want to add wording in DOIC that says that an agent that 
changes the identity in the OLR is responsible for ensuring that 
abatement happens on requests targeted to the overloaded host(s).

This is a pretty small change that improves the overall resiliency of 
the DOIC solution and gives operators more control over how they handle 
overload.
> Now, as for topology hiding, I think that any agent that will have to change the Origin-Host of a message sent by a server will have to ensure that such a modification has no impact on the normal p…
I don't disagree with what you are saying about proper implementation of 
topology hiding.  However, there is no normative definition of topology 
hiding behavior that we can depend upon being followed. There is also no 
way for an existing topology hiding agent to know how to handle overload 
control.  So any breakage that might happen from existing topology 
hiding agents cannot be assumed away by saying that the agent needs to 
properly handle overload control.

> A lot of things can be done around proxy/agent. But the protocol does not have to support everything.
No, not everything, just the scenarios where the presence of non DOIC 
agents breaks the DOIC solution.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 5 Aug 2014 17:51:29 +0000

Steve,

What is so difficult here and not sure why two operators are involved since the proposal is restricted to change of behavior in either the host or the agent at operator B?
Operator B has two choices:
- Turn off topology hiding in its agent since agents are not supporting DOIC yet.
- Turn off generation of overload report at the host since topology hiding is important.

These are configuration related issue and interim/transient problems - until the agents are upgraded to support DOIC.
So I don't think we need protocol solution for these types of problems.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Tuesday, August 05, 2014 5:47 PM
To: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

How does operator A tell operator B to turn off topology hiding in operator B's network?

Keep in mind as well that topology hiding is just one example of a feature that would require an agent to change the origin-host in answer messages.  There may be others.  We need to solve the general problem and, if possible, solve it through signalling, not configuration.

Steve

On 8/5/14, 2:22 AM, [email-masked] wrote:
>>>>>>   ---- Nirav Salot (nsalot) a écrit ----  Steve,  For this issue, 
>>>>>> I don't agree to include identity of the DOIC node that sends the report, into the realm reports.
>>>>>> the node that sends the realm-report" to discard the other report

---

From: <[email-masked]>
Date: Wed, 6 Aug 2014 13:19:19 +0000

Hi,

In order to try to conclude on the fact that an agent modifying the Origin-host AVP can only be a proxy agent and then such a proxy can be upgraded to deal with DOIC:

>From RFC6733:

6.3. Origin-Host AVP

   The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and
   it MUST be present in all Diameter messages.  This AVP identifies the
   endpoint that originated the Diameter message.  

<<< Relay agents MUST NOT   modify this AVP. >>>

   The value of the Origin-Host AVP is guaranteed to be unique within a
   single host.

   Note that the Origin-Host AVP may resolve to more than one address as
   the Diameter peer may support more than one address.

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : mardi 5 août 2014 19:51
À : Steve Donovan; [email-masked]
Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Steve,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Tuesday, August 05, 2014 5:47 PM
To: [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Aug 2014 10:16:10 -0500

Nirav,

Here's the cross operator scenario:

     Operator 1          Operator 2
                   |
                   |           +--+
                   |           |S1|
                   |          /+--+
                   |         /
   +-+       +-+   |    +-+ /   +--+
   |C|-------|A|---|----|A|-----|S2|
   +-+       +-+   |    +-+ \   +--+
                   |         \
                   |          \+--+
                   |           |S3|
                   |           +--+

Operator 1 is fully DOIC capable.

The agent in operator 2's network is not DOIC enabled.

The servers in operator 2's network are DOIC enabled.

All traffic from operator 1 targeted for operator 2 flows through 
operator 2's agent.

The agent in operator 2's network changes the origin-host header, maybe 
for topology hiding reasons, maybe for other reasons.

C sends a request that is routed to S1.  The request includes the 
OC-Supported-Features AVP.

S1 is overloaded and sends a response with an overload report requesting 
a reduction in traffic.  In the worst case S1 can send an overload 
report with a request for a 100% reduction in traffic.

C will see this as coming from the identity inserted by operator 2's 
agent and, as a result will throttle 100% of traffic targeted for 
operator 2's network despite there being two fully operational servers 
in operator 2's network.

While it may be in operator 2's best interest to upgrade their agent to 
support DOIC, operator 1 has no ability to make that upgrade happen.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Aug 2014 10:22:31 -0500

Lionel,

No one is saying that an agent cannot be upgraded to support DOIC.

What I did say was that it is not reasonable to expect existing agents, 
those deployed before DOIC is defined, to be able to support DOIC.

Steve

---

From: <[email-masked]>
Date: Wed, 6 Aug 2014 15:29:34 +0000

Hi Steve,

In that case it would mean that the proxy would not be any more compliant with the application it is supposed to support and advertise in CER/CEA.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mercredi 6 août 2014 17:23
À : MORAND Lionel IMT/OLN; Nirav Salot (nsalot); [email-masked]
Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Lionel,

What I did say was that it is not reasonable to expect existing agents, those deployed before DOIC is defined, to be able to support DOIC.

Steve

On 8/6/14, 8:19 AM, [email-masked] wrote:
> De : DiME [mailto:[email-masked]] De la part de Nirav Salot 
> (nsalot) Envoyé : mardi 5 août 2014 19:51 À : Steve Donovan; 
> [email-masked] Objet : Re: [Dime] Attribution of Overload Reports (was 
> Re: DOIC issue #58 Proposal)
>
> Steve,
>
>>>>>>>    ---- Nirav Salot (nsalot) a écrit ----  Steve,  For this 
>>>>>>> issue, I don't agree to include identity of the DOIC node that sends the report, into the realm reports.
>>>>>>> _ _ _______________________________________________________

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 6 Aug 2014 16:14:01 +0000

Steve,

Thanks for pointing out a different scenario. But for me, nothing changes yet.
The operator 1 and operator 2 will get in special agreement to share the overload report across operator's boundary. As part of the same, (since the operator 2 does not fully support DOIC yet) the hosts in the operator 1 is configured to not include the overload report in the answer messages going towards the operator 2. Or alternatively, the edge agents at operator 1 remove those overload reports.

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, August 06, 2014 8:46 PM
To: Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Nirav,

     Operator 1          Operator 2
                   |
                   |           +--+
                   |           |S1|
                   |          /+--+
                   |         /
   +-+       +-+   |    +-+ /   +--+

All traffic from operator 1 targeted for operator 2 flows through operator 2's agent.

The agent in operator 2's network changes the origin-host header, maybe for topology hiding reasons, maybe for other reasons.

C sends a request that is routed to S1.  The request includes the OC-Supported-Features AVP.

S1 is overloaded and sends a response with an overload report requesting a reduction in traffic.  In the worst case S1 can send an overload report with a request for a 100% reduction in traffic.

C will see this as coming from the identity inserted by operator 2's agent and, as a result will throttle 100% of traffic targeted for operator 2's network despite there being two fully operational servers in operator 2's network.

While it may be in operator 2's best interest to upgrade their agent to support DOIC, operator 1 has no ability to make that upgrade happen.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Aug 2014 11:55:14 -0500

This is a backwards compatibility scenario.

The proxy-agent can be 100% compatible with the n-1 version of the 
application that does not include DOIC support and still advertise 
support for that application.

I am not familiar with a mechanism for advertising support for a 
specific version of the application without changing the application-id 
itself.  Have I missed something?  Are you proposing changing the 
application-id for all applications that support DOIC?

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Aug 2014 12:01:27 -0500

Nirav,
All,

It seems like we at least have agreement that an agent that changes 
Origin-Host, for whatever reason, can result in clients abating too much 
traffic routed through that agent.  The worst case is that this could 
result in 100% of traffic targeted for the Diameter Identity inserted by 
the agent being throttled.

We have two solutions proposed:

1) A signaling based solution that would allow reacting nodes to know 
that an "origin-host-munging" agent was in the path of the message.

2) An administrative based solution involving turning off 
"origin-host-munging" behavior in agents until the agent is upgraded to 
fully supports DOIC.

Is this a correct summary of where we are so far on this issue?

Steve

---

From: <[email-masked]>
Date: Wed, 6 Aug 2014 17:05:22 +0000

Hi Steve,

There are several ways to avoid the problem of backward incompatibility and changing the application-id is one of them.
In 3GPP, we are using the Supported-Features AVP for the same purpose and the OC-Feature-Vector is introduced in this draft for the same reason i.e. discover what a node is supporting at the application level without changing the application-id.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mercredi 6 août 2014 18:55
À : MORAND Lionel IMT/OLN; Nirav Salot (nsalot); [email-masked]
Objet : Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

The proxy-agent can be 100% compatible with the n-1 version of the application that does not include DOIC support and still advertise support for that application.

I am not familiar with a mechanism for advertising support for a specific version of the application without changing the application-id itself.  Have I missed something?  Are you proposing changing the application-id for all applications that support DOIC?

Steve

On 8/6/14, 10:29 AM, [email-masked] wrote:
> De : Steve Donovan [mailto:[email-masked]] Envoyé : mercredi 
> 6 août 2014 17:23 À : MORAND Lionel IMT/OLN; Nirav Salot (nsalot); 
>>>>>>>>     Finally, I don't see any value-add of using the "identity 
>>>>>>>> of the node that sends the realm-report" to discard the other 
>>>>>>>> _ _ _ _______________________________________________________
>>>>>>>>     This message and its attachments may contain confidential 
>>>>>>>> or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>>> _ _ ___________________________________________________
>>>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 6 Aug 2014 17:25:22 +0000

Steve,

To be honest, I don't think 1 below - of including identity of the host in the report - can be considered as solution here since it has multiple issues:
- It breaks the topology hiding. So basically introduction of new feature breaks the existing feature and hence I don't think it is acceptable. 
- Finally the client discards the overload report so I am not sure what good we achieved here as compared to turning off the feature at the source itself.

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, August 06, 2014 10:31 PM
To: Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] Attribution of Overload Reports (was Re: DOIC issue #58 Proposal)

Nirav,
All,

It seems like we at least have agreement that an agent that changes Origin-Host, for whatever reason, can result in clients abating too much traffic routed through that agent.  The worst case is that this could result in 100% of traffic targeted for the Diameter Identity inserted by the agent being throttled.

1) A signaling based solution that would allow reacting nodes to know that an "origin-host-munging" agent was in the path of the message.

2) An administrative based solution involving turning off "origin-host-munging" behavior in agents until the agent is upgraded to fully supports DOIC.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Aug 2014 13:16:13 -0500

Lionel,

I understand all of that and that we have separated advertisement of 
support for a specific application from advertisement of support for 
DOIC.  I thought you were implying that a proxy that advertised support 
for an application that has incorporated DOIC implied support that it 
also supported DOIC.

Steve

On 8/6/14, 12:05 PM, [email-masked] wrote:
> Hi Steve,
>
> There are several ways to avoid the problem of backward incompatibilityand changing the application-id is one of them.
> I am not familiar with a mechanism for advertising support for a specific version of the application without changing the application-id itself. Have I missed something?  Are you proposing changing the application-idfor all applications that support DOIC?
>
> Steve
>
>>>       The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity,and
>>> What is so difficult here and not sure why two operators are involvedsince the proposal is restricted to change of behavior in either the host or the agent at operator B?
>>>> Assume S1 becomes overloaded. It sends an host OLR with a reduction percentage of 100% in an answer to a request sent by C. The answer has anOrigin-Host of "S1".
>>>>
>>>> This is not the desired behavior. RFC7068 Req 17 says the following.The behavior in this example clearly violates the MUST NOT:
>>>>
>>>>>                materially less useful throughput during overload aswould
>>>> If, on the other hand, the OLR internally identified the overloaded node as "S1", C would at least know that it can't do anything useful withthe OLR, since it doesn't know about S1 due to the topology hiding at P.In this case, it just ignores the OLR. That still violates the SHOULD, but at least does not violate the MUST NOT.
>>>>
>>>>
>>>>
>>>>> Yes, it could be either.  The critical point is that the overloadedhost is indicated by the diameter id in the overload report, not the origin-host AVP.
>>>>>
>>>>> Steve
>>>>>
>>>>>>> As such, I propose that we add a required AVP to the OC-OLR groupAVP that carries the diameter identity of the DOIC node that inserted the overload report into the answer message.  Issue #66 points out the needin host reports and issue #58 points out the need in realm reports.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>>> "In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detectoutdates/replays/freshness of OLRs in this scenario, it is proposed thatrealm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take theDiameter Identity received within the OLR into acco
 u
nt in order to detect outdates/replays/freshness."
>>>>>>>>>
>>>>>>>>> I agree with Ulrich that realm reports must include the identity of the DOIC node that sends the report.  This would be an optional AVP only required for realm reports.  It would not be required for host reports as the identity of the sender of the host report is implicitly definedby the origin-host in the answer message.
>>>>>>>>>
>>>>>>>>> I also agree that the Diameter Identity of the reporting node be used to determine if a received report is ignored or used to update existing state.  To this end I propose that we add wording that for the duration of a realm report, the reacting node only listens for updates to therealm report from from the DOIC node that sent the realm report that resulted in the realm OCS being stored.
>>>>>>>>>
>>>>>>>>> The effect should be that the reacting node will accept a realmreport from anyone when there is no active OLR for the realm but it willonly listen to one reporting node when it has an active report.
>>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>>
>>>> privileged information that may be protected by law; they should notbe distributed, used or copied without authorisation.
>>> As emails may be altered, Orange is not liable for messages that havebeen modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere,deforme ou falsifie. Merci.
>>
>> If you have received this email in error, please notify the sender anddelete this message and its attachments.
> Orange decline toute responsabilite si ce message a ete altere, deformeou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilegedinformation that may be protected by law;

---

From: Steve Donovan <[email-masked]>
Date: Wed, 06 Aug 2014 13:05:22 -0500

Nirav,

So you agree there is an issue, correct?

If we feel that we have properly characterized the issue, then the next 
step should be to outline the pros and cons of the possible solutions.

I want to make sure we have step one taken care of before we move into 
step 2.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Aug 2014 13:41:04 -0500

> 1) A signaling based solution that would allow reacting nodes to know that an "origin-host-munging" agent was in the path of the message.

I would say "allows the reacting node to do the right thing even if an OHM agent is in the path, at the expense of potentially leaking topology information to the reacting node."
> Is this a correct summary of where we are so far on this issue?

I think we have also mentioned a third option:  Configure DOIC supporting nodes to not send OLRs across, or accept OLRs from non-supporting OHM agents.  (Preferably with some mechanism to actually _detect_ non-supporting agents rather than requiring configuration on a per-agent basis.  )

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Aug 2014 13:52:22 -0500

> - It breaks the topology hiding. So basically introduction of new feature breaks the existing feature and hence I don't think it is acceptable. 

It's a cost. We should discuss more explicitly whether it's a reasonable cost.

> - Finally the client discards the overload report so I am not sure what good we achieved here as compared to turning off the feature at the source itself.

Discarding the report is _much_ better than acting incorrectly on a report.  Req 17 says the "solution MUST not result in materially less useful throughput" than if DOIC was not deployed.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Aug 2014 13:52:58 -0500

> I am not familiar with a mechanism for advertising support for a specific version of the application without changing the application-id itself.  Have I missed something?  Are you proposing changin…

That is _explicitly_ not supported. (That is, 6733 goes out of its way to say there is no versioning of applications.)

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Aug 2014 13:53:11 -0500

> In that case it would mean that the proxy would not be any more compliant with the application it is supposed to support and advertise in CER/CEA.

Only if said application is updated to _require_ DOIC (not merely allow it.)

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Aug 2014 13:53:16 -0500

> - Turn off generation of overload report at the host since topology hiding is important.

More likely, it means B uses DOIC in it's own network, but turns it off for anything that passes the non-supporting topology-hiding proxy. This requires some careful and complex configuration, and getting it wrong is _bad_.

> So I don't think we need protocol solution for these types of problems.

Req 6 requires us to make a reasonable attempt to solve issues in the protocol, rather than require people to configure around them.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Aug 2014 13:53:28 -0500

On Aug 5, 2014, at 9:18 AM, Steve Donovan <[email-masked]> wrote:

> I don't disagree with what you are saying about proper implementation of topology hiding.  However, there is no normative definition of topology hiding behavior that we can depend upon being followed. There is also no way for an existing topology hiding agent to know how to handle overload control.  So any breakage that might happen from existing topology hiding agents cannot be assumed away by saying that the agent needs to properly handle overload control.

It's really hard for a topology hiding agent to, in advance, avoid breaking things that haven't been invented yet. And in this case, we are not just talking about breaking DOIC, we are talking about an interaction with DOIC that can make things behave worse than if DOIC was not deployed at all.

Normally, I would agree with you that, if you use topology hiding, you've made your own bed and get to sleep in it. But unfortunately, the use of topology hiding proxies is fairly pervasive, so being unable to work across them is a pretty big problem for incremental deployment. You either get "islands" of overload control split by the topology hiding proxy, and a need for careful configuration to avoid accidentally sending (or accepting) something across the non-supporting proxy.

Also, we don't need full-blown topology hiding for this to be a problem. Anything that modifies Origin-Host will cause it. (Remember the SFE concept early in this work.)

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Aug 2014 13:53:52 -0500

> Topology hiding is a non-issue. It is just a matter of configuration.

   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require that this knowledge
           be configured at each node.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Fri, 8 Aug 2014 04:45:00 +0000

Ben,

Here, we are talking about overload control between two operators - between two PLMNs.
And we already need to have configuration (however careful and complex it is) to share/expose overload report across operator's boundary. So I am not talking about any new configuration on top of that, here, for the use case we are trying to solve.

Regards,
Nirav.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 8 Aug 2014 00:11:11 -0500

The two operator aspect was just an example. The use cases for this problem are in no way limited to inter-operator cases.

Another very common example would be a non-DOIC supporting server-front-end proxy, as we talked about in the early days of this draft. Or a commonly deployed approach to the central proxy in policy applications.