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

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 13 Oct 2013 19:57:52 -0400

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Oct 2013 03:14:14 +0000

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

Regards!
-Qin

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

>The base ALTO protocol (http://www.ietf.org/id/draft-ietf-alto-protocol-20.txt) is mostly a single-cost-metric centric:

...

>- The Endpoint Cost service allows filtering (Sec. 11.5.1.3) as well, and is similar to Cost Map Filtering:

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

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 14 Oct 2013 07:53:53 -0700

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
> 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:
>
> Although this is not too bad, it is inconvenient. Note that preceding
> is first discussed by Sabine, Wendy, Nico in:
> 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 (510) 573-2237

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Oct 2013 09:50:08 +0000

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

By comparing the designs in three drafts, here is my rough analysis.
the difference between these drafts are:

a.       draft-randriamasy-alto-multi-cost-07 seems to assume filtering condition and output are based on the same Cost metrics or a set of same metrics.
               Both draft-lee-alto-app-net-info-exchange-02 and draft-wu-alto-json-te-01 allows filtering condition and output based on different cost metrics
              and therefore it require filtering constraint   relaxing In the ALTO base protocol.

b.      draft-randriamasy-alto-multi-cost-07 specifies one new cost metrics (i.e.,pathoccupationcost) while draft-lee-alto-app-net-info-exchange-02

defines a new object called DstCostsConstraints which contains a list of cost metrics that are not stable over a constant period(i.e., they are

 dynamic parameters). draft-wu-alto-json-te-01 gives a complete list of those cost metrics based on IETF standardization work

(see draft-ietf-idr-ls-distribution-03,RFC5305, draft-wu-idr-te-pm-bgp<http://tools.ietf.org/id/draft-wu-idr-te-pm-bgp-02.txt>,draft-ietf-ospf-te-metric-extensions-04, draft-ietf-isis-te-metric-extensions-00)

and define them as a list of independent cost metrics.

c.       draft-randriamasy-alto-multi-cost-07 requires cost value encoded as JSON Array rather than JSON while  draft-lee-alto-app-net-info-exchange-02

also encode cost value as JSON Array. In addition, draft-lee-alto-app-net-info-exchange-02 defines linkentry object and support representing a

end to end path with a list of links traversed in the path. draft-wu-alto-json-te-01 also defines link related metrics and uses linkname to identify each link.

Thanks a lot!

Richard

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 15 Oct 2013 17:15:49 +0000

Hi Qin and all,

Thank to Richard and Qin for this discussion. Please see, my answers inline to Qin on the design positioning for filtering constraints.
Thanks for your feedback,
Sabine

De : Qin Wu [mailto:[email-masked]]
Envoyé : mardi 15 octobre 2013 11:50
À : Y. Richard Yang; IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); [email-masked]; Leeyoung; Greg Bernstein; [email-masked]; Dhruv Dhody
Objet : RE: ALTO Extension: A document defining multi-metrics filtering?

a.       draft-randriamasy-alto-multi-cost-07 seems to assume filtering condition and output are based on the same Cost metrics or a set of same metrics.
[     ] Correct. The initial thought was to smoothly extend the format of basic ALTO transactions (requ and responses) and handle only indexes of the multiple metrics listed in the Cost Type array.
               Both draft-lee-alto-app-net-info-exchange-02 and draft-wu-alto-json-te-01 allows filtering condition and output based on different cost metrics
              and therefore it require filtering constraint   relaxing In the ALTO base protocol.
[     ] We need to extend the base protocol filtering constraint as soon as there is more than one metric in the set of constraints, which is the case for all the 3 designs. It is a good idea to allow constraint involving metrics that do not belong to the set of requested cost metrics. One simple and light way to implement this is to allow an indexing of the cost types in the IRD and simply use these indexes in the expressions of constraints.

Note that draft-randriamasy-alto-multi-cost-07 in addition proposes to relate constraints by both logical AND and logical OR with the idea of supporting compromises such as  "either (solutions with moderate 'hopcount' AND  high 'routingcost') OR (solutions with higher 'hopcount' AND moderate 'routingcost')", see section 4.6.2 of the draft.

Last, as the intention is to filter the response on the ALTO metric values, the ALTO Server is required only to provide values meeting the constraints expressed in the request, but is not requested to provide values on the metrics involved in the constraints. Note that an ALTO Server operator may wish to use metrics only for filtering without unveiling the values, but this would require to extend the base protocol with a status such as "hidden" or "filter-only", which may be discussed when extending the ALTO Costs.

b.      draft-randriamasy-alto-multi-cost-07 specifies one new cost metrics (i.e.,pathoccupationcost)
[     ] the draft actually proposes, see 3.1.4: Endpoint Nominal Memory, Endpoint Nominal Bandwidth (ie CPU capacity), endpoint Occupied Memory, Endpoint Occupied Bandwidth, Path Occupation Cost. The naming is just a proposal. Some of these metrics may have values that change and are updated in different frequencies, but in no case are they real time measurements.
, while draft-lee-alto-app-net-info-exchange-02

[     ] very interesting sets and proposals. I agree that it would be useful to list proposals on metrics and their definition as suggested by Richard in another thread.

also encode cost value as JSON Array.

[     ] please correct me if I missed something, in the example of draft-lee-alto-app-net-info-exchange-02, I see JSONArrays used to provide the value on each of the metrics expressed in the constraints for the admissible (S,D) pairs. No value is provided for the requested cost metric. I'm not sure I understand why and I think we may find a way to harmonize views on expressing constraints.

In addition, draft-lee-alto-app-net-info-exchange-02 defines linkentry object and support representing a

[     ] this looks very useful in cases where path costs and network maps are detailed below the end 2 end level. I see an easy integration of this idea with the topology extension proposed by Richard that assumes "multi-switched" paths (or their abstraction). Though I don't see a light and easy way to integrate constraints on path sections in the base protocol.

Thanks a lot!

Richard

---

From: Qin Wu <[email-masked]>
Date: Wed, 16 Oct 2013 09:01:29 +0000

From: RANDRIAMASY, SABINE (SABINE) [mailto:[email-masked]]
Sent: Wednesday, October 16, 2013 1:16 AM
To: Qin Wu; Y. Richard Yang; IETF ALTO
Cc: ROOME, Wendy D (Wendy); [email-masked]; Leeyoung; Greg Bernstein; [email-masked]; Dhruv Dhody
Subject: RE: ALTO Extension: A document defining multi-metrics filtering?

Hi Qin and all,

[Qin]:Good idea, this may require filtering constraint to be extended to support multiple cost representations as a joint constraint. I believe your draft has already specified this.

[Qin]: I believe this is related to how to distinguish the case where filtering condition and output are based on the same metric and the case where filtering condition and output are based on different cost metric.

[Qin]: It seems you have already answered this by proposing "hidden" or "filter-only" to indicate the metrics only used for filtering.

In my understanding, in path computation to the network, usually we use constraints only for compute the path, e.g., end to end latency in the path is less than 100 milliseconds, what is returned is not computed cost metric but a list of links in the path or a list of endpoints in the path that satisfy the constraint. However in some cases,

They do allow return computed cost metric to the client, e.g., we use end to end latency in the path less than 100 milliseconds as constraint, then we compute a path that satisfy this constraint,

Then the server can return the computed end to end latency (e.g.,50miliseconds) associated with this path to the client.

[Qin]:Your observation is correct.

Thanks a lot!

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 16 Oct 2013 13:43:29 -0400

Dear Qin, Sabine,

Great discussions!

Here are two quick questions:

1. I found the idea of distinguishing between "filtering-only" and
"revealing" quite interesting. Here is an "attack". Suppose latency is a
"filtering-only" metric: by specifying "latency <= 10 ms AND latency >= 5
ms" then will in a sense reveal the metric of latency. Even if we do not
allow AND, a client can make two queries and observe the difference. How
may this be addressed: specify that this is a controlled or semi-control
environment, or impose other constraints on multiple queries?

2. I actually see quite a lot synergy in the three docs. Personal, I would
like to propose that we add a WG item on a general filtering service. What
is the likelihood that there is some convergence on the design before IETF?
Is there a need for an informal design meeting before the ALTO meeting?

Thanks a lot!

Richard

On Wed, Oct 16, 2013 at 5:01 AM, Qin Wu <[email-masked]> wrote:

>   *From:* RANDRIAMASY, SABINE (SABINE) [mailto:
> [email-masked]]
> *Sent:* Wednesday, October 16, 2013 1:16 AM
> *To:* Qin Wu; Y. Richard Yang; IETF ALTO
> *Cc:* ROOME, Wendy D (Wendy); [email-masked]; Leeyoung; Greg
> Bernstein; [email-masked]; Dhruv Dhody
> *Subject:* RE: ALTO Extension: A document defining multi-metrics
> filtering?****
>
> ** **
>
> Hi Qin and all,****
>
> ** **
>
> Thank to Richard and Qin for this discussion. Please see, my answers
> inline to Qin on the design positioning for filtering constraints.****
>
> Thanks for your feedback, ****
>
> Sabine****
>
> ** **
>
> ** **
>
> *De :* Qin Wu [mailto:[email-masked]]
> *Envoyé :* mardi 15 octobre 2013 11:50
> *À :* Y. Richard Yang; IETF ALTO
> *Cc :* RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy);
> [email-masked]; Leeyoung; Greg Bernstein; [email-masked]; Dhruv
> Dhody
> *Objet :* RE: ALTO Extension: A document defining multi-metrics filtering?
> ****
>
> ** **
>
> >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;****
>
> <srcs2, dsts2> in return;****
>
> result.****
> ** **
> >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****
>
> ** **
>
> 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.**
> **
>
> ** **
>
> By comparing the designs in three drafts, here is my rough analysis.****
>
> the difference between these drafts are:****
>
> **a.       **draft-randriamasy-alto-multi-cost-07 seems to assume
> filtering condition and output are based on the same Cost metrics or a set
> of same metrics.****
>
> *[     ] Correct. The initial thought was to smoothly extend the format
> of basic ALTO transactions (requ and responses) and handle only indexes of
> the multiple metrics listed in the Cost Type array. *****
>
>                Both draft-lee-alto-app-net-info-exchange-02 and
> draft-wu-alto-json-te-01 allows filtering condition and output based on
> different cost metrics ****
>
>               and therefore it require filtering constraint   relaxing In
> the ALTO base protocol.****
>
> *[     ] We need to extend the base protocol filtering constraint as soon
> as there is more than one metric in the set of constraints, which is the
> case for all the 3 designs. It is a good idea to allow constraint involving
> metrics that do not belong to the set of requested cost metrics. One simple
> and light way to implement this is to allow an indexing of the cost types
> in the IRD and simply use these indexes in the expressions of constraints.
> *
>
> * *
>
> *Note that draft-randriamasy-alto-multi-cost-07 in addition proposes to
> relate constraints by both logical AND and logical OR with the idea of
> supporting compromises such as  “either (solutions with moderate 'hopcount'
> AND  high 'routingcost') OR (solutions with higher 'hopcount' AND moderate
> 'routingcost')”, see section 4.6.2 of the draft. *
>
> * *
>
> *[Qin]:Good idea, this may require filtering constraint to be extended to
> support multiple cost representations as a joint constraint. I believe your
> draft has already specified this.*
>
> * *
>
> *Last, as the intention is to filter the response on the ALTO metric
> values, the ALTO Server is required only to provide values meeting the
> constraints expressed in the request, but is not requested to provide
> values on the metrics involved in the constraints. Note that an ALTO Server
> operator may wish to use metrics only for filtering without unveiling the
> values, but this would require to extend the base protocol with a status
> such as “hidden” or “filter-only”, which may be discussed when extending
> the ALTO Costs.  *
>
> * *
>
> *[Qin]: I believe this is related to how to distinguish the case where
> filtering condition and output are based on the same metric and the case
> where filtering condition and output are based on different cost metric.*
>
> ** **
>
> **b.      **draft-randriamasy-alto-multi-cost-07 specifies one new cost
> metrics (i.e.,pathoccupationcost)****
>
> *[     ] the draft actually proposes, see 3.1.4: Endpoint Nominal Memory,
> Endpoint Nominal Bandwidth (ie CPU capacity), endpoint Occupied Memory,
> Endpoint Occupied Bandwidth, Path Occupation Cost. The naming is just a
> proposal. Some of these metrics may have values that change and are updated
> in different frequencies, but in no case are they real time measurements.
> *
>
> , while draft-lee-alto-app-net-info-exchange-02 ****
>
> defines a new object called DstCostsConstraints which contains a list of
> cost metrics that are not stable over a constant period(i.e., they are ***
> *
>
>  dynamic parameters). draft-wu-alto-json-te-01 gives a complete list of
> those cost metrics based on IETF standardization work****
>
> (see draft-ietf-idr-ls-distribution-03,RFC5305, draft-wu-idr-te-pm-bgp<http://tools.ietf.org/id/draft-wu-idr-te-pm-bgp-02.txt>,draft-ietf-ospf-te-metric-extensions-04,
> draft-ietf-isis-te-metric-extensions-00) ****
>
> and define them as a list of independent cost metrics.****
>
> *[     ] very interesting sets and proposals. I agree that it would be
> useful to list proposals on metrics and their definition as suggested by
> Richard in another thread.  *****
>
> ** **
>
> **c.       **draft-randriamasy-alto-multi-cost-07 requires cost value
> encoded as JSON Array rather than JSON while
>  draft-lee-alto-app-net-info-exchange-02 ****
>
> also encode cost value as JSON Array. ****
>
> *[     ] please correct me if I missed something, in the example of
> draft-lee-alto-app-net-info-exchange-02, I see JSONArrays used to provide
> the value on each of the metrics expressed in the constraints for the
> admissible (S,D) pairs. No value is provided for the requested cost metric.
> I’m not sure I understand why and I think we may find a way to harmonize
> views on expressing constraints. *
>
> * *
>
> *[Qin]: It seems you have already answered this by proposing “hidden” or
> “filter-only” to indicate the metrics only used for filtering.*
>
> *In my understanding, in path computation to the network, usually we use
> constraints only for compute the path, e.g., end to end latency in the path
> is less than 100 milliseconds, what is returned is not computed cost metric
> but a list of links in the path or a list of endpoints in the path that
> satisfy the constraint. However in some cases,*
>
> *They do allow return computed cost metric to the client, e.g., we use
> end to end latency in the path less than 100 milliseconds as constraint,
> then we compute a path that satisfy this constraint, *
>
> *Then the server can return the computed end to end latency
> (e.g.,50miliseconds) associated with this path to the client.*
>
> * *
>
> * *
>
> In addition, draft-lee-alto-app-net-info-exchange-02 defines linkentry
> object and support representing a ****
>
> end to end path with a list of links traversed in the path.
> draft-wu-alto-json-te-01 also defines link related metrics and uses
> linkname to identify each link.****
>
> *[     ] this looks very useful in cases where path costs and network
> maps are detailed below the end 2 end level. I see an easy integration of
> this idea with the topology extension proposed by Richard that assumes
> “multi-switched” paths (or their abstraction). Though I don’t see a light
> and easy way to integrate constraints on path sections in the base
> protocol. *****
>
> ** **
>
> *[Qin]:Your observation is correct.*
>
> ** **
>
> Thanks a lot!****
>
> ** **
>
> Richard****
>

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Wed, 16 Oct 2013 22:44:14 +0000

Dear Richard,
Thanks for your comments, see my answers inline,
Best regards
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de Y. Richard Yang
Envoyé : mercredi 16 octobre 2013 19:43
À : Qin Wu
Cc : RANDRIAMASY, SABINE (SABINE); IETF ALTO; ROOME, Wendy D (Wendy); [email-masked]; Leeyoung; Greg Bernstein; [email-masked]; Dhruv Dhody
Objet : Re: ALTO Extension: A document defining multi-metrics filtering?

Dear Qin, Sabine,

Great discussions!

1. I found the idea of distinguishing between "filtering-only" and "revealing" quite interesting. Here is an "attack". Suppose latency is a "filtering-only" metric: by specifying "latency <= 10 ms AND latency >= 5 ms" then will in a sense reveal the metric of latency. Even if we do not allow AND, a client can make two queries and observe the difference.
[     ] Indeed, allowing a fine granularity in the constraint metric values may end up accepting to reveal real values. In such a case, using metrics for "filtering-only" would then just allow to gain time.
How may this be addressed: specify that this is a controlled or semi-control environment, or impose other constraints on multiple queries?
[     ] It is an interesting option to impose constraints such as a minimal value range for "AND" constraints or coarse value granularity, say multiple of K.

2. I actually see quite a lot synergy in the three docs. Personal, I would like to propose that we add a WG item on a general filtering service. What is the likelihood that there is some convergence on the design before IETF?
[     ] We may start sorting out the different possible filtering services that could be integrated in the base protocol, with associated conditions (controlled or not) and related constraints & rules.
 Is there a need for an informal design meeting before the ALTO meeting?
[     ] A meeting would be for sure interesting.

Thanks a lot!

Richard

On Wed, Oct 16, 2013 at 5:01 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
From: RANDRIAMASY, SABINE (SABINE) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 16, 2013 1:16 AM
To: Qin Wu; Y. Richard Yang; IETF ALTO
Cc: ROOME, Wendy D (Wendy); [email-masked]<mailto:[email-masked]>; Leeyoung; Greg Bernstein; [email-masked]<mailto:[email-masked]>; Dhruv Dhody
Subject: RE: ALTO Extension: A document defining multi-metrics filtering?

Hi Qin and all,

De : Qin Wu [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 15 octobre 2013 11:50
À : Y. Richard Yang; IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); [email-masked]<mailto:[email-masked]>; Leeyoung; Greg Bernstein; [email-masked]<mailto:[email-masked]>; Dhruv Dhody
Objet : RE: ALTO Extension: A document defining multi-metrics filtering?

Thanks a lot!

Richard

---

From: Qin Wu <[email-masked]>
Date: Thu, 17 Oct 2013 03:58:34 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: Thursday, October 17, 2013 1:43 AM
To: Qin Wu
Cc: RANDRIAMASY, SABINE (SABINE); IETF ALTO; ROOME, Wendy D (Wendy); [email-masked]; Leeyoung; Greg Bernstein; [email-masked]; Dhruv Dhody
Subject: Re: ALTO Extension: A document defining multi-metrics filtering?

Dear Qin, Sabine,

Great discussions!

1.      I found the idea of distinguishing between "filtering-only" and "revealing" quite interesting. Here is an "attack". Suppose latency is a "filtering-only" metric: by specifying "latency <= 10 ms AND latency >= 5 ms" then will in a sense reveal the metric of latency. Even if we do not allow AND, a client can make two queries and observe the difference. How may this be addressed: specify that this is a controlled or semi-control environment, or impose other constraints on multiple queries?
[Qin]: Cost metric used as constraint is different from cost metric used as output. The value of cost metric used as constraint is the requested value or range of a cost metric, the value of cost metric used as output is computed value.

Take PCEP as example, a Metric Object is defined in RFC5440. In this Metric Object, a flag bit 'C'(i.e.,comuted) is defined to indicate whether Path Computation Client(PCC) asks Path Computation Element(PCE) to return computed metric value. When the metric object is included in the PCE request message sent from PCC to PCE, this metric object could be used as constraint, when it is included in PCE response sent from PCE to PCC, it can be used to return the computed metric value.

Regarding controlled or semi-control, I think we need a parameter or a property to indicate which one is computed value, which one is metric value for a constraint.

2.      I actually see quite a lot synergy in the three docs. Personal, I would like to propose that we add a WG item on a general filtering service. What is the likelihood that there is some convergence on the design before IETF? Is there a need for an informal design meeting before the ALTO meeting?

[Qin]: Agree and support.

Thanks a lot!

Richard

Hi Qin and all,

Thanks a lot!

Richard

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Wed, 16 Oct 2013 23:05:24 +0000

Hi again,

Re-sending. For some reason, Dhruv, Greg, Lee and Nico were no more on the recipient list, sorry.
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de RANDRIAMASY, SABINE (SABINE)
Envoyé : jeudi 17 octobre 2013 00:44
À : Y. Richard Yang; Qin Wu
Cc : ROOME, Wendy D (Wendy); IETF ALTO; [email-masked]
Objet : Re: [alto] ALTO Extension: A document defining multi-metrics filtering?

Dear Richard,

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Y. Richard Yang
Envoyé : mercredi 16 octobre 2013 19:43
À : Qin Wu
Cc : RANDRIAMASY, SABINE (SABINE); IETF ALTO; ROOME, Wendy D (Wendy); [email-masked]<mailto:[email-masked]>; Leeyoung; Greg Bernstein; [email-masked]<mailto:[email-masked]>; Dhruv Dhody
Objet : Re: ALTO Extension: A document defining multi-metrics filtering?

Dear Qin, Sabine,

Great discussions!

Thanks a lot!

Richard

Hi Qin and all,

Thanks a lot!

Richard