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

[Qin Wu <[e-mail]>]

Hi,Richard:
Thanks for raising discussion for this on the list.
Please see my reply inline below.

Regards!
-Qin

>From: [e-mail] [mailto:[e-mail]] On Behalf Of Y. Richard Yang
>Sent: Monday, October 14, 2013 7:58 AM
>To: IETF ALTO
>Cc: Sabine Randriamasy; Wendy Roome; [e-mail]; Qin Wu; Leeyoung; Greg Bernstein; [e-mail]; Dhruv Dhody
>Subject: ALTO Extension: A document defining multi-metrics filtering?

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

[Qin]: Exactly, the restriction of base protocol is require filtering condition and the output basing on the same cost metric,e.g., routing cost.
In draft-wu-alto-json-te-01, we propose to relax such restriction to make filtering condition and the output based on the different cost metric.
The change to the base protocol is:
In the JSON Object of type ReqFilteredCostMap in base protocol, the constraint
attribute is expressed as:
"
[gt | lt | ge | le | eq ] <value>
"

In draft-wu-alto-json-te-01, the constraint attribute is changed to
      "
   <cost-type2>  [gt | lt | ge | le | eq ] <value>
      "
i.e., an cost type is by default cost-type in the JSON Object of type ReqFilteredCostMap in base protocol.
However it could be another cost-type used for the returned cost.

I guess this new constraint attribute should go to the document defining multi-metrics filering.


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

[Qin]: I believe the base ALTO protocol support these queries.
However it doesn't looks efficient to do such query since these queries should happen in order one by one , i.e.,<Q1,Q2,Q3>.
It takes three round exchange to get the results.

If we have five or  six metrics as filtering,  it takes ever longer to get the results, which is not desirable.

On the other hand, in some cases, not only we want to know cost information from one source endpoint to one destination endpoint, but also
We want to know all the endpoints traversed by traffic in the path that satisfy several constraints, e.g.,delay, packet loss, jitter, bandwidth.
e.g., in path computation in the networks, we want to compute  end-to-end path with latency, latency-variation and packet loss
 constraints, the end to end path is identified by (source address, middlepoint1 address, middlepoint2 address,....,destination address)


>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

[Qin]:Young ,Dhruv and I have already looking for consolidation in this aspect in these days.

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

[Qin]: Good idea, I think some constraints can be applied to all path from source endpoint to destination, some constraint can be applied to some links in the path.
e.g., delay can be applied to per link or end to end path, if the delay is applied to the end to end path, that means, we want to find a path from src to dest that meets end to end delay requirement.
Another example is utilized bandwidth, utilized bandwidth can be applied to per link, if the utilized bandwidth is applied to per link, that means we want to find a path from src to dest that meet
Per link bandwidth utilization requirement.

>Thanks a lot!

>Richard