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

["Y. Richard Yang" <[e-mail]>]

Dear Sabine, Qin,



On Thu, Oct 17, 2013 at 2:17 PM, RANDRIAMASY, SABINE (SABINE) <
[e-mail]> wrote:

>  Hello,****
>
> ** **
>
> This is definitely a good idea and it will be interesting to merge the
> metric definitions of the current drafts.
>

Thanks a lot for the work on systematically defining a set of metrics.
Please see below. I agree that it is a good idea to merge the definitions.


> I started the exercise, using the RFC 6390 definition template
>

This is a good starting point indeed. We should also define "routingcost"
in this metrics document.


> 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.
>

This multi-level/layer concept is quite interesting. Can you please
elaborate a bit?

>
>


> **
>
> 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,
>

Let me try to understand. The hopcount metric might say 5 hops, and then a
"hopcount-detail" will give the exact 5 hops; an AScount metric might say 5
ASes, and ASPath then lists the 5 AS's, and then routePath lists the
spwcifi routes, for example? Or this is too detailed?


> or whether their values are explicitly provided or are just used in a
> hidden way to filter or tie-break other metric values.
>

Filtering-only metrics can be tricky, but of course interesting.


> **
>
> 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.
>

I am not sure we may want to combine transport and storage/CPU metrics in a
single documents. My first reaction is that separate documents may be a
more modular design, and I can think more.

Thanks!

Richard



>  ****
>
> ** **
>
> What is your opinion?****
>
> ** **
>
> Thanks****
>
> Sabine****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *De :* [e-mail] [mailto:[e-mail]] *De la part de
> * Y. Richard Yang
> *Envoyé :* lundi 14 octobre 2013 01:20
> *À :* IETF ALTO
> *Cc :* [e-mail]; RANDRIAMASY, SABINE (SABINE);
> [e-mail]; 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****
>
>   ****
>