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

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:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> 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>
 I am OK with Lionel's
"wording" here.

- Jouni

>  
>  
>  
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com
> Sent: Wednesday, February 05, 2014 4:14 PM
> To: Steve Donovan; dime@ietf.org
> 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:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoyé : mercredi 5 février 2014 15:56
> À : dime@ietf.org
> 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, lionel.morand@orange.com 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:trac+dime@trac.tools.ietf.org] 
> Envoyé : mardi 4 février 2014 09:55
> À : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> 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
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime