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

From: Steve Donovan <[email-masked]>
Date: Wed, 03 Sep 2014 10:45:58 -0500

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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 3 Sep 2014 14:07:22 -0500

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 <[email-masked]> 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Wed, 03 Sep 2014 15:44:43 -0500

Ben,

You are correct.  The definition for host routed needs to be as you 
indicate.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 3 Sep 2014 16:05:58 -0500

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 <[email-masked]> wrote:

> Ben,
> 
> You are correct.  The definition for host routed needs to be as you indicate.
> 
> Steve
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 4 Sep 2014 08:23:23 +0000

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

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Thu, 4 Sep 2014 08:26:15 +0000

Hello Steve,

As discussed before, most of 3GPP delegates prefer to have the report type as optional. So apart from updating the AVP as optional in the other parts of the draft, if we are going to add the following texts, I would propose to rephrase the first paragraph as follows:

A report of type host can be sent to indicate the overload of a specific server for the application-id indicated in the transaction. By default, the overload report is for a specific server. When receiving an OLR for a specific server, 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.

Best Regards,

Susan

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, September 03, 2014 11:46 PM
To: [email-masked]
Subject: [Dime] Proposed additional wording in section 3. Solution Overview

All,

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. By default, the overload report is for a specific server. , 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.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 4 Sep 2014 09:38:07 +0000

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:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: jueves, 04 de septiembre de 2014 10:23
To: ext Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview

Ben,

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 4 Sep 2014 10:27:23 +0000

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:[email-masked]] 
Sent: Thursday, September 04, 2014 11:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: RE: [Dime] Proposed additional wording in section 3. Solution Overview

Steve, Ben, Ulrich,

Regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: jueves, 04 de septiembre de 2014 10:23
To: ext Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview

Ben,

Ulrich

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 4 Sep 2014 10:31:00 +0000

Thanks Ulrich,
Fine to me

/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: jueves, 04 de septiembre de 2014 12:27
To: Maria Cruz Bartolome; ext Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: RE: [Dime] Proposed additional wording in section 3. Solution Overview

MCruz,
I agree.

Ulrich

-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:[email-masked]] 
Sent: Thursday, September 04, 2014 11:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: RE: [Dime] Proposed additional wording in section 3. Solution Overview

Steve, Ben, Ulrich,

Regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: jueves, 04 de septiembre de 2014 10:23
To: ext Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview

Ben,

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Thu, 04 Sep 2014 06:55:22 -0500

Susan,

Lionel called consensus on this so it is considered as already decided 
that the report type is required as part of the overload report.

Please talk to Lionel and/or Jouni if you need an explanation of the 
rough consensus process used within the IETF.

Regards,

Steve

On 9/4/14, 3:26 AM, Shishufeng (Susan) wrote:
>
> Hello Steve,
>
> As discussed before, most of 3GPP delegates prefer to have the report 
> type as optional. So apart from updating the AVP as optional in the 
> other parts of the draft, if we are going to add the following texts, 
> I would propose to rephrase the first paragraph as follows:
>
> A report of type host can be sent to indicate the overload of a 
> specific server for the application-id indicated in the transaction. 
> By default, the overload report is for a specific server. When 
> receiving an OLR for a specific server, 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.
>
> Best Regards,
>
> Susan
>
> server for the application-id indicated in the transaction. By 
> default, the overload report is for a specific server. , 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.
>
> 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.
>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 04 Sep 2014 07:01:58 -0500

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 4 Sep 2014 14:59:05 -0500

I agree, that version is better.