Re: [alto] ALTO Extension: A document defining multi-metrics filtering?

[Greg Bernstein <[e-mail]>]

Hi Richard, in our expired draft on  large bandwidth uses
cases,http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02,
we were counting on some type of multi-cost extension (see section 5).
Hence, I concur with your assessment of the need and usefulness of such
an extension.
Cheers

Greg B.
On 10/13/2013 4:57 PM, Y. Richard Yang wrote:
> Dear all,
>
> The base ALTO protocol
> (http://www.ietf.org/id/draft-ietf-alto-protocol-20.txt) is mostly a
> single-cost-metric centric:
>
> - The Cost Map filtering service uses only one cost-type (Sec. 11.3.2.3):
>
>      object {
>      CostType   cost-type;
>      [JSONString constraints<0..*>;]
>      [PIDFilter  pids;]
>    } ReqFilteredCostMap;
>
>    object {
>      PIDName srcs<0..*>;
>      PIDName dsts<0..*>;
>    } PIDFilter;
>
> ...
>  constraints  Defines a list of additional constraints on which
>       elements of the Cost Map are returned.  This parameter MUST NOT be
>       specified if this resource's capabilities (Section 11.3.2.4)
>       indicate that constraint support is not available.  A constraint
>       contains two entities separated by whitespace: (1) an operator,
>       'gt' for greater than, 'lt' for less than, 'ge' for greater than
>       or equal to, 'le' for less than or equal to, or 'eq' for equal to;
>       (2) a target cost value. 
>
> - The Endpoint Cost service allows filtering (Sec. 11.5.1.3) as well,
> and is similar to Cost Map Filtering:
>
>    object {
>      CostType          cost-type;
>      [JSONString       constraints<0..*>;]
>      EndpointFilter    endpoints;
>    } ReqEndpointCostMap;
>
>    object {
>      [TypedEndpointAddr srcs<0..*>;]
>      [TypedEndpointAddr dsts<0..*>;]
>    } EndpointFilter;
>
>    constraints  Defined equivalently to the "constraints" input
>       parameter of a Filtered Cost Map (see Section 11.3.2).
>
> In other words, in the base protocol, the filtering condition and the
> output are based on the same Cost Metric. It is natural that the
> filtering and the output are based on different Cost metrics. For
> example, a Client asks for routingcost for only pairs whose latency is
> below a threshold (see use cases in
> http://tools.ietf.org/html/draft-randriamasy-alto-multi-cost-07). 
>
> One may argue that the filter-metric-no-equal-to-output-metric
> function can be implemented on top of the
> filter-and-output-using-one-metric function:
>
> In particular, suppose the filtering is based on metrics M1 and M2,
> and the output is M3, for a set src to a set dsts. The Client can use
> the following three queries:
>
> - Q1: Use single metric <M1, filter on M1, srcs, dsts> and obtains
> <srcs1, dsts1> in return;
> - Q2: Use single metric <M2, filter on M2, srcs1, dsts1> and obtains
> <srcs2, dsts2> in return;
> - Q3: Use single metric <M3, no filter, srcs2, dsts2> to get the final
> result.
>
> Although this is not too bad, it is inconvenient. Note that preceding
> is first discussed by Sabine, Wendy, Nico in:
> http://tools.ietf.org/html/draft-randriamasy-alto-multi-cost-07
>
> I saw that this is also the issue discussed in  
> - http://tools.ietf.org/html/draft-wu-alto-json-te-01
> - http://tools.ietf.org/html/draft-lee-alto-app-net-info-exchange-02
>
> Hence, I propose that the WG extends the base protocol with this
> capability, as I see that it is quite useful. One issue is that I see
> three designs, and I am wondering if the authors are preparing on
> discussing their designs at the coming IETF, and if there is a
> possibility for a single, unified document, focusing on this issue.
>
> Thanks a lot!
>
> Richard


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]