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 <y...@cs.yale.edu> Sent: Monday, February 28, 2023 10:28 To: IETF ALTO <alto@ietf.org> 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
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto