发件人: [email protected] [mailto:[email protected]] 代表 Y. Richard Yang 发送时间: 2014年7月22日 15:00 收件人: Dhruv Dhody 抄送: RANDRIAMASY, SABINE (SABINE); Qin Wu; [email protected] 主题: Re: statistics operators for ALTO cost metrics
Hi Dhruv, all, On Tue, Jul 22, 2014 at 1:25 PM, Dhruv Dhody <[email protected]<mailto:[email protected]>> wrote: Hi Sabine, Reply inline for both of your mails... Mail 1: On Tue, Jul 22, 2014 at 12:27 PM, RANDRIAMASY, SABINE (SABINE) <[email protected]<mailto:[email protected]>> wrote: > 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. 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. 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. 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. > 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). 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. Agree that absolute value still have a place, also percentage could also be useful in filtering as well. > > 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. > 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. 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 > > > -----Message d'origine----- > De : Dhruv Dhody [mailto:[email protected]<mailto:[email protected]>] > Envoyé : mardi 22 juillet 2014 17:23 > À : Qin Wu > Cc : [email protected]<mailto:[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]<mailto:[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
