From jros@qti.qualcomm.com Sun Nov 5 00:40:57 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 E2187C232056; Sun, 5 Nov 2023 00:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=qualcomm.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 sI2IejF9-8RZ; Sun, 5 Nov 2023 00:40:53 -0700 (PDT) Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 AE243C46AC5A; Sun, 5 Nov 2023 00:39:50 -0700 (PDT) Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3A57dZOZ003103; Sun, 5 Nov 2023 07:39:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=qcppdkim1; bh=zaNwDF9DDdFdJTotuDU/uTXVKzVuet+H0kJVzyMnzK8=; b=bOKbE83rWCggI/CiOWq0pKnwS3tzqj2VZSl6506ihS/B1GDtyi9L8NEvzkqrAU/MWl2z GzLqCUuoZR6aRe00b4DX+wtGX25Rl9LElvqVSTSmxUfoi3XmpBYlqD9IyeLBdNOicwHv LLOTsRfblzpWBh62CTYOUYrtvpusAoxEyir1TLPSsrcyG65Y1c0q2BzfmnySkoUH9Zp9 GBxBdsnFAss7pppBteZpfPFekKQ3H0wA6k2Y4Q3IICr8Zz64ZLBgLL+qHALxI7kg3oNk AjqHtgctTRbSdqYsW2c9eRhZ5noERSMtq2uOxIW1Tlk4PVYM66dwvatVJ9xPWWNbmbqL Nw== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3u5eqn1p5k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2023 07:39:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JOO4ZEPtYPTafmbiqYsZC+f2Aq5HOsJP93YTe3TRshGMfrUdH+pj8pCEnRviKdZ4myIjhDcENJ2F456cVyC/Bas6ycMO1pGOjen40FPnxBrA35lqRTWGrMRjUlki7Lrh5q6oxMW/6l32DiTJLHAXYtbTDp4vrwrEwAm/vZq/g704zvbMcGAQLPMN7pmra2t6ROahdIteXxSZMY8QTgbrLwiGDvvJXmL/5VQGLS8JIbY1CUJBrrF6kG7z9a+7xap8PR7AWePeifikueukFKmk5+6SBVpj4BtXogmUBdHGKBo96Csqojf6rgZiwH11oo6kENHccfXC8Wbu1+a/h/Tfag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zaNwDF9DDdFdJTotuDU/uTXVKzVuet+H0kJVzyMnzK8=; b=mpZ/M9CNWQLVomi8F7w/pASTxzAHyZ1kMTLy6hGyko5CjdAYAiE1iNX/7+vG9+V2w6p/drlFhGehE7LX1kRAKAHTzJI2LymV6+Vu64XdBedJ5y4MSQ3FymBrGah7NVc0H9Cd64llEFEa+auLrpYlg1OsbNx19SDE92YmZDLtz2a6I7m7Kafxn4ytJmkPrTw22AeTuwl+tXXW/bhrJelyvfw2oiDLr4vHpf/MiyCALdaSniDk7ofd2POMpMDJ50bxu0jPA0CO6ckmZ0L1j2rN3SzqpWmybD9fb0nR7XrePttfoC8BXtlBU2mbZQPqFiouXldVQDEb8HpTdA28jeQ1Hw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from SN6PR02MB5375.namprd02.prod.outlook.com (2603:10b6:805:75::12) by PH7PR02MB9991.namprd02.prod.outlook.com (2603:10b6:510:2f8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.27; Sun, 5 Nov 2023 07:39:11 +0000 Received: from SN6PR02MB5375.namprd02.prod.outlook.com ([fe80::b53:98b6:51e4:f458]) by SN6PR02MB5375.namprd02.prod.outlook.com ([fe80::b53:98b6:51e4:f458%4]) with mapi id 15.20.6954.027; Sun, 5 Nov 2023 07:39:10 +0000 From: Jordi Ros Giralt To: Joel Halpern , LUIS MIGUEL CONTRERAS MURILLO , Linda Dunbar , "cats@ietf.org" , "alto@ietf.org" , "adrian@olddog.co.uk" , "weilin_wang@bjtu.edu.cn" CC: "idr@ietf.org" Thread-Topic: [Cats] [Idr] New draft on joint exposure of network and compute information Thread-Index: AQHaBmtv3lfj91oqKU6ZkcpSGEnn+bBlvBbQgAGZq8iAAAs5AIAANinQgAAFnwCAA8tkPw== Date: Sun, 5 Nov 2023 07:39:09 +0000 Message-ID: References: <97e45412-7d7c-4bcd-a1bb-2daa77ec147b@joelhalpern.com> In-Reply-To: <97e45412-7d7c-4bcd-a1bb-2daa77ec147b@joelhalpern.com> Accept-Language: en-US, es-ES, ca-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SN6PR02MB5375:EE_|PH7PR02MB9991:EE_ x-ms-office365-filtering-correlation-id: 680e40fe-5ad7-444e-c283-08dbddd24c1c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zzh8uEZQNHjn5y9MdxPH8VMaCCz9gO0j59DCLMGQSx6bIWz2MlDl41bhryTkAiVot2b90+RWHPHCdwdjKR7//+wvazWYyWbYI5/9bjR1x8TkOG1fly39gYnBtXWqnCtuK9xi5cFubWjUdR65MpsD/3u4+cj8ghkh8Bhcmy9C+R7steqglcatR14647YbxgMGQwnqDtT44NbB3qkVJL6kE/mUhBk4XbNCjayLMhWfTY+6a2LWBlZic7h0NJqrjlJtGB1fd1NXv9502PjkE4FsaXep40puASee67LiKrhA/9qLMb38xxob8wkXvKcHaE8vi08AuVJXtlju/hBHhckn/4+xHKTg7Ccnknj2TkVfnd7M6IZVMew7BjbQbJzvn+FOP15+Tm6Yf+cgO3cS2SxQTQ9nTnEeq790tU0BBMlA3rDgiG4Jv0KX7rpiFYzwvdhNdX50iR3MFoDjiRDVLUYHKCpmFoqWrt/t74Qhvc1wHenIzDfs1vt9MzxAQwxMdmbzqUpBpAhr1jtjrWcgNZ2WvlJ8YSRpUdZCfXuUMqwp5IYmBPlytnSgPKfV9deNvgkhtxZhqqjcW/OlLC1oMgpytROAbP/y1Ek+ncNZkG0wWtnbjyP9nxzrZCXtDY/JL64ztL7m5BNvCELwCJUVLlyww9Mky0SwZmMoMwwpXQbMnHVm9luL+wDoq3KkVpg3Li8C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB5375.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(346002)(136003)(366004)(396003)(39860400002)(230922051799003)(230273577357003)(230173577357003)(1800799009)(186009)(64100799003)(451199024)(38070700009)(66899024)(33656002)(55016003)(316002)(66574015)(52536014)(83380400001)(4326008)(8676002)(8936002)(26005)(110136005)(64756008)(66446008)(66476007)(66556008)(66946007)(91956017)(76116006)(5660300002)(30864003)(41300700001)(2906002)(478600001)(9686003)(19627405001)(966005)(71200400001)(53546011)(7696005)(6506007)(19627235002)(122000001)(86362001)(166002)(38100700002)(15398625002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?eZK0QiTvP210CmAHwjFIyTJ+GzOgjKA7zTINJGJTk6MaBPxY82EFODcC?= =?Windows-1252?Q?EEu0+oA+pKgBL8UqXnnAl1oAQkcuU8HTh+ZAzpJRb9byIIeKvDYceoFN?= =?Windows-1252?Q?JfQt4QnKRLc60Q1pZEmMN1cX8Pfm6uU5TTa07XltWhub5VO936wftcWK?= =?Windows-1252?Q?1K49RkP4fCx6GBu5y19W+Ez8OGeZKHVPbsh7OODDvyiHLrZ7JucZCWQ7?= =?Windows-1252?Q?eEgoVN2MTgUzz9MDk+p/3UzSpMRlBWTb3B7lLEHeMQFNNLX/s7YuN6Ta?= =?Windows-1252?Q?cEflnjPyg3/NCNQqIOuFDSNTvkbDhqFFWq32IL0A6+27bGAlvQjUlFbx?= =?Windows-1252?Q?27OMhrW5SbA8rCfGUQXwnCYo/KllkP2YXYbCXYsNW9fDLF2K18i2qC77?= =?Windows-1252?Q?09wj39fnQQ6hhEoZEWW1CTB425ezvashwqWErn4MAzBS/X6Mm3fb2JJo?= =?Windows-1252?Q?TNvVEyya5dAWR+T2ooryaG8VGZTdcU5rD3M3/06HOYuuy5DCVGI8CY2G?= =?Windows-1252?Q?8tdb0gg3ceSS8gAr+7e6rcrxmZ1a40+MsjDDpt0NHUfB5fziT+dfTLEb?= =?Windows-1252?Q?/rT48s9+YUCpAygxXZmlktFdpX2CeNnGhB/JrJ6WANuK3J/3fGWjwhP5?= =?Windows-1252?Q?x4aOOIZfGfWP/7BWLXvHE7UARFYw2P27a3zzBF9T9wizd2WdcJ1qrfV9?= =?Windows-1252?Q?B44CJE3kWq8EGidD9gh+DFpdeDFZs0N7mEBEQAwg7gjQG699FIyW0b+n?= =?Windows-1252?Q?KiGwjprSe3GR5onne8y97N2u9RvqSjKlIz8H9W2EeuL2qsqZX/ZcSsmz?= =?Windows-1252?Q?lGdouGn/rjegAKjNZKTQfYjYWKeOdLZRYDL82sOD6G8tM/bgRCn9Re8S?= =?Windows-1252?Q?Y8V+/FEnHzYlqYn0NkOuO48av6KyiO2rfKxVuW1pRjcZlo6k+IxAEEPC?= =?Windows-1252?Q?lHZsyCtp1HBChx6S5DnSlV7dfAix9alubmChAwJafEkEwmJbS9nGY/kB?= =?Windows-1252?Q?M+M7yUaPGipPZScF2UL2xhZ8qZh/oI87yNtYa3kt9Gxgff+xDwgmvy0s?= =?Windows-1252?Q?9SWYDpdCWxpUWkF22kr0bB3j+1TCE2YENxLLlaHIXRImwsFfjaXA3poL?= =?Windows-1252?Q?tgmfN+/ZsdKaxxkPYkNfodkozJ8E4JFMx4ljZjcZFZU2V6LRSdaUYtc8?= =?Windows-1252?Q?1zqB+rGOu85b6KcBLR5v3uLFi/ijcE3MfOnckeB1dGe4qBYNy/N7su65?= =?Windows-1252?Q?xXCft9wMKDKMyud5qiz4RhIkuBy7ylPC94y69WalYxJedX3xsu03AHTB?= =?Windows-1252?Q?hPqjrrb7b91NPBNOtHafI7XHjC+IoX8pDdW1ADerjAdU5nMYGQF660n/?= =?Windows-1252?Q?374E42hzNBST4xLTTqrUm0XVzZ74I5uOF1iYsR5Yf/F139EDLnOImm2S?= =?Windows-1252?Q?819ShO5w1So5FbniELp3qtsnSvJEGuXcqn2XXA8SFjUmnGx/9i1ZOEhp?= =?Windows-1252?Q?Z1FI61mElbRu5qe+8TBqDjcWu+ZtQ8htxDvK+b8fxHturo2rymKYHDRg?= =?Windows-1252?Q?96xRCrptx9QJOjF692+f2lEG/hZCywVLJFrYxkVm6uLK8oz9j62wZRk7?= =?Windows-1252?Q?4XbUrQqS9QPV+yOL3UcwgRPinWYqGFXETytBslzMR5D6D/NFu/xEHpXh?= =?Windows-1252?Q?ygqvQi90Ui/hSzchC+GjiEQyZJwtYSRt?= Content-Type: multipart/alternative; boundary="_000_SN6PR02MB5375996503565402FB71E16AF6ABASN6PR02MB5375namp_" MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?Windows-1252?Q?mBKMhAINehKgJ+sV/Vx5EPRgtEi8wOtEWLReQxsgFJ4uHiu1Tx6+U8rl?= =?Windows-1252?Q?FBfRfH/wrRICm6FagkXzK4jw6VE/a/oBHFr9ZC5ndV3LZAxjrpulzfPK?= =?Windows-1252?Q?nZg1zgTAkdV5T6rm8zmz+J1Og6ye232OTPOchRryYjg8FcvoDZvnITUS?= =?Windows-1252?Q?Gs/P6gOhF/3DCaI6vZskaJG/EyuooXmoUJj+wqgn1GtvuhtnxegZww8E?= =?Windows-1252?Q?j0d6SLAHS7JelHVesjX2CIFSnjqig+a6l3fddjqSiD2FUefdhnsV6wR9?= =?Windows-1252?Q?8XvgOyjCgvxXEV14LCwAXZ25nGUC1FpUyr0w2rZXn0+0gm95TcMowHD/?= =?Windows-1252?Q?UsZOrkM/UFbaNTSt6cEkRjCqJUc+3V+6IbwluN3HMDcDYgH9VEBT3dlI?= =?Windows-1252?Q?TdzjQGq69lz8+8tfuAGUJtSC8JelNOIs8VEuCSZwx2E2bM0yeFI0M0oJ?= =?Windows-1252?Q?jDFnEpzw2tJZbYT2EWX5+P5LxlKhDQXFQLGdxPwP+J2ADWztE7m1Lt8+?= =?Windows-1252?Q?iCoZ2cgpYZ65NuKMsBNzt4E1AZsjPFAMN7ZFzhP2SwLwaj2PbP1PtB/z?= =?Windows-1252?Q?mWGdFnTLQP6tEz+KwDt9t2qavx/inGnkNZ4VK2NmhY2UPZprTm18ab90?= =?Windows-1252?Q?XuwbdI6Seyo6MkODT2W3bM+Ipgjg6xZqpL3sf0ujqjWAiFZSZzWBW0gh?= =?Windows-1252?Q?9aRVF2ciBeMLtRE7xFIp8oQNH3ednlUeOkHGpB55a01YGXXEnpXFiVq7?= =?Windows-1252?Q?2/Wy5TVuhiFT9ZniBHN/j8oMUdnAo4QKBoe17y1hSNf0f6vD8KVHgQxK?= =?Windows-1252?Q?IK1rHC5shgB4cht9TB8DvbkypWV5oz1fSOx6ogkA3ZWccvAdPJi6bCgc?= =?Windows-1252?Q?VwZ7UEJUmziNrArJlKeoPhS2/eULMJGkyE5dhjjMkxCsJ17aXkSvGeRy?= =?Windows-1252?Q?/KZVu6mArUnY1ZFbhG8ScZPLvfXrq1/uJC/Wv9p/ss2WSLUV7hZTd+DI?= =?Windows-1252?Q?LrOzlmAO?= X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB5375.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 680e40fe-5ad7-444e-c283-08dbddd24c1c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2023 07:39:09.2849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sE39vruSdFwi0xxT5/rLBiWeS34QvpJjkC2ikj110WUCgftUnIkwJ8EHW6tvArbBw+I29WPP9byYoc91uJmisQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR02MB9991 X-Proofpoint-GUID: uYZRtqDzDT6JUEjmnh7wu-0w2-xRU2sO X-Proofpoint-ORIG-GUID: uYZRtqDzDT6JUEjmnh7wu-0w2-xRU2sO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-05_04,2023-11-02_03,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 malwarescore=0 clxscore=1011 adultscore=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 lowpriorityscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000 definitions=main-2311050064 Archived-At: Subject: Re: [alto] [Cats] [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: Sun, 05 Nov 2023 07:40:58 -0000 --_000_SN6PR02MB5375996503565402FB71E16AF6ABASN6PR02MB5375namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks all. I am summarizing some of the key questions that are emanating from the conv= ersations below and that I think are important to discuss. I am also includ= ing my thoughts. (1) Is it likely that the network can expose communication and compute info= rmation to the service provider and application? (2) Are there gaps in the entire service lifecycle (deployment/instantiatio= n/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 m= etrics to address the various lifecycle stages? On #1, this is already happening. As mentioned by Luis, the Linux CAMARA pr= oject 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 t= oward the Edge instance of the Application". Related to CAMARA, there is al= so the GSMA Open Gateway initiative, which aims to provide access to operat= or 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 extr= act this information. We think there is a need to get a more coordinated/st= ructured way to access this information from the network infrastructure sid= e. On #2, there are gaps in the deployment and service instance selection stan= dpoint. Thanks to CATS, the IETF is now covering the problem of how the net= work 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 th= e application side (in addition to the edge nodes within the network covere= d by CATS). On #3, it has been argued in this thread that different stages of the lifec= ycle 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 ser= vice lifecycle stages (service deployment and service selection) are equiva= lent to the two main lifecycle stages of a communication network: (1) "capa= city 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 the= se resources are deployed, traffic engineering kicks in, which deals with h= ow 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 thes= e metrics are defined taking the whole lifecycle into account, to ensure th= at 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 Sent: Thursday, November 2, 2023 22:37 To: LUIS MIGUEL CONTRERAS MURILLO ; Jordi Ros Giralt ; Linda Dunbar ; cats@ietf.org ; alto@ietf.org Cc: idr@ietf.org Subject: Re: [Cats] [Idr] New draft on joint exposure of network and comput= e 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 t= ied 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 abou= t that. Similarly, service placement may well want to know about the range of possi= ble resource consumption (e.g. memory) that the application server instance= may exhibit. Client traffic direction does not care, as long as the hosti= ng 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 t= hat 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 En nombre de= Joel Halpern Enviado el: jueves, 2 de noviembre de 2023 19:04 Para: Jordi Ros Giralt ; Linda Dunbar ; cats@ietf.org; alto@ietf.org CC: idr@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 approach= es 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 metric= s). Defining separated metrics could lead to inconsistent approaches. A com= mon set of metrics that could be used for different purposes would be desir= able. 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 cl= early can chose to make their own decision, or to send anycast traffic allo= wing CATS to make its decision. However, expecting the network to expose detailed topology and related metr= ics 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 netw= orks is desirable. Which is why most applications have taken the approach of using their own p= robes to make their decisions. [[Luis>]] The applications following that approach infer the status of the = network for taking decisions. Though proper exposure mechanisms the applica= tions could take informed decisions in a more precise manner than the infer= ence, which will be certainly beneficial. However this discussion separates= from the topic of the draft (common definition of compute metrics), so may= be better discuss in a thread apart. If you want to argue for a protocol to expose information to client appli= cations, that is a very complicated discussion with many stakeholders. And= it is a discussion that needs to take place before one discusses exact met= rics, or even the properties of such an exposure mechanism. (It is an appr= oach 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. Serv= ice selection can both be seen as part of the routing area (as you point ou= t), but also a part of the application area. For instance, an application r= unning 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 informati= on 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 pa= th selection decisions. In addition, there is also a need for this informat= ion to be exposed to the service or application layer. If there is service = replication, the application running in the UE (or an application-layer pro= xy on behalf of it) needs to decide which of the service replicas it connec= ts 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-poi= nt 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 sho= uld be separated, as the Service Deployment belongs to the OpsArea, and the= Service selection (including Network Path & DCs that host the services) be= longs to the Routing area. https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/ h= as proposed a new Metadata Path Attribute and some Sub-TLVs for egress rou= ters 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 D= ata 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=92ed the IDR WG, so your comments on the Path Selection can be visibl= e 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 informat= ion Dear CATS and ALTO WG mailing list members, We submitted a new draft on joint exposure of network and compute informati= on for service placement and selection: https://datatracker.ietf.org/doc/dr= aft-rcr-opsawg-operational-compute-metrics/ Joint Exposure of Network and Compute Information for Infrastructure-Aware = Service DeploymentJoint Exposure of Network and Compute Information for Inf= rastructure-Aware Service Deployment This draft focuses on the problem of exposing both network and compute info= rmation to the service provider/application to support service placement an= d selection decisions. ALTO provides an interface for network information e= xposure to the service provider/application; thus, an approach is to levera= ge and extend it with compute metrics. CATS also needs to develop compute m= etrics 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 AL= TO). This draft also aims at providing a framework for continuing the discussion= initiated during IETF 117 regarding the presentation "Compute-aware metric= s: CATS working with ALTO": https://datatracker.ietf.org/doc/slides-117-alt= o-compute-aware-metrics-cats-working-with-alto/ We would like to seek feedback from both working groups on developing compu= te 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 ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is confidential and privileg= ed 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o ________________________________ Le informamos de que el responsable del tratamiento de sus datos es la enti= dad del Grupo Telef=F3nica vinculada al remitente, con la finalidad de mant= ener el contacto profesional y gestionar la relaci=F3n establecida con el d= estinatario o con la entidad a la que est=E1 vinculado. Puede contactar con= el responsable del tratamiento y ejercitar sus derechos escribiendo a priv= acidad.web@telefonica.com. Puede cons= ultar informaci=F3n adicional sobre el tratamiento de sus datos en nuestra = Pol=EDtica de Privacidad. We inform you that the data controller is the Telef=F3nica Group entity lin= ked 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 yo= ur rights by writing to privacidad.web@telefonica.com. You may consult additional information on the processing = of your data in our Privacy Policy= . Informamos que o respons=E1vel pelo tratamento dos seus dados =E9 a entidad= e do Grupo Telef=F3nica vinculada ao remetente, a fim de manter o contato p= rofessional e administrar a rela=E7=E3o estabelecida com o destinat=E1rio o= u com a entidade =E0 qual esteja vinculado. Voc=EA pode entrar em contato c= om o respons=E1vel do tratamento de dados e exercer os seus direitos escrev= endo a privacidad.web@telefonica.com.= Voc=EA pode consultar informa=E7=E3o adicional sobre o tratamento do seus = dados na nossa Pol=EDtica de Privacidade. --_000_SN6PR02MB5375996503565402FB71E16AF6ABASN6PR02MB5375namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks all.

I am summarizing some of the key questions that are emanating from the conve= rsations below and that I think are important to discuss. I am also includi= ng my thoughts.

(1) Is it likely that the network can expose communication and compute informa= tion to the service provider and application?

(2) Are there gaps in the entire service lifecycle (deployment/instantiation/s= election) that are not currently being addressed and that are relevant?

(3) Would it make sense to have a common set of communication and compute metr= ics to address the various lifecycle stages?

On #1, this is already happening. As mentioned by Luis, the Linux CAMARA proj= ect is building APIs to expose such information. For instance, the CAMARA E= dge Cloud develops service APIs to "reserve compute resources within t= he operator network" and "influence the traffic routing from the user device toward the Edge instance of the Appli= cation". Related to CAMARA, there is also the GSMA Open Gateway initia= tive, which aims to provide access to operator networks for application dev= elopers. 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 ar= e 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 t= he network infrastructure side.

On #2, there are gaps in the deployment and service instance selection standp= oint. Thanks to CATS, the IETF is now covering the problem of how the network edge can steer traffic between clients of a ser= vice and sites offering the service within the network. But there is also a= need to (1) cover the service deployment stage within the service lifecycl= e 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 lifecyc= le 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 t= o all stages (although a stage might have additional metrics specific for it). An analogy we are used to unders= tand might help here. The two key service lifecycle stages (service deploym= ent and service selection) are equivalent to the two main lifecycle stages = of a communication network: (1) "capacity planning" and (2) "traffic engineering". Cap= acity planning deals with provisioning the right disposition of resources (= say for example bandwidth and latency) to provide a communication service t= o a set of users. Once these resources are deployed, traffic engineering kicks in, which deals with how these resources (the sa= me bandwidth and latency provisioned in the first stage) are utilized.= These are distinct stages in the lifecycle, but they deal with the same co= re 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 met= rics that are aligned with the resources deployed in the first stage.

Thanks,
Jordi
From: Joel Halpern <jmh@= joelhalpern.com>
Sent: Thursday, November 2, 2023 22:37
To: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@te= lefonica.com>; Jordi Ros Giralt <jros@qti.qualcomm.com>; Linda Dun= bar <linda.dunbar@futurewei.com>; cats@ietf.org <cats@ietf.org>= ; alto@ietf.org <alto@ietf.org>
Cc: idr@ietf.org <idr@ietf.org>
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 li= nks or attachments, and do not enable macros.

It is not obvious to me that the metrics for service placement are at al= l tied to the metrics for isntance selection for client traffic.  For = example, service placement may want to know about the capacity and type det= ails 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 po= ssible resource consumption (e.g. memory) that the application server insta= nce may exhibit.  Client traffic direction does not care, as long as t= he hosting server is giving the application service the resources it needs.  

Conversely, client service instance likely cares about the current laten= cy 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 t= he ones I can see to start from are quite distinct.

Yours,

Joel

On 11/2/2023 5:31 PM, LUIS MIGUEL CONTRERA= S MURILLO wrote:

Hi Joel, all,

 

Please, see in-line

 

Best regards

 

Luis

 

De: Cats <cats-bounces@ietf.org> En nombre de Joel Halpern
Enviado el: jueves, 2 de noviembre de 2023 19:04
Para: Jordi Ros Giralt <jros@qti.qualcomm.com>; Linda Dunbar <linda.dunbar@futurewei.com>; cats@ietf.org; alto@ietf.org
CC: idr@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 appro= aches to service selection / traffic direction. 

[[Luis>]] service selection / traffic dire= ction is a part of the problem. A previous step is service / application in= stantiation. What we claim is the convenience of defining compute-related m= etrics suitable for both (and any other step in the service lifecycle that could require such kind of metrics). De= fining separated metrics could lead to inconsistent approaches. A common se= t of metrics that could be used for different purposes would be desirable.<= /span>

 

It can be done by the application, or it can be don= e by the operator edge.  CATS is chartered to address the operator-based approach.  Appl= ications clearly can chose to make their own decision, or to send anycast t= raffic allowing CATS to make its decision.

 

However, expecting the network to expose detailed topology and related m= etrics to end application clients seems unlikely. 

[[Luis>]] Exposing information from networ= k side is becoming an industrial trend in order to benefit the service deli= very and experience by customers (e.g. Linux CAMARA project). Closer intera= ction among applications and networks is desirable.  

 

Which is why most applications have taken the appro= ach 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 prope= r exposure mechanisms the applications could take informed decisions in a m= ore 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 be= tter discuss in a thread apart.

 

  If you want to argue for a protocol to expos= e 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 dr= aft describes two aspects of the service performance 

> impacted by the Computing: Service Deployment a= nd  Service (Path) 

> Selection. Those two should be separated, as th= e Service Deployment 

> belongs to the OpsArea, and the Service selecti= on (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 par= t 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 servic= e instance based on the communication and compute resource information expo= sed to it.

 

> draft-ietf-idr-5g-edge= -service-metadata has proposed a new Metadata Path 

> Attribute and some Sub-TLVs  for egress routers to advertis= e the Metadata 

> about the attached edge services (ES). 

> (...) Can this Metadata Path Attribute address= the problem stated in your draft? 

 

[JRG] I agree thi= s information is valuable to the ingress router to make path selection deci= sions. 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 servi= ce replicas it connects to. Once a service replica is selected, the UE migh= t also have a variety of ways to reach that service (e.g., 4G, 5G, Wi-Fi). Both of these end-point selectio= n decisions need to know the available communication and compute resources.=

 

Thanks,

Jordi

 



 

 

 

From: Linda Dunbar <linda.dunbar@futurewei.co= m>
Sent: Wednesday, November 1, 2023 18:11
To: Jordi Ros Giralt &= lt;jros@qti.qualcomm.com>; cats@iet= f.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 onl= y based on the routing cost but also the running environment of the edge se= rvices.  The goal is to improve latency and performance for 5G  e= dge services.

 

 

Can this Metadata Path Attribute address the problem stated in your draf= t?  I CC=92ed the IDR WG, so your comments on the Path Selection can b= e 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@iet= f.org
Subject: [Cats] New draft on joint exposure of network and comp= ute information

 

Dear CATS and ALTO WG mailing list members,

 

We submitted a new draft on joint expo= sure of network and compute information for service placement and selection= : https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metri= cs/

 

 

Joint Exposure of Network and Comp= ute Information for Infrastructure-Aware Service DeploymentJoint Exposure o= f 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 serv= ice placement and selection decisions. ALTO provides an interface for network information exposure to the service prov= ider/application; thus, an approach is to leverage and extend it with compu= te metrics. CATS also needs to develop compute metrics to support traffic s= teering 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 applicat= ion as in ALTO).

 

This draft also aims at providing a framework for continuin= g 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 a= void duplicated work and increase the effectiveness of future standards.

 

Thanks,

Jordi 

 

 



_______________________________________________
Idr mailing list
Idr@=
ietf.org
https://www.ietf.org/mailman/listinfo/idr


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is confidential and privileg= ed 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o


Le informamos de que el responsable del tratamiento de sus datos es la enti= dad del Grupo Telef=F3nica vinculada al remitente, con la finalidad de mant= ener el contacto profesional y gestionar la relaci=F3n establecida con el d= estinatario o con la entidad a la que est=E1 vinculado. Puede contactar con el responsable del tratamiento y eje= rcitar sus derechos escribiendo a privacidad.web@telefonica.com. Puede consultar informaci=F3n ad= icional sobre el tratamiento de sus datos en nuestra Pol=EDtica de Privacidad.

We inform you that the data controller is the Telef=F3nica Group entity lin= ked 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.web@telefonica.com. You may consult additional information o= n the processing of your data in our Privacy Policy.

Informamos que o respons=E1vel pelo tratamento dos seus dados =E9 a entidad= e do Grupo Telef=F3nica vinculada ao remetente, a fim de manter o contato p= rofessional e administrar a rela=E7=E3o estabelecida com o destinat=E1rio o= u com a entidade =E0 qual esteja vinculado. Voc=EA pode entrar em contato com o respons=E1vel do tratamento de dados e exerce= r os seus direitos escrevendo a privacidad.web@telefonica.com. Voc=EA pode consultar informa=E7= =E3o adicional sobre o tratamento do seus dados na nossa Pol=EDtica de Privacidade.

--_000_SN6PR02MB5375996503565402FB71E16AF6ABASN6PR02MB5375namp_--