Subject: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response

From: "dime issue tracker" <[email-masked]>
Date: Tue, 14 Oct 2014 16:07:34 -0000

#85: New error response

 This issue is implied by others but is being added to make sure that the
 need for a new error response code (or modification of an existing error
 response code) to address requests that are rejected due to overload
 abatement.  The required behavior in response to the new code is to not
 retry the transaction.

 This response code will likely be defined in a separate document and
 referred to by the DOIC specification.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]           |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/85>
dime <http://tools.ietf.org/wg/dime/>

---

From: "dime issue tracker" <[email-masked]>
Date: Mon, 20 Oct 2014 06:38:04 -0000

#85: New error response

Comment (by [email-masked]):

 Raw notes taken from discussion at interim meeting:

 Requirements

 •       Current Too-Busy behavior allows for retry
 •       Too-Busy was originally defined to have a per connection scope
 •       MUST only be used when a specific server exists
 o       This might mean that Too-Busy cannot be used for the throttle
 error without updating the definition of Too-Busy behavior
 •       Unable-to-deliver might be another alternative for throttling
 behavior

 •       Need new error response behavior – DOIC needs error response
 behavior to prevent retries due to the message being throttled.

 •       Need to handle case where transaction client supports the
 throttling error behavior and for transaction clients that do not support
 the throttling error behavior.

 Proposal: Use Unable-to-Comply error code when throttling by agent, too-
 busy when throttling by server

 Use case where agent is reacting node – throttled messages should result
 in Unable-to-Comply

 Use case – agent throttling when client supports DOIC unable-to-comply
 also works

 Use case – Server throttling – too-busy works

 Could add optional “error-diagnostic AVP” to indicate the reason for
 unable-to-comply – should be addressed in a separate RFC

 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/85#comment:1>
dime <http://tools.ietf.org/wg/dime/>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2014 09:18:43 -0500

I think the guidance of agents sending unable-to-comply and servers sending too-busy needs to be pointed out as "typical". There may be cases where the opposites make sense, e.g., if an agent has reason to think an alternate route may be ok (as in agent-overload), it might send too-busy. If a server has reason to believe that the request should not be retried, it can send unable-to-comply.

It's probably best to state this generically based on the expected result (retrying on different route vs final error.), and then describe "typical" behavior for agents and servers.

> On Oct 20, 2014, at 1:38 AM, dime issue tracker <[email-masked]> wrote:
> 
> #85: New error response
> 
>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 20 Oct 2014 18:59:23 +0200

Ben,

I attempted to treat them generically in the separate email I sent with 
the title "[Dime] Proposal for error response wording (issue 85)".

Does that address your concern?

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2014 12:02:02 -0500

Not really. I will respond to that email separately.

> On Oct 20, 2014, at 11:59 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ben,
> 
> I attempted to treat them generically in the separate email I sent with the title "[Dime] Proposal for error response wording (issue 85)".
>

---

From: "dime issue tracker" <[email-masked]>
Date: Tue, 21 Oct 2014 08:27:12 -0000

#85: New error response

 Added the following proposed wording to the draft:

    When a DOIC node rejects a Diameter request due to throttling, the
    DOIC node needs to select the appropriate error response code.  This
    determination is made based on the probability of the request
    succeeding if retried on a different path.

    The DIAMETER_TOO_BUSY response code SHOULD be used when the request
    is likely to succeed on a different path.

       For instance, if the request arrived at the reporting node without
       a Destination-Host AVP then the reporting node might determine
       that there is an alternative Diameter node that could successfully
       process the request and that retrying the transaction would not
       negatively impact the reporting node.

    The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to
    indicate that the request should not be retried.  This is used when
    the request is not likely to succeed on a different path and retrying
    would consume valuable resources during an occurance of overload.

       For instance, if the request arrived at the reporting node with a
       Destination-Host AVP populated with its own Diameter identity then
       the reporting node can assume that retrying the request would
       result in it coming to the same reporting node.

       A second example is when an agent that supports the DOIC solution
       is preforming the role of a reacting node for a non supporting
       client.  Requests that are rejected as a result of DOIC throttling
       in this scenario would generally be rejected with a
       DIAMETER_UNABLE_TO_COMPLY response code.

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/85#comment:2>
dime <http://tools.ietf.org/wg/dime/>

---

From: "dime issue tracker" <[email-masked]>
Date: Wed, 22 Oct 2014 04:55:26 -0000

#85: New error response

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-dime-
  [email-masked]           |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  draft-ietf-dime-ovli     |     Version:
 Severity:  Active WG Document       |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/85#comment:3>
dime <http://tools.ietf.org/wg/dime/>