Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host

[Ben Campbell <[e-mail]>]

Hi Ulrich,

I think I agree with your intent, but I think the text has gotten more complicated than it needs to be. Here's a proposed alternative:

In 6.6:

0	A host report. The reacting node applies overload abatement to the set of  "host-routed" requests (see Section 3)  that would otherwise
	be served by a node with a Diameter-Identity that matches the Origin-Host AVP value of the Diameter answer message
	that contained the report.

1	A realm report. The reacting node applies overload abatement to the set of "realm-routed" requests (see Section 3), where the
	Destination-Realm AVP value from the request matches the Origin-Realm AVP value of the Diameter answer message that 
	contained the 	report.

Then, replace the 2nd and 3rd to last paragraphs and the last line of the 4th to last paragraph of Section 3 with the following:

This document defines report types for overload of a specific server, and for overload of an entire realm.

A request is considered to be "host-routed" by a Diameter node if that node has advance knowledge that the request will be served by a particular destination. There are several ways a node can know this. For example, the request could contain a Destination-Host AVP that matches the destination. The sending node may perform final server selection.. Or the sending node could be aware of some routing policy that will force a request to go to the particular destination. (e.g., perhaps all requests for a particular user go to a specific server).

A request is considered to be "realm-routed" by a Diameter node if that node does not know the actual destination for the request. For example, the sending node may forward the request to an agent, based on the routing table entry for the request's application and realm. The sending node may have no idea where the agent might forward the request.

The distinction of whether a given request is "host-routed" or "realm-routed" is from the perspective of a particular node sending node. For example, a request may be "realm-routed" from the perspective of the client, but "host-routed" from the perspective of an agent that performs the final server selection. In general, any "realm-routed" request will eventually become a host-routed request as it traverses a Diameter network.

A report of type "host" is sent to request a reduction of offered load for a specific server for the application-id indicated in the transaction.  When receiving an OLR of type "host", a reacting node applies overload abatement to host routed requests that would otherwise go to the overloaded server.  The reacting node applies overload abatement to the set of "host-routed" requests that the reacting node knows will be served by the server that matches the Origin-Host AVP of the message that contained report.

A report type of "realm" is sent to indicate the overload of all servers in a realm for the application-id.  When receiving an OLR of type "realm", a reacting node applies overload abatement to the set of "realm-routed" requests destined for the realm indicate by the Origin-Realm AVP of the message that contained the report.



On Sep 26, 2014, at 12:37 PM, Wiehe, Ulrich (NSN - DE/Munich) <[e-mail]> wrote:

> Mcruz, JJ,
> 
> Maybe I missed your point, but my understanding is a bit different. 
> Please see the attached proposal.
> 
> Best regards
> Ulrich
> 
> -----Original Message-----
> From: DiME [mailto:[e-mail]] On Behalf Of ext Maria Cruz Bartolome
> Sent: Friday, September 26, 2014 11:58 AM
> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [e-mail]; [e-mail]
> Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host
> 
> Dear JJ, all
> 
> I think I understand your concern.
> I modified text in clause 6.6 to clarify this point. Attached.
> Let me know your opinions.
> Best regards
> /MCruz
> 
> 
> -----Original Message-----
> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[e-mail]] 
> Sent: viernes, 26 de septiembre de 2014 10:12
> To: Maria Cruz Bartolome; [e-mail]; [e-mail]
> Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host
> 
> 
> Hi Maria Cruz
> 
> 1) The hereafter proposed text  is in a sub part of section 6.6 addressing  the overload treatment when the  OC-report type indicates realm report so according to a Realm type OLR. The proposed  text mentions "...Origin-Host AVP of the received message that contained the OC-OLR AVP". This  OC-OLR AVP can be understood  as the Realm type OLR subject of this section 6.6 subpart (this was my first reading), but it is another report which is a host type OLR generated by this peer. 
> As you said we have to distinguish when either a host or a realm report to be applied, so here the proposal is to exclude from the text the case where the reacting node has an active type Host type OLR of which the Origin Host match the peer identity, as for this case the host type OLR will be applied. On this basis I would propose write "Host type OC-OLR AVP" as hereafter.   
> 
> "The Destination-Host AVP is absent in the request and the value of peer identity associated with the connection used to send the request does not match the value of the Origin-Host AVP of a received message that contained a Host type OC-OLR AVP"
> 
> 2) When thinking a bit more to this case where the reacting node is directly connected to the reporting node (eg a Client directly connected to two or more servers, without intermediate DA, or a DA acting as a reacting node directly connected to servers). The servers usually only send Host type reports (I know there  is a  debate on servers sending realm reports), so the reacting node will not receive Realm reports.  For requests for which there is no destination Host, the reacting node will select the peer according to the host OLRs  it has or not for each of the peers (eg a peer that is not overload or with a small overload )  and then apply the abatement/throttling according to the Host type OLR of this peer. I think we have the same understanding.       
> 
> 
> Best regards
> 
> JJacques 
> 
> -----Message d'origine-----
> De : Maria Cruz Bartolome [mailto:[e-mail]]
> Envoyé : jeudi 25 septembre 2014 18:28
> À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [e-mail]; [e-mail]
> Objet : RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host
> 
> Dear JJ,
> 
> I do not understand your point.
> 
> Proposed clarification has the purpose to allow a reacting node to distinguish when either a host or a realm report shall apply.
> 
> Some time ago we based such a distinction on the presence (meaning host report) or absence (meaning realm report).
> Now we have covered the case for host reports when the host is absent but it refers to the directly connected peer. Therefore, just absence does not allow the reacting node to identify it has to apply a realm report.
> 
> Let me know if this clarifies, or if I may be missing your point.
> Thanks
> /MCruz
> 
> 
> -----Original Message-----
> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[e-mail]]
> Sent: viernes, 12 de septiembre de 2014 14:13
> To: [e-mail]; [e-mail]; Maria Cruz Bartolome
> Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host
> 
> Hi MCruz
> 
> The proposed  text applies to the realm report. 
> 
> Realm OLRs (in particular with same seq number) may be conveyed in answers with different Origin-host (but with same Origin realm), so what means to refer "to the Origin-Host AVP of the received message that contained the (realm type) OC-OLR AVP". This is different  from the Host report, where the host type OC-OLR always refers to the origin host  of the answer.
> 
> Can you  clarify and give a use case / topology case.
> 
> Best regards
> 
> JJacques
> 
> 
> -----Message d'origine-----
> De : DiME [mailto:[e-mail]] De la part de Steve Donovan Envoyé : vendredi 5 septembre 2014 16:16 À : [e-mail]; [e-mail]; [e-mail] Objet : Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host
> 
> I agree.
> 
> On 9/5/14, 2:40 AM, dime issue tracker wrote:
>> #69: Report Type - Realm, with absent Destination-Host
>> 
>>  In clause 6.6, host report was updated to add:
>> 
>>  ... or the Destination-Host is
>>        not present in the request but the value of peer identity
>>        associated with the connection used to send the request matches
>>        the value of the Origin-Host AVP of the received message that
>>        contained the OC-OLR AVP.
>> 
>>  but this clarification needs to be included as well for realm report.
>> 
>>  Original text:
>> 
>>     1  A realm report.  The overload treatment should apply to requests
>>        for which all of the following conditions are true:
>> 
>>        The Destination-Host AVP is absent in the request.
>> 
>>        ...
>> 
>>  Proposed text:
>> 
>>     1  A realm report.  The overload treatment should apply to requests
>>        for which all of the following conditions are true:
>> 
>>        The Destination-Host AVP is absent in the request and the the value
>>  of peer identity associated with the connection used to send the request
>>  does not match the value of the Origin-Host AVP of the received message
>>  that contained the OC-OLR AVP.
>> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
> <OC-Report-Type clause 6-6 UW.docx>_______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime