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
