Re: [Dime] Issue #27 - Result code sent when agent throttles message

[Steve Donovan <[e-mail]>]

All,

Do we have any thoughts on the options outlined below?

Regards,

Steve

On 3/24/14, 3:37 PM, Steve Donovan wrote:
> All,
>
> We don't have a clean solution for this as existing error result codes 
> do not get the desired behavior of the reacting node not retrying the 
> request on another path, if available.
>
> The proposal has been made that we propose an extension to 6733 to 
> introduce a new result code.  This would be something like:
>
>    DIAMETER_REQUEST_THROTTLED  3011
>
>     A request was received by an agent and the agent determined that 
> the request needed to be throttled due to an existing overload
>     condition.  The client SHOULD NOT attempt to retry the request and 
> the client SHOULD NOT attempt to sent the request to an
>     an alternate peer.
>
> My assumption is that this extension would be included in the the 
> CER/CEA exchange so an agent would know if it is supported. A client 
> that supports this extension is referred to as a 6733+ client below.  
> A client that doesn't is referred to as a 6733 client.
>
> With this extension we have two options for wording to be put into the 
> DOIC specification.
>
> 1) Indicate that a DOIC agent that throttles a request MUST send a 
> 3011 error response for all clients, 6733 and 6733+.  This would 
> depend on default processing in clients for result codes that the 
> client does not understand.  This default processing is not defined in 
> 6733 (at least I didn't find it).  The closest I could find was the 
> following.  If an unrecognized result code was interpreted as the 
> answer message containing an error then throttling a request would 
> result in the session being terminated.
> In the case where the answer message itself contains errors, any
>     related session SHOULD be terminated by sending an STR or ASR
>     message.  The Termination-Cause AVP in the STR MAY be filled with the
>     appropriate value to indicate the cause of the error.  An application
>     MAY also send an application-specific request instead of an STR or
>     ASR message to signal the error in the case where no state is
>     maintained or to allow for some form of error recovery with the
>     corresponding Diameter entity.
> RFC 6733 - Diameter Base Protocol 2) Indicate that a DOIC agent that 
> throttles a request MUST send a 3011 response to 6733+ clients.  For 
> 6733 clients the agent MUST send DIAMETER_TOO_BUSY 3002.  This is not 
> perfect as 3002 says the client should try to send to an alternative 
> peer, but it is as close as we can get.
>
> Neither of these solutions are perfect and would come with the strong 
> recommendation that Diameter nodes that support DOIC should also 
> support the above extension.
>
> I propose number 1 as it at least does result in reduction of traffic 
> sent toward the overloaded server.
>
> Regards,
>
> Steve
>
>
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime