Thanks all. I am summarizing some of the key questions that are emanating from the conversations below and that I think are important to discuss. I am also including my thoughts.
(1) Is it likely that the network can expose communication and compute information to the service provider and application? (2) Are there gaps in the entire service lifecycle (deployment/instantiation/selection) that are not currently being addressed and that are relevant? (3) Would it make sense to have a common set of communication and compute metrics to address the various lifecycle stages? On #1, this is already happening. As mentioned by Luis, the Linux CAMARA project is building APIs to expose such information. For instance, the CAMARA Edge Cloud develops service APIs to "reserve compute resources within the operator network" and "influence the traffic routing from the user device toward the Edge instance of the Application". Related to CAMARA, there is also the GSMA Open Gateway initiative, which aims to provide access to operator networks for application developers. Another example is 3GPP NEF, which aims to enable exchange of information to/from an external application in a controlled and secure way. These solutions are finding ad hoc ways to extract this information. We think there is a need to get a more coordinated/structured way to access this information from the network infrastructure side. On #2, there are gaps in the deployment and service instance selection standpoint. Thanks to CATS, the IETF is now covering the problem of how the network edge can steer traffic between clients of a service and sites offering the service within the network. But there is also a need to (1) cover the service deployment stage within the service lifecycle and (2) to support the application side (in addition to the edge nodes within the network covered by CATS). On #3, it has been argued in this thread that different stages of the lifecycle may need distinct metrics. It seems to me though that there is a need to have a holistic approach and that a common set of metrics are applicable to all stages (although a stage might have additional metrics specific for it). An analogy we are used to understand might help here. The two key service lifecycle stages (service deployment and service selection) are equivalent to the two main lifecycle stages of a communication network: (1) "capacity planning" and (2) "traffic engineering". Capacity planning deals with provisioning the right disposition of resources (say for example bandwidth and latency) to provide a communication service to a set of users. Once these resources are deployed, traffic engineering kicks in, which deals with how these resources (the same bandwidth and latency provisioned in the first stage) are utilized. These are distinct stages in the lifecycle, but they deal with the same core metrics (bw and latency). It is important that these metrics are defined taking the whole lifecycle into account, to ensure that the second stage in the lifecycle makes decisions based on metrics that are aligned with the resources deployed in the first stage. Thanks, Jordi ________________________________ From: Joel Halpern <[email protected]> Sent: Thursday, November 2, 2023 22:37 To: LUIS MIGUEL CONTRERAS MURILLO <[email protected]>; Jordi Ros Giralt <[email protected]>; Linda Dunbar <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Cats] [Idr] 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. 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 <[email protected]><mailto:[email protected]> En nombre de Joel Halpern Enviado el: jueves, 2 de noviembre de 2023 19:04 Para: Jordi Ros Giralt <[email protected]><mailto:[email protected]>; Linda Dunbar <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> CC: [email protected]<mailto:[email protected]> 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 <[email protected]><mailto:[email protected]> Sent: Wednesday, November 1, 2023 18:11 To: Jordi Ros Giralt <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> 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 <[email protected]><mailto:[email protected]> On Behalf Of Jordi Ros Giralt Sent: Tuesday, October 24, 2023 6:47 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]>. 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 [email protected]<mailto:[email protected]>. 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 [email protected]<mailto:[email protected]>. 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 [email protected] https://www.ietf.org/mailman/listinfo/alto
