There are, as far as I can tell, two very valid and very different
approaches to service selection / traffic direction. It can be done by
the application, or it can be done by the operator edge. CATS is
chartered to address the operator-based approach. Applications clearly
can chose to make their own decision, or to send anycast traffic
allowing CATS to make its decision.
However, expecting the network to expose detailed topology and related
metrics to end application clients seems unlikely. Which is why most
applications have taken the approach of using their own probes to make
their decisions. If you want to argue for a protocol to expose
information to client applications, that is a very complicated
discussion with many stakeholders. And it is a discussion that needs to
take place before one discusses exact metrics, or even the properties of
such an exposure mechanism. (It is an approach much closer to ALTO than
to CATS.)
Yours,
Joel
On 11/2/2023 1:45 PM, Jordi Ros Giralt wrote:
Thanks Linda for your comments. Find my responses below:
> Your draft describes two aspects of the service performance
> impacted by the Computing: Service Deployment and Service (Path)
> Selection. Those two should be separated, as the Service Deployment
> belongs to the OpsArea, and the Service selection (including Network
> Path & DCs that host the services) belongs to the Routing area.
[JRG] I agree that service deployment can be seen as part of ops area.
Service selection can both be seen as part of the routing area (as you
point out), but also a part of the application area. For instance, an
application running in a UE could decide whether to use 5G, 4G, or
Wi-Fi to connect to a service instance based on the communication and
compute resource information exposed to it.
> draft-ietf-idr-5g-edge-service-metadata has proposed a new Metadata Path
> Attribute and some Sub-TLVs for egress routers to advertise the Metadata
> about the attached edge services (ES).
> (...) Can this Metadata Path Attribute address the problem stated in your
draft?
[JRG] I agree this information is valuable to the ingress router to
make path selection decisions. In addition, there is also a need for
this information to be exposed to the service or application layer. If
there is service replication, the application running in the UE (or an
application-layer proxy on behalf of it) needs to decide which of the
service replicas it connects to. Once a service replica is selected,
the UE might also have a variety of ways to reach that service (e.g.,
4G, 5G, Wi-Fi). Both of these end-point selection decisions need to
know the available communication and compute resources.
Thanks,
Jordi
------------------------------------------------------------------------
*From:* Linda Dunbar <linda.dun...@futurewei.com>
*Sent:* Wednesday, November 1, 2023 18:11
*To:* Jordi Ros Giralt <j...@qti.qualcomm.com>; c...@ietf.org
<c...@ietf.org>; alto@ietf.org <alto@ietf.org>
*Cc:* i...@ietf.org <i...@ietf.org>
*Subject:* RE: New draft on joint exposure of network and compute
information
*WARNING:* This email originated from outside of Qualcomm. Please be
wary of any links or attachments, and do not enable macros.
Jordi,
Your draft describes two aspects of the service performance impacted
by the Computing: Service Deployment and Service (Path) Selection.
Those two should be separated, as the Service Deployment belongs to
the OpsArea, and the Service selection (including Network Path & DCs
that host the services) belongs to the Routing area.
https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/
<https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/> has
proposed a new Metadata Path Attribute and some Sub-TLVs for egress
routers to advertise the Metadata about the attached edge services
(ES). The Edge Service Metadata can be used by the ingress routers in
the 5G Local Data Network to make path selections not only based on
the routing cost but also the running environment of the edge
services. The goal is to improve latency and performance for 5G edge
services.
Can this Metadata Path Attribute address the problem stated in your
draft? I CC’ed the IDR WG, so your comments on the Path Selection can
be visible to them.
Thanks, Linda
*From:* Cats <cats-boun...@ietf.org> *On Behalf Of *Jordi Ros Giralt
*Sent:* Tuesday, October 24, 2023 6:47 AM
*To:* c...@ietf.org; alto@ietf.org
*Subject:* [Cats] New draft on joint exposure of network and compute
information
Dear CATS and ALTO WG mailing list members,
We submitted a new draft on joint exposure of network and compute
information for service placement and selection:
https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metrics/
<https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metrics/>
Joint Exposure of Network and Compute Information for
Infrastructure-Aware Service DeploymentJoint Exposure of Network and
Compute Information for Infrastructure-Aware Service Deployment
This draft focuses on the problem of exposing both network and compute
information to the service provider/application to support service
placement and selection decisions. ALTO provides an interface for
network information exposure to the service provider/application;
thus, an approach is to leverage and extend it with compute metrics.
CATS also needs to develop compute metrics to support traffic steering
decisions. The common ground is in these compute metrics, which could
be reused across the various use cases (e.g., consumed by the network
as in CATS or consumed by the application as in ALTO).
This draft also aims at providing a framework for continuing the
discussion initiated during IETF 117 regarding the presentation
"Compute-aware metrics: CATS working with ALTO":
https://datatracker.ietf.org/doc/slides-117-alto-compute-aware-metrics-cats-working-with-alto/
<https://datatracker.ietf.org/doc/slides-117-alto-compute-aware-metrics-cats-working-with-alto/>
We would like to seek feedback from both working groups on developing
compute metrics that can be reused for different use cases, to avoid
duplicated work and increase the effectiveness of future standards.
Thanks,
Jordi
_______________________________________________
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
