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.
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.
I've used the convention that the ordinal version of a metric start with
ord-, but that is just a convention, not a requirement.
Yes, that may lead to more metrics -- assuming ordinal mode makes sense
for the new metrics. But look at the number of places where we have
cost-type: {cost-metric: name, cost-mode: name}
Those would all change to just
cost-metric: name
- Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
