Subject: [alto] ALTO multidomain extension

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 4 Nov 2020 17:12:35 -0500

Dear ALTOers,

During the weekly meeting yesterday, one issue discussed is an extension of
ALTO to multidomains. This is a relevant issue and investigated by Ingmar,
Sebastian, Kai and Qiao. Below is a proposal to get the WG feedback.

Problem: Consider a basic ALTO service say the endpoint-cost service (ECS).
The client has a set of (srci, dsti) pairs which we call flows, and a
performance metric m; the client wants to query the system to receive the
value of m for each flow. The existing ALTO framework solves the issue in
the context of a single domain network as follows:

- Use ALTO service discovery (using an address say srci) to find the single
ALTO server
- Send the ECS query to the server

The preceding will not work if the {(srci, dsti)} span multiple networks.
Consider the simplest case of only one flow, but the path of the flow spans
multiple networks: assume src is in network 1,

src ---> net1-int ----> net1-egress ---> net2-ingress ----> net2-int --->
dst,

then the information does not come from a single network (via its ALTO
server), but should come from multiple segments, assuming that there is not
an aggregator ALTO server sering both net1 and net2, Hence, it is a
relevant issue that we should solve.

To show that this is not a research problem because it has no solution yet,
the team designed an initial solution which should address the following
two tasks:

[T1] first, we need a solution to discover that the path from a src to a
dst.
[T2] given a network, the query will no longer be from the src to the dst,
but from a given ingress.

A first solution demonstrating the feasibility is the following:

- [E1] For a given network, add a new ALTO service with
  input: a flow, its ingress to the network
  output: the egress of the flow from the network, and the ingress of the
network
  // To address issue that there can be internal addresses (e.g.,
net1-egress, net1-ingress), we design that the return includes a network
identifier

- [E2] Extend basic (full path) cost service to collect segment cost.

Basic single flow case:

  input: a flow, its ingress to the network. [egress of this network;
ingress-next]
  output: the cost (metric m) of the flow traversing the segment from
ingress to egress
 // comment: missing the segment from egress to next ingress; in general
case, we can include the segment from ingress to next ingress for
consistency but the WG can discuss this issue for final design.

General multi flows, as the original cost service. Then the client using E1
can construct a flow graph from all flows specified in the original ECS
query, e.g.,

 src1 ---> net1-int ---> net1-egress ---> net2-ingress ---> net2-int -->
dst1
                                ^
     \
                               /
      \
 src2 --> net1-int  -
net2-int --> ...

For the same network, the client collects all sgements traversing the
network and issue a single query. Note that this makes the original cost
services just c a special case.

[E3] Instead of client conducting aggregation (aka DNS iterative), the
client can request an aggregator like query (aka DNS recursive). Single the
aggregator may not be able to aggregate data from different networks for
some metrics (e.g., internal-cost), the results will be a vector instead of
a single number.

We will go over some details during the recharter discussion in 2 weeks but
want to share this simple, clean design first with the WG to seek feedback.

Cheers,
Richard