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 protected]] Envoyé : vendredi 25 juillet 2014 15:23 À : Dhruv Dhody Cc : Y. Richard Yang; RANDRIAMASY, SABINE (SABINE); [email protected] Objet : RE: statistics operators for ALTO cost metrics 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 protected]] 发送时间: 2014年7月23日 7:33 收件人: Qin Wu 抄送: Y. Richard Yang; RANDRIAMASY, SABINE (SABINE); [email protected] 主题: Re: statistics operators for ALTO cost metrics 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)}). [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 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 protected]> wrote: > > > 发件人: [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]> 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]> 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]] 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
