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

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 21 Oct 2013 10:08:59 -0400

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

On Friday, October 18, 2013, RANDRIAMASY, SABINE (SABINE) wrote:

>  Hi Richard, ****
>
> ** **
>
> Please see inline****
>
> Sabine****
>
> ** **
>
> *De :* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> *De la part de* Y. Richard Yang
> *Envoyé :* vendredi 18 octobre 2013 08:14
> *À :* RANDRIAMASY, SABINE (SABINE)
> *Cc :* IETF ALTO; ROOME, Wendy D (Wendy); [email-masked]<javascript:_e({}, 'cvml', [email-masked]');>;
> Qin Wu; Young Lee; Greg Bernstein; [email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>; 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) <
> [email-masked]> 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 :* [email-masked] [mailto:[email-masked]] *De la part de
> * Y. Richard Yang
> *Envoyé :* lundi 14 octobre 2013 04:42
> *À :* IETF ALTO
> *Cc :* RANDRIAMASY, SABINE (SABINE); ROOME, Wendy D (Wendy);
> [email-masked]; Qin Wu; Young Lee; Greg Bernstein; [email-masked];
> 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… *****
>
> **
>
>