Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Ben Campbell <ben@nostrum.com> Wed, 10 September 2014 02:37 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 D14271A0360 for <dime@ietfa.amsl.com>; Tue, 9 Sep 2014 19:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 nIGfRocieqeW for <dime@ietfa.amsl.com>; Tue, 9 Sep 2014 19:37:40 -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 DC0741A0348 for <dime@ietf.org>; Tue, 9 Sep 2014 19:37:40 -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 s8A2bVoW049858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Sep 2014 21:37:33 -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="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net>
Date: Tue, 09 Sep 2014 21:37:31 -0500
X-Mao-Original-Outgoing-Id: 432009451.744359-c7bfc5148aa1a5215f0776646a586f5f
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1FB443E-36D4-4A51-AF4B-C71A65A236F1@nostrum.com>
References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <E194C2E18676714DACA9C3A2516265D2026C2A8B@FR712WXCHMBA12.zeu.alcatel-lucent.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bk1AEwAc079TG-gEVTjLg97I4Sw
Cc: "draft-ietf-dime-ovli@tools.ietf.org" <draft-ietf-dime-ovli@tools.ietf.org>, "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
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: Wed, 10 Sep 2014 02:37:43 -0000

We had exactly that example in the draft discussed in Toronto ( draft-donovan-doic-agent-cases ).

Comments inline:

On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Dear JJacques,
> 
> assume the following example:
> In step 1 (realm routed request sent from Client to Agent), the client indicates that it supports loss.
> In step 2 (host routed request send from agent to S1), the agent indicates that it supports loss and rate.
> In step 3 (answer from S1 to agent, containing a host type OLR), S1 indicates that it selected rate.
> 
> Now in step 4 there is no point in forwarding the host-type OLR from agent to client as the client does not support rate. Similar for step 8 where no host type OLR of rate shall be sent in addition to the realm-type OLR of loss.

I agree there is no point forwarding the OLR per se. However, the agent may still indicate that it supports "loss" back to the client, and send loss-based reports if the client sends too much traffic for the agent to comply with the max rate without throttling.

> 
> Also note that the answer in step 8 can contain only one Supported-Features AVP i.e. can only contain one selected algorithm. Even when the agent supports loss and realm, you cannot say in one answer "use loss for realm routed requests and rate for host routed requests"

One approach is where you end up with is "loss" is supported between the client and agent, and "rate" is supported between the agent and server.

Don't get me wrong, I'm not saying that's a _required_ approach, but it should be allowed.

> 
> Furthermore the client may never send host routed requests to S1. (And if it does, it will learn the host type OLR and selected algorithm in the corresponding answer).
> 

I don't follow this. Do you mean "might never"? (I read "may never" as "is never allowed to").

The agent has to ensure that any OLRs that get back to the client match the capabilities the client advertised, and received. It could do that by stripping all OC-S-F and OLR avps in answers, or it could act as as an algorithm "gateway" and (statefully) translate between the capabilities selected on either side. 

> I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the answer that corresponds to a realm type request.

I don't see that following. We should prevent a server from putting any host reports into answers to realm routed requests. Otherwise, you have use cases that just want work. For example, consider how a server could report any overload at all for an application that is exclusively realm-routed.

Also, consider that with the recently discussed distinction between realm-routed requests and host-routed requests, we consider a request to be host-routed if it has a Destination-Host _or_ if a node has other knowledge that the request will go to specific server (e.g., if the peer-selection decision would send a request to the specific host. ) In the second case, the server itself cannot distinguish a host-routed request from a host-routed request.