IETF Logo Mail Archive

Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC

Jouni Korhonen <jouni.nospam@gmail.com> Fri, 28 February 2014 17:46 UTC

Return-Path: <jouni.nospam@gmail.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 7DADF1A00B4 for <dime@ietfa.amsl.com>; Fri, 28 Feb 2014 09:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 AaTLeKHpt3Uf for <dime@ietfa.amsl.com>; Fri, 28 Feb 2014 09:46:28 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC681A0123 for <dime@ietf.org>; Fri, 28 Feb 2014 09:46:28 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id hr13so2932694lab.17 for <dime@ietf.org>; Fri, 28 Feb 2014 09:46:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=986VEqwSYsoOTCK+i0uuAVF/xCYNQKI1nkXYMwtIZdg=; b=kF6Iu61wIjDcV+sByOLeXx3TjaFP/EvX8uSdtQI/Bg8Cy0iRVVNzKTprre+EWXvyXS KzU9Bgbi8A7W6snxcu/lH+hoLIbmgAwUnczZlweMVkZtPvoG2lxKV3sT+jlsNCMo1J00 lvMzCeEPAa6NzyjXofX8sad8/1RqysYW9/IEXi/R0kFZnOnFgqhFP6lteIfRgP0ssgCn ZZ3/yw/WCPH9bn9WMmNiz7Wlo/mOmhFQ50gPq3c+iyCJF8b5+LG6ORDUC0yNO+F5fDKJ pN6S38vleZjw/8F9TnWXfjf20cZ6psSYMgMa+DJhGfg43RtO62exKr44WdKjnpYqVX/O f/ug==
X-Received: by 10.152.36.196 with SMTP id s4mr502452laj.24.1393609585865; Fri, 28 Feb 2014 09:46:25 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id gi5sm4723477lbc.4.2014.02.28.09.46.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 09:46:12 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com>
Date: Fri, 28 Feb 2014 19:46:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4337BE9-6BA2-421F-8DEB-32A261E3D22B@gmail.com>
References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O0mH_sEJZp_n3L2MZjlzouZF8DE
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
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: Fri, 28 Feb 2014 17:46:35 -0000

Ben,

On Feb 25, 2014, at 1:11 AM, Ben Campbell <ben@nostrum.com> wrote:

> 
> On Feb 24, 2014, at 12:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:
> 
>> There has been no discussion of ticket #27.  I can't even find it on the DIME list, so I'm copying it here to initiate discussion.
>> 
>> The proposal is for an agent to send a TOO-BUSY response when it throttles a request from a non supporting client.  The behavior of the agent in this case would be in the new section to be added to capture agent behavior as proposed in issue #24 (and various other places).
>> 
> 
> RFC6733 has the following to say about TOO_BUSY
> 
> "When returned, a Diameter node SHOULD attempt to send the message to an alternate peer.  This error MUST only be used when a specific server is requested, and it cannot provide the requested saervice."

"when a specific server is requested" means the use of Destination-Host to me.

> Do those semantics and limitations apply to this usage? Is there a chance if incorrect behavior from a client that doesn't support DOIC, and therefore is not aware of this new usage of TOO_BUSY? For example, if an agent sends TOO_BUSY due due to a host OLR received from the an upstream server, the client might (actually SHOULD) try to reach that same server via an alternate agent. Is that okay?

I would say this could be a desired behaviour but I am not sure
whether it is okay. DIAMETER_TOO_BUSY is a protocol error, which
means an error-answer, which again probably is completely different
what the server sent (in the above example). Although this is allowed
(see the usage of Error-Reporting-Host AVP) but then RFC 6733 Section
6.2.2. MUST on sending STR to the server does not really fit our use
case.

A client knows from the Origin-Host & Error-Reporting-Host whether the
error came from the final destination or from an intermediate. It can
reason based that whether it needs to find a new server or just an
alternate path.

> I'm not sure I understand the original intent of the MUST only sentence. But the only way I know of to request a specific server is to use D-H. So would we allow the sending of a TOO_BUSY in response to a realm-routed request?

I would think twice updates to RFC6733. But if seen necessary,
I would do that in a separate I-D.

- Jouni


> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

v2.23.0 | Report a Bug | By Email