Richard took words out of my mouth,:) Yes, in some cases, from source to destination, there is only one hop away, or we only care about source endpoint address and destination endpoint address, we don't care about which intermediary it traverses in the path from src to destination, I think base protocol strong support such case.
However when we put more constraints on the path, e.g.,we need to compute an end to end path with these constraints. These constraints can be latency, packet loss, jitter. However latency, packet loss, jitter are usually gathered from routing protocol, and put as per link metrics, so we need to do some aggregation when we apply these per link metrics to the end to end path, e.g., per link latency, if we choose a path that traverses link A, link B, link C, then we can get end to end latency by choosing the sum of per link latency of link A, link B and link C. Regards! -Qin From: [email protected] [mailto:[email protected]] On Behalf Of Y. Richard Yang Sent: Monday, October 14, 2013 10:42 AM To: IETF ALTO Cc: Wendy Roome; [email protected]; Qin Wu Subject: Re: [alto] ALTO Extension: A document defining multi-metrics filtering? Let me add on: although a filtering service can be a very useful service, it can also be quite involved, and hence the WG may need to think through the issues when designing this service. For example, there are two types of use cases: - end-to-end: given src set {s1, s2, s3, ..., sn} and dst set {d1, d2, d3, ..., dm}, return all pairs (si, dj), where si in {s1, ..., sn} and dj in {d1, ..., dm} such that (si, dj) satisfies the constraints; - relay: given src s, dst d, and a relay candidate set {r1, r2, ..., rk}, return all of the ri such that s -> ri -> d satisfies the constraints. Note that with relay, we will then need to worry about the "composition" semantics of metrics. For example, delay might be additive, loss rate (unless small and independent) may not be. The relay could be even fancier (e.g., one-hop server detour such as Akamai one-hop detour and hence may involved two relay servers), but it may or may not be a good idea to go too complex, depending on if the WG can define a clean API (e.g., SQL select/where grammar comes to mind quickly). Thanks! Richard On Sun, Oct 13, 2013 at 7:57 PM, Y. Richard Yang <[email protected]<mailto:[email protected]>> 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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
