Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

Wendy Roome <w.roome@alcatel-lucent.com> Fri, 22 February 2013 17:51 UTC

Return-Path: <w.roome@alcatel-lucent.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3686521F886A for <alto@ietfa.amsl.com>; Fri, 22 Feb 2013 09:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.689
X-Spam-Level:
X-Spam-Status: No, score=-9.689 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8C9RmhESGGh for <alto@ietfa.amsl.com>; Fri, 22 Feb 2013 09:51:06 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1121F8853 for <alto@ietf.org>; Fri, 22 Feb 2013 09:51:04 -0800 (PST)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r1MHp3iD000186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Feb 2013 11:51:03 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r1MHp2RR016103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 11:51:03 -0600
Received: from [135.222.152.198] (wdr-i7mbp.mh.lucent.com [135.222.152.198]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r1MHp1pD020940; Fri, 22 Feb 2013 11:51:01 -0600 (CST)
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Fri, 22 Feb 2013 12:50:59 -0500
From: Wendy Roome <w.roome@alcatel-lucent.com>
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, "alto@ietf.org" <alto@ietf.org>
Message-ID: <CD4D112F.36160%w.roome@alcatel-lucent.com>
Thread-Topic: [alto] Discussion II: Unifying cost-mode and cost-type to a single type
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901008C@xmb-rcd-x04.cisco.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3444382261_18923091"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2013 17:51:09 -0000

Okay, I can avoid the IANA registration requirements by using "priv:" or
"exp:" for custom Cost Types.

But that doesn't answer the question of *why* we should register Cost Types.
What's the advantage? How does that benefit us? That's a serious question.
To me, registration looks like an annoyance without any redeeming benefit.

I realize that the goal might have been to make costs interoperable, but I
don't think registration accomplishes that. Take "routingcost". I believe
all the IANA registration says is that "routingcost is a non-negative
number, and lower is better". I don't think that's enough. To make
routingcost interoperable, I'd like to know what "40" means. Better yet, I
think "interoperable" would mean that I could compare routingcost values
between different ALTO servers, so 40 on one server means roughly the same
as 40 on another server.

That's clearly not true.

Here's a sample use-case. I want to select a host for new VM. The VM manager
gives me the CPU load (0.0 to 1.0) for several hosts. I then ask an ALTO
server for the routingcosts between my client and each of those hosts. I run
a function to blend the alto cost and the cpu load into an overall cost,
using the appropriate weighting and scaling factors, and I select the host
with the lowest overall cost.

So how do I determine those scaling factors? The IANA registry doesn't help.
I have to talk to the folks who provide that ALTO server, or else just look
at the values it returns. If I switch to a different ALTO server, I'll have
to start over again.

To me, that is not "interoperable". To me, "interoperable" would mean that I
could determine the scaling factors just from the central registry, and use
the same factors with any ALTO server.

As it stands now, "routingcost" values are only meaningful in the context of
a specific ALTO server. So even though "routingcost" is registered, it's
still a custom cost that varies widely from server to server. So what's the
benefit to registration?

Sorry to be a pest, but it seems that a while back, someone just declared,
"Well, of course we should to register cost types!" Since then we've all
accepted that on blind faith. All I'm asking is for is why registration
helps.

- Wendy Roome


From:  "Reinaldo Penno (repenno)" <repenno@cisco.com>
Date:  Thu, February 21, 2013 12:16
To:  Bill Roome <w.roome@alcatel-lucent.com>, "alto@ietf.org"
<alto@ietf.org>
Subject:  Re: [alto] Discussion II: Unifying cost-mode and cost-type to a
single type

This is what you need. A private cost you can use within your ALTO servers
and domain.

"Identifiers prefixed with ¹priv:¹ are reserved for Private Use"