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

[Ben Campbell <[e-mail]>]

On Apr 2, 2014, at 8:25 AM, Steve Donovan <[e-mail]> wrote:

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

Why SHOULD NOTs and not MUST NOTs?

OTOH, I'm not sure the proscription against sending to alternate peers is generally applicable. There may be cases where you want the downstream node to resend to an alternate peer. E.g some agent overload scenarios. Maybe we need two separate codes? (Or maybe TOO_BUSY is enough for the other case?)


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

I could have sworn that I read that for unknown errors in a known class, the error should be treated as the base for the class. But I can't find that anywhere.

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

Would that guidance still make since if one or both peers in question are agents?

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

I am skeptical of requiring different behavior depending on whether the client supports 6733bis. That would require a version number change, or some other way to signal 6733bis support. If we were to go that route, it might make more sense to make the new code part of DOIC.

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

So the real reason for separating this from DOIC is some sense that nodes might support the new code when they otherwise don't support DOIC. Do we expect that to really happen?

>> 
>> 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
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime