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 > 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 -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
