On Mon, Aug 01, 2016 at 11:11:42AM -0400, Wendy Roome wrote: > In the early days of ALTO, we decided that cost-metrics and cost-modes > were orthogonal: any metric could be presented in either mode. We were > able to get away with that when routingcost was the only metric, because > routingcost values are totally arbitrary, with no intrinsic meaning. > > But now we are considering new metrics, like delay and bandwidth. These > have intrinsic meaning. If a client wants a server with a latency of less > than (say) 50 ms or an available bandwidth of more than 1 mb/sec, that > client *must* have a numerical-mode delay. An ordinal-mode delay is > useless.
Couldn't there be a case where a client says "I want to talk to the top three of the list of candidate peers, ordered by latency, irrespectively what the absolute latency is"? > > Contrast that with routingcost: most clients just pick the server with the > lowest cost, so ordinal-mode and numerical-mode are interchangeable. > > So here is my suggestion: rather than being orthogonal to the metric, the > mode is really *part* of the metric. That is, a metric is defined as > either numericsl or ordinal. Or absolute or relative, if you prefer. > > Thus we would have the metrics: > > routingcost: A numerical cost. Scalable, proportional, comparable between > queries. > > ord-routingcost: A ranked cost. The values can be compared to others in > this response, but are not scalable or proportional, and cannot be > compared to costs from previous queries. > > hopcount: The actual hop count. > > ord-hopcount: A ranking that tracks the actual hop count for (src,dst) > pairs in this query. Useful for finding the pair with the lowest hopcount, > but not for estimating the actual number of hops. > > delay: The actual delay, in seconds (or millisec, or whatever) > > ord-delay: A ranking that tracks the delay, without revealing the actual > delay. If, indeed, this metric is useful at all. Isn't that just concatenating the two fields? Is there really a metric where the ord-xxx does not make sense at all? And is that such a big problem that we should change the spec (maybe we should have done that differently, but is it worth changing now?). Sebastian _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
