Re: [alto] ALTO Extension: Defining a Cost Metrics document?

"RANDRIAMASY, SABINE (SABINE)" <sabine.randriamasy@alcatel-lucent.com> Thu, 17 October 2013 18:17 UTC

Return-Path: <sabine.randriamasy@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 DE6E111E8146 for <alto@ietfa.amsl.com>; Thu, 17 Oct 2013 11:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.523
X-Spam-Level:
X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz4u2HiNzt5J for <alto@ietfa.amsl.com>; Thu, 17 Oct 2013 11:17:20 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F08D111E8116 for <alto@ietf.org>; Thu, 17 Oct 2013 11:17:16 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9HIH4L7006198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2013 13:17:05 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9HIH3dK031595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 20:17:03 +0200
Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.168]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 17 Oct 2013 20:17:03 +0200
From: "RANDRIAMASY, SABINE (SABINE)" <sabine.randriamasy@alcatel-lucent.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>, IETF ALTO <alto@ietf.org>
Thread-Topic: ALTO Extension: Defining a Cost Metrics document?
Thread-Index: AQHOyGq+4uXNZ1CeREy4alNEanaEcpn5MLNg
Date: Thu, 17 Oct 2013 18:17:02 +0000
Message-ID: <A7A5844EB93EB94AB22C2068B10AD65A29442420@FR711WXCHMBA01.zeu.alcatel-lucent.com>
References: <CANUuoLpy5Budcx+tJCeExeYC_yTcQ9J2gC7HsXcjCvhOi7p_Vg@mail.gmail.com>
In-Reply-To: <CANUuoLpy5Budcx+tJCeExeYC_yTcQ9J2gC7HsXcjCvhOi7p_Vg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_A7A5844EB93EB94AB22C2068B10AD65A29442420FR711WXCHMBA01z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "choits@etri.re.kr" <choits@etri.re.kr>, Qin Wu <bill.wu@huawei.com>
Subject: Re: [alto] ALTO Extension: Defining a Cost Metrics document?
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: Thu, 17 Oct 2013 18:17:26 -0000

Hello,

This is definitely a good idea and it will be interesting to merge the metric definitions of the current drafts. I started the exercise, using the RFC 6390 definition template and found that there are other definition attributes that highlight the attractiveness of the ALTO Service that may be used at several layers of the network, with several levels of control and by several parties.

There has been a number of metrics proposed besides 'routingcost' and 'hopcount'.  One aspect that should be documented is the usage of such metrics in different environments. For instance, some drafts assume a controlled environment where metric values are closer or equal to real values where as other drafts assume a less or no access control and propose abstracted metric values to reflect preferences w.r.t. these metrics.

So it could be useful to include attributes in the metric definition reflecting their degree (may be yes/no) of abstraction, or whether their values are explicitly provided or are just used in a hidden way to filter or tie-break other metric values.

Besides, most currently documented ALTO metrics relate to the transport topology where as the protocol architecture and initial extension discussions mentioned metrics relating to capabilities, of endpoints such as storage or CPU capacity. So I could be useful to document the potential providers of the different metrics and the potential users.

What is your opinion?

Thanks
Sabine




De : yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com] De la part de Y. Richard Yang
Envoyé : lundi 14 octobre 2013 01:20
À : IETF ALTO
Cc : choits@etri.re.kr; RANDRIAMASY, SABINE (SABINE); dhruv.dhody@huawei.com; Greg Bernstein; Qin Wu; Young Lee
Objet : ALTO Extension: Defining a Cost Metrics document?

Dear all,

I am reading up on the documents that define cost metrics.

The motivation is that the base ALTO protocol (http://www.ietf.org/id/draft-ietf-alto-protocol-20.txt) has defined only one Cost Metric: 'routingcost':

- Defined the semantics at Sec. 6.1.1.1 of , and then listed it at Table 3.

- Used "hopcount" in examples of Sec. 9.2.3 and 9.2.4, but the semantics of not formally defined.

Given the aforementioned state of the base protocol, I see good value in that the WG produces a WG document that defines a relatively complete set of Cost Metrics.

I particular, I read the following:

- http://tools.ietf.org/html/draft-lee-alto-app-net-info-exchange-02
  (Sec. 3.4 introduced three metrics: hopcount, latency, pktcost, and cost)

- http://tools.ietf.org/html/draft-wu-alto-json-te-01
  Defined a set of metrics: in Sec. 4. This work, as stated in the document, is motivated by

- http://www.ietf.org/id/draft-ietf-ospf-te-metric-extensions-04.txt

During the review of ALTO base protocol, we are suggested to document performance metrics (cost metrics) per the guideline of
- RFC 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also BCP0170) (Status: BEST CURRENT PRACTICE)

Here a first question, I have, is whether the authors will produce a "simple" document, at the upcoming IETF, whose only purpose is to:

  define a set of cost metrics, including the nameing, the semantics, ... following the guideline per RFC 6390, that can benefit the base protocol.

I feel that such a document is focused, and has good value by itself.

The implications of the introducing multiple cost metrics can be explored in another document, which I will send in another email shortly.

Thanks.

Richard