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

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

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 <[e-mail]> wrote:

>   *From:* RANDRIAMASY, SABINE (SABINE) [mailto:
> [e-mail]]
> *Sent:* Wednesday, October 16, 2013 1:16 AM
> *To:* Qin Wu; Y. Richard Yang; IETF ALTO
> *Cc:* ROOME, Wendy D (Wendy); [e-mail]; Leeyoung; Greg
> Bernstein; [e-mail]; 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:[e-mail]]
> *Envoyé :* mardi 15 octobre 2013 11:50
> *À :* Y. Richard Yang; IETF ALTO
> *Cc :* RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy);
> [e-mail]; Leeyoung; Greg Bernstein; [e-mail]; 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;****
>
> >- 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.**
> **
>
> ** **
>
> 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****
>