-----邮件原件-----
发件人: RANDRIAMASY, SABINE (SABINE) 
[mailto:[email protected]] 
发送时间: 2014年7月22日 9:27
收件人: Dhruv Dhody; Qin Wu
抄送: [email protected]; Y. Richard Yang
主题: RE: statistics operators for ALTO cost metrics

Hi Qin and all,

I agree with Dhruv's point. ALTO is expected to provide TE metric values on E2E 
paths. 
Therefore these values will necessarily be the result of a composition of link 
values (space aggregation). A typical operator on metrics related to available 
BW is the MIN of BW values on path links. 

[Qin]: Right, but I would rather use utilized bandwidth as an example, if we 
provide utilized bandwidth as E2E cost metrics, we definitely need some 
aggregation algorithm to calculate end to end cost metrics based on each link 
cost metric in the path. But not all bandwidth related metrics should
Be provided to ALT client as end to end cost, as I said earlier, they may only 
be used as filter or constraint.

An E2E path may have heterogeneous links, of different dynamics, that may be 
monitored differently allowing thus no common parameters such as measurement 
intervals. 
[Qin]:I am not sure this is real use case when you say we may have 
heterogeneous links. Usually in TE network, they follow the same measurement 
interval and use the same measurement unit for each link.

We therefore assume that the path-wide E2E metric value is computed by the ALTO 
Server. So need to define ALTO TE cost value generation parameters that 
characterize the "accuracy" of the values: e.g.  time aggregation ops. such as 
statistics, time interval on which the aggregation was done (e.g. at least MAX 
measurement interval on links), and other parameters to be discussed.

Besides, I agree with Qin that percentiles are easy to process and usually 
trigger TE decisions as for example load thresholds. I think is useful to keep, 
in addition, full values on available BW (are related). The reason is that 50% 
of a capacity is not the same on a 10 Gb link than on a 10 Mb link. 

Last, the draft specifies a set of TE ALTO metrics that attempts to be as wide 
as possible. It does not mandate an ALTO Server to support all the metrics. 
[Qin]: Agree.
Best regards
Sabine


-----Message d'origine-----
De : Dhruv Dhody [mailto:[email protected]] Envoyé : mardi 22 juillet 2014 
17:23 À : Qin Wu Cc : [email protected]; Y. Richard Yang; RANDRIAMASY, SABINE 
(SABINE) Objet : Re: statistics operators for ALTO cost metrics

Hi Qin,

One point to note that would be that metrics in IGP drafts are in terms of a TE 
link, in ALTO we need to worry about E2E cost ( or cost of an abstract link 
incase when ALTO also convey an abstract topology), so these cost metrics are 
composite metrics.

ALTO server may rely on database populated by routing protocols, or a PCE, or a 
measurement system. Thus ALTO server rely completely on the source on how this 
cost metric is derived and all it can do is to specify the source (or 
composition mechanism) in its reply.

Bandwidth is a bit different from the delay, jitter and loss which can be 
easily composed to an end to end metric. Bandwidth is well suited to filtering 
to get endpoints that can provide the requested bandwidth. As a cost it might 
either represent the bottleneck link for the E2E path.
Question for us to consider is -  do we need all of max bandwidth, max resv 
bandwidth, available bandwidth etc;  and what format they should be in.

Dhruv


On Fri, Jul 18, 2014 at 8:13 AM, Qin Wu <[email protected]> wrote:
> Hi,
>
> Motivated by RFC3630 and draft-ietf-isis-te-metric-extensions, we 
> define 11 alto cost metrics,
>
> The value of these alto cost metrics are high aggregated value, we may 
> have several statistics operators, e.g.,
>
> Mean, variance, avg, percentile).
>
> In the current draft, delay and delay jitter are both on delay, we use 
> mean
>
> For delay and use variance for delayjitter.
>
> It is not clear these statistics operator are appropriate for them? 
> E.g., should we use percentile for bandwidth related cost metric?
>
> Any opinion?
>
>
>
> Regards!
>
> -Qin
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to