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

Ben Campbell <ben@nostrum.com> Mon, 20 October 2014 14:40 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BB71A908B for <dime@ietfa.amsl.com>; Mon, 20 Oct 2014 07:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1myQqeFd5ZT for <dime@ietfa.amsl.com>; Mon, 20 Oct 2014 07:40:41 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7721A87D7 for <dime@ietf.org>; Mon, 20 Oct 2014 07:18:44 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KEIhg2052344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 09:18:43 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <081.59481ca83ddcf9ab4a68dda3859e21ec@trac.tools.ietf.org>
Date: Mon, 20 Oct 2014 09:18:43 -0500
X-Mao-Original-Outgoing-Id: 435507523.0472-20b908177f01d241fbd4435b9da8ca8b
Content-Transfer-Encoding: quoted-printable
Message-Id: <7351BCD3-8FF0-4485-9110-66C3C07CBB06@nostrum.com>
References: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> <081.59481ca83ddcf9ab4a68dda3859e21ec@trac.tools.ietf.org>
To: dime@ietf.org
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YEF4bVL7sxklF3bdcA7Nonqlglo
Cc: draft-ietf-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Oct 2014 14:40:45 -0000

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 <trac+dime@zinfandel.tools.ietf.org> wrote:
> 
> #85: New error response
> 
> 
> Comment (by srdonovan@usdonovans.com):
> 
> 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
> 
> -- 
> -------------------------------------+-------------------------------------
> Reporter:                           |       Owner:  draft-ietf-dime-
>  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
>     Type:  defect                   |      Status:  new
> Priority:  major                    |   Milestone:
> Component:  draft-ietf-dime-ovli     |     Version:
> 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/>
>