Subject: [Dime] Definition of host report

From: Steve Donovan <[email-masked]>
Date: Mon, 07 Apr 2014 14:40:41 +0100

All,

I believe that the current definition of the host report needs to be 
enhanced.

The following is what is currently in the -02 draft:

    0  A host report.  The overload treatment should apply to requests
       for which all of the following conditions are true:

       The Destination-Host AVP is present in the request and its value
       matches the value of the Origin-Host AVP of the received message
       that contained the OC-OLR AVP.

       The value of the Destination-Realm AVP in the request matches the
       value of the Origin-Realm AVP of the received message that
       contained the OC-OLR AVP.

       The value of the Application-ID in the Diameter Header of the
       request matches the value of the Application-ID of the Diameter
       Header of the received message that contained the OC-OLR AVP.

The second paragraph says that only requests that contain a 
Destination-Host AVP can be used for overload treatment.

This does not address the case where there is no agent between the 
reacting and reporting nodes.  In other words, the reacting node has a 
direct connection to the reporting node.  In this case the reacting node 
should include all messages that would be sent to the reporting node, 
including those that do not contain a Destination-Host AVP and those 
that the reacting node would sent to the reporting node through normal 
route selection for requests that do not contain a Destination-Host AVP.

I propose that the second paragraph be changed to the following:

"The reacting node knows that the request will be routed to the 
overloaded Diameter node identified by the Diameter ID in the OLR. This 
is the value of the Origin-Host AVP in the message that carried the 
OLR.  There are two cases where the reacting node will know that the 
request will be routed to the overloaded node.  The first is the request 
contains a Destination-Host AVP that matches the Diameter ID contained 
in the OLR.  The second is when the reacting node selects a route that 
is a direct connection to the overloaded Diameter node."

Regards,

Steve

---

From: <[email-masked]>
Date: Mon, 7 Apr 2014 14:07:31 +0000

Hi Steve,

As defined today, the originator of a Host-based report is the node identified by the Origin-host in the answer. I don't understand what is wrong with the existing definition in the draft.

Please see below.

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 7 avril 2014 15:41
À : [email-masked]
Objet : [Dime] Definition of host report

All,

I believe that the current definition of the host report needs to be enhanced.

The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment.

This does not address the case where there is no agent between the reacting and reporting nodes. 
[LM] I think you mean: this does ONLY address, right?

In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.
[LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP?

"The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR.  This is the value of the Origin-Host AVP in the message that carried the OLR.  There are two cases where the reacting node will know that the request will be routed to the overloaded node.  The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR.  The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node."
[LM] this is not needed if the Origin-host in the answer is enough to identify which node is overloaded, that is the current assumption in the draft.

Regards,

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: Steve Donovan <[email-masked]>
Date: Mon, 07 Apr 2014 16:29:43 -0500

Lionel,

Please see inline.

Steve

> [LM] I think you mean: this does ONLY address, right?
SRD> No, I mean the case where a client is connected directly to a set
of servers.  One of the servers becomes overloaded and sends a host
report.  The server is telling clients to reduce the traffic sent to it
by x%.  The client selects a route for the request.  Any request that
would be routed to the connection to the server should be a candidate
for overload treatment.  If this is not the case then how do you protect
a server for an application that has 100% realm routed requests?
> [LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP?
SRD> Because there is nothing else in the network that can manage that
traffic.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 8 Apr 2014 07:38:12 +0000

Steve,
I tend to agree.
However, wouldn't this mean that also the current definition of realm report (which actually is RRR) needs to be enhanced?

e.g. replace
The Destination-Host AVP is absent in the request.

with something like
"The reacting node does not know to which Diameter Host the request will be routed."

I was also wondering if there may be cases where
a) the reacting node selects the host, detects that it has a direct connection to that host and therefore does not include the Destination-Host AVP in the request. The selected host, however, when receiving the Destination-Host-less request decides to forward the request to another host. Or
b) the reacting node does not select a host and therefore does not include a Destination-Host AVP, but sends the request to the next hop, which happens to be a Host that decides to handle the request.

Are those cases valid and covered?

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, April 07, 2014 3:41 PM
To: [email-masked]
Subject: [Dime] Definition of host report

All,

This does not address the case where there is no agent between the reacting and reporting nodes.  In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.

Regards,

Steve

---

From: <[email-masked]>
Date: Tue, 8 Apr 2014 12:20:34 +0000

Hi Steve,

I understand your point now. Thank you for the clarification.

However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR.

The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer.

Regards, 

Lionel

De : Steve Donovan [mailto:[email-masked]] 
Envoyé : lundi 7 avril 2014 23:30
À : MORAND Lionel IMT/OLN; [email-masked]
Objet : Re: [Dime] Definition of host report

Lionel,

Please see inline.

Steve

Please see below.

Regards,

Lionel

All,

This does not address the case where there is no agent between the reacting and reporting nodes. 
[LM] I think you mean: this does ONLY address, right?
SRD> No, I mean the case where a client is connected directly to a set of servers.  One of the servers becomes overloaded and sends a host report.  The server is telling clients to reduce the traffic sent to it by x%.  The client selects a route for the request.  Any request that would be routed to the connection to the server should be a candidate for overload treatment.  If this is not the case then how do you protect a server for an application that has 100% realm routed requests?

In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.
[LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP?
SRD> Because there is nothing else in the network that can manage that traffic.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 08 Apr 2014 08:06:56 -0500

Lionel,

I'm not proposing adding an AVP to the overload report.  I should have
said the Diameter ID in the overload control state.  I agree completely
that the Diameter ID comes from the Origin-Host AVP in the answer
message containing the OLR.

Regards,

Steve

---

From: <[email-masked]>
Date: Tue, 8 Apr 2014 13:23:24 +0000

I see my mistake. I was confused by "the overloaded Diameter node identified by the Diameter ID in the OLR"
Therefore, I agree with the proposed change. In order to keep the existing text, do you think that the following wording would be clear enough:

      Either the Destination-Host AVP is present in the request and its value

      that contained the OC-OLR AVP; Either the Destination-Host is not present

      in the request but the value of peer identity associated with the connection

      used to send the request matches the value of the Origin-Host AVP of the

      received message that contained the OC-OLR AVP.

Regards,

Lionel

De : Steve Donovan [mailto:[email-masked]]
Envoyé : mardi 8 avril 2014 15:07
À : MORAND Lionel IMT/OLN; [email-masked]
Objet : Re: [Dime] Definition of host report

Lionel,

I'm not proposing adding an AVP to the overload report.  I should have said the Diameter ID in the overload control state.  I agree completely that the Diameter ID comes from the Origin-Host AVP in the answer message containing the OLR.

Regards,

Steve
On 4/8/14 7:20 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Steve,

Regards,

Lionel

À : MORAND Lionel IMT/OLN; [email-masked]<mailto:[email-masked]>

Lionel,

Please see inline.

Steve

On 4/7/14 9:07 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Steve,

Please see below.

Regards,

Lionel

À : [email-masked]<mailto:[email-masked]>

All,

Regards,

Steve

Thank you.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 08 Apr 2014 10:34:25 -0500

Ulrich,

Please see inline.

Steve

On 4/8/14 2:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> I tend to agree.
>
> However, wouldn't this mean that also the current definition of realm
> report (which actually is RRR) needs to be enhanced?
>
>  
>
> e.g. replace
>
SRD> How about "The reacting node does not know to which Diameter Host
within the Realm the request will be routed."
> a) the reacting node selects the host, detects that it has a direct
> connection to that host and therefore does not include the
> Destination-Host AVP in the request. The selected host, however, when
> receiving the Destination-Host-less request decides to forward the
> request to another host. Or
>
SRD> Why would the receiving host decide to forward the request?  If it
does, it's either an agent or there is some new application layer
behavior that the reacting node can't predict.
>
> b) the reacting node does not select a host and therefore does not
> include a Destination-Host AVP, but sends the request to the next hop,
> which happens to be a Host that decides to handle the request.
>
SRD> But the reacting node will know if the next hop matches an active
overload report based on the ID of the host on the other end of the
connection used.  This is the case I'm addressing with my proposal. 
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, April 07, 2014 3:41 PM
> *To:* [email-masked]
> *Subject:* [Dime] Definition of host report
>
>  
>
> All,
>
> direct connection to the reporting node.  In this case the reacting
> node should include all messages that would be sent to the reporting
> node, including those that do not contain a Destination-Host AVP and
> those that the reacting node would sent to the reporting node through
> normal route selection for requests that do not contain a
> Destination-Host AVP.
>
> overloaded Diameter node identified by the Diameter ID in the OLR. 
> This is the value of the Origin-Host AVP in the message that carried
> the OLR.  There are two cases where the reacting node will know that
> the request will be routed to the overloaded node.  The first is the
> request contains a Destination-Host AVP that matches the Diameter ID
> contained in the OLR.  The second is when the reacting node selects a
> route that is a direct connection to the overloaded Diameter node."
>
> Regards,
>
> Steve
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 08 Apr 2014 10:38:17 -0500

Lionel,

The second Either would need to be "Or".

I'm generally ok with your wording.  I was attempting to get to wording
that referred to the overload control state and not the message that
carried the OC-OLR AVP.  I just didn't do a good job of it. 

We can go with your wording for now but I might take another attempt to
have it refer to the OCS instead.

Steve

On 4/8/14 8:23 AM, [email-masked] wrote:
>
> I see my mistake. I was confused by "the overloaded Diameter node
> identified by the Diameter ID in the OLR"
>
> Therefore, I agree with the proposed change. In order to keep the
> existing text, do you think that the following wording would be clear
> enough:
>
>  
>
> *De :*Steve Donovan [mailto:[email-masked]]
> *Envoyé :* mardi 8 avril 2014 15:07
> *À :* MORAND Lionel IMT/OLN; [email-masked]
> *Objet :* Re: [Dime] Definition of host report
>
>  
>
> Lionel,
>
> said the Diameter ID in the overload control state.  I agree
> completely that the Diameter ID comes from the Origin-Host AVP in the
> answer message containing the OLR.
>
> Regards,
>
> Steve
>
>     À : MORAND Lionel IMT/OLN; [email-masked] <mailto:[email-masked]>
>
>     On 4/7/14 9:07 AM, [email-masked] <mailto:[email-masked]> wrote:
>
>     Hi Steve,
>
>      
>
>     À : [email-masked] <mailto:[email-masked]>
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 17 Apr 2014 16:56:08 -0500

> I'm not proposing adding an AVP to the overload report.  I should have said the Diameter ID in the overload control state.  I agree completely that the Diameter ID comes from the Origin-Host AVP in…

There's a potential issue here. Maybe we've discussed this before, but I've forgotten:

What happens if an intervening agent changes the Origin-Host AVP in the answer? I think we can take our previous discussions ofidentity-mapping server front end agents as an existence proof of agents that do that sort of thing.

The obvious answer is that any agent that did that sort of thing should remove the overload report, and perhaps replace it with one of it's own. But if the proxy does not support DOIC in the first place, it's likely not to do that. If a host report leaks past an agent that modifies the Origin-Host, then the reacting node is highly likely to do the Wrong Thing.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 23 Apr 2014 10:05:03 -0500

Ben,

I think this is something that needs to be thought through.  I suggest
entering it in the issue tracker to make sure it gets addressed.

Steve