From adrian@olddog.co.uk Thu Nov 2 13:43:11 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 F3AECC15107E; Thu, 2 Nov 2023 13:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 (2048-bit key) header.d=olddog.co.uk 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 Nq2LOsybhxcn; Thu, 2 Nov 2023 13:43:06 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E363C15106B; Thu, 2 Nov 2023 13:43:04 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 3A2Kh0xk007173; Thu, 2 Nov 2023 20:43:00 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 612D54604B; Thu, 2 Nov 2023 20:43:00 +0000 (GMT) Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4165C4604A; Thu, 2 Nov 2023 20:43:00 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Thu, 2 Nov 2023 20:43:00 +0000 (GMT) Received: from LAPTOPK7AS653V ([213.246.239.115]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 3A2Kgxi6029371 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Nov 2023 20:42:59 GMT Reply-To: From: "Adrian Farrel" To: "'Jordi Ros Giralt'" , "'Linda Dunbar'" , , References: In-Reply-To: Date: Thu, 2 Nov 2023 20:42:58 -0000 Organization: Old Dog Consulting Message-ID: <006d01da0dcd$2a4a9a80$7edfcf80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01DA0DCD.2A4BD300" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHuKN5IUDyst+lSR3x8teqUw5KEwQKg5AY0Aa94SzIBNk7zx7ATEdDA Content-Language: en-gb X-Originating-IP: 213.246.239.115 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=a7+KkkIpFIju96rUgm4VZ EpajbWF8AMCIwgzUoVztRQ=; b=wGfyOR3rPBZuz1TYGymaTFcErOkljAIcUdhGJ Vbt7u5vVS5DEqrzqsR9+Y6g2Ntiqy+5z0AxVvIqN6X+5v6BUaROx2Z9GHvYXh67P Mcr2xuSuMrigVXxDbFMQly75zL6+65mAQ3yW76YtYCaXqTdLMH6//nnhkWk0bL+K oZoND+EjY3cecdSgNAOjHeORw/qSmiOeRrzg/2/b6Ef5BmfspUc/6tX5yx2JLYGN tagAqPwONJSqBkd/VqWavcEjU2XO7FT0fWq2HzKr4aOKGeAH8/yKT8UXmmPynWqC YwJG8Qa/18bQlCrfnDALxAOZMhqsFpBg/E7In5PnV78moH7cw== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27974.002 X-TM-AS-Result: No--40.455-10.0-31-10 X-imss-scan-details: No--40.455-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27974.002 X-TMASE-Result: 10--40.455000-10.000000 X-TMASE-MatchedRID: fSYce/2kgDyE006O1YmEnBme6in2W5ggBApSYI86Y6hB79wWUlPJ2KI0 r0nZSC3iUCQuDvGEd6NGk4qcd9wxZ/ZptiP8qRp7Mu8sU58q7h/ece0aRiX9WsCTaqQAifkR3cp u54+ohaoz+A8PtCjHV28B9lA7FWU/pu9FQl2xzBBp5GkIQCcEIcIkzTqL3E/W0pQS8tGeD8Svlo AnGr4qhooWlS5cw47V2f0LAEvHT6WfpwWoBJ/J6eyt+a9Mtf+eCtzGvPCy/m4ejl8XURi8fKR75 s8MEKvazZed9XvcyXq5iEI90L56odCx59LlYtdTfrwSmTdybpz6zT5BlgBw3zoSfZud5+GgVtDt dluQbaEfF7U3vuk4Uyv0dKcRE7KVgkS2o4ug/VIWWH3wEhRe0sZEAATZonfTPYWAASIMdr+77Ex FvcxKE30gtdZWeGxwNEscQDAfSXxKE5oc/s+TYob5qwo07CM2x0gyixf3Fjj7xERmZJ7geG1/Oi WPM9c7wtUWziB5M+575tX1gODVlw8jzenV/KzFSTlIxL09Kvv+xRIVoKNMvOWzJnTmLPxvJyF8B oMrCNDv/72zC4hJFdPtBu4qP+B1rUOe87lxJlzHt8FegNoXIRxA1AKmVGTOCCo+lsDuynVL/3rQ mWrTBrptMBEexxEKUhPNkIKYS0o3hu8snJh6PoW00NeRX+Br30kDaWZBE1TQTttTsZbKLweDfW9 m9jreigWii6tzEwPYMPFYAn4//1Qh5YE9uDH7gzyd7INd5idB9I5g6XEpi6n/3nyhTdZwj+DosV yGG7dLMIHo/IE5gYDgsby6N7P67h5XOKVrREwxjl0MrQJYVJXpCTgJQ7zgfS0Ip2eEHnyvXSmSd lcYmsnjLTA/UDoAnL8I93Xanom/ZOFeDeXHgAoLhiNKxnoXsOzOncrmCoOFR9Hau8GO7qfDnZdV cKQklExlQIQeRG0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: Subject: Re: [alto] 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 20:43:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006E_01DA0DCD.2A4BD300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So, my view is that CATS is specifically chartered to look at these metrics. I think the metrics could equally be applied in ALTO (as I said at IETF-117 in the ALTO WG meeting). I had hoped that we might hold an interim to discuss metrics, but progress has been slow. That said, the CATS list has recently been discussing metrics a bit, and I hope we can build on that. I would like to hear lots of opinions. At the moment, I don't mind much whether there is consensus or strong debate. I'd just like to hear many voices. What are the factors: * Simple? * Generic? * Variable or static? * Actual compute load/capability versus anticipated delay for a "standard" compute action? * Cheers, Adrian From: alto On Behalf Of Jordi Ros Giralt Sent: 02 November 2023 17:58 To: Linda Dunbar ; cats@ietf.org; alto@ietf.org Subject: Re: [alto] New draft on joint exposure of network and compute information Thanks Linda. These metrics can be common to a variety of use cases. That is, the same common metrics can be used to support the CATS use cases (exposure to the ingress point) or (as suggested by this draft) to support service providers and applications to make service deployment and selection decisions. The two efforts (network and application layer) can complement each other to achieve the performance requirements. As for metrics, it depends on the application, but certainly on the compute side, CPU, GPU, NPU, memory, storage are all important to make proper placement and selection decisions. A good part is that, in general, for a given application (e.g., AI inference), the requirements to run it are generally well-known at deployment/selection time. Thanks, Jordi _____ From: Linda Dunbar Sent: Wednesday, November 1, 2023 18:15 To: Jordi Ros Giralt ; cats@ietf.org ; alto@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, In addition, CATS WG is discussing many more metrics that can impact the service performance. Really appreciate if you can elaborate more on the new metrics that impact the deployment and path section. It will be very useful. Thanks, Linda From: Linda Dunbar Sent: Wednesday, November 1, 2023 12:11 PM 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 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-metric s/ 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 ------=_NextPart_000_006E_01DA0DCD.2A4BD300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So, my view is that CATS is = specifically chartered to look at these metrics. I think the metrics = could equally be applied in ALTO (as I said at IETF-117 in the ALTO WG = meeting).

I had hoped that we might hold an = interim to discuss metrics, but progress has been = slow.

That said, the CATS list has = recently been discussing metrics a bit, and I hope we can build on that. =

I would like to hear lots of = opinions. At the moment, I don’t mind much whether there is = consensus or strong debate. I’d just like to hear many = voices.

What are the = factors:

  • Simple?
  • Generic?
  • Variable or = static?
  • Actual compute load/capability = versus anticipated delay for a “standard” compute = action?
  • <your idea = here>

 

Cheers,

Adrian

 

From: alto = <alto-bounces@ietf.org> On Behalf Of Jordi Ros = Giralt
Sent: 02 November 2023 17:58
To: Linda Dunbar = <linda.dunbar@futurewei.com>; cats@ietf.org; = alto@ietf.org
Subject: Re: [alto] New draft on joint exposure = of network and compute information

 

Tha= nks Linda.

 

The= se metrics can be common to a variety of use cases. That is, the same = common metrics can be used to support the CATS use cases (exposure to = the ingress point) or (as suggested by this draft) to support service = providers and applications to make service deployment and selection = decisions. The two efforts (network and application layer) can = complement each other to achieve the performance = requirements. 

 

As = for metrics, it depends on the application, but certainly on the compute = side, CPU, GPU, NPU, memory, storage are all important to make proper = placement and selection decisions. A good part is that, in general, for = a given application (e.g., AI inference), the requirements to run it are = generally well-known at deployment/selection = time.

 

Tha= nks,

Jor= di

From: Linda Dunbar = <linda.dunbar@futurewei.com>
Sent: Wednesday, November = 1, 2023 18:15
To: Jordi Ros Giralt = <jros@qti.qualcomm.com>; cats@ietf.org <cats@ietf.org>; = alto@ietf.org <alto@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,

 

In addition, CATS WG is discussing = many more metrics that can impact the service performance. =

 

Really appreciate if you can elaborate more on the new = metrics that impact the deployment and path section. It will be very = useful.

 

Thanks, Linda

 

 

 

From: Linda Dunbar =
Sent: Wednesday, November 1, 2023 12:11 PM
To: = Jordi Ros Giralt <jros@qti.qualcomm.com>; cats@ietf.org; = alto@ietf.org
Cc: idr@ietf.org
Subject: RE: New = draft on joint exposure of network and compute = information

 

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

 

Dea= r 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-operatio= nal-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

Thi= s 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).

&nb= sp;

Thi= s 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-11= 7-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.

 

Tha= nks,

Jor= di 

 

 

------=_NextPart_000_006E_01DA0DCD.2A4BD300--