Re: [alto] ALTO service query spanning multiple domains (ECS)

[Qin Wu <[e-mail]>]

Richard and All:

Come back for this multi-domain setting issue, I feel the first problem is about inter-domain alto query, when we assume each domain has one alto server, is the sequence of domain traversed is either administratively predetermined or discovered?

from source domain to destination domain, there are multiple intermediate domains in parallel, e.g., <src-domain, middle-domain-1, dest-domain>, <src-domain,middle-domain-2, dest-domain>, you have two domain sequence set, how do we tackle this case?



How inter domain query is exchanged across domain, I think server to server communication is required. In this case, one server can be seen as client, the other server plays the role of ALTO server. So the question is how does ALTO server know

Server to server communication happens within a single domain or across domain, I believe alto protocol extension is required, let’s say inter-domain flags to distinguish single domain communication from server to server communication across domain,

Similar idea can be seen in section 2.3 of draft-ietf-pce-stateful-interdomain.



Secondly, if we really want to support multi-domain setting, cross domain Topology Confidentiality needs to be considered,  we can explore how JOSE can be used to carry ALTO payloads across a collection of intermediate servers in different domain.

RFC5520 （https://datatracker.ietf.org/doc/rfc5520/）defines path key to hide the contents of a segment of a path. Maybe JOSE can be used to provide similar functionality.



Regarding Multi-flow queries, using caches seems to provide an optimization solution to the first problem but also adds a lot of complexity. Without end to end stitching label, it seems hard to get it implemented. If we want to tackle this hard problem,

I suggest to take a look at Backward-Recursive PCE-Based Computation (BRPC) Procedure defined in RFC5441 and Inter-domain Path Management defined in section 5 of draft-ietf-pce-stateful-interdomain.



Regarding metric-dependent function, you can refer to section 3.3 of RFC8233 for more details, do we want to define more new objective function?

One more question to the pseudo code below:

alto-server = server-discovery(ingressIP)
Is server discovery cross domain server discovery defined in RFC8686?

-Qin
发件人: alto [mailto:[e-mail]] 代表 Y. Richard Yang
发送时间: 2022年9月13日 10:51
收件人: IETF ALTO <[e-mail]>
主题: [alto] ALTO service query spanning multiple domains (ECS)

Hi all,

During the weekly meeting last week, we went over the details when deploying ALTO in a multi-domain setting, say the FTS/Rucio setting supporting the TCN deployment [1]. Below is the endpoint cost service (ECS) case, and it was suggested that we post it to the WG mailing list to update the WG and get potential feedback.

Problem: An ALTO client queries the endpoint cost from srcIP to dstIP for a given performance metric (e.g., latency). Consider the case that the srcIP and dstIP belong to different networks, with the whole layer-3 path as the list [ip[0], ip[1], ..., ip[N]], where ip[0] = srcIP and ip[N] = dstIP. Define Net(ip) as the function that maps an IP address to the network that owns the IP---ignore the complexity such as anycast since the deployment does not have this case. Then Net(srcIP) != Net(dstIP), if it is multi-domain. Consider the initial deployment that we have only an ALTO server for each network; that is, it provides ALTO service for only Net(srcIP) == Net(dstIP). Then, there is not a single ALTO server that can provide the answer.

Basic solution (one src-dst flow): Map the list [ip[0], ..., ip[N]] to a list of segments, where each segment starts with an IP address, and ends with the first IP address in the sequence that leaves the network of the start IP address. Hence, the basic query framework at an aggreation ALTO client:
- alto-ecs(srcIP, dstIP, metric)
  metrics = EMPTY
  ingressIP = srcIP
  do {
      alto-server = server-discovery(ingressIP)
      (metricVal, egressIP) = alto-server.query(ingressIP, srcIP, dstIP, metric)
      metrics.add(metricVal)
      ingressIP = egressIP
  } while (egressIP != dstIP)

The preceding assumes a procedure that collects segment attributes, and it can be a single pass composition using a metric-dependent function (e.g., latency is addition, and bw is min).

Multi-flow queries: ALTO ECS supports the querying of multiple src-dst pairs. A simple solution is to query each src-dst pair one-by-one. Such a query is necessary because the routing can be dependent on packet attributes (srcIP, dstIP) and a pseudo packet attribute (ingressIP), and the ALTO client cannot reuse the results. To allow reuse (both in multi-flow queries and caching of past queries), it helps that the ALTO server indicates equivalent classes, which Kai and Jensen investigated.

A revision of the protocol using caching and equivalent class is:
alto-server-cache: indexed by ALTO server, <attribute, mask> pairs
- alto-ecs(srcIP, dstIP, metric)
  metrics = EMPTY
  ingressIP = srcIP
  do {
      alto-server = server-discovery(ingressIP)
      if (alto-server-cache.match(alto-server, ingressIP, srcIP, dstIP)
         use cache results
      else
         (metricVal, egressIP; ingressIPMask, srcIPMask, dstIPMask)
                 = alto-server.query(ingressIP, srcIP, dstIP, metric)
         alto-server-cache.add(alto-server, <ingressIP, ingressIPMask>,
                    <srcIP, srcIPMask>, <dstIP, dstIPMask>
      metrics.add(metricVal)
      ingressIP = egressIP
  } while (egressIP != dstIP)

The mask design is a special case. For the general case, the most flexible equivalent class may be using predicates (e.g., supporting identifying the lower entries of longest prefix matching). It is an issue that can benefit from more benchmarking, or if there are any related pointers, the team will appreciate the pointers.

In the next email, Kai and Jensen will post a slightly different design supporting a map oriented service.

Cheers,

[1] Transport control networking: optimizing efficiency and control of data transport for data-intensive networks, https://dl.acm.org/doi/abs/10.1145/3538401.3548550