Subject: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

From: "dime issue tracker" <[email-masked]>
Date: Tue, 04 Feb 2014 08:54:37 -0000

#34: Semantics of OC-Report-Type AVP

 Text in clause 4.6  does not fully explain to which requests overload
 treatment of a given report type applies.
 Proposal:

    0  A host report.  The overload treatment should apply to requests
       for which all of the following conditions are true:
       a) 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.
       b) 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.
       c) 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.

    1  A realm report.  The overload treatment should apply to
       requests for which all of the following conditions are true:
       a) The Destination-Host AVP is absent in the request.
       b) 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.
       c) 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.

-- 
--------------------------------------+--------------------------
 Reporter:  [email-masked]  |      Owner:  Ulrich Wiehe
     Type:  defect                    |     Status:  new
 Priority:  major                     |  Milestone:
Component:  draft-docdt-dime-ovli     |    Version:
 Severity:  Active WG Document        |   Keywords:
--------------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/34>
dime <http://tools.ietf.org/wg/dime/>

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 17:12:33 +0000

The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

Does it make sense?

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:[email-masked]] 
Envoyé : mardi 4 février 2014 09:55
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : [dime] #34: Semantics of OC-Report-Type AVP

_________________________________________________________________________________________________________________________

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: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 5 Feb 2014 11:37:56 +0000

Sorry, I don't understand the question.

An agent that is configured to take the role of a reporting node for a realm 
- will send (insert) realm type OLRs in answer messages that correspond to realm type request messages (request messages that do not contain a destination host), and
- will be transparent with regard to host type request messages (request messages that contain a destination hostand answer messages) and the corresponding answer messages.
Consequently the reacting node will receive realm type OLRs from the agent and host type OLRs from the servers.
The received realm type OLR will be relevant for the reacting node when sending/throttling realm type requests; the received host type OLR will be relevant for the reacting node when sending/throttling host type requests.

+--------+                                         +--------+                +--------+
| Client |                                         | Agent  |                | Server |
|        |                                         |        |                |        |
|        |                                         |        |                |        | 
+--------+                                         +--------+                +--------+
    |                                                |                             |
    |<---DOIC association 1------------------------->|<-------DOIC association 2-->|
    |                                                |                             |
    |<-----------------DOIC association 3----------------------------------------->|
    |                                                |                             |
    |                                                |                             |
    |                                                |                             |
    |---1.xxR-----(realm type request)-------------->|agent selects server         |
    |                                                |--------2.xxR--------------->| 
    |                                                |<-------3.xxA----------------|
    |<--4.xxA-----(realm type OLR )------------------|agent inserts OLR            |
    |                                                |                             |
    |                                                |                             |
    |                                                |                             |
    |                                                |                             |
    |                                                |                             |
    |                                                |                             |
    |---5.xxR-----(host type request)----------------|---------------------------->|
    |                                                |agent is transparent         |
    |<--6.xxA-----(host type OLR)--------------------|-----------------------------|
    |                                                |                             |
    |                                                |                             |
    |---7.xxR--(realm type request)->x throttled     |                             |
    |                                  according to  |                             |
    |                                  the receive   |                             |
    |                                  realm type OLR|                             |
    |                                                |                             |
    |                                                |                             |
    |---8.xxR--(host type request)->x  throttled     |                             |
    |                                  according to  |                             |
    |                                  the receive   |                             |
    |                                  host type OLR |                             |
    |                                                |                             |
    |                                                |                             | 
-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, February 04, 2014 6:13 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Does it make sense?

Lionel

-----Message d'origine-----

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Feb 2014 08:56:21 -0600

It makes more sense to me for a realm report to apply to all requests
targeted for that realm, independent the type of request.  This implies
that it would apply to requests that also have a Destination-Host specified.

If this is the definition of a realm report then we need to specify the
interaction between realm reports and host reports.

I propose that throttling would occur on the realm first and the host
second.  If a message targetted for the host is throttled as a result of
realm overload then that throttled message would count as part of the
reduction needed to address the host overload.  Messages to the host
that survive realm abatement would then be candidates for host overload.

Steve

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 15:13:55 +0000

I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

Lioenl

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:56
À : [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

Steve
On 2/4/14 11:12 AM, [email-masked]<mailto:[email-masked]> wrote:

Does it make sense?

Lionel

-----Message d'origine-----

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

 Proposal:

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 15:18:46 +0000

Here, you assume both types of reports sent back to the client.
My point was: if only realm-based report are sent to the client, the abatement will apply whatever the type of requests sent to the realm, with or without destination-host... whereas in your description for realm report it was said that the destination-host was absent.

This point is clarified in the other mail, in response/complement to Steve.

Lionel

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : mercredi 5 février 2014 12:38
À : MORAND Lionel IMT/OLN; [email-masked]
Objet : RE: [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, February 04, 2014 6:13 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Does it make sense?

Lionel

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 5 Feb 2014 16:29:43 +0000

I better like Lionel’s approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
What is wrong with letting the client
-not throttle host-type requests to S1,
-throttle host type request to S2 with 50% and
-throttle realm type requests wit 25%?

From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, February 05, 2014 4:14 PM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lioenl

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:56
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Steve

Does it make sense?

Lionel

-----Message d'origine-----

 Proposal:

Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 12:13:49 +0200

Few comments here.

>          that contained the OC-OLR AVP.

It is perfectly valid to send a request that has Destination-Host AVP
but no Destination-Realm AVP. It just means the Diameter nodes must 
be adjacent peers. 

>          Header of the received message that contained the OC-OLR AVP.

No need for this since we agreed that DOIC implicitly always refers 
to the application on which the DOIC AVPs are carried in.

>          Header of the received message that contained the OC-OLR AVP.

Same not as above.

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 12:20:47 +0200

> -throttle realm type requests wit 25%?

Isn't this what Lionel said below? I am OK with Lionel's
"wording" here.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Feb 2014 13:08:15 +0000

Jouni 
Please see inline.
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Friday, February 07, 2014 11:14 AM
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Few comments here.

It is perfectly valid to send a request that has Destination-Host AVP
but no Destination-Realm AVP. It just means the Diameter nodes must 
be adjacent peers. 
<Ulrich> ok, then let's remove b) from 0</Ulrich>

No need for this since we agreed that DOIC implicitly always refers 
to the application on which the DOIC AVPs are carried in.
<Ulrich>yes, we agreed on that, so c) is correct and it does not harm to keep c)</Ulrich>

>          Header of the received message that contained the OC-OLR AVP.

Same not as above.
<Ulrich> I understand that this "above" referrs to 0c), not to 0b).
 Same response as above. </Ulrich>

- JOuni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Feb 2014 13:12:43 +0000

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> wrote:

> I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?

Isn't this what Lionel said below?
<Ulrich> no it is not</Ulrich>
 I am OK with Lionel's
"wording" here.

- Jouni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 7 Feb 2014 16:15:14 +0000

Dear all,

I am in favor of the proposal made by Ulrich in the sequence diagram he provided.
----
As a summary:
Consequently the reacting node will receive realm type OLRs from the agent and host type OLRs from the servers.
The received realm type OLR will be relevant for the reacting node when sending/throttling realm type requests; the received host type OLR will be relevant for the reacting node       when sending/throttling host type requests.
-----

It may occur though, that a Client has only received Realm type OLR, and then it has to send a request to one specific host, then the Client will not apply any restriction, but as soon as the response is received back, Client will update Host type OLR.  Same will apply when only Host type OLR has been received by Client.
The alternative will be to always send back from an Agent both Host OLR plus Realm OLR, but I do not think this is necessary and may complicate the solution.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 9 Feb 2014 14:45:58 +0200

> <Ulrich> no it is not</Ulrich>

Ok, maybe I misread the "realm abatement is applied in any case
except if there is an explicit report for the destination-host"?

If this means the realm abatement is still applied after applying
the host abatement, then I agree it is not the same you said.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 10 Feb 2014 13:28:45 +0200

> <Ulrich> ok, then let's remove b) from 0</Ulrich>

My statement above is actually wrong. Sorry about misinformation. 

- Jouni

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 11:30:48 +0000

No it was not my intention and it is why it was written "except" :)

The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.

Is it clearer?

Lioenl 

-----Message d'origine-----
De : Jouni Korhonen [mailto:[email-masked]] 
Envoyé : dimanche 9 février 2014 13:46
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : MORAND Lionel IMT/OLN; Steve Donovan; [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- Jouni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 10 Feb 2014 12:55:40 +0000

Dear  all

I share Ulrich and MCruz views,
- Host OLR based control applies to requests where Destination Host is known 
- Realm OLR based control applies to requests where Destination Host is not known (only the Destination realm).

I think it is simple, otherwise as MCruz indicated it complicates; e.g about the Ulrich's example where the Host S1 is not overloaded but the realm is overloaded. the client will not receive Host OLR reports from host S1 (so no explicit traffic reduction requested by S1), but according to Lionel comment, I understand  client will have to throttle the requests sent to S1 according to realm OLR, so how to avoid this.

JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : vendredi 7 février 2014 17:15
À : [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- Jouni

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 13:24:48 +0000

I disagree and my proposal was somehow misunderstood.

I don't see the issue to have the following sequence:

- If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host
- If the reacting node has received an indication only for host traffic reduction, apply host reduction for messages containing a Destination-Host. No reduction for messages with only a Destination-Realm.
- If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).

In other words, as said earlier, the Host reduction prevails over realm reduction when the overloaded host is inside an overloaded realm and the reacting has received info about both type of overload.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : lundi 10 février 2014 13:56
À : [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear  all

JJacques

-----Message d'origine-----

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- Jouni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 10 Feb 2014 14:00:09 +0000

Hi Lionel 

Please see in line

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 10 février 2014 14:25
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host
[JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
   
[JJ] OK
 
- If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).
[JJ] OK, Host reduction prevails

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 10 février 2014 13:56 À : [email-masked] Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear  all

JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : vendredi 7 février 2014 17:15 À : [email-masked] Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 08:39:17 -0600

I think we have agreement that a realm report applies to all traffic
targeted for that realm, independent of the presence or absence of the
destination-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should
take precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm. 
Call it the "realm overload authority".  The health of the realm can be
based on a number of factors including the health of individual servers,
individual agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is
congested, for instance, it would instruct agents or servers to send
realm overload reports with the expectation that the overall traffic
sent to the realm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence
over the health of the servers.  As such, it is likely that requests
targeted for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports
in any answer message, not just answers to requests that did not contain
a destination-host AVP.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 08:43:51 -0600

> <Ulrich>yes, we agreed on that, so c) is correct and it does not harm to keep c)</Ulrich>
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way
for the application-id
in the answer message to be different than the application-id in the
request message without
breaking Diameter.

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 16:59:14 +0000

Hi Steve,

In your example, if an agent has a better knowledge than the server, the Host type OLR should not be sent unmodified in forwarded answers, or even removed as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than the reduction needed for a node. S1 is not overload, S2 is 50% overload, the realm (S1+S2) is overloaded 25%. So only the reduction for the Host should apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:[email-masked]]
Envoyé : lundi 10 février 2014 15:39
À : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc : [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic targeted for that realm, independent of the presence or absence of the destination-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should take precedence over the host overload report.

- There is something responsible for tracking the health of the realm.  Call it the "realm overload authority".  The health of the realm can be based on a number of factors including the health of individual servers, individual agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is congested, for instance, it would instruct agents or servers to send realm overload reports with the expectation that the overall traffic sent to the realm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence over the health of the servers.  As such, it is likely that requests targeted for a healthy server will be throttled.

For all requests:

Note that this also requires the ability to put realm overload reports in any answer message, not just answers to requests that did not contain a destination-host AVP.

Steve
On 2/10/14 5:30 AM, [email-masked]<mailto:[email-masked]> wrote:

Is it clearer?

Lioenl

-----Message d'origine-----

Cc : MORAND Lionel IMT/OLN; Steve Donovan; [email-masked]<mailto:[email-masked]>

On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

-----Original Message-----

Cc: ext [email-masked]<mailto:[email-masked]>; Steve Donovan; [email-masked]<mailto:[email-masked]>

On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked]<mailto:[email-masked]>

To: Steve Donovan; [email-masked]<mailto:[email-masked]>

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

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

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 11:52:11 -0600

Lionel,

Why would the reduction for the realm be less than servers.  It is
perfectly valid for a realm overload report to ask for a reduction when
there are no servers in overload.  This could happen in the case I
mentioned where the realm overload report is triggered by layer 3
congestion.

Clearly realm overload will be significantly influenced by server
overload, but that isn't the only consideration.

My logic was not quite correct, but for a different reason.  There is no
reason to do the host throttling if the request has already been
throttled by the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host
overload report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm
abatement algorithm and input that into the server abatement algorithm. 
This might look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the
destination-host AVP
  If the request has not already been throttled and there is a host
overload report that applies to the request:
    If host credits exist for the host indicated in the destination-host
AVP:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request

Steve

On 2/10/14 10:59 AM, [email-masked] wrote:
>
> Hi Steve,
>
>  
>
> In your example, if an agent has a better knowledge than the server,
> the Host type OLR should not be sent unmodified in forwarded answers,
> or even removed as irrelevant.
>
>  
>
> And in a normal case, the reduction for the realm will be likely lower
> than the reduction needed for a node. S1 is not overload, S2 is 50%
> overload, the realm (S1+S2) is overloaded 25%. So only the reduction
> for the Host should apply, why the host-type should prevail over
> realm-type OLR.
>
>  
>
> By the way, in your proposed logic, it is not clear if the relation
> between the first and the second conditions is an "IF NOT".
>
>  
>
> Lionel
>
>  
>
> *De :*Steve Donovan [mailto:[email-masked]]
> *Envoyé :* lundi 10 février 2014 15:39
> *À :* MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN -
> DE/Munich)
> *Cc :* [email-masked]
> *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> I don't agree with Lionel's proposal.  The realm overload report
> should take precedence over the host overload report.
>
> - There is something responsible for tracking the health of the
> realm.  Call it the "realm overload authority".  The health of the
> realm can be based on a number of factors including the health of
> individual servers, individual agents and the network connecting
> Diameter entities.
>
> - When this "realm overload authority" determines that the IP network
> is congested, for instance, it would instruct agents or servers to
> send realm overload reports with the expectation that the overall
> traffic sent to the realm as a whole will be reduced.
>
> In this scenario, the fact that the realm is overloaded takes
> precedence over the health of the servers.  As such, it is likely that
> requests targeted for a healthy server will be throttled.
>
> in any answer message, not just answers to requests that did not
> contain a destination-host AVP.
>
> Steve
>
>     Cc : MORAND Lionel IMT/OLN; Steve Donovan; [email-masked] <mailto:[email-masked]>
>
>     On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>          
>
>          
>
>         Cc: ext [email-masked] <mailto:[email-masked]>; Steve Donovan; [email-masked] <mailto:[email-masked]>
>
>         On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>          
>
>             From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked] <mailto:[email-masked]>
>
>             To: Steve Donovan; [email-masked] <mailto:[email-masked]>
>
>             À : [email-masked] <mailto:[email-masked]>
>
>             On 2/4/14 11:12 AM, [email-masked] <mailto:[email-masked]> wrote:
>
>             Cc : [email-masked] <mailto:[email-masked]>
>
>             [email-masked] <mailto:[email-masked]>
>

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 18:45:13 +0000

What about my comment on the fact that irrelevant host report in presence of a realm reporting agent should not be forwarded?

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

Steve Donovan <[email-masked]> a écrit :

Lionel,

Why would the reduction for the realm be less than servers.  It is perfectly valid for a realm overload report to ask for a reduction when there are no servers in overload.  This could happen in the case I mentioned where the realm overload report is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload, but that isn't the only consideration.

My logic was not quite correct, but for a different reason.  There is no reason to do the host throttling if the request has already been throttled by the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm abatement algorithm and input that into the server abatement algorithm.  This might look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the destination-host AVP
  If the request has not already been throttled and there is a host overload report that applies to the request:
    If host credits exist for the host indicated in the destination-host AVP:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request

Steve

On 2/10/14 10:59 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi Steve,

Lionel

For all requests:

Steve

Is it clearer?

Lioenl

-----Original Message-----

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

Thank you.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Feb 2014 09:37:18 +0000

Steve,

I do not agree.

e.g. 
1. reacting node sends Request with application ID = x to reporting node
2. reporting node sends back answer (containing an OLR) with application ID = x
3. reacting node now may very well send  a new request with application ID = y to the reporting node without breaking any Diameter rules. 
The new request sent in step 3 is NOT subject to throttling according to the OLR received in step 2.
I hope this is not contentious.
In order to provide a complete list of conditions to say when an OLR of a given type applies to a new request, we should not let c) go by the board.

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Feb 2014 09:43:51 +0000

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Monday, February 10, 2014 3:39 PM
To: [email-masked]; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

<Ulrich> NO, again:

..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?

</Ulrich>

For all requests:

Steve

Is it clearer?

Lioenl

-----Original Message-----

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

Thank you.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Feb 2014 09:54:59 +0000

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Monday, February 10, 2014 6:52 PM
To: [email-masked]; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

Why would the reduction for the realm be less than servers.  It is perfectly valid for a realm overload report to ask for a reduction when there are no servers in overload.
<Ulrich> I don't think so</Ulrich>
  This could happen in the case I mentioned where the realm overload report is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload, but that isn't the only consideration.
<Ulrich> all considerations other than server overload are (or should be) out of scope. (May be covered by agent overload control)</Ulrich>

For all requests:

For all requests:
<Ulrich> sounds quite complicated</Ulrich>

Lionel

For all requests:

Steve

Is it clearer?

Lioenl

-----Original Message-----

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

Thank you.

Thank you.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 11 Feb 2014 09:57:44 +0000

Steve,

I don't understand one aspect.
Why should the request be throttled with realm report when the request is targeted to a particular host within the realm.
Can this request be routed to another host in that realm? If not, the request should be subjected to the throttling based on the host report.

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Monday, February 10, 2014 11:22 PM
To: [email-masked]; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

For all requests:

For all requests:

Steve

Lionel

For all requests:

Steve

Is it clearer?

Lioenl

-----Original Message-----

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

Thank you.

Thank you.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 10:38:12 +0000

Steve,

I prefer this text to remain, as Ulrich proposed, since it clarifies.
It refers to new requests that need to match same application Id as in the answer that includes the OLR. (It does not refer to the answer of a request).
One endpoint can send requests for multiple applications, we have  not restricted this.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 15:44
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

> No need for this since we agreed that DOIC implicitly always refers to 
> the application on which the DOIC AVPs are carried in.
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way for the application-id in the answer message to be different than the application-id in the request message without breaking Diameter.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 10:42:33 +0000

Exact, I agree.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 11 de febrero de 2014 10:37
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Steve,

I do not agree.

e.g. 
1. reacting node sends Request with application ID = x to reporting node 2. reporting node sends back answer (containing an OLR) with application ID = x 3. reacting node now may very well send  a new request with application ID = y to the reporting node without breaking any Diameter rules. 
The new request sent in step 3 is NOT subject to throttling according to the OLR received in step 2.
I hope this is not contentious.
In order to provide a complete list of conditions to say when an OLR of a given type applies to a new request, we should not let c) go by the board.

Ulrich

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 10:48:46 +0000

Hello,
I agree with JJ:

[MCruz] And... if the request is sent to a Destination-Host, if there is any applicable OLR, it will be received immediately in the answer, and will be applicable from next request on.
Simple and robust in my opinion. Then, we do not need to evaluate whether we have OLR for Realm and/or Host, and even check their validity & applicability.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 15:00
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Lionel 

Please see in line

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] Envoyé : lundi 10 février 2014 14:25 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked] Objet : RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.

Lionel

-----Message d'origine-----

Dear  all

JJacques

-----Message d'origine-----

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> wrote:

> -not throttle host-type requests to S1, -throttle host type request to 
> S2 with 50% and -throttle realm type requests wit 25%?

- Jouni

> Envoyé : mercredi 5 février 2014 15:56 À : [email-masked] Objet : Re: 
> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>  
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.
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: <[email-masked]>
Date: Tue, 11 Feb 2014 10:50:19 +0000

I think that there is no contentious issue here :)
I think that Ulrich is right saying that the reacting node needs to take into account the application-id to perform the abatement. Not when receiving the OLR... but when sending a new request.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mardi 11 février 2014 11:43
À : [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Exact, I agree.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 11 de febrero de 2014 10:37
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Steve,

I do not agree.

e.g. 

Ulrich

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 10:51:46 +0000

Hello all,

I agree with Ulrich comments, since I agree on the basic approach as mentioned already in this thread (inline with JJ comments as well):

Best regards
/MCruz

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Monday, February 10, 2014 6:52 PM
To: [email-masked]<mailto:[email-masked]>; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

For all requests:

For all requests:

Lionel

For all requests:

Steve

Is it clearer?

Lioenl

-----Original Message-----

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 11 Feb 2014 10:56:49 +0000

Hi maria-cruz,

JJ agreed on the following approach:

 

What is the issue with this approach?

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mardi 11 février 2014 11:49
À : [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hello,
I agree with JJ:

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 15:00
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Lionel 

Please see in line

-----Message d'origine-----

   

Lionel

-----Message d'origine-----

Dear  all

JJacques

-----Message d'origine-----

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Tue, 11 Feb 2014 06:19:45 -0600

The definition of a realm overload report is to decrease the total
number of requests sent to the realm.  The algorithm suggests one way of
achieving the reduction of traffic.  Other approaches could clearly be
taken, as long as the total amount of traffic to the realm is reduced.

Steve

On 2/11/14 3:57 AM, Nirav Salot (nsalot) wrote:
> Why should the request be throttled with realm report when the request
> is targeted to a particular host within the realm.
>
> Can this request be routed to another host in that realm? If not, the
> request should be subjected to the throttling based on the host report.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Steve Donovan
> *Sent:* Monday, February 10, 2014 11:22 PM
> *To:* [email-masked]; Jouni Korhonen; Wiehe, Ulrich (NSN -
> DE/Munich)
> *Cc:* [email-masked]
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> Lionel,
>
> perfectly valid for a realm overload report to ask for a reduction
> when there are no servers in overload.  This could happen in the case
> I mentioned where the realm overload report is triggered by layer 3
> congestion.
>
> My logic was not quite correct, but for a different reason.  There is
> no reason to do the host throttling if the request has already been
> abatement algorithm and input that into the server abatement
> algorithm.  This might look something like the following:
>
> For all requests:
>     In your example, if an agent has a better knowledge than the
>     server, the Host type OLR should not be sent unmodified in
>     forwarded answers, or even removed as irrelevant.
>
>      
>
>     And in a normal case, the reduction for the realm will be likely
>     lower than the reduction needed for a node. S1 is not overload, S2
>     is 50% overload, the realm (S1+S2) is overloaded 25%. So only the
>     reduction for the Host should apply, why the host-type should
>     prevail over realm-type OLR.
>
>      
>
>     By the way, in your proposed logic, it is not clear if the
>     relation between the first and the second conditions is an "IF NOT".
>
>      
>
>     Lionel
>
>      
>
>     *Cc :* [email-masked] <mailto:[email-masked]>
>     I think we have agreement that a realm report applies to all
>     traffic targeted for that realm, independent of the presence or
>     absence of the destination-host avp.  Is that correct?
>
>     - When this "realm overload authority" determines that the IP
>     network is congested, for instance, it would instruct agents or
>     servers to send realm overload reports with the expectation that
>     the overall traffic sent to the realm as a whole will be reduced.
>
>     precedence over the health of the servers.  As such, it is likely
>     that requests targeted for a healthy server will be throttled.
>
>     Note that this also requires the ability to put realm overload
>     reports in any answer message, not just answers to requests that
>     did not contain a destination-host AVP.
>
>     Steve
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 11 Feb 2014 06:22:43 -0600

The we have disagreement on the definition of the Realm overload report.

Multiple times it has been said the that realm report applied to all
requests, independent of the content or presence of the destination-host
AVP.

A realm overload report is of limited value if it does not apply to all
traffic sent to the realm.  It is a needed tool to protect a realm from
a network wide issue that cannot be detected by just looking at the
overload status of individual servers.

Steve

On 2/11/14 4:51 AM, Maria Cruz Bartolome wrote:
>
> Hello all,
>
>  
>
> I agree with Ulrich comments, since I agree on the basic approach as
> mentioned already in this thread (inline with JJ comments as well):
>
>  
>
> - Realm OLR based control applies to requests where Destination Host
> is not known (only the Destination realm).
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*ext Steve Donovan [mailto:[email-masked]]
> *Sent:* Monday, February 10, 2014 6:52 PM
> *To:* [email-masked] <mailto:[email-masked]>;
> Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
> *Cc:* [email-masked] <mailto:[email-masked]>
> when there are no servers in overload.
>
> */<Ulrich> I don't think so</Ulrich>/*
>
>   This could happen in the case I mentioned where the realm overload
> report is triggered by layer 3 congestion.
>
> */<Ulrich> all considerations other than server overload are (or
> should be) out of scope. (May be covered by agent overload
> control)</Ulrich>/*
>
> */<Ulrich> sounds quite complicated</Ulrich>/*
> Steve
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 11 Feb 2014 12:27:57 +0000

I share the below understanding from Maria-Cruz.

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 4:22 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hello all,

Best regards
/MCruz

Lionel,

For all requests:

For all requests:

Lionel

For all requests:

Steve

Is it clearer?

Lioenl

-----Original Message-----

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

Thank you.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 11 Feb 2014 06:33:20 -0600

> */<Ulrich> I don't think so</Ulrich>/*
/*<srd> I do think so. */
> *//*
<srd> I disagree. We are building tools for a service provider to
protect their network.  We aren't specifying how the status of a realm
is determined, we are giving the ability for a service provider to
protect the network in extreme conditions.  In addition, this has
nothing to do with agent overload.  Overload status of an agent would be
an input into realm overload status but the overload of an individual
agent cannot and should not be interpreted as overload of a realm.
> */<Ulrich> sounds quite complicated</Ulrich>/*
srd> Looks pretty straight forward to me.  Even if it is complication,
so what?  We are talking about protecting a Diameter network from a
condition that can cause operators to lose a lot of money.  A little
complexity is acceptable.  This, of course, would not be normative.  The
normative definition would be that the reacting node must decrease
traffic to the realm by the requested reduction.  Applications can
define different reduction algorithms.  Implementations can take
different approaches.  This would just be the suggested approach.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 11 Feb 2014 12:33:22 +0000

Steve,

I still don't understand how this work.
If a host (within the realm) is more overloaded than the realm itself, is it justified to throttle the traffic towards this host with realm-report?
If yes, can it guarantee the overload mitigation of the server?
If yes, what is the use of host report when realm report is provided. Can we simply say that the reacting node simply forgets the host report when realm report is available?

Regards,
Nirav.

From: Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 5:50 PM
To: Nirav Salot (nsalot); [email-masked]; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

The definition of a realm overload report is to decrease the total number of requests sent to the realm.  The algorithm suggests one way of achieving the reduction of traffic.  Other approaches could clearly be taken, as long as the total amount of traffic to the realm is reduced.

Steve

Regards,
Nirav.

Lionel,

For all requests:

For all requests:

Steve

Lionel

For all requests:

Steve

Is it clearer?

Lioenl

-----Original Message-----

- Jouni

I am OK with Lionel's

"wording" here.

- Jouni

Lioenl

Steve

Does it make sense?

Lionel

-----Message d'origine-----

Proposal:

Thank you.

DiME mailing list

Thank you.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 11 Feb 2014 06:40:59 -0600

Agreed, there is nothing contentious here.  I agree that the report
applies only to the application ID included in the message carrying the
overload report. 

Ulrich's wording isn't clear on which messages are being referenced.  Or
I wasn't looking at full context.  It might be better to try to change
the proposed wording from:
How about changing Ulrich's proposal from:

to the following:

"The value of the application-ID in the Diameter Header of new request
messages matches the value of the Application-ID is an active overload
report."

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 11 Feb 2014 06:53:19 -0600

Nirav,

I'm saying that the two are independent conditions, treated separately.

A reacting node receiving both a realm report and a host report must do
two things -- reduce the traffic to the realm by the percentage
requested in the realm report and reduce the traffic sent to the host by
the amount requested in the host report.

The algorithm I suggested achieved this, but is only a suggestion. 
Implementations can do it any way they want, as long as the above two
requirements are met.

More inline.

Steve

On 2/11/14 6:33 AM, Nirav Salot (nsalot) wrote:
> If a host (within the realm) is more overloaded than the realm itself,
> is it justified to throttle the traffic towards this host with
> realm-report?
>
SRD> Yes, messages that are throttled because of a throttling to the
host can, and probably should be counted in the separate count of
messages throttled for the realm.
> If yes, can it guarantee the overload mitigation of the server?
SRD> The reacting node is responsible for reducing the traffic sent to
the server by the requested amount.  So, if the reacting node is doing
its job then yes.
>
> If yes, what is the use of host report when realm report is provided.
> Can we simply say that the reacting node simply forgets the host
> report when realm report is available?
>
SRD> A hosts overload condition is separate from a realms overload
condition.  The host report will clearly be an input to the realms
overload state, but they are separate and should be treated as separate
events.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*Steve Donovan [mailto:[email-masked]]
> *Sent:* Tuesday, February 11, 2014 5:50 PM
> *To:* Nirav Salot (nsalot); [email-masked]; Jouni Korhonen;
> Wiehe, Ulrich (NSN - DE/Munich)
> *Cc:* [email-masked]
> number of requests sent to the realm.  The algorithm suggests one way
> of achieving the reduction of traffic.  Other approaches could clearly
> be taken, as long as the total amount of traffic to the realm is reduced.
>
> Steve
>
>     Why should the request be throttled with realm report when the
>     request is targeted to a particular host within the realm.
>
>     Can this request be routed to another host in that realm? If not,
>     the request should be subjected to the throttling based on the
>     host report.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     when there are no servers in overload.  This could happen in the
>     case I mentioned where the realm overload report is triggered by
>     layer 3 congestion.
>
>     My logic was not quite correct, but for a different reason.  There
>     is no reason to do the host throttling if the request has already
>     been throttled by the realm report.
>     It should be as follows:
>
>     For all requests:
>       If the request has not already been throttled and there is a
>     host overload report that applies to the request:
>     One improvement would be to remember the host throttled by the
>     realm abatement algorithm and input that into the server abatement
>       If the request has not already been throttled and there is a
>     host overload report that applies to the request:
>         And in a normal case, the reduction for the realm will be
>         likely lower than the reduction needed for a node. S1 is not
>         overload, S2 is 50% overload, the realm (S1+S2) is overloaded
>         25%. So only the reduction for the Host should apply, why the
>         host-type should prevail over realm-type OLR.
>
>          
>
>         *À :* MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich
>         (NSN - DE/Munich)
>         traffic targeted for that realm, independent of the presence
>         or absence of the destination-host avp.  Is that correct?
>
>         I don't agree with Lionel's proposal.  The realm overload
>         report should take precedence over the host overload report.
>
>         - There is something responsible for tracking the health of
>         the realm.  Call it the "realm overload authority".  The
>         health of the realm can be based on a number of factors
>         including the health of individual servers, individual agents
>         and the network connecting Diameter entities.
>
>         network is congested, for instance, it would instruct agents
>         or servers to send realm overload reports with the expectation
>         that the overall traffic sent to the realm as a whole will be
>         reduced.
>
>         precedence over the health of the servers.  As such, it is
>         likely that requests targeted for a healthy server will be
>         throttled.
>
>         reports in any answer message, not just answers to requests
>         that did not contain a destination-host AVP.
>
>         Steve
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 14:13:03 +0000

Steve,

Ulrich proposal was the following:

Since the text is for Host Report, and as it is introduced, I think original text is better.
Cheers
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: martes, 11 de febrero de 2014 13:41
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Agreed, there is nothing contentious here.  I agree that the report applies only to the application ID included in the message carrying the overload report.

Ulrich's wording isn't clear on which messages are being referenced.  Or I wasn't looking at full context.  It might be better to try to change the proposed wording from:
How about changing Ulrich's proposal from:

"The value of the application-ID in the Diameter Header of new request messages matches the value of the Application-ID is an active overload report."

Steve
On 2/11/14 4:50 AM, [email-masked]<mailto:[email-masked]> wrote:

Lionel

-----Message d'origine-----

Exact, I agree.

Cheers

/MCruz

-----Original Message-----

To: ext Steve Donovan; [email-masked]<mailto:[email-masked]>

Steve,

I do not agree.

e.g.

Ulrich

-----Original Message-----

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

<Ulrich>yes, we agreed on that, so c) is correct and it does not harm

to keep c)</Ulrich>

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 14:19:39 +0000

Lionel,

About first case:

I do not agree on this, since if Destination Host is used, there is no reason to throttle messages if this Host has not provided any OLR.
This is in line with the example used from the beginning:
---------
..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
What is wrong with letting the client
-not throttle host-type requests to S1,
-throttle host type request to S2 with 50% and
-throttle realm type requests wit 25%?
------------

And I think this is what JJ commented:
[JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.

In my opinion, reducing traffic to S1 is wrong.

Regards
/MCruz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: martes, 11 de febrero de 2014 11:57
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi maria-cruz,

   

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : mardi 11 février 2014 11:49 À : [email-masked] Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hello,
I agree with JJ:

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 15:00
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Lionel 

Please see in line

-----Message d'origine-----

   

Lionel

-----Message d'origine-----

Dear  all

JJacques

-----Message d'origine-----

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Tue, 11 Feb 2014 09:07:50 -0600

> I do not agree on this, since if Destination Host is used, there is no reason to throttle messages if this Host has not provided any OLR.
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not
have visibility of the entire realm. 
> -throttle realm type requests wit 25%?
SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.

---

From: <[email-masked]>
Date: Tue, 11 Feb 2014 15:24:57 +0000

Hi Maria Cruz,

Actually I've missed this point. Sorry.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 11 février 2014 16:08
À : [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 15:29:37 +0000

Steve,

Well, it is clear that we do not agree on this.

On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
> Lionel,
>
> About first case:
>
> - If the reacting node has received an indication only for Realm 
> traffic Reduction, apply Realm reduction is for any message, with 
> Destination-Realm and with/without Destination-Host
>
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not have visibility of the entire realm. 
> De : DiME [mailto:[email-masked]] De la part de Maria Cruz 
> Bartolome Envoyé : mardi 11 février 2014 11:49 À : [email-masked] Objet 
> : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hello,
> I agree with JJ:
>
> De : [email-masked] [mailto:[email-masked]] Envoyé 
> : lundi 10 février 2014 14:25 À : TROTTIN, JEAN-JACQUES 
> (JEAN-JACQUES); [email-masked] Objet : RE: [Dime] [dime] #34: Semantics 
> of OC-Report-Type AVP
>
> De : DiME [mailto:[email-masked]] De la part de TROTTIN, 
> JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 10 février 2014 13:56 À : 
> [email-masked] Objet : Re: [Dime] [dime] #34: Semantics of 
> OC-Report-Type AVP
>
> Dear  all
>
> De : DiME [mailto:[email-masked]] De la part de Maria Cruz 
> Bartolome Envoyé : vendredi 7 février 2014 17:15 À : [email-masked] 
>> What is wrong with letting the client -not throttle host-type 
>> requests to S1, -throttle host type request to
>>  Text in clause 4.6  does not fully explain to which requests 
>> overload treatment of a given report type applies.
>>  Proposal:
>>  
>> _____________________________________________________________________
>> _ ___________________________________________________
>>

---

From: <[email-masked]>
Date: Tue, 11 Feb 2014 15:30:41 +0000

So now I understand Ulrich, Maria Cruz and JJ comments.

"My" proposal would force the servers in the realm to always send an OLR just to say "I'm not overloaded" i.e. with the value 0. That is anyway a possibility.
But if we want to avoid that, Realm type must only apply to message without destination host.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 11 février 2014 16:25
À : Steve Donovan; [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Maria Cruz,

Lionel

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 11 Feb 2014 21:52:43 +0000

Dear all

I come back a bit late on this long debate to confirm my position that I share with  Ulrich MCruz Nirav and I think now Lionel and that I again summarize here in these two statements : 
- Host OLR based control applies to requests where Destination Host is known
- Realm OLR based control applies to requests where Destination Host is not known (only the Destination realm).

>From History, we have started by defining the Host report so to control the traffic towards each server,(our main goal), but we observed a difficulty when the reacting node does not know  the host to which a  request is sent and for this  we introduced the realm report. Annex B1 example in the draft is the use case well illustrating  this approach and  which corresponds to the above statements.

Another point which was mentioned, is, for  the reacting node, to keep the throttling based on realm report independent of the throttling based on the host report, this is naturally achieved with the two above statements as we distinguish requests having a destination host from those having not. But if we can apply both reports to the same request, then we need additional rules eg  which report prevails; in the discussion there were also divergence on this point, but we can imagine other rules eg the report that has the highest reduction value prevails, why not in some cases, so a trend to overcomplexify. 

For me the two above statements avoid overlapping between the two reports  and are simple to apply, so I keep my preference for these two statements.

Best regards

JJacques   

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 11 février 2014 16:31
À : MORAND Lionel IMT/OLN; Steve Donovan; [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked] Envoyé : mardi 11 février 2014 16:25 À : Steve Donovan; [email-masked] Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Maria Cruz,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan Envoyé : mardi 11 février 2014 16:08 À : [email-masked] Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 12 Feb 2014 01:11:41 +0200

So are we converging to an agreement here? I could join the
camp of U/MC/N/L/J..

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Thu, 13 Feb 2014 06:35:03 -0600

Ok, Ok, no reason to gang up on me. :-)

What we have here is an overload report to reduce realm routed
requests.  I think we should be explicit in the draft to define it as such.

I am still concerned that we do not have a way to indicate overload of
the realm as a whole.  I'll enter a new trouble ticket to capture this
issue.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Fri, 14 Feb 2014 16:21:27 -0600

(Apologies for coming late to this thread)

On Feb 13, 2014, at 6:35 AM, Steve Donovan <[email-masked]> wrote:

> What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.
> 

At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 

> I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.
> 

I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?

---

From: Steve Donovan <[email-masked]>
Date: Mon, 17 Feb 2014 10:13:19 -0600

I do think it would be a new report type, as it would require different
behavior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this
is the correct approach.  We are creating a good number of relatively
small extensions.  It might lead to the need to pull them all together
in a future version of the DOIC draft/RFC.

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 17 Feb 2014 17:53:14 +0000

Hi

I share the view to analyze the overload of the realm as a whole in a separate extension  and see if this lead to another report type.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 17 février 2014 17:13
À : Ben Campbell
Cc : [email-masked] list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I do think it would be a new report type, as it would require different behavior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this is the correct approach.  We are creating a good number of relatively small extensions.  It might lead to the need to pull them all together in a future version of the DOIC draft/RFC.

Steve

On Feb 13, 2014, at 6:35 AM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 18 Feb 2014 10:11:20 +0000

Hello all,

Overload of the realm is one of the use cases that is required by 3GPP applications.
And I think this should be part of the basic mechanism, or?

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 17 de febrero de 2014 18:53
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 17 février 2014 17:13
À : Ben Campbell
Cc : [email-masked]<mailto:[email-masked]> list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Steve

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Feb 2014 06:48:16 -0600

It shouldn't be much work to add realm overload to the draft.  We would
need to do the following (at a minimum):

- Change that name of the current realm report to something like
"realm-routed".
- Create a new report type of name realm that applies to all traffic
routed to the realm.
- Add a few words in the reporting node section about generation of
realm reports.
- Define the interaction between realm, realm-routed and host report
types.  This is probably the most difficult part that is likely to
require some discussion.

Other then the section on interactions between report types, I don't
think this impacts the existing text so it should fold in pretty cleanly.

I'd be happy to take the first shot at this to be included in the -02
version of the draft if there is consensus to add it.

Steve

On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* lunes, 17 de febrero de 2014 18:53
> *To:* [email-masked]
> I share the view to analyze the overload of the realm as a whole in a
> separate extension  and see if this lead to another report type.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>   
>
>  
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Steve Donovan
> *Envoyé :* lundi 17 février 2014 17:13
> *À :* Ben Campbell
> *Cc :* [email-masked] <mailto:[email-masked]> list
> I'm ok with this being in a separate extension if the group thinks
> this is the correct approach.  We are creating a good number of
> relatively small extensions.  It might lead to the need to pull them
> all together in a future version of the DOIC draft/RFC.
>
> Steve
>
>     On Feb 13, 2014, at 6:35 AM, Steve Donovan <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 18 Feb 2014 13:41:43 +0000

Steve,

first of all I would like to better understand the usecase especially on the reporting side.
Which node would act as a reporting node generating new realm-type reports?
How would this node detect that the complete realm is in overload (and what does that mean? All servers in the realm, also clients? Agents? )?
Would this node be (logically) a single node? If not, how to synchronize different new-realm-type reporting nodes so that they don't report different things to the same reacting node?

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 18, 2014 1:48 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

It shouldn't be much work to add realm overload to the draft.  We would need to do the following (at a minimum):

- Change that name of the current realm report to something like "realm-routed".
- Create a new report type of name realm that applies to all traffic routed to the realm.
- Add a few words in the reporting node section about generation of realm reports.
- Define the interaction between realm, realm-routed and host report types.  This is probably the most difficult part that is likely to require some discussion.

Other then the section on interactions between report types, I don't think this impacts the existing text so it should fold in pretty cleanly.

I'd be happy to take the first shot at this to be included in the -02 version of the draft if there is consensus to add it.

Steve

Best regards
/MCruz

Hi

Best regards

JJacques

Steve

Steve

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Feb 2014 08:54:36 -0600

Ulrich,

All good questions.

I mapped out the use case in a previous email with discussing the
realm-routed overload report type. 

Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm
hoping someone involved in the discussions that lead to that requirement
can speak up on the use case driving the need for realm reports.

The means of detection is out of scope for the DOIC draft, just as it is
for host and realm-routed report types.  We should, however, include
wording to explain how it might be done. 

A few bullet points outlining a proposed solution.  I can put together a
couple of slides explaining this if it would be helpful.

- The method of detection can be based on the collected status of
Diameter nodes in the realm.  It can also be based on the status of the
underlying network.  For instance, if there is a network outage that
reduces the effective throughput of the signaling network, the best
method for handling this might be to signal a realm overload report.

- The network element detecting the realm status is out of scope for the
DOIC document.

- The Diameter node that reports realm overload can be any Diameter node
and is up to the service provider to define.  Assuming we are using
Diameter answer messages to transport the realm reports, it would need
to be either all agents or all servers.  This is to guarantee that all
reacting nodes get the report.

- The method that the reporting node is told that the realm is
overloaded, triggering the realm overload report, is out of scope for
this document.

- Reacting nodes should listen to only one realm overload reporting
node.  It is up to the implementation of the realm overload detection
element to make sure that all reporting nodes have the same state.

One way to model this is for an external element being responsible for
detecting realm overload and signaling the realm overload reporting
nodes of the status using an out of bands mechanism.  All realm overload
reporting nodes would be responsible for sending realm overload
reports.  Reacting nodes would only listen to one of the reporting nodes.

There are also security considerations similar to host reports, except
that an attack using realm overload reports has a much bigger impact
than an attack using host reports.

Steve

On 2/18/14 7:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> How would this node detect that the complete realm is in overload (and
> what does that mean? All servers in the realm, also clients? Agents? )?
>
> Would this node be (logically) a single node? If not, how to
> synchronize different new-realm-type reporting nodes so that they
> don't report different things to the same reacting node?
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, February 18, 2014 1:48 PM
> *To:* [email-masked]
> It shouldn't be much work to add realm overload to the draft.  We
> would need to do the following (at a minimum):
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     I share the view to analyze the overload of the realm as a whole
>     in a separate extension  and see if this lead to another report type.
>
>      
>
>     Best regards
>
>      
>
>     JJacques
>
>       
>
>      
>
>     relatively small extensions.  It might lead to the need to pull
>     them all together in a future version of the DOIC draft/RFC.
>
>     Steve
>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 18 Feb 2014 18:04:43 +0000

Hi all

1)      I come back on this Steve's comment : "Define the interaction between realm, realm-routed and host report types.  This is probably the most difficult part that is likely to require some discussion".
This joins one of  my remarks about the overlapping between different reports in a previous mail and drives to the use cases regarding realm overload:

-          If realm overload is due to server overload, I would think that  our current  mechanism dealing with host report and realm (alias realm-routed) report will address / solve server overload  and in consequence indirectly  address / solve  this overload realm  case

-          if realm overload is due to the overload of Diameter agents, we have discussion and a Steve's  proposal   about  Agent overload. I would also think that by addressing / solving the DA overload, it would also address and solve this overload realm  case.

-          About an underlying  network congestion (eg due to network outage), here REQ 13 mentions that "The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols". So here I am also questioning if  we may have  duplication or overlapping, and what to do .

-          Have we other realm overload use cases?

So my current thinking is  we have first  to identify the various realm  overload use cases and see those actually justifying to add new mechanisms.

2)      I share Ulrich's questions  on how to deal with realm overload. Steve's  answer introduces a high complexity about detecting , evaluate the realm overload  and then which DA are acting etc. The fact to consider many of these points out of the scope does not suppress this complexity (which in addition occurs in an overloaded environment...) . So  I come back to my point 1 about the use cases to address  and the use of the mechanisms for server and DA overload

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 18 février 2014 15:55
À : Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Ulrich,

All good questions.

I mapped out the use case in a previous email with discussing the realm-routed overload report type.

Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm hoping someone involved in the discussions that lead to that requirement can speak up on the use case driving the need for realm reports.

The means of detection is out of scope for the DOIC draft, just as it is for host and realm-routed report types.  We should, however, include wording to explain how it might be done.

A few bullet points outlining a proposed solution.  I can put together a couple of slides explaining this if it would be helpful.

- The method of detection can be based on the collected status of Diameter nodes in the realm.  It can also be based on the status of the underlying network.  For instance, if there is a network outage that reduces the effective throughput of the signaling network, the best method for handling this might be to signal a realm overload report.

- The network element detecting the realm status is out of scope for the DOIC document.

- The Diameter node that reports realm overload can be any Diameter node and is up to the service provider to define.  Assuming we are using Diameter answer messages to transport the realm reports, it would need to be either all agents or all servers.  This is to guarantee that all reacting nodes get the report.

- The method that the reporting node is told that the realm is overloaded, triggering the realm overload report, is out of scope for this document.

- Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.

One way to model this is for an external element being responsible for detecting realm overload and signaling the realm overload reporting nodes of the status using an out of bands mechanism.  All realm overload reporting nodes would be responsible for sending realm overload reports.  Reacting nodes would only listen to one of the reporting nodes.

There are also security considerations similar to host reports, except that an attack using realm overload reports has a much bigger impact than an attack using host reports.

Steve

Ulrich

Steve

Best regards
/MCruz

Hi

Best regards

JJacques

Steve

Steve

DiME mailing list

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Feb 2014 16:30:12 -0600

On Feb 18, 2014, at 12:04 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <[email-masked]> wrote:

> Hi all
>  
> 1)      I come back on this Steve’s comment : “Define the interaction between realm, realm-routed and host report types.  This is probably the most difficult part that is likely to require some discussion”.

I don't think that's necessarily hard as long as you aren't mixing algorithms. I think you will get close enough for our purposes if you apply the "most restrictive" active report to any requests that fall into the overlap of more than one active report. You could get into cross-set calculations, but I don't think the gain in precision would be enough to make it worth the complexity.

OTOH, I don't know what it means to have an overlap between "loss" and "rate". I'd lean towards forbidding that sort of thing, but I'm not sure if it can really be prevented.

> -          if realm overload is due to the overload of Diameter agents, we have discussion and a Steve’s  proposal   about  Agent overload. I would also think that by addressing / solving the DA overload, it would also address and solve this overload realm  case.
> -          About an underlying  network congestion (eg due to network outage), here REQ 13 mentions that “The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols”. So here I am also questioning if  we may have  duplication or overlapping, and what to do .

Nothing proposed so far would _interfere_ with with transport congestion control mechanisms. 

> So my current thinking is  we have first  to identify the various realm  overload use cases and see those actually justifying to add new mechanisms.

I think Steve has offered reasonable justification, especially if 3GPP already has this requirement.

I also think this is important for cross-realm cases, where one realm may not want to share any more detail than "reduce traffic to my entire realm".

> 2)      I share Ulrich’s questions  on how to deal with realm overload. Steve’s  answer introduces a high complexity about detecting , evaluate the realm overload  and then which DA are acting etc. The fact to consider many of these points out of the scope does not suppress this complexity (which in addition occurs in an overloaded environment…) . So  I come back to my point 1 about the use cases to address  and the use of the mechanisms for server and DA overload  

Steve's answers do the opposite--he basically says that those details are out of scope for the IETF. (That doesn't prevent 3GPP from coming up with some.) There are lots of ways one might determine the overload for a realm. It's completely unnecessary to standardize them.

> Would this node be (logically) a single node? If not, how to synchronize different new-realm-type reporting nodes so that they don’t report different things to the same reacting node?
>  
> Ulrich
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Feb 2014 17:16:29 -0600

> - The Diameter node that reports realm overload can be any Diameter node and is up to the service provider to define.  Assuming we are using Diameter answer messages to transport the realm reports,…

I think "any Diameter node" is too broad. It has to be node that is, at least sometimes, in the path for requests for that particular realm+application.  (Although I note that explicit realm and application AVPs in an OLR would fix that ;-)  )

> - The method that the reporting node is told that the realm is overloaded, triggering the realm overload report, is out of scope for this document.

Agreed, although one possible way to do it would be for the reporting node to be an agent that infers general realm overload based on upstream overload information.

> - Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same…

I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.

> There are also security considerations similar to host reports, except that an attack using realm overload reports has a much bigger impact than an attack using host reports.

Yep. IIRC, We already have language in the security considerations that reacting nodes need to properly authorize sources of OLRs. That applies here as well.

(Maybe it's time to propose an "all-realms" report type :-) )

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Feb 2014 06:48:51 +0000

Ben, Steve, all

Let's conclude on #34.
The particular question under discussion here actually belongs to #55

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 11:12:02 -0600

Ben,

One comment below.

Steve

> I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that…
SRD> The reason for this requirement is to handle the likelihood that
each reporting node of the new realm report type will have independent
sequence numbers.  Thus, as long as all reporting nodes report all
updates to the realm overload status, it should be sufficient for a
reacting node to only listen to one of the reporting nodes when
determining if the OLR is new.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Feb 2014 12:08:48 -0600

On Feb 24, 2014, at 11:12 AM, Steve Donovan <[email-masked]> wrote:

> SRD> The reason for this requirement is to handle the likelihood that each reporting node of the new realm report type will have independent sequence numbers.  Thus, as long as all reporting nodes report all updates to the realm overload status, it should be sufficient for a reacting node to only listen to one of the reporting nodes when determining if the OLR is new.

Okay, does that imply an argument for actual timestamps? :-) 

Or a way to make sure the timestamp is scoped to the reporting node?  Do we need to be unique across just time, or time and space?

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Feb 2014 14:55:25 +0000

Ben, Steve, all

I still think we can conclude on #34.

The issue here is independent and is valid for both realm-routed-request reports and realm reports (should we ever agree on them, see #55).  I shall open a new ticket on Multiple Reporting Nodes reporting realm-routed-request reports for the same realm.

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Monday, February 24, 2014 6:12 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Ben,

One comment below.

Steve

On Feb 18, 2014, at 8:54 AM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Feb 2014 09:02:35 -0600

Ulrich,

Sounds good, thanks,

Steve

On 2/26/14 8:55 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> The issue here is independent and is valid for both
> realm-routed-request reports and realm reports (should we ever agree
> on them, see #55).  I shall open a new ticket on Multiple Reporting
> Nodes reporting realm-routed-request reports for the same realm.
>
>  
>
> Ulrich
>
>  
>
> *Sent:* Monday, February 24, 2014 6:12 PM
> *To:* Ben Campbell
> *Cc:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
>     On Feb 18, 2014, at 8:54 AM, Steve Donovan <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Feb 2014 09:15:09 -0600

Given the further discussion, what is the currently proposed conclusion?

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Feb 2014 15:18:58 +0000

#34 	Semantics of OC-Report-Type AVP	Resolved	Agreed - Replace text in section 4.6 with text proposed in the ticket.