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

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 1 Sep 2014 21:21:53 +0000

Dear JJ, all,

My understanding is that "alternate peer" in the TOO_BUSY description is interpreted as either a new destination_host, or a new server that provides service to the same realm.
Then, I think that already the standardized behavior for a reacting node when it receives TOO_BUSY may be enough. It is not explicitly mentioned that retransmissions to the same "peer" should be avoid, but a different action is requested. 
Therefore, I am not sure we really need to define a new error, just to request the reacting node to throttle if required, since in my opinion this is already implied by TOO_BUSY description by "SHOULD". If this attempt is not possible or not successful (for any reason), then reacting node will throttle this request.

As a conclusion, in my opinion, we do not need a new error. If you do not agree nowadays TOO_BUSY description is enough we could extend/clarify this description, either updating RFC or with new additional guidelines. 
Apart from that, take into account TOO_BUSY is already an indication of overload, and this is part of the main RFC, then if we need this requires some clarification, I think this should not be constraint to the new DOIC draft.

Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: viernes, 29 de agosto de 2014 10:38
To: Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposal for new error response for DOIC

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

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. 

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:

> 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

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

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

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

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 2 Sep 2014 02:39:14 +0000

I don't have a strong opinion here but I still prefer to have a new error response code specifically for the request rejected due to overload for the following reason:
- TOO_BUSY can be used already today due to other than overload reason as well. Additionally, it does not prevent the sender from retransmitting the same request, and this does not help specifically in the overload scenario.
- New error response code will also allow the operator/system administrator to quantify the rejected requests while in the overload. This will further allow the fine tuning of the overload algorithm or the prediction mechanism at the overloaded node (so that more accurate overload-reduction-metric can be advertised or a different overload control algorithm can be used and fewer requests may be rejected).

These are the arguments we used during GTP-C overload control work in 3GPP to define a new GTP-C error cause code.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, September 02, 2014 2:52 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposal for new error response for DOIC

Dear JJ, all,

Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: viernes, 29 de agosto de 2014 10:38
To: Ben Campbell; Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposal for new error response for DOIC

Best regards

JJacques

-----Message d'origine-----

Dear all

A few remarks

 
Best raegrds.

JJacques     

-----Message d'origine-----

I agree with doing this.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 03 Sep 2014 09:02:07 -0500

Maria Cruz,

I don't have the same interpretation.  A peer has a direct connection to 
the client.  If a client is connected to multiple agents then it can be 
configured to have multiple routes to the same destination-host.  If it 
gets a TOO_BUSY from one of these routes than it is supposed to attempt 
to send the request to the other route.

The new error response code would prevent this attempt to send the 
request to the alternative route as the client has already been told 
that the server is overloaded.

I also agree with Nirov that having the new error response improves the 
operators ability to fine tune DOIC usage.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 3 Sep 2014 13:57:45 -0500

The problem with DIAMETER_TOO_BUSY, is that the definition is unclear, and different implementations have treated it differently.

Steve is correct that for Diameter, "peer" is defined to be a diameter host that you share a direct transport (TCP or SCTP) with. That is, it means the next hop. But the definition of DIAMETER_TOO_BUSY says the following:

     "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. "

This seems nonsensical. "Specific server is requested" seems to mean that Destination-Host is present. Assuming the antecedent of "it" in "... it cannot..." refers to that server, then sending to an alternate peer will _never_ help.

To further confuse things, RFC 3539 defines a "busy" message semantic that means pretty much what Maria described, except that it means the server is too busy for _any_ request, not just requests for a particular service. I suspect Maria is right that the intent of DIAMETER_TOO_BUSY was to provide the RFC 3539 "busy" semantic. But unfortunately, that's not what the words say--as it is, it seems like a merger of "busy" and "can't forward".

As a result, implementors try to figure out what 6733 "really" meant, and of course came up with different, non-interoperable interpretations. For backwards compatibility, I think the best way to clarify DIAMETER_TOO_BUSY is to deprecate it.

On Sep 3, 2014, at 9:02 AM, Steve Donovan <[email-masked]> wrote:

> Maria Cruz,
> 
> I don't have the same interpretation.  A peer has a direct connection to the client.  If a client is connected to multiple agents then it can be configured to have multiple routes to the same destination-host.  If it gets a TOO_BUSY from one of these routes than it is supposed to attempt to send the request to the other route.
> 
> The new error response code would prevent this attempt to send the request to the alternative route as the client has already been told that the server is overloaded.
> 
> I also agree with Nirov that having the new error response improves the operators ability to fine tune DOIC usage.
> 
> Steve
>

---

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

Would DIAMETER_THROTTLED apply to future messages? Does it need a "Retry-After" concept?