Re: [alto] Multi-domain use case discussion

[mengtong <[e-mail]>]

Hi All,

Here is the use case I briefly explained in the interim meeting.

The stringent throughput and latency requirements of emerging immersive
applications tend to come with edge server deployment, making last-mile access
network the dominating bottleneck. Last-mile provider can expose differentiated
network QoS for server invocation by content provider. Application server can
treat differentiated network QoS as separate logical paths, and leverage
multi-path transport to optimize QoE. (Low-layer network feedback can also
be exposed as a network service, which is the case considered in MoWIE [1].)

In the above scenario, differentiated network services are exposed from
last-mile provider to content provider, forming a multi-domain setting. As
brought up by Richard in interim meeting, the problem could be extended if
multiple ISPs with disjoint physical last-mile are involved. Related
technologies of the use case need to be further discussed though. For example,
an in-band identifier may be needed so that last-mile provider can correctly
associate traffic to QoS pipe. Besides, the role of ALTO server/client may be
combined with network exposure in cellular last-mile (e.g., NEF and GSMA Open
Gateway [2,3]).

[1] https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/
[2] https://www.gsma.com/newsroom/press-release/gsma-open-gateway/
[3] https://dl.acm.org/doi/abs/10.1145/3538401.3546825

Best Wishes!
Tong

________________________________
From: Y. Richard Yang <[e-mail]>
Sent: Monday, February 28, 2023 10:28
To: IETF ALTO <[e-mail]>
Subject: [alto] Multi-domain use case discussion

Hi All,

With the interim meeting behind us, I was suggested to start the discussion
of the multi-domain use case, which is a use case driven by a real setting.

Details: A motivation use case of multi-domain ALTO is the LHCONE setting,
which is an L3VPN consisting of multiple networks [1]. Given a set of
endpoint nodes N (e.g., remote storage elements), and their connectivity,
which is a set E of selected source-destination pairs (s, d) in NxN, we can
define a multi-domain cluster as a set of autonomous systems formed by (1)
the autonomous systems containing the endpoints; and (2) the autonomous
systems on the path for those for an (s, d) in E.

Both the transport scheduling system (FTS) and the transport orchestration
system (Rucio) can benefit from a network view of a multi-domain cluster.
For example, FTS can use the mapping (s, d) -> path to compute the
accounting of total traffic volume on a given link; and Rucio can use (s,
d) -> path metric to select the source with the lowest distance path, when
there are multiple potential sources.

The current ALTO protocol is designed more for a single-domain setting, and
hence needs extensions to allow the stitching of information from multiple
ALTO servers representing the member autonomous systems (AS) in a
multi-domain cluster. For example, the source AS can have the global path
vector, but it is abstracted to the AS level. Hence, it needs a recursive
query process to reconstruct the finer-grain metrics (beyond the AS path
metric) of the path from the source to the destination. There can be
multiple southbound implementations, e.g., extension to BGP (e.g., flow
BGP) and also the extension of the ALTO northbound querying process. It
needs also to address the issue of incremental deployment.

Hence, a short paragraph describing the problem is:
Design ALTO multi-domain queries to compute the aggregated path metrics
from a given source to a given destination in a multi-domain cluster.

[1] https://twiki.cern.ch/twiki/bin/view/LHCONE/LhcOneMaps