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

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

Hi all,

Just a thought, some networks already provide public performance metrics,
and ALTO should be able to provide such info in a standard way and cover
these metrics, if we agree:

-AT&T
 - http://ipnetwork.bgtmo.ip.att.net/pws/averages.html
 - http://ipnetwork.bgtmo.ip.att.net/pws/network_delay.html
   shows latency, loss, jitter, reliability, modem success rate

 - In particular, the link provides a methodology page (
http://ipnetwork.bgtmo.ip.att.net/pws/glossary.html), which points to a
major challenge in defining the metrics: metrics have parameters (e.g., the
AT&T link specifies 15-min interval for latency), and I assume that ALTO
cannot work with a single interval, but then how do we handle parameters?

- CenturyLink (formerly Qwest):
  - https://kai04.centurylink.com/PtapRpts/Public/BackboneReport.aspx
    shows jitter, latency, pkt delivery rate, availability

...

And we could think that ALTO could be extended to be used as a standard way
to check on the service outage of an endpoint (
http://customer.comcast.com/help-and-support/cable-tv/outages-in-your-area/),
which may imply performance metrics as well...

Thanks.

Richard


On Mon, Oct 14, 2013 at 2:30 AM, Qin Wu <[e-mail]> wrote:

>   *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Y. Richard Yang
> *Sent:* Monday, October 14, 2013 7:20 AM
> *To:* IETF ALTO
> *Cc:* [e-mail]; Qin Wu
> *Subject:* [alto] 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.*
> ***
>
> ** **
>
> [Qin] This is exactly what I we are doing in draft-wu-alto-json-te. We
> are checking if we can give a complete list of cost metrics that are built
> based on****
>
> draft-ietf-idr-ls-distribution-03,RFC5305, draft-wu-idr-te-pm-bgp <http://tools.ietf.org/id/draft-wu-idr-te-pm-bgp-02.txt>,draft-ietf-ospf-te-metric-extensions-04, draft-ietf-isis-te-metric-extensions-01.****
>
> We will further generalize them to firstly have some base metrics that can applied either to the whole path or any link in the path and then have****
>
> Derived metrics that are link specific.****
>
> ** **
>
> The update (v-02) will come in a few days. ****
>
> ** **
>
> ** **
>
> 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****
>
>   ****
>