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? > > 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 :-) > > 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
