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

[Y. Richard Yang]

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

[Y. Richard Yang]

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

Post by Y. Richard Yang
Dear all,
The base ALTO protocol (
http://www.ietf.org/id/draft-ietf-alto-protocol-20.txt) is mostly a
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
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
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
- 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
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

[Qin Wu]

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: alto-***@ietf.org [mailto:alto-***@ietf.org] On Behalf Of Y. Richard Yang
Sent: Monday, October 14, 2013 10:42 AM
To: IETF ALTO
Cc: Wendy Roome; ***@etri.re.kr; 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 <***@cs.yale.edu<mailto:***@cs.yale.edu>> 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

[RANDRIAMASY, SABINE (SABINE)]

A few questions and comments inline to make sure I understood. If we are to document proposed filtering services, should we put separate sections, one on filtering services for the basic protocol and the other one, more prospective for protocol extensions on topologies?
Thanks
Sabine


De : ***@gmail.com [mailto:***@gmail.com] De la part de Y. Richard Yang
Envoyé : lundi 14 octobre 2013 04:42
À : IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); ***@nico-schwan.de; Qin Wu; Young Lee; Greg Bernstein; ***@etri.re.kr; dhruv.dhody
Objet : Re: 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;
[ ] This use case corresponds to the base protocol. The requested service is the ALTO Cost Map Filtering Service w.r.t metric values. It seems easy to extend this service by extending the set of constraints with additional constraints metrics and additional logical operators.

- 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.
[ ] This use case relates to a proposed ALTO extension on topologies providing cost maps where there may be several paths between an (S,D) pair. Is the ALTO Service here the ALTO Cost Map Filtering Service w.r.t metric values adapted to a multi-path topology? The cost map here would need to include some index on the cost value w.r.t. the relay ID and the service would only return cost values on the indexed (S,D, idx) triples satisfying the constraints. If this is correct, then such a use case would well fit into filtering services for topology based ALTO extensions.

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.
[ ] I think the composition and optimization operators should be documented in any case (I think in the "use and application" field of the RFC6390 template). Indeed, the OPTIMUM-COMPOSITION attributes may be MIN-SUM, MAX-MIN, MIN-PROD etc...

In the base protocol an e2e cost value provided by the server is already composed and abstracted. But if we have a protocol extension that details paths per sections, then indeed e2e path cost composition may have to be done at the ALTO Client side.

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 <***@cs.yale.edu<mailto:***@cs.yale.edu>> 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

[Y. Richard Yang]

Hi Sabine,

Good comments. Please see below.

On Thu, Oct 17, 2013 at 1:40 PM, RANDRIAMASY, SABINE (SABINE) <

Post by RANDRIAMASY, SABINE (SABINE)
A few questions and comments inline to make sure I understood. If we are
to document proposed filtering services, should we put separate sections,
one on filtering services for the basic protocol and the other one, more
prospective for protocol extensions on topologies?

Following the guideline of modular design, how about using different
documents whenever possible?

Here is some thinking on organization. A main design feature of the
ALTO base protocol is its single-switch abstraction. Hence, how about we
first focus on filtering on this base abstraction, and not beyond?

Specifically, in this base abstraction model, a network map and a cost map
based on the network map defines an abstract, single switch. Each PID in
the network map defines a PoP (i.e., the set of endhosts, which can be
either servers or clients in an application context, attached to this PoP),
and the cost map of each cost metric defines the pair-wise values of the
given cost metric. Let V be the set of n PIDs (nodes), and E the set of n^2
edges. Filtering is to help an application to narrow down its choices when
building an application overlay based on this single-switch model. Hence,
we need to define the following components:

- how to filter the set of nodes?
- how to filter the set of candidate overlay paths (one hop or multiple
hops in extreme e.g., origin -> edge server -> consumer)?

Richard

Post by RANDRIAMASY, SABINE (SABINE)
****
Thanks****
Sabine****
** **
** **
*De la part de* Y. Richard Yang
*Envoyé :* lundi 14 octobre 2013 04:42
*À :* IETF ALTO
*Cc :* RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy);
*Objet :* Re: 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;****
*[ ] This use case corresponds to the base protocol. The requested
service is the ALTO Cost Map Filtering Service w.r.t metric values. It
seems easy to extend this service by extending the set of constraints with
additional constraints metrics and additional logical operators. *****
** **
- 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. ***
*
*[ ] This use case relates to a proposed ALTO extension on topologies
providing cost maps where there may be several paths between an (S,D) pair.
Is the ALTO Service here the ALTO Cost Map Filtering Service w.r.t metric
values adapted to a multi-path topology? The cost map here would need to
include some index on the cost value w.r.t. the relay ID and the service
would only return cost values on the indexed (S,D, idx) triples satisfying
the constraints. If this is correct, then such a use case would well fit
into filtering services for topology based ALTO extensions. *****
** **
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.****
*[ ] I think the composition and optimization operators should be
documented in any case (I think in the “use and application” field of the
RFC6390 template). Indeed, the OPTIMUM-COMPOSITION attributes may be
MIN-SUM, MAX-MIN, MIN-PROD etc… *
* *
*In the base protocol an e2e cost value provided by the server is already
composed and abstracted. But if we have a protocol extension that details
paths per sections, then indeed e2e path cost composition may have to be
done at the ALTO Client side. *
** **
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****
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
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****
** **

[RANDRIAMASY, SABINE (SABINE)]

Hi Richard,

Please see inline
Sabine

De : ***@gmail.com [mailto:***@gmail.com] De la part de Y. Richard Yang
Envoyé : vendredi 18 octobre 2013 08:14
À : RANDRIAMASY, SABINE (SABINE)
Cc : IETF ALTO; ROOME, Wendy D (Wendy); ***@nico-schwan.de; Qin Wu; Young Lee; Greg Bernstein; ***@etri.re.kr; dhruv.dhody
Objet : ALTO Extension: A document defining multi-metrics filtering?

Hi Sabine,

Good comments. Please see below.

On Thu, Oct 17, 2013 at 1:40 PM, RANDRIAMASY, SABINE (SABINE) <***@alcatel-lucent.com<javascript:_e(%7b%7d,%20'cvml',%20'***@alcatel-lucent.com');>> wrote:
A few questions and comments inline to make sure I understood. If we are to document proposed filtering services, should we put separate sections, one on filtering services for the basic protocol and the other one, more prospective for protocol extensions on topologies?
Following the guideline of modular design, how about using different documents whenever possible?
[ ] agree

Here is some thinking on organization. A main design feature of the ALTO base protocol is its single-switch abstraction. Hence, how about we first focus on filtering on this base abstraction, and not beyond?
[ ] Ok then I will start on my side and document the set of filtering services for the base protocol, based on the Multi-Cost 07 proposal, the proposals of Young et al. and Qin et al. , list what I see as possible harmonization items to have a discussion basis.

Specifically, in this base abstraction model, a network map and a cost map based on the network map defines an abstract, single switch. Each PID in the network map defines a PoP (i.e., the set of endhosts, which can be either servers or clients in an application context, attached to this PoP), and the cost map of each cost metric defines the pair-wise values of the given cost metric. Let V be the set of n PIDs (nodes), and E the set of n^2 edges. Filtering is to help an application to narrow down its choices when building an application overlay based on this single-switch model. Hence, we need to define the following components:

- how to filter the set of nodes?
- how to filter the set of candidate overlay paths (one hop or multiple hops in extreme e.g., origin -> edge server -> consumer)?
[ ] Ok

Richard

Thanks
Sabine


De : ***@gmail.com<javascript:_e(%7b%7d,%20'cvml',%20'***@gmail.com');> [mailto:***@gmail.com<javascript:_e(%7b%7d,%20'cvml',%20'***@gmail.com');>] De la part de Y. Richard Yang
Envoyé : lundi 14 octobre 2013 04:42
À : IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); ***@nico-schwan.de<javascript:_e(%7b%7d,%20'cvml',%20'***@nico-schwan.de');>; Qin Wu; Young Lee; Greg Bernstein; ***@etri.re.kr<javascript:_e(%7b%7d,%20'cvml',%20'***@etri.re.kr');>; dhruv.dhody
Objet : Re: 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;
[ ] This use case corresponds to the base protocol. The requested service is the ALTO Cost Map Filtering Service w.r.t metric values. It seems easy to extend this service by extending the set of constraints with additional constraints metrics and additional logical operators.

- 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.
[ ] This use case relates to a proposed ALTO extension on topologies providing cost maps where there may be several paths between an (S,D) pair. Is the ALTO Service here the ALTO Cost Map Filtering Service w.r.t metric values adapted to a multi-path topology? The cost map here would need to include some index on the cost value w.r.t. the relay ID and the service would only return cost values on the indexed (S,D, idx) triples satisfying the constraints. If this is correct, then such a use case would well fit into filtering services for topology based ALTO extensions.

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.
[ ] I think the composition and optimization operators should be documented in any case (I think in the "use and application" field of the RFC6390 template). Indeed, the OPTIMUM-COMPOSITION attributes may be MIN-SUM, MAX-MIN, MIN-PROD etc...

In the base protocol an e2e cost value provided by the server is already composed and abstracted. But if we have a protocol extension that details paths per sections, then indeed e2e path cost composition may have to be done at the ALTO Client side.

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 <***@cs.yale.edu<javascript:_e(%7b%7d,%20'cvml',%20'***@cs.yale.edu');>> 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

[Y. Richard Yang]

Hi Sabine, all who are working on filtering,

Here is a use case that I use, personally, to evaluate a filtering service:

- this paper, which won IMC'12 Best Paper, measured the structures of
several applications, including Skype, Google Hangout, and iChat:
http://eeweb.poly.edu/faculty/yongliu/docs/imc12tech.pdf

- Suppose ALTO is ready and can be used for the Skype case (see Figure 2
page 4).

The setting then is:

Input:
- a set S of candidate relay servers (say VIP represented by pid or real
IP);
- a set C of participants;

Output:
- determine who should be the initiator (we often try different people as
initiator to try o improve performance): init(C);
- determine a relay server for each c in C: relay (c)

One can see that there can be multiple constraints:

- audio paths:
c1 -> init(C) -> c2 latency requirement, for any c1, c2;
Download and upload bw of init(C) >= all video streams;

- video paths:
latency and bw on the servers.

I am hoping that any filtering service, if we design, is evaluated by the
preceding case.

Cheers!

Richard

Hi Richard, ****
** **
Please see inline****
Sabine****
** **
*De la part de* Y. Richard Yang
*Envoyé :* vendredi 18 octobre 2013 08:14
*À :* RANDRIAMASY, SABINE (SABINE)
*Objet :* ALTO Extension: A document defining multi-metrics filtering?****
** **
Hi Sabine,****
** **
Good comments. Please see below.****
** **
On Thu, Oct 17, 2013 at 1:40 PM, RANDRIAMASY, SABINE (SABINE) <
A few questions and comments inline to make sure I understood. If we are
to document proposed filtering services, should we put separate sections,
one on filtering services for the basic protocol and the other one, more
prospective for protocol extensions on topologies?****
Following the guideline of modular design, how about using different
documents whenever possible?****
*[ ] agree*
* *
Here is some thinking on organization. A main design feature of the
ALTO base protocol is its single-switch abstraction. Hence, how about we
first focus on filtering on this base abstraction, and not beyond?****
*[ ] Ok then I will start on my side and document the set of
filtering services for the base protocol, based on the Multi-Cost 07* *proposal,
the proposals of Young et al. and Qin et al. , list what I see as
possible harmonization items to have a discussion basis. *****
** **
Specifically, in this base abstraction model, a network map and a cost map
based on the network map defines an abstract, single switch. Each PID in
the network map defines a PoP (i.e., the set of endhosts, which can be
either servers or clients in an application context, attached to this PoP),
and the cost map of each cost metric defines the pair-wise values of the
given cost metric. Let V be the set of n PIDs (nodes), and E the set of n^2
edges. Filtering is to help an application to narrow down its choices when
building an application overlay based on this single-switch model. Hence,
we need to define the following components:****
** **
- how to filter the set of nodes?****
- how to filter the set of candidate overlay paths (one hop or multiple
hops in extreme e.g., origin -> edge server -> consumer)?****
*[ ] Ok*****
** **
Richard****
****
Thanks****
Sabine****
****
****
* Y. Richard Yang
*Envoyé :* lundi 14 octobre 2013 04:42
*À :* IETF ALTO
*Cc :* RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy);
dhruv.dhody
*Objet :* Re: 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;****
*[ ] This use case corresponds to the base protocol. The requested
service is the ALTO Cost Map Filtering Service w.r.t metric values. It
seems easy to extend this service by extending the set of constraints with
additional constraints metrics and additional logical operators. *****
****
- 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. ***
*
*[ ] This use case relates to a proposed ALTO extension on topologies
providing cost maps where there may be several paths between an (S,D) pair.
Is the ALTO Service here the ALTO Cost Map Filtering Service w.r.t metric
values adapted to a multi-path topology? The cost map here would need to
include some index on the cost value w.r.t. the relay ID and the service
would only return cost values on the indexed (S,D, idx) triples satisfying
the constraints. If this is correct, then such a use case would well fit
into filtering services for topology based ALTO extensions. *****
****
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.****
*[ ] I think the composition and optimization operators should be
documented in any case (I think in the “use and application” field of the
RFC6390 template). Indeed, the OPTIMUM-COMPOSITION attributes may be
MIN-SUM, MAX-MIN, MIN-PROD etc… *****
**

[Qin Wu]

Hi,Richard:
Thanks for raising discussion for this on the list.
Please see my reply inline below.

Regards!
-Qin

Sent: Monday, October 14, 2013 7:58 AM
To: IETF ALTO
Subject: ALTO Extension: A document defining multi-metrics filtering?
Dear all,
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.
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.

[Qin]: Exactly, the restriction of base protocol is require filtering condition and the output basing on the same cost metric,e.g., routing cost.
In draft-wu-alto-json-te-01, we propose to relax such restriction to make filtering condition and the output based on the different cost metric.
The change to the base protocol is:
In the JSON Object of type ReqFilteredCostMap in base protocol, the constraint
attribute is expressed as:
"
[gt | lt | ge | le | eq ] <value>
"

In draft-wu-alto-json-te-01, the constraint attribute is changed to
"
<cost-type2> [gt | lt | ge | le | eq ] <value>
"
i.e., an cost type is by default cost-type in the JSON Object of type ReqFilteredCostMap in base protocol.
However it could be another cost-type used for the returned cost.

I guess this new constraint attribute should go to the document defining multi-metrics filering.

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).
- 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.

[Qin]: I believe the base ALTO protocol support these queries.
However it doesn't looks efficient to do such query since these queries should happen in order one by one , i.e.,<Q1,Q2,Q3>.
It takes three round exchange to get the results.

If we have five or six metrics as filtering, it takes ever longer to get the results, which is not desirable.

On the other hand, in some cases, not only we want to know cost information from one source endpoint to one destination endpoint, but also
We want to know all the endpoints traversed by traffic in the path that satisfy several constraints, e.g.,delay, packet loss, jitter, bandwidth.
e.g., in path computation in the networks, we want to compute end-to-end path with latency, latency-variation and packet loss
constraints, the end to end path is identified by (source address, middlepoint1 address, middlepoint2 address,....,destination address)

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

[Qin]:Young ,Dhruv and I have already looking for consolidation in this aspect in these days.

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.

[Qin]: Good idea, I think some constraints can be applied to all path from source endpoint to destination, some constraint can be applied to some links in the path.
e.g., delay can be applied to per link or end to end path, if the delay is applied to the end to end path, that means, we want to find a path from src to dest that meets end to end delay requirement.
Another example is utilized bandwidth, utilized bandwidth can be applied to per link, if the utilized bandwidth is applied to per link, that means we want to find a path from src to dest that meet
Per link bandwidth utilization requirement.

Thanks a lot!
Richard

[Greg Bernstein]

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.

Post by Y. Richard Yang
Dear all,
The base ALTO protocol
(http://www.ietf.org/id/draft-ietf-alto-protocol-20.txt) is mostly a
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,
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
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
- 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
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

[Qin Wu]

- 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.
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.
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.


b. draft-randriamasy-alto-multi-cost-07 specifies one new cost metrics (i.e.,pathoccupationcost) 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.


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. 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.



Thanks a lot!

Richard

[RANDRIAMASY, SABINE (SABINE)]

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:***@huawei.com]
Envoyé : mardi 15 octobre 2013 11:50
À : Y. Richard Yang; IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); ***@nico-schwan.de; Leeyoung; Greg Bernstein; ***@etri.re.kr; Dhruv Dhody
Objet : RE: ALTO Extension: A document defining multi-metrics filtering?

- 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.
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.

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.


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.

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.



Thanks a lot!

Richard

[Qin Wu]

From: RANDRIAMASY, SABINE (SABINE) [mailto:***@alcatel-lucent.com]
Sent: Wednesday, October 16, 2013 1:16 AM
To: Qin Wu; Y. Richard Yang; IETF ALTO
Cc: ROOME, Wendy D (Wendy); ***@nico-schwan.de; Leeyoung; Greg Bernstein; ***@etri.re.kr; 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:***@huawei.com]
Envoyé : mardi 15 octobre 2013 11:50
À : Y. Richard Yang; IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); ***@nico-schwan.de; Leeyoung; Greg Bernstein; ***@etri.re.kr; Dhruv Dhody
Objet : RE: ALTO Extension: A document defining multi-metrics filtering?

- 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.
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

[Y. Richard Yang]

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

*Sent:* Wednesday, October 16, 2013 1:16 AM
*To:* Qin Wu; Y. Richard Yang; IETF ALTO
*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****
** **
** **
*Envoyé :* mardi 15 octobre 2013 11:50
*À :* Y. Richard Yang; IETF ALTO
*Cc :* RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy);
Dhody
*Objet :* RE: ALTO Extension: A document defining multi-metrics filtering?
****
** **

Post by Y. Richard Yang
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:****
** **

Post by Y. Richard Yang
- Q1: Use single metric <M1, filter on M1, srcs, dsts> and obtains

<srcs1, dsts1> in return;****

Post by Y. Richard Yang
- Q2: Use single metric <M2, filter on M2, srcs1, dsts1> and obtains

<srcs2, dsts2> in return;****

Post by Y. Richard Yang
- Q3: Use single metric <M3, no filter, srcs2, dsts2> to get the final

result.****
** **

Post by Y. Richard Yang
Although this is not too bad, it is inconvenient. Note that preceding is
http://tools.ietf.org/html/draft-randriamasy-alto-multi-cost-07****

** **

Post by Y. Richard Yang
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****

** **

Post by Y. Richard Yang
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 ****

Post by Y. Richard Yang
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****

[RANDRIAMASY, SABINE (SABINE)]

Dear Richard,
Thanks for your comments, see my answers inline,
Best regards
Sabine

De : ***@gmail.com [mailto:***@gmail.com] De la part de Y. Richard Yang
Envoyé : mercredi 16 octobre 2013 19:43
À : Qin Wu
Cc : RANDRIAMASY, SABINE (SABINE); IETF ALTO; ROOME, Wendy D (Wendy); ***@nico-schwan.de; Leeyoung; Greg Bernstein; ***@etri.re.kr; Dhruv Dhody
Objet : Re: ALTO Extension: A document defining multi-metrics filtering?

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.
[ ] Indeed, allowing a fine granularity in the constraint metric values may end up accepting to reveal real values. In such a case, using metrics for "filtering-only" would then just allow to gain time.
How may this be addressed: specify that this is a controlled or semi-control environment, or impose other constraints on multiple queries?
[ ] It is an interesting option to impose constraints such as a minimal value range for "AND" constraints or coarse value granularity, say multiple of K.

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?
[ ] We may start sorting out the different possible filtering services that could be integrated in the base protocol, with associated conditions (controlled or not) and related constraints & rules.
Is there a need for an informal design meeting before the ALTO meeting?
[ ] A meeting would be for sure interesting.

Thanks a lot!

Richard

On Wed, Oct 16, 2013 at 5:01 AM, Qin Wu <***@huawei.com<mailto:***@huawei.com>> wrote:
From: RANDRIAMASY, SABINE (SABINE) [mailto:***@alcatel-lucent.com<mailto:***@alcatel-lucent.com>]
Sent: Wednesday, October 16, 2013 1:16 AM
To: Qin Wu; Y. Richard Yang; IETF ALTO
Cc: ROOME, Wendy D (Wendy); ***@nico-schwan.de<mailto:***@nico-schwan.de>; Leeyoung; Greg Bernstein; ***@etri.re.kr<mailto:***@etri.re.kr>; 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:***@huawei.com<mailto:***@huawei.com>]
Envoyé : mardi 15 octobre 2013 11:50
À : Y. Richard Yang; IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); ***@nico-schwan.de<mailto:***@nico-schwan.de>; Leeyoung; Greg Bernstein; ***@etri.re.kr<mailto:***@etri.re.kr>; Dhruv Dhody
Objet : RE: ALTO Extension: A document defining multi-metrics filtering?

- 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.
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

[RANDRIAMASY, SABINE (SABINE)]

Hi again,

Re-sending. For some reason, Dhruv, Greg, Lee and Nico were no more on the recipient list, sorry.
Sabine

De : alto-***@ietf.org [mailto:alto-***@ietf.org] De la part de RANDRIAMASY, SABINE (SABINE)
Envoyé : jeudi 17 octobre 2013 00:44
À : Y. Richard Yang; Qin Wu
Cc : ROOME, Wendy D (Wendy); IETF ALTO; ***@etri.re.kr
Objet : Re: [alto] ALTO Extension: A document defining multi-metrics filtering?

Dear Richard,
Thanks for your comments, see my answers inline,
Best regards
Sabine

De : ***@gmail.com<mailto:***@gmail.com> [mailto:***@gmail.com] De la part de Y. Richard Yang
Envoyé : mercredi 16 octobre 2013 19:43
À : Qin Wu
Cc : RANDRIAMASY, SABINE (SABINE); IETF ALTO; ROOME, Wendy D (Wendy); ***@nico-schwan.de<mailto:***@nico-schwan.de>; Leeyoung; Greg Bernstein; ***@etri.re.kr<mailto:***@etri.re.kr>; Dhruv Dhody
Objet : Re: ALTO Extension: A document defining multi-metrics filtering?

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.
[ ] Indeed, allowing a fine granularity in the constraint metric values may end up accepting to reveal real values. In such a case, using metrics for "filtering-only" would then just allow to gain time.
How may this be addressed: specify that this is a controlled or semi-control environment, or impose other constraints on multiple queries?
[ ] It is an interesting option to impose constraints such as a minimal value range for "AND" constraints or coarse value granularity, say multiple of K.

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?
[ ] We may start sorting out the different possible filtering services that could be integrated in the base protocol, with associated conditions (controlled or not) and related constraints & rules.
Is there a need for an informal design meeting before the ALTO meeting?
[ ] A meeting would be for sure interesting.

Thanks a lot!

Richard

On Wed, Oct 16, 2013 at 5:01 AM, Qin Wu <***@huawei.com<mailto:***@huawei.com>> wrote:
From: RANDRIAMASY, SABINE (SABINE) [mailto:***@alcatel-lucent.com<mailto:***@alcatel-lucent.com>]
Sent: Wednesday, October 16, 2013 1:16 AM
To: Qin Wu; Y. Richard Yang; IETF ALTO
Cc: ROOME, Wendy D (Wendy); ***@nico-schwan.de<mailto:***@nico-schwan.de>; Leeyoung; Greg Bernstein; ***@etri.re.kr<mailto:***@etri.re.kr>; 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:***@huawei.com<mailto:***@huawei.com>]
Envoyé : mardi 15 octobre 2013 11:50
À : Y. Richard Yang; IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); ***@nico-schwan.de<mailto:***@nico-schwan.de>; Leeyoung; Greg Bernstein; ***@etri.re.kr<mailto:***@etri.re.kr>; Dhruv Dhody
Objet : RE: ALTO Extension: A document defining multi-metrics filtering?

- 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.
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

[Qin Wu]

From: ***@gmail.com [mailto:***@gmail.com] On Behalf Of Y. Richard Yang
Sent: Thursday, October 17, 2013 1:43 AM
To: Qin Wu
Cc: RANDRIAMASY, SABINE (SABINE); IETF ALTO; ROOME, Wendy D (Wendy); ***@nico-schwan.de; Leeyoung; Greg Bernstein; ***@etri.re.kr; Dhruv Dhody
Subject: Re: ALTO Extension: A document defining multi-metrics filtering?

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?
[Qin]: Cost metric used as constraint is different from cost metric used as output. The value of cost metric used as constraint is the requested value or range of a cost metric, the value of cost metric used as output is computed value.

Take PCEP as example, a Metric Object is defined in RFC5440. In this Metric Object, a flag bit 'C'(i.e.,comuted) is defined to indicate whether Path Computation Client(PCC) asks Path Computation Element(PCE) to return computed metric value. When the metric object is included in the PCE request message sent from PCC to PCE, this metric object could be used as constraint, when it is included in PCE response sent from PCE to PCC, it can be used to return the computed metric value.

Regarding controlled or semi-control, I think we need a parameter or a property to indicate which one is computed value, which one is metric value for a constraint.


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?


[Qin]: Agree and support.

Thanks a lot!

Richard

On Wed, Oct 16, 2013 at 5:01 AM, Qin Wu <***@huawei.com<mailto:***@huawei.com>> wrote:
From: RANDRIAMASY, SABINE (SABINE) [mailto:***@alcatel-lucent.com<mailto:***@alcatel-lucent.com>]
Sent: Wednesday, October 16, 2013 1:16 AM
To: Qin Wu; Y. Richard Yang; IETF ALTO
Cc: ROOME, Wendy D (Wendy); ***@nico-schwan.de<mailto:***@nico-schwan.de>; Leeyoung; Greg Bernstein; ***@etri.re.kr<mailto:***@etri.re.kr>; 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:***@huawei.com<mailto:***@huawei.com>]
Envoyé : mardi 15 octobre 2013 11:50
À : Y. Richard Yang; IETF ALTO
Cc : RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy); ***@nico-schwan.de<mailto:***@nico-schwan.de>; Leeyoung; Greg Bernstein; ***@etri.re.kr<mailto:***@etri.re.kr>; Dhruv Dhody
Objet : RE: ALTO Extension: A document defining multi-metrics filtering?

- 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.
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