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

[Steve Donovan <[e-mail]>]

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