From jmh@joelhalpern.com Thu Nov 2 11:04:06 2023 Return-Path: X-Original-To: alto@ietfa.amsl.com Delivered-To: alto@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBA0C15109D; Thu, 2 Nov 2023 11:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FONT_INVIS_MSGID=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGLfmitPSgIk; Thu, 2 Nov 2023 11:04:02 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBECC153CA8; Thu, 2 Nov 2023 11:03:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4SLsFM0nxRz1pjTJ; Thu, 2 Nov 2023 11:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1698948231; bh=rVrHYbJ+avvIjpPx47xBq7NCCuvUthaR/Fk2+9Z1VYE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VIwDcPJLIlzJzVhMdOiUeqVGNlM2feKxSwoBv2e71q1EJhtwRRt/lUMpKuMNO1EqJ FMJQzMKonKExWJb1rFcOJUf/OnoKpnX8CC5Gts6S3bdfHIq6Pq8qSaGU1t5flOWRSq 3XdlPCDlie0gIsGaA6Hk84j9stcK9HOkfjoUiYmE= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.231] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4SLsFK3qJfz1nvVS; Thu, 2 Nov 2023 11:03:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------vgzH406uBJy9ceOWltCUWluj" Message-ID: Date: Thu, 2 Nov 2023 14:03:40 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Jordi Ros Giralt , Linda Dunbar , "cats@ietf.org" , "alto@ietf.org" Cc: "idr@ietf.org" References: From: Joel Halpern In-Reply-To: Archived-At: Subject: Re: [alto] [Idr] New draft on joint exposure of network and compute information X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2023 18:04:06 -0000 This is a multi-part message in MIME format. --------------vgzH406uBJy9ceOWltCUWluj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > *Sent:* Wednesday, November 1, 2023 18:11 > *To:* Jordi Ros Giralt ; cats@ietf.org > ; alto@ietf.org > *Cc:* idr@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 *On Behalf Of *Jordi Ros Giralt > *Sent:* Tuesday, October 24, 2023 6:47 AM > *To:* cats@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 > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------vgzH406uBJy9ceOWltCUWluj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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.dunbar@futurewei.com>
Sent: Wednesday, November 1, 2023 18:11
To: Jordi Ros Giralt <jros@qti.qualcomm.com>; cats@ietf.org <cats@ietf.org>; alto@ietf.org <alto@ietf.org>
Cc: idr@ietf.org <idr@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-bounces@ietf.org> On Behalf Of Jordi Ros Giralt
Sent: Tuesday, October 24, 2023 6:47 AM
To: cats@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
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--------------vgzH406uBJy9ceOWltCUWluj--