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


alto mailing list

Reply via email to