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
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
