Subject: [alto] statistics operators for ALTO cost metrics

From: Qin Wu <[email-masked]>
Date: Fri, 18 Jul 2014 12:13:46 +0000

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

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 22 Jul 2014 11:23:12 -0400

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-masked]> wrote:
> 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

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 22 Jul 2014 16:27:20 +0000

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. 

An E2E path may have heterogeneous links, of different dynamics, that may be monitored differently allowing thus no common parameters such as measurement intervals. 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. 

Best regards
Sabine

-----Message d'origine-----
De : Dhruv Dhody [mailto:[email-masked]] 
Envoyé : mardi 22 juillet 2014 17:23
À : Qin Wu
Cc : [email-masked]; 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-masked]> wrote:
> 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

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 22 Jul 2014 16:44:21 +0000

Hi Dhruv and all,

I also agree with you that "Bandwidth is well suited to filtering to get endpoints that can provide the requested bandwidth". An ALTO Server may also use other TE metrics to filter on other abstracted metrics. This may be convenient for ALTO Servers that do not wish to unveil their TE metrics values to all Clients. 

The ALTO Server may protect from "malicious" requests by setting thresholds on the granularity of the filtering interval, e.g. reject [a, b]  with b-a < 10, and or reject series of requests with e.g. "< a" with "too close" values of a. 

Best regards
Sabine

-----Message d'origine-----

Hi Qin,

Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 22 Jul 2014 13:25:50 -0400

Hi Sabine,

Reply inline for both of your mails...

Mail 1:

On Tue, Jul 22, 2014 at 12:27 PM, RANDRIAMASY, SABINE (SABINE)
<[email-masked]> wrote:
> An E2E path may have heterogeneous links, of different dynamics, that may be monitored differently allowing thus no common parameters such as measurement intervals. We therefore assume that the path-wide E2E metric value is computed by the ALTO Server.

Thus ALTO server itself could be the source of the cost metric and can
specify how the client should interpret it. And on the other extreme
ALTO server rely on a 3rd party and may not be aware of / or have any
control over the metric. So maybe what we need is a generic way to
specify how the cost metric is gathered/measured/computed and let ALTO
client to interpret it accordingly.

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

If this is done, I wish its 'optional'!  (to handle the case when ALTO
server has no control as mentioned above).

> 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 (…

Agree that absolute value still have a place, also percentage could
also be useful in filtering as well.

Mail 2:

>Hi Dhruv and all,
>
>I also agree with you that "Bandwidth is well suited to filtering to get endpoints that can provide the requested bandwidth". >An ALTO Server may also use other TE metrics to filter on other abstracted metrics. This may be convenient for ALTO >Servers that do not wish to unveil their TE metrics values to all Clients.

Absolutely, filtering based on delay etc is equally valid. But that
might not be in scope of 'draft-wu-alto-te-metrics-03'

>
>The ALTO Server may protect from "malicious" requests by setting thresholds on the granularity of the filtering interval, >e.g. reject [a, b]  with b-a < 10, and or reject series of requests with e.g. "< a" with "too close" values of a.
>
>Best regards
>Sabine

Regards,
Dhruv

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 22 Jul 2014 17:59:54 -0400

Hi Dhruv, all,

On Tue, Jul 22, 2014 at 1:25 PM, Dhruv Dhody <[email-masked]> wrote:

> > 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.
> >
> > An E2E path may have heterogeneous links, of different dynamics, that
> may be monitored differently allowing thus no common parameters such as
> measurement intervals.
>

Good point. One function that ALTO can provide is heterogeneous information
aggregation for application. Merging info collected with diverse parameters
(e.g., measurement intervals) is a difficult problem, you point it out well.

> We therefore assume that the path-wide E2E metric value is computed by the
> ALTO Server.
>
This makes sense. Any specific proposal on how to specify it?

> > 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.
>
> Agree, optional it is.

> >
> > 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.
>
>
I wish that ietf starts to take on more on percentile. More production
networks/apps care about the long tail, not the mean.

> > 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.
>
>
Yes. My understanding is that the metrics are optional and indicated in
IRD, if supported. What I want, from Qin and others, is a good illustration
of the relationship of the metrics in the TE-metric document. If I cannot
visualize the relationship, I cannot convince that they are minimal (i.e.,
not redundant) and complete. I am looking for an update from Qin on the
illustration :-)

> > Best regards
> > Sabine
>
> Mail 2:
>
> >Hi Dhruv and all,
> >
> >I also agree with you that "Bandwidth is well suited to filtering to get
> endpoints that can provide the requested bandwidth". >An ALTO Server may
> also use other TE metrics to filter on other abstracted metrics. This may
> be convenient for ALTO >Servers that do not wish to unveil their TE metrics
> values to all Clients.
>
> >The ALTO Server may protect from "malicious" requests by setting
> thresholds on the granularity of the filtering interval, >e.g. reject [a,
> b]  with b-a < 10, and or reject series of requests with e.g. "< a" with
> "too close" values of a.
> >
> >Best regards
> >Sabine
>
> Regards,
> Dhruv
>
> >
> >
> > 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.
> >
> source on how this cost metric is derived and all it can do is to specify
> the source (or composition mechanism) in its reply.
> >
> 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.
> resv bandwidth, available bandwidth etc;  and what format they should be in.
> >
> > Dhruv
> >
> >

---

From: Qin Wu <[email-masked]>
Date: Wed, 23 Jul 2014 00:00:40 +0000

Hi, Dhruv:
My take to this is what we specify is cost metrics between endpoint to endpoint or between PID and PID, shall we need to distinguish whether a cost metric is end to end cost or link cost, to me E2E cost and link cost are both path metric, the different is one is whole path metric while the other is sub-path metric.

Yes, users may only care about end to end cost metrics, but sub-path can be used as filter or constraint to select a best path.
From this point view, end to end cost metrics should definitely be mandatorily supported (e.g., delay, jitter, packet loss)while sub-path metric is optionally supported(e.g.,available bandwidth).
In addition, we also have bandwidth metric to be defined in this draft, shall we view this bandwidth metrics as end to end path metrics and set it to mandatory? E.g., from application point of view, we have upstream bandwidth or downstream bandwidth, I think both are end to end path metrics.

Regards!
-Qin
-----邮件原件-----
发件人: alto [mailto:[email-masked]] 代表 Dhruv Dhody
发送时间: 2014年7月22日 8:23
收件人: Qin Wu
抄送: [email-masked]
主题: Re: [alto] statistics operators for ALTO cost metrics

Hi Qin,

Dhruv

> E.g., should we use percentile for bandwidth related cost metric?

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Qin Wu <[email-masked]>
Date: Wed, 23 Jul 2014 00:15:54 +0000

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

Hi Qin and all,

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

[Qin]: Agree.
Best regards
Sabine

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

Hi Qin,

Dhruv

---

From: Qin Wu <[email-masked]>
Date: Wed, 23 Jul 2014 00:54:42 +0000

发件人: [email-masked] [mailto:[email-masked]] 代表 Y. Richard Yang
发送时间: 2014年7月22日 15:00
收件人: Dhruv Dhody
抄送: RANDRIAMASY, SABINE (SABINE); Qin Wu; [email-masked]
主题: Re: statistics operators for ALTO cost metrics

Hi Dhruv, all,

On Tue, Jul 22, 2014 at 1:25 PM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sabine,

Mail 1:

> An E2E path may have heterogeneous links, of different dynamics, that may be monitored differently allowing thus no common parameters such as measurement intervals.

Good point. One function that ALTO can provide is heterogeneous information aggregation for application. Merging info collected with diverse parameters (e.g., measurement intervals) is a difficult problem, you point it out well.

We therefore assume that the path-wide E2E metric value is computed by the ALTO Server.

This makes sense. Any specific proposal on how to specify it?
[Qin]: If we don’t care about whether it is end to end metric or link metric and we only care about what is the value of cost metric between endpoint A and endpoint B, we don’t need to specify it clearly.
If specification is really needed, I don’t think it should be in the scope of this alto cost metrics draft since it may require another protocol extension for that.

Agree, optional it is.

> 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 (…

I wish that ietf starts to take on more on percentile. More production networks/apps care about the long tail, not the mean.

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

Yes. My understanding is that the metrics are optional and indicated in IRD, if supported. What I want, from Qin and others, is a good illustration of the relationship of the metrics in the TE-metric document. If I cannot visualize the relationship, I cannot convince that they are minimal (i.e., not redundant) and complete. I am looking for an update from Qin on the illustration :-)

[Qin]: Maximum bandwidth is more about link capacity.
Maxresbw can be larger than maxbw if the link is oversubscirbed
The initial value of unresbw for each priority can be maxbw.
Residbw = maxbw -  tunnel reservation bw
Availbw = residbw- measured bw for best effort traffic
Utilbw = measured bw for best effort traffic a+ bw for TE traffic
Since all these bandwidth related metrics are motivated by the existing IETF work, metrics defined in this draft are all they have.
Also we have abstract bandwidth cost metric which can be used to refer to any other type of bandwidth metric,
So from my personal point of view, they are complete. Also there are no redundancy.

Regards,
Dhruv

> De : Dhruv Dhody [mailto:[email-masked]<mailto:[email-masked]>]
> Cc : [email-masked]<mailto:[email-masked]>; Y. Richard Yang; RANDRIAMASY, SABINE (SABINE)
> On Fri, Jul 18, 2014 at 8:13 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
>> Hi,
>>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 23 Jul 2014 10:33:16 -0400

Hi Qin, Richard, Sabine, et at

Sorry for top posting...

(1) E2E v/s Link
IMHO this document may just extend the base ALTO protocol to support
multiple TE related metrics with current focus entirely on E2E cost.
Once the topology work is progressed, the drafts there should be able
to reuse these TE metrics for abstract links as well. So when we write
this specification we can make sure that it is written in such a way
that the reuse/extension would be easy enough.

(2) Filtering
Should this document handle filtering? if yes, then its better to have
a separate section to specify that. Regarding Bandwidth is it an E2E
metric or link metric.. I feel though bandwidth is a property of a
link, but in the context of ALTO it should be considered as E2E i.e.
suppose we want to filter based on available bandwidth, and use
'availbw gt 100' that should filter the endpoints whose path have
links that does not satisfy this (basically the availbw for the path =
min{availbw(Li)}).

(3) Mandatory v/s Optional
I feel that these TE metrics should be optional in the sense that not
all ALTO server implementation out there must have support for these
metrics.

(4) Measurement Source
The question boils down to - should we limit the measurement source to
IGP/BGP and thus specify the measurement interval based on those or
keep it completely generic and let the client only let the source and
measurement mechanisms if known.

(5) Bandwidth Metric
As end to end metric we can think of how bandwidth would apply to a path.
In that case i can think of following defining
- Load of Path
- Residual Bandwidth of Path
- Available Bandwidth of Path
- Utilization of Path

for ex. availbw for the path = min{availbw(Li)}

As filter -
>From the point of view of this document, filter should focus on
filtering the endpoints (and not to select a particular path to an
endpoint), so IMHO filter should apply to path and not links. Maybe in
topology draft things may turn out to be different and they can reuse
/ develop on these metrics.

Regards,
Dhruv

On Tue, Jul 22, 2014 at 8:54 PM, Qin Wu <[email-masked]> wrote:
>> 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.
>>
>> 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]: If we don’t care about whether it is end to end metric or link metric
> and we only care about what is the value of cost metric between endpoint A
> and endpoint B, we don’t need to specify it clearly.
>
> If specification is really needed, I don’t think it should be in the scope
> of this alto cost metrics draft since it may require another protocol
> extension for that.
>
>
>
>> 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.
>
>
>
> Yes. My understanding is that the metrics are optional and indicated in IRD,
> if supported. What I want, from Qin and others, is a good illustration of
> the relationship of the metrics in the TE-metric document. If I cannot
> Since all these bandwidth related metrics are motivated by the existing IETF
> work, metrics defined in this draft are all they have.
>
>> also use other TE metrics to filter on other abstracted metrics. This may be
>> convenient for ALTO >Servers that do not wish to unveil their TE metrics
>> values to all Clients.
>
>>The ALTO Server may protect from "malicious" requests by setting thresholds
>> on the granularity of the filtering interval, >e.g. reject [a, b]  with b-a
>> < 10, and or reject series of requests with e.g. "< a" with "too close"
>> values of a.
>>
>>Best regards
>>Sabine
>
> Regards,
> Dhruv
>
>
>>
>>
>> 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

---

From: Qin Wu <[email-masked]>
Date: Fri, 25 Jul 2014 13:22:50 +0000

Hi,Dhruv:
Good clarification. I agree ALTO cost metrics should be defined in a end to end basis.
For other comments, see my reply inline.

Regards!
-Qin
-----邮件原件-----
发件人: Dhruv Dhody [mailto:[email-masked]] 
发送时间: 2014年7月23日 7:33
收件人: Qin Wu
抄送: Y. Richard Yang; RANDRIAMASY, SABINE (SABINE); [email-masked]
主题: Re: statistics operators for ALTO cost metrics

Sorry for top posting...

(1) E2E v/s Link
IMHO this document may just extend the base ALTO protocol to support multiple TE related metrics with current focus entirely on E2E cost.
Once the topology work is progressed, the drafts there should be able to reuse these TE metrics for abstract links as well. So when we write this specification we can make sure that it is written in such a way that the reuse/extension would be easy enough.

(2) Filtering
Should this document handle filtering? if yes, then its better to have a separate section to specify that. Regarding Bandwidth is it an E2E metric or link metric.. I feel though bandwidth is a property of a link, but in the context of ALTO it should be considered as E2E i.e.
suppose we want to filter based on available bandwidth, and use 'availbw gt 100' that should filter the endpoints whose path have links that does not satisfy this (basically the availbw for the path = min{availbw(Li)}).

[Qin]: I think the answer seems no since this draft should focus on defining new metrics.

(3) Mandatory v/s Optional
I feel that these TE metrics should be optional in the sense that not all ALTO server implementation out there must have support for these metrics.

[Qin]: but some of these TE metrics reflecting network performance are not applicable to TE traffic or bandwidth guaranteed traffic but also best effort traffic,
e.g., packet loss, jitter, delay.

(4) Measurement Source
The question boils down to - should we limit the measurement source to IGP/BGP and thus specify the measurement interval based on those or keep it completely generic and let the client only let the source and measurement mechanisms if known.

[Qin]:Yes, the measurement source should not be limited to IGP/BGP.

(5) Bandwidth Metric

As filter -
From the point of view of this document, filter should focus on filtering the endpoints (and not to select a particular path to an endpoint), so IMHO filter should apply to path and not links. Maybe in topology draft things may turn out to be different and they can reuse / develop on these metrics.

Regards,
Dhruv

On Tue, Jul 22, 2014 at 8:54 PM, Qin Wu <[email-masked]> wrote:
>> 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.
>>
>> may be monitored differently allowing thus no common parameters such 
>> as measurement intervals.
>
>
>
> Good point. One function that ALTO can provide is heterogeneous 
> information aggregation for application. Merging info collected with 
> diverse parameters (e.g., measurement intervals) is a difficult problem, you point it out well.
>
>
>
> [Qin]: If we don’t care about whether it is end to end metric or link 
> metric and we only care about what is the value of cost metric between 
> endpoint A and endpoint B, we don’t need to specify it clearly.
>
> If specification is really needed, I don’t think it should be in the 
> scope of this alto cost metrics draft since it may require another 
> protocol extension for 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.
>
>> 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.
>
>
>
> Yes. My understanding is that the metrics are optional and indicated 
> in IRD, if supported. What I want, from Qin and others, is a good 
> illustration of the relationship of the metrics in the TE-metric 
> document. If I cannot visualize the relationship, I cannot convince 
> that they are minimal (i.e., not redundant) and complete. I am looking 
> for an update from Qin on the illustration :-)
>
>
>
> Since all these bandwidth related metrics are motivated by the 
> existing IETF work, metrics defined in this draft are all they have.
>
>>I also agree with you that "Bandwidth is well suited to filtering to 
>>get  endpoints that can provide the requested bandwidth". >An ALTO 
>>Server may  also use other TE metrics to filter on other abstracted 
>>metrics. This may be  convenient for ALTO >Servers that do not wish to 
>>unveil their TE metrics  values to all Clients.
>
>>thresholds  on the granularity of the filtering interval, >e.g. reject 
>>[a, b]  with b-a  < 10, and or reject series of requests with e.g. "< a" with "too close"
>> values of a.
>>
>>Best regards
>>Sabine
>
> Regards,
> Dhruv
>
>
>>
>>
>> De : Dhruv Dhody [mailto:[email-masked]] Envoyé : mardi 22 
>> juillet 2014 17:23 À : Qin Wu Cc : [email-masked]; Y. Richard Yang; 
>> RANDRIAMASY, SABINE (SABINE) Objet : Re: statistics operators for 
>> ALTO cost metrics
>>
>> Hi Qin,
>>
>> 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
>>
>>
>>> The value of these alto cost metrics are high aggregated value, we 
>>> may have several statistics operators, e.g.,
>>>

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Fri, 25 Jul 2014 15:20:40 +0000

Hi Qin, Dhruv and all,

I agree with your point on filtering. This should be seen as a separate service, although associated to requests on Cost Values. An ALTO Client may or may not want filtering on its selected Endpoints or paths. Today, I will present the filtering section of the Multi-Cost draft and the possibility to complement the proposed services with other previous work on this matter.  

As for the TE metrics, I fully agree, these metrics are expected to apply to e2e paths and therefore their values are aggregated over the path links with classical operators such as SUM, MIN, PROD and probably over time as e2e paths links are heterogeneous and their measurements are done and reported at different paces. 

Best regards
Sabine

-----Message d'origine-----
De : Qin Wu [mailto:[email-masked]] 
Envoyé : vendredi 25 juillet 2014 15:23
À : Dhruv Dhody
Cc : Y. Richard Yang; RANDRIAMASY, SABINE (SABINE); [email-masked]
Objet : RE: statistics operators for ALTO cost metrics

Hi,Dhruv:

Regards!
-Qin
-----邮件原件-----
发件人: Dhruv Dhody [mailto:[email-masked]]
发送时间: 2014年7月23日 7:33
收件人: Qin Wu
抄送: Y. Richard Yang; RANDRIAMASY, SABINE (SABINE); [email-masked]
主题: Re: statistics operators for ALTO cost metrics

Sorry for top posting...

(1) E2E v/s Link

(2) Filtering

[Qin]: but some of these TE metrics reflecting network performance are not applicable to TE traffic or bandwidth guaranteed traffic but also best effort traffic, e.g., packet loss, jitter, delay.

(4) Measurement Source

(5) Bandwidth Metric

As filter -

Regards,
Dhruv

---

From: "Songhaibin (A)" <[email-masked]>
Date: Fri, 25 Jul 2014 17:45:18 +0000

One thought that came into my mind when Sabine presented the slides, I think it may be useful to define the "exception" semantics in the cost calendar. For example, you can define the cost for "every Monday" in one year, but it happens that some holidays are also on Mondays, so you can define some exceptions like "Dec 25", "May 1st", and some other Mondays which may not apply the same cost value. Any thoughts?

Regards!
-Haibin