Subject: Re: [alto] cost metrics vs cost modes

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 22 Sep 2016 18:54:34 +0200

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

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Tue, 27 Sep 2016 16:20:50 +0000

Hi Wendy and Sebastian,

Please see inline,
Sabine

>>-----Message d'origine-----
>>De : alto [mailto:[email-masked]] De la part de Sebastian Kiesel
>>Envoyé : jeudi 22 septembre 2016 18:55
>>À : Roome, Wendy (Nokia - US)
>>Cc : IETF ALTO
>>Objet : Re: [alto] cost metrics vs cost modes
>>
>>> 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,
>>> 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.
>>>
>>> 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
>>> pairs in this query. Useful for finding the pair with the lowest
>>> hopcount, but not for estimating the actual number of hops.
>>>
>>> ord-delay: A ranking that tracks the delay, without revealing the
>>> actual delay. If, indeed, this metric is useful 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?).
>>
[SR     ] Agree. Many metrics provided in numerical modes are likely to be requested in ordinal mode. For instance a client may ask : "as long as their path bandwidth > xx mb/sec, rank those k servers". This may apply to most of the ALTO performance metrics. 
Other potential modes such as "Boolean", "string", "path-vector", are often uniquely associated to a metric. In those cases indeed, requests and responses with just "cost-name" : "mode-metric" would be lighter. 

However how do we ensure backwards compatibility with RFC7285 ? 

>>
>>Sebastian
>>
>>_______________________________________________
>>alto mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/alto