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

Wendy Roome <w.roome@alcatel-lucent.com> Wed, 20 February 2013 15:58 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 16EAA21F8698 for <alto@ietfa.amsl.com>; Wed, 20 Feb 2013 07:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.422
X-Spam-Level:
X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, 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 z+v-5u2weQw1 for <alto@ietfa.amsl.com>; Wed, 20 Feb 2013 07:58:13 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7F46121F85D9 for <alto@ietf.org>; Wed, 20 Feb 2013 07:58:13 -0800 (PST)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r1KFwBOQ013786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <alto@ietf.org>; Wed, 20 Feb 2013 09:58:11 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r1KFwAJJ026053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <alto@ietf.org>; Wed, 20 Feb 2013 09:58:11 -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 r1KFw8Qc017752 for <alto@ietf.org>; Wed, 20 Feb 2013 09:58:09 -0600 (CST)
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 20 Feb 2013 10:58:09 -0500
From: Wendy Roome <w.roome@alcatel-lucent.com>
To: "alto@ietf.org" <alto@ietf.org>
Message-ID: <CD4A5CC1.3541C%w.roome@alcatel-lucent.com>
Thread-Topic: Discussion II: Unifying cost-mode and cost-type to a single type
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
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: Wed, 20 Feb 2013 15:58:14 -0000

I'd like to propose a radical change to "cost mode". But first, I make the
following assertion:

"Ordinal" mode exists to allow ALTO servers to hide the details of their
network. For a client, "ordinal" mode has no advantage over "numerical"
mode; clients will never explicitly request an "ordinal" mode cost.
"Ordinal" mode benefits servers, not clients.

If you accept that, then I claim there's no reason for an ALTO server to
provide both "ordinal" and "numerical" values for the same cost type. If
the server wants to hide the network details, it will only provide an
"ordinal" cost. If the server doesn't mind exposing the details, it will
provide a "numerical" cost.

So I suggest the logical conclusion is that we drop "mode" as we've been
using it. Instead, a cost type has a binary-valued "linear" attribute
("true" => "numerical", "false" => "ordinal"). The ALTO server decides
whether a cost type is linear, and declares it in the resource directory.
The client lives with that decision; the client cannot chose to get an
ordinal cost.

In other words, I think we've over-engineered the concept of "cost mode",
and we should simply it.

	- Wendy Roome