Subject: [Dime] Proposal for new error response for DOIC

From: Steve Donovan <[email-masked]>
Date: Thu, 28 Aug 2014 10:26:15 -0500

All,

One of the open issues is the DOIC behavior when a DOIC node rejects a 
request as a result of an overload condition.

Today, the logical error response would be the DIAMETER_TOO_BUSY 
response.  The issue with this behavior is that it can result in the 
client retrying the request to an alternative peer.

The desired behavior for a request rejected because of overload 
throttling is the same as if the client, acting as a reacting node, 
throttled the request.  As a result, the transaction should not be retried.

The proposal is to define a new protocol error response code called 
DIAMETER_THROTTLED with the defined behavior that the request SHOULD be 
treated as a final response and SHOULD NOT be retried.

This error response could be generated by agents acting as reacting 
nodes or by any reporting node.  A server, for instance, that is in a 
severe overload condition might chose to reject some transactions with 
the DIAMETER_THROTTLED response if the current requested reduction 
included in the overload report is not sufficient.

One issue with this proposal is backwards compatibility with Diameter 
nodes that do not support DOIC and, as such, would not understand the 
DIAMETER_THROTTLED response.  The proposal to address this is to make 
the generation of the DIAMETER_THROTTLED error response conditional.  
This is an attempt at wording this conditional behavior:

A DOIC node SHOULD use the DIAMETER_THROTTLED error response for 
transactions that are throttled and the DOIC node knows that there is a 
DOIC reacting node able to process the error response.  The DOIC node 
generating the DIAMETER_THROTTLED error response determines that there 
there is a DOIC reacting node by the presence or absence of an 
OC-Supported-Features AVP in the request message for the transaction.

If there is no OC-Supported-Features AVP in the request message for a 
transaction that is throttled then the DOIC node SHOULD send the 
DIAMETER_TO_BUSY response message.

Assuming we get agreement on the proposal then I'll come back with 
detailed wording proposals for the DOIC specification.

Regards,

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 28 Aug 2014 15:34:23 +0000

Steve,

I support the principle of the proposal - DOIC node should use the newly defined error code towards the DOIC supporting client.

Should we explicitly specify that the request may be rejected even if the overload report was provided by the DOIC node?

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Thursday, August 28, 2014 8:56 PM
To: [email-masked]
Subject: [Dime] Proposal for new error response for DOIC

All,

One of the open issues is the DOIC behavior when a DOIC node rejects a request as a result of an overload condition.

Today, the logical error response would be the DIAMETER_TOO_BUSY response.  The issue with this behavior is that it can result in the client retrying the request to an alternative peer.

The desired behavior for a request rejected because of overload throttling is the same as if the client, acting as a reacting node, throttled the request.  As a result, the transaction should not be retried.

The proposal is to define a new protocol error response code called DIAMETER_THROTTLED with the defined behavior that the request SHOULD be treated as a final response and SHOULD NOT be retried.

This error response could be generated by agents acting as reacting nodes or by any reporting node.  A server, for instance, that is in a severe overload condition might chose to reject some transactions with the DIAMETER_THROTTLED response if the current requested reduction included in the overload report is not sufficient.

One issue with this proposal is backwards compatibility with Diameter nodes that do not support DOIC and, as such, would not understand the DIAMETER_THROTTLED response.  The proposal to address this is to make the generation of the DIAMETER_THROTTLED error response conditional.  
This is an attempt at wording this conditional behavior:

A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transactions that are throttled and the DOIC node knows that there is a DOIC reacting node able to process the error response.  The DOIC node generating the DIAMETER_THROTTLED error response determines that there there is a DOIC reacting node by the presence or absence of an OC-Supported-Features AVP in the request message for the transaction.

If there is no OC-Supported-Features AVP in the request message for a transaction that is throttled then the DOIC node SHOULD send the DIAMETER_TO_BUSY response message.

Assuming we get agreement on the proposal then I'll come back with detailed wording proposals for the DOIC specification.

Regards,

Steve

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 28 Aug 2014 14:57:09 -0500

I agree with doing this. 

But I'm also concerned that the backwards compatibility issue you mention means that this doesn't help in what is potentially the biggest use case for throttling at an agent. that is, an agent throttling on behalf of a non-supporting client.

One approach would be to define DIAMETER_THROTTLED in a separate update to RFC 6733, in hopes that people who aren't ready to fully support DOIC might at least support the new error. (Yeah, I know that's a long shot.) Another might be to write some additional (BCP?) guidance on how clients should handle TOO_BUSY. 

On Aug 28, 2014, at 10:26 AM, Steve Donovan <[email-masked]> wrote:

> One issue with this proposal is backwards compatibility with Diameter nodes that do not support DOIC and, as such, would not understand the DIAMETER_THROTTLED response.  The proposal to address this is to make the generation of the DIAMETER_THROTTLED error response conditional.  This is an attempt at wording this conditional behavior:
>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 29 Aug 2014 07:58:37 +0000

Dear all

A few remarks

1) I am also questioning about  the backward compatibility case where a DA is acting on behalf of a non DOIC client.
The  solution  Steve proposes , to my view, also work in this case: if the DA throttles a request, it will generate a Diameter too busy to the client, so with the possible consequence that the non DOIC client do a retry to an alternate destination. But we cannot avoid it,  this is the non DOIC client existing behavior.
In any case we should avoid to send a new Diameter error to a non DOIC client as it can result to a non predictable behavior. 

Among the possible solutions, one is to continue to use Diameter to busy in all cases but with, in addition,  a new  AVP (a "DOIC diagnostic" AVP) which means message throttled in a DOIC case, which is generated by the DOIC reporting node, supported by a DOIC reacting node (which will not do retry to another destination)   and ignored by a non DOIC client. This AVP may be in the future take other values if needed.   

2) some remark about the new retry.
- I think a DA can do a retry in the case it has received a realm only request (without destination host), and if not successful, will sent the new diameter error to the client. But if instead,  the client had received a classical Diameter too busy, it will also not do a retry to another destination (as it only knows the realm, but not the server), so Diameter too busy seems here acceptable, isn't it?
- If the client has sent a request with a Destination host, which is rejected by the reporting node (so with the new Diameter error) I do not think that a DA can do a retry to another destination host (as the client has requested a specific Destination host). Am I wrong here? But the client may eventually do a retry towards another destination host, according to the application case, so not so in line with the meaning of the new Diameter error requesting no retry.
- a server rejecting a request, will generate the new Diameter error, but the intermediate DA receiving this error  may nevertheless do a retry to another destination a retry, so the meaning of the new Diameter error does not always mean "no retry" for a reacting node. 
 To have your view on these remarks.

Best raegrds.

JJacques     

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : jeudi 28 août 2014 21:57
À : Steve Donovan
Cc : [email-masked]
Objet : Re: [Dime] Proposal for new error response for DOIC

I agree with doing this.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 29 Aug 2014 08:37:50 +0000

To come back on my point 2) , and reviewing the definition of Diameter too busy in RFC 6733. 
	DIAMETER_TOO_BUSY 3004
	When returned, a Diameter node SHOULD attempt to send the message
      to an alternate peer.  This error MUST only be used when a
      specific server is requested, and it cannot provide the requested
      service

Does it mean that the request is sent to the same specific server but via an alternate path (the request contains the same Realm and host destinations AVP but is sent to another peer (another DA) , or can the alternate peer corresponds to another server (so another destination host). According to the understanding, this  impacts my Point 2) remarks

Best regards

JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : vendredi 29 août 2014 09:59
À : Ben Campbell; Steve Donovan
Cc : [email-masked]
Objet : Re: [Dime] Proposal for new error response for DOIC

Dear all

A few remarks

 
Best raegrds.

JJacques     

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell Envoyé : jeudi 28 août 2014 21:57 À : Steve Donovan Cc : [email-masked] Objet : Re: [Dime] Proposal for new error response for DOIC

I agree with doing this.