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

["Nirav Salot (nsalot)" <[e-mail]>]

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:[e-mail]] On Behalf Of Steve Donovan
Sent: Monday, February 10, 2014 11:22 PM
To: [e-mail]; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [e-mail]
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.  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, [e-mail]<mailto:[e-mail]> 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:[e-mail]]
Envoyé : lundi 10 février 2014 15:39
À : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc : [e-mail]<mailto:[e-mail]>
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.

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
On 2/10/14 5:30 AM, [e-mail]<mailto:[e-mail]> wrote:

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:[e-mail]]

Envoyé : dimanche 9 février 2014 13:46

À : Wiehe, Ulrich (NSN - DE/Munich)

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

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





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







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

From: ext Jouni Korhonen [mailto:[e-mail]]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext [e-mail]<mailto:[e-mail]>; Steve Donovan; [e-mail]<mailto:[e-mail]>

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





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]><mailto:[e-mail]> 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?

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%?



Isn't this what Lionel said below?

<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





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:[e-mail]] On Behalf Of ext [e-mail]<mailto:[e-mail]>

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; [e-mail]<mailto:[e-mail]>

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



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:[e-mail]] De la part de Steve Donovan

Envoyé : mercredi 5 février 2014 15:56

À : [e-mail]<mailto:[e-mail]>

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, [e-mail]<mailto:[e-mail]> wrote:

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:[e-mail]]

Envoyé : mardi 4 février 2014 09:55

À : MORAND Lionel IMT/OLN

Cc : [e-mail]<mailto:[e-mail]>

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



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





_________________________________________________________________________________________________________________________



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.

_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dime







_________________________________________________________________________________________________________________________



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.






_________________________________________________________________________________________________________________________



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.