Re: [alto] [ippm] Cost metrics in draft-wu-alto-te-metrics

Hi Mirja and Joachim,

Another way to interpret what ALTO needs is to look at 
cost metrics the same as link costs in routing.
Routing link costs are usually static and the values
might be set relative to some real metric like latency
or max link line rate. These involve no measurement at all.

So when they say:
   In this document, we proposes a set of Cost Metrics, derived and
   aggregated from routing protocols with different granularity and
   scope, such as BGP-LS,OSPF-TE and ISIS-TE, or from end to end traffic
   management tool.

only the last phrase implies measurement, with the long list of examples:

   We currently define 11 new Performance Metric to
   measure network delay, jitter, packet loss, hop count, and bandwidth.

None of these are new, and they are already defined in great detail
or ippm is in the process of doing so. The draft seems to assume that a 
measurement system exists to supply all the needed measurements with 
relevant context and scope.

I wonder how much all these "new" metrics actually improve alto cost
accuracy.

Al

> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Joachim Fabini
> Sent: Thursday, July 21, 2016 10:46 AM
> To: Mirja Kühlewind; alto@ietf.org; ippm@ietf.org
> Subject: Re: [ippm] Cost metrics in draft-wu-alto-te-metrics
> 
> Hi Mirja,
> 
> thanks for bringing this topic to ippm. Some technical notes on this:
> RFC2330  does not differentiate at which layer timestamps are acquired.
> If the host time is considered to be an application layer timestamp,
> alto could immediately adopt/use the base framework and all the metrics
> that have been defined so far in ippm - including OWD, RTD, IPDV (alias
> Jitter), Loss, Loss Patterns, BTC, etc., all defined in separate
> documents and in substantial detail.
> 
> So yes, I share your opinion. I recommend alto to consider this
> procedure - unless there are specific reasons why this can't be done (in
> which case ippm will likely be very interested in feedback on the
> reasons).
> 
> Some more related documents:
> - The update to 2330 (RFC7312) has particular focus on uncertainty
> factors that measurements at application level will encounter in today's
> networks.
> 
> - Al and I have written a draft to update RFC2330 to be more specific
> wrt timestamp acquisition, even considering virtualization and related
> challenges. The draft
> (https://datatracker.ietf.org/doc/draft-fabini-ippm-2330-time/ )  has
> expired but I plan to rewrite it to fit what we have discussed in
> Yokohama (in particular a use-case based discussion of timestamp
> acquisition in measurements).
> 
> - IPv6 update for 2330 is on the way.
> (https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-00 )
> 
> Any feedback and summary on requirements from alto is very welcome;
> likewise some statements on the challenges in adopting the existing ippm
> metrics. I guess that this information is valuable feedback for ippm in
> evaluating past and guiding future work.
> 
> Joachim
> 
> On 2016-07-21 15:41, Mirja Kühlewind wrote:
> > Hi ippm folks, hi alto folks,
> >
> > cross-posting because draft-wu-alto-et-metrics defines a set of alto
> cost metrics such as delay or bandwidth which sound to me like IP
> performance metrics. At the same time IPPM is currently in the process
> of defining a metric registry (draft-ietf-ippm-metric-registry-07 and
> draft-ietf-ippm-initial-registry-01). How do these relate to each other
> and how can we make sure that they are inline with each other?
> >
> > Mirja
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm
> >
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm