Re: [Dime] Proposed additional wording in section 3. Solution Overview

Maria Cruz,

The wording did assume that the Diameter identity is implicitly a part 
of the overload report.  There are a number of places where that 
definition of overload report makes the wording easier.  That said, I am 
ok with the modifications suggested by Ben and Ulrich.

I'll go ahead and make the change unless I hear objections today.

Steve

On 9/4/14, 5:31 AM, Maria Cruz Bartolome wrote:
> Thanks Ulrich,
> Fine to me
>
> /MCruz
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> Sent: jueves, 04 de septiembre de 2014 12:27
> To: Maria Cruz Bartolome; ext Ben Campbell; Steve Donovan
> Cc: dime@ietf.org
> Subject: RE: [Dime] Proposed additional wording in section 3. Solution Overview
>
> MCruz,
> I agree.
> I would have thought that an overload report contains (not explicitly but implicitly) the Diameter-Id of the overloaded node.
> Anyway, I would propose to replace "the OC-OLR AVP" with "the received OLR of type host" to better reference back to the second sentence.
> This would result in:
>
> A report of type host is sent to indicate the overload of 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 what is referred to in this document as host-routed requests.  This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node.  The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host.
>
> Ulrich
>
> -----Original Message-----
> From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]
> Sent: Thursday, September 04, 2014 11:38 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell; Steve Donovan
> Cc: dime@ietf.org
> Subject: RE: [Dime] Proposed additional wording in section 3. Solution Overview
>
> Steve, Ben, Ulrich,
>
> What do you mean by " the server that matches the Diameter-Id from the overload report "?
> It should be replaced by " the server that matches the Origin-Host AVP of the received
>        message that contained the OC-OLR AVP"
>
> Regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
> Sent: jueves, 04 de septiembre de 2014 10:23
> To: ext Ben Campbell; Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview
>
> Ben,
>
> second sentence should read
>
> "The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Diameter-Id from the overload report."
>
> Ulrich
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Wednesday, September 03, 2014 11:06 PM
> To: Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview
>
> I think this could be fixed with the following change:
>
> Paragraph 1, last two sentences:
>
> This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node.  The reacting node applies overload abatement on the host-routed requests with that would be served by a host with a Diameter Identity that matches the Diameter-Id from the overload report.
>
> Paragraph 2, last sentence:
>
> This is the set of requests that are not host-routed as defined in the previous paragraph.
>
>
> On Sep 3, 2014, at 3:44 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>
>> Ben,
>>
>> You are correct.  The definition for host routed needs to be as you indicate.
>>
>> Steve
>>
>> On 9/3/14, 2:07 PM, Ben Campbell wrote:
>>> I agree with putting text similar to those paragraphs in, but I don't think they are quite right on the distinction between host-routed and realm-routed.
>>>
>>> I think "host routed" requests include any request where the sender has a priori knowledge that the request will land on a particular server. The presence of Destination-Host is the most obvious way to have that knowledge.
>>>
>>> Another way to have the knowledge would be when that host is a direct peer to the reacting node, and the reacting nodes peer-selection algorithm chooses that server. This case is a bit more flexible, in that if the peer-selection algorithm allowed other alternatives, the reacting-node could choose a different peer. It also allows nodes to appropriately handle things like pseudo-sessions, correlated sessions, etc, even if Destination-Host is not present.
>>>
>>>
>>> On Sep 3, 2014, at 10:45 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>>>
>>>> All,
>>>>
>>>> I propose to add the following paragraph to the Solution Overview section.  This would be immediately before the last paragraph and come after the paragraph that introduces the concept of report-types.
>>>>
>>>> This is part of the solution to issue #23 - DOIC behavior for realm overload
>>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>> ----
>>>>
>>>> A report of type host is sent to indicate the overload of 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 what is referred to in this document as host-routed requests.  This is the set of requests that contain a Destination-Host AVP.  The reacting node applies overload abatement on the host-routed requests with a Destination-Host value that matches the Diameter-ID for the overload 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 what is referred to in this document as realm-routed requests.  This is the set of messages that do not contain a Destination-Host AVP and are, as a result, routed based on the Destination-Realm AVP.
>>>>
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>