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

[Steve Donovan <[e-mail]>]

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

On 2/11/14 5:11 PM, Jouni Korhonen wrote:
> So are we converging to an agreement here? I could join the
> camp of U/MC/N/L/J..
>
> - Jouni
>
> On Feb 11, 2014, at 11:52 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]> wrote:
>
>> 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:[e-mail]] De la part de [e-mail]
>> Envoyé : mardi 11 février 2014 16:31
>> À : MORAND Lionel IMT/OLN; Steve Donovan; [e-mail]
>> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>
>> 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:[e-mail]] De la part de [e-mail] Envoyé : mardi 11 février 2014 16:25 À : Steve Donovan; [e-mail] Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>
>> Hi Maria Cruz,
>>
>> Actually I've missed this point. Sorry.
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : DiME [mailto:[e-mail]] De la part de Steve Donovan Envoyé : mardi 11 février 2014 16:08 À : [e-mail] Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>
>>
>> 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
>>>
>>> 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. 
>>> 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.
>> SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.
>>> Regards
>>> /MCruz
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> Sent: martes, 11 de febrero de 2014 11:57
>>> To: Maria Cruz Bartolome; [e-mail]
>>> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>> Hi maria-cruz,
>>>
>>> JJ agreed on the following approach:
>>>
>>> - 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.
>>>
>>> - 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.
>>> [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
>>>
>>> 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.
>>>
>>> What is the issue with this approach?
>>>
>>> Regards,
>>>
>>> Lionel
>>>
>>> -----Message d'origine-----
>>> De : DiME [mailto:[e-mail]] De la part de Maria Cruz 
>>> Bartolome Envoyé : mardi 11 février 2014 11:49 À : [e-mail] Objet 
>>> : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>> Hello,
>>> I agree with JJ:
>>>
>>> - 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.
>>>
>>> [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:[e-mail]] On Behalf Of TROTTIN, 
>>> JEAN-JACQUES (JEAN-JACQUES)
>>> Sent: lunes, 10 de febrero de 2014 15:00
>>> To: [e-mail]
>>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>> Hi Lionel
>>>
>>> Please see in line
>>>
>>> -----Message d'origine-----
>>> De : [e-mail] [mailto:[e-mail]] Envoyé 
>>> : lundi 10 février 2014 14:25 À : TROTTIN, JEAN-JACQUES 
>>> (JEAN-JACQUES); [e-mail] Objet : RE: [Dime] [dime] #34: Semantics 
>>> of OC-Report-Type AVP
>>>
>>> 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 [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.
>>>
>>> - 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.
>>> [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
>>>
>>> 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:[e-mail]] De la part de TROTTIN, 
>>> JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 10 février 2014 13:56 À : 
>>> [e-mail] Objet : Re: [Dime] [dime] #34: Semantics of 
>>> OC-Report-Type AVP
>>>
>>> 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:[e-mail]] De la part de Maria Cruz 
>>> Bartolome Envoyé : vendredi 7 février 2014 17:15 À : [e-mail] 
>>> Objet : 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:[e-mail]] On Behalf Of Wiehe, Ulrich 
>>> (NSN - DE/Munich)
>>> Sent: viernes, 07 de febrero de 2014 14:13
>>> To: ext Jouni Korhonen
>>> Cc: [e-mail]
>>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>>
>>>
>>> -----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]; Steve Donovan; [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]> 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:[e-mail]] On Behalf Of ext 
>>>> [e-mail]
>>>> Sent: Wednesday, February 05, 2014 4:14 PM
>>>> To: Steve Donovan; [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] 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] 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]
>>>> 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]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> [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.
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [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.
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>> _______________________________________________
>> DiME mailing list
>> [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.
>>
>> _______________________________________________
>> DiME mailing list
>> [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.
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>