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

["Y. Richard Yang" <[e-mail]>]

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