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 protected]> wrote: > *From:* RANDRIAMASY, SABINE (SABINE) [mailto: > [email protected]] > *Sent:* Wednesday, October 16, 2013 1:16 AM > *To:* Qin Wu; Y. Richard Yang; IETF ALTO > *Cc:* ROOME, Wendy D (Wendy); [email protected]; Leeyoung; Greg > Bernstein; [email protected]; 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 protected]] > *Envoyé :* mardi 15 octobre 2013 11:50 > *À :* Y. Richard Yang; IETF ALTO > *Cc :* RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); > [email protected]; Leeyoung; Greg Bernstein; [email protected]; 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**** >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
