Hi Wendy and Sebastian, Please see inline, Sabine
>>-----Message d'origine----- >>De : alto [mailto:[email protected]] 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 >> >>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?). >> [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 protected] >>https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
