It is not obvious to me that the metrics for service placement are at
all tied to the metrics for isntance selection for client traffic. For
example, service placement may want to know about the capacity and type
details of the physical server. Client traffic direction generally does
not acre about that.
Similarly, service placement may well want to know about the range of
possible resource consumption (e.g. memory) that the application server
instance may exhibit. Client traffic direction does not care, as long
as the hosting server is giving the application service the resources it
needs.
Conversely, client service instance likely cares about the current
latency under load of the service instance. Service placement doesn't
care about that as the service is not yet under load.
There are many more examples of differences in concern.
I can imagine that there are metrics that both care about, but most of
the ones I can see to start from are quite distinct.
Yours,
Joel
On 11/2/2023 5:31 PM, LUIS MIGUEL CONTRERAS MURILLO wrote:
Hi Joel, all,
Please, see in-line
Best regards
Luis
*De:* Cats <cats-boun...@ietf.org> *En nombre de * Joel Halpern
*Enviado el:* jueves, 2 de noviembre de 2023 19:04
*Para:* Jordi Ros Giralt <j...@qti.qualcomm.com>; Linda Dunbar
<linda.dun...@futurewei.com>; c...@ietf.org; alto@ietf.org
*CC:* i...@ietf.org
*Asunto:* Re: [Cats] [Idr] New draft on joint exposure of network and
compute information
There are, as far as I can tell, two very valid and very different
approaches to service selection / traffic direction.
*/[[Luis>]] service selection / traffic direction is a part of the
problem. A previous step is service / application instantiation. What
we claim is the convenience of defining compute-related metrics
suitable for both (and any other step in the service lifecycle that
could require such kind of metrics). Defining separated metrics could
lead to inconsistent approaches. A common set of metrics that could be
used for different purposes would be desirable./*
*//*
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.
*/[[Luis>]] Exposing information from network side is becoming an
industrial trend in order to benefit the service delivery and
experience by customers (e.g. Linux CAMARA project). Closer
interaction among applications and networks is desirable. /*
*//*
Which is why most applications have taken the approach of using their
own probes to make their decisions.
*/[[Luis>]] The applications following that approach infer the status
of the network for taking decisions. Though proper exposure mechanisms
the applications could take informed decisions in a more precise
manner than the inference, which will be certainly beneficial. However
this discussion separates from the topic of the draft (common
definition of compute metrics), so maybe better discuss in a thread
apart. /*
*//*
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>
<mailto:linda.dun...@futurewei.com>
*Sent:* Wednesday, November 1, 2023 18:11
*To:* Jordi Ros Giralt <j...@qti.qualcomm.com>
<mailto:j...@qti.qualcomm.com>; c...@ietf.org <c...@ietf.org>
<mailto:c...@ietf.org>; alto@ietf.org <alto@ietf.org>
<mailto:alto@ietf.org>
*Cc:* i...@ietf.org <i...@ietf.org> <mailto: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/
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>
<mailto: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/
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/
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
------------------------------------------------------------------------
Este mensaje y sus adjuntos se dirigen exclusivamente a su
destinatario, puede contener información privilegiada o confidencial y
es para uso exclusivo de la persona o entidad de destino. Si no es
usted. el destinatario indicado, queda notificado de que la lectura,
utilización, divulgación y/o copia sin autorización puede estar
prohibida en virtud de la legislación vigente. Si ha recibido este
mensaje por error, le rogamos que nos lo comunique inmediatamente por
esta misma vía y proceda a su destrucción.
The information contained in this transmission is confidential and
privileged information intended only for the use of the individual or
entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this transmission in error, do not read it.
Please immediately reply to the sender that you have received this
communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu
destinatário, pode conter informação privilegiada ou confidencial e é
para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
senhoria o destinatário indicado, fica notificado de que a leitura,
utilização, divulgação e/ou cópia sem autorização pode estar proibida
em virtude da legislação vigente. Se recebeu esta mensagem por erro,
rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
------------------------------------------------------------------------
Le informamos de que el responsable del tratamiento de sus datos es la
entidad del Grupo Telefónica vinculada al remitente, con la finalidad
de mantener el contacto profesional y gestionar la relación
establecida con el destinatario o con la entidad a la que está
vinculado. Puede contactar con el responsable del tratamiento y
ejercitar sus derechos escribiendo a privacidad....@telefonica.com.
Puede consultar información adicional sobre el tratamiento de sus
datos en nuestra Política de Privacidad
<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.
We inform you that the data controller is the Telefónica Group entity
linked to the sender, for the purpose of maintaining professional
contact and managing the relationship established with the recipient
or with the entity to which it is linked. You may contact the data
controller and exercise your rights by writing to
privacidad....@telefonica.com. You may consult additional information
on the processing of your data in our Privacy Policy
<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.
Informamos que o responsável pelo tratamento dos seus dados é a
entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o
contato professional e administrar a relação estabelecida com o
destinatário ou com a entidade à qual esteja vinculado. Você pode
entrar em contato com o responsável do tratamento de dados e exercer
os seus direitos escrevendo a privacidad....@telefonica.com. Você pode
consultar informação adicional sobre o tratamento do seus dados na
nossa Política de Privacidade
<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
