Subject: [Dime] Ulrich's suggested change #16

From: Steve Donovan <[email-masked]>
Date: Tue, 09 Dec 2014 08:06:25 -0600

Ulrich,

For your suggested change #16:

Section 4.2.2, 5th and 6th paragraph:
Existing text:
    If the request is a host-routed request then the reacting node SHOULD
    apply throttling abatement treatment to the request.
  
    If the request is a realm-routed request then the reacting node
    SHOULD apply diversion abatement treatment to the request.

Comment: I don't think so. If the reacting node selects the server and
then detects that the selected server is overloaded and then detects that
the request does not survive (i.e. is subject to abatement), then the reacting
node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
If the reacting node does not select the server (either a. because the server was
already selected by a downstream node, or b. because the server will be selected
by an upstream node) then there is no point in applying diversion and the reacting
node SHOULD apply throttling of requests that do not survive.

Proposal: replace the paragraphs with:
    If the reacting node does not select the server then it SHOULD apply
    throttling abatement to the request.

    If the reacting node selects the server then it SHOULD apply diversion
    abatement treatment (i.e. select an alternative server if possible) to
    the request.

Diversion is not selecting an alternative node to handle the request.  
Diversion is selecting an alternative route to the selected node.

Whether it is appropriate to select an alternative node for a request is 
an application decision that probably changes on a per command-code 
basis within the application.  Logic like this is outside the scope of 
the DOIC specification.

The text is correct based on the definition of diversion.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 9 Dec 2014 17:29:51 +0000

Steve,
yes, then, maybe, the definition of Diversion is not correct?
What are other people's views?

My assumption was:
If a host is overloaded, it does not help to direct traffic to that host via a different path.
If a realm is overloaded, it does not help to direct traffic to that realm via a different path.
If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.
If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.

With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.

Regards
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 3:06 PM
To: [email-masked]
Subject: [Dime] Ulrich's suggested change #16

Ulrich,

   If the reacting node selects the server then it SHOULD apply diversion
   abatement treatment (i.e. select an alternative server if possible) to
   the request.
Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.  

Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 10 Dec 2014 07:06:30 -0600

Ulrich,

I agree with your assumptions below.  For the third one, the only time 
it is possible, at least from a DOIC perspective, to send to another 
host is if it is a realm-routed request.  I might also change the "not 
overloaded" to "less overloaded".

I do think the statements can be improved to differentiate between 
behavior for host reports and realm reports.

How about the following:

    For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
    apply throttling abatement treatment to the request.

    For OLRs of type host, If the request is a realm-routed request then the reacting node
    SHOULD apply diversion abatement treatment to the request.

    For OLRs of type realm, the reacting node SHOULD
    apply throttling abatement treatment to the request, independent of the type (host-routed or
    realm-routed) of request.

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Dec 2014 17:42:56 -0600

> On Dec 9, 2014, at 8:06 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ulrich,
> 

Hmm. Isn't that only true for the proposed Peer-Report type in the Agent draft?

> Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outsid…

So how does it work for existing applications? But I agree in principle. I somehow missed that we had 2119 language around this. I think the choice to apply diversion vs throttling should be local policy. We don't need to state it normatively.

> The text is correct based on the definition of diversion.

I'm not sure we have that definition right.

> 
> Regards,
> 
> Steve
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 11 Dec 2014 12:40:44 +0000

Steve,
I find your new proposal more confusing.

I still think my original proposal is preferred. In addition the definition for diversion may need to be updated.

Regards
Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, December 10, 2014 2:07 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #16

Ulrich,

I agree with your assumptions below.  For the third one, the only time it is possible, at least from a DOIC perspective, to send to another host is if it is a realm-routed request.  I might also change the "not overloaded" to "less overloaded".

I do think the statements can be improved to differentiate between behavior for host reports and realm reports.

How about the following:

Regards,

Steve

Steve,

My assumption was:

Regards

Ulrich

To: [email-masked]<mailto:[email-masked]>

Ulrich,

Existing text:

   the request.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 08:07:02 -0600

Ben,

Diversion works for realm-routed requests in response to host reports.

See my proposed wording sent in an early email.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 08:13:16 -0600

Ulrich,

There are two report types defined in the document -- host and realm.

There are two types of requests - host-routed and realm-routed.

This leaves four combinations for requests that are selected for 
abatement treatment:

If there is a host report and the request is host-routed then the 
abatement treatment should be to throttle the request.

If there is a host report and the request is realm-routed then the 
abatement treatment should be to divert the request.

If there is a realm report and the request is host-routed then the 
abatement treatment should be to throttle the request.

If there is a realm report and the request is realm-routed then the 
abatement treatment should be to divert the request.

If we agree to the above then we can come up with the proper wording.

Steve

On 12/11/14, 6:40 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> I still think my original proposal is preferred. In addition the 
> definition for diversion may need to be updated.
>
> Regards
>
> Ulrich
>
> *From:*ext Steve Donovan [mailto:[email-masked]]
> *Sent:* Wednesday, December 10, 2014 2:07 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
> *Subject:* Re: [Dime] Ulrich's suggested change #16
>
> Ulrich,
>
>     To:[email-masked]  <mailto:[email-masked]>
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Dec 2014 12:55:14 -0600

> On Dec 11, 2014, at 8:07 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ben,
> 

The original language did not discriminate on report-type. But I see you've sent a text proposal that does, so I will reply there.

I still take issue with your assertion that diversion is not about server selection. I think for the context of this section, it is exactly about server selection.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Dec 2014 13:03:30 -0600

> On Dec 10, 2014, at 7:06 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ulrich,
> 

Personally, I think that should be non-normative. Or if normative, no stronger than MAY. I agree it's a good choice, but I think we can leave it to the market to enforce.

I think there when we distinguish request-type, we need to consider _when_. For example, an agent may _receive_ a realm routed request but _send_ a host-routed request. And for a client, that may be even more subtle.

This really does seem like a case of server selection.

>    realm-routed) of request.

Again, I think this should not be normative. In this case this is pretty much a statement of fact--you simply cannot reasonably divert given the way that Diameter routing works.  I suppose there might be a case where a node has some magical knowledge that realm2 can handle anything that realm1 can, and could divert to a different realm (which we probably still don't want to forbid.)

>> From: DiME [
>> mailto:[email-masked]
>> ] On Behalf Of ext Steve Donovan
>> To: 
>> [email-masked]

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 13:27:12 -0600

> I still take issue with your assertion that diversion is not about server selection. I think for the context of this section, it is exactly about server selection.
Yes, it feeds into server selection.  It does not apply if server 
selection has already been done, either by a previous transaction or by 
a previous Diameter node.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 13:36:38 -0600

> Personally, I think that should be non-normative. Or if normative, no stronger than MAY. I agree it's a good choice, but I think we can leave it to the market to enforce.
If we make it non normative then we probably need an additional 
statement along the lines of "the reacting node MUST attempt to reduce 
traffic by the amount requested in the OLR" if we don't already have it 
somewhere else in the document.
> This really does seem like a case of server selection.
I don't think it's that subtle.  If server selection hasn't already 
happened for a request and that request is selected for abatement and 
the request would have otherwise been routed to an overloaded host then 
the request should/may be diverted to another server.

Server selection could have happened as a result of a previous 
transaction specifying the host for subsequent transactions or by the 
presence of the Destination-Host in the message when it arrives at an 
agent.  It could have also already happened as a result of configuration.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Dec 2014 13:45:28 -0600

> On Dec 11, 2014, at 1:36 PM, Steve Donovan <[email-masked]> wrote:
> 
> 
> If we make it non normative then we probably need an additional statement along the lines of "the reacting node MUST attempt to reduce traffic by the amount requested in the OLR" if we don't already have it somewhere else in the document.

Agreed

> I don't think it's that subtle.  If server selection hasn't already happened for a request and that request is selected for abatement and the request would have otherwise been routed to an overloaded host then the request should/may be diverted to another server.
> 
> Server selection could have happened as a result of a previous transaction specifying the host for subsequent transactions or by the presence of the Destination-Host in the message when it arrives at an agent.  It could have also already happened as a result of configuration.

In the case of a client, the decision on whether to divert vs just not send a request may be heavily influenced by the client application.  (Not necessarily the _Diameter_ application.)  In the case of either, a node might have local knowledge that a 2nd server can handle everything the first server can handle. Even if a downstream node performed server selection, a node with such knowledge might override it. We don't necessarily need to talk about that sort of thing, but we should avoid language that forbids it.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 15 Dec 2014 20:42:33 +0000

Steve,
can you please summarize the status of #16. I'm getting lost.

Regards
Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, December 11, 2014 8:45 PM
To: Steve Donovan
Cc: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #16

Agreed

---

From: Steve Donovan <[email-masked]>
Date: Tue, 16 Dec 2014 08:54:24 -0600

Ulrich,

I still think the following statements are sufficient:

    For OLRs of type host, if the request is a realm-routed request then the reacting node
    SHOULD apply diversion abatement treatment to the request.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Dec 2014 09:09:42 +0000

Steve,

I'm still not convinced.

Another proposal:

If diversion abatement treatment is possible (i.e. a different path for the request can be selected where the overloaded node is not part of the different path), then the reacting node SHOULD apply diversion abatement treatment to the request. Otherwise the reacting node SHOULD apply throttling abatement treatment to the request. 

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Tuesday, December 16, 2014 3:54 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #16

Ulrich,

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 19 Dec 2014 18:07:28 +0000

Hello all,

I agree with Ulrich proposal.
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: jueves, 18 de diciembre de 2014 10:10
To: ext Steve Donovan; ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #16

Steve,

I'm still not convinced.

Another proposal:

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, December 16, 2014 3:54 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #16

Ulrich,

Regards,

Steve

On 12/15/14, 2:42 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Again, I think this should not be normative. In this case this is 
>>> pretty much a statement of fact--you simply cannot reasonably divert 
>>> given the way that Diameter routing works. I suppose there might be 
>>> a case where a node has some magical knowledge that realm2 can 
>>> handle anything that realm1 can, and could divert to a different 
>>> realm (which we probably still don't want to forbid.)
>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>>> Comment: I don't think so. If the reacting node selects the server 
>>>>> and then detects that the selected server is overloaded and then 
>>>>> detects that the request does not survive (i.e. is subject to 
>>>>> abatement), then the reacting node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
>>>>> If the reacting node does not select the server (either a. because 
>>>>> the server was already selected by a downstream node, or b. 
>>>>> because the server will be selected by an upstream node) then 
>>>>> there is no point in applying diversion and the reacting node SHOULD apply throttling of requests that do not survive.
>>>>>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 22 Dec 2014 08:29:56 -0600

I've made this change.  It will be in the next version of -06 that 
should come out today.

Steve