Re: [Can] WG Review: Computing-Aware Networking (can)
Adrian Farrel <adrian@olddog.co.uk> Sat, 18 February 2023 19:37 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: can@ietfa.amsl.com
Delivered-To: can@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32043C14CEFF for <can@ietfa.amsl.com>; Sat, 18 Feb 2023 11:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.092
X-Spam-Level:
X-Spam-Status: No, score=-7.092 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 lBJDnT7b-A6E for <can@ietfa.amsl.com>; Sat, 18 Feb 2023 11:37:40 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 47A49C14F730 for <can@ietf.org>; Sat, 18 Feb 2023 11:37:38 -0800 (PST)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 31IJbZwt016579 for <can@ietf.org>; Sat, 18 Feb 2023 19:37:35 GMT
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AC9194604A for <can@ietf.org>; Sat, 18 Feb 2023 19:37:35 +0000 (GMT)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A104646043 for <can@ietf.org>; Sat, 18 Feb 2023 19:37:35 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs4.iomartmail.com (Postfix) with ESMTPS for <can@ietf.org>; Sat, 18 Feb 2023 19:37:35 +0000 (GMT)
Received: from LAPTOPK7AS653V ([148.252.132.138]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 31IJbWvO020677 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <can@ietf.org>; Sat, 18 Feb 2023 19:37:35 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: can@ietf.org
References: <167665870649.20411.6592450254104203463@ietfa.amsl.com>
In-Reply-To: <167665870649.20411.6592450254104203463@ietfa.amsl.com>
Date: Sat, 18 Feb 2023 19:37:31 -0000
Organization: Old Dog Consulting
Message-ID: <096b01d943d0$73e7f420$5bb7dc60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQHRhHH+/19NLSHKf1snLDMe4NaWNK7kdKRg
X-Originating-IP: 148.252.132.138
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:content-transfer-encoding; s= 20221128; bh=BUIv7K8BhvI/sD5p+jMrgGqWNF4H3wjGNk0h9b4DJng=; b=Ijt 9NQk90lm7XB78LGZMWVQZ0JZ+leew0772REJ6JkhAIC2XC5d2+9ZLR3cPiHsxLjC blHk8VpKjsklJFLjudJcIS8NASZXVcRiD+9+8Z/oGwA4iT/yi8+nkxVLjSFYC0RU 8+4jfRNZxiEgV+Bs4mG+qBXN5rFwL2ovFosiwfICsK/owVYljbzfs9e+Cnh69pTC SutJYlt+uDlVJC7sQvF1LvV7F9l0evCPDZ5NomouzS9RD9pc9k1kktgNgV/2gUaI WdQgsjt+c3ch5IRaea7oNjePkDQ4kU+WzqZ8QD/x0e3gCO/ylhpFc4kgTwtCQ0LJ edkqy+K4KpvVZscXjdw==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27456.002
X-TM-AS-Result: No--20.475-10.0-31-10
X-imss-scan-details: No--20.475-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27456.002
X-TMASE-Result: 10--20.475100-10.000000
X-TMASE-MatchedRID: cxtZ8fwm3r/xIbpQ8BhdbMQ4mpKyfkqZIfZjRfGTydje6dEbvIyrxSmU JG/NuCSS8Xo3NKXpyhdvtPtMpliQxedv6cWcdrc0lVHM/F6YkvTcAmu1xqeetlgLks93sG9txnU Xzyseixz3zZ3UBZZ1rxf1kL+6Ssg6w5B5ycCESlu4V0/u9pqUzct3zHe6QppepR1YIl7PWZ+ETM jf6aTOJzsjLjEwO02e8jehMiyZVE2wcHwzEtk5yYdlc1JaOB1TFei5YP5NvsJWLer44mCwe5/bL 8lMFJRVNEscQDAfSXz23jc+gV6AAPRr52i2NSUs9UrC1zJxJSyQoBr+SFneJC196sn93sBvgTh9 bhW48Qoax6DXJKFg8bhrwPZ8pqtZRFalKrpY6zyy3/Rgg5KscIPAtNs5CO8OL31P64kiV5GBHLc NLQbjSUHjnDxIZ/hqYkcwbeol/UZgcLWMrBu/JVHnGPCAzBnaNroBpCbt+Gbk3GeNbRoaNp0uWN ya/UhH0qthY6eBVpDy5b3PCF/W+O2bJ5fdprbOTOzi7zU/vulkbdIIs/tC0psoi2XrUn/JyeMtM D9QOgAfACoClnjRoUprfkiB9+n/3QfwsVk0Ubv+efAnnZBiLyF6bSSak9kx
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/can/MLVfSLYzd8XJIfhqQbFK-qcNGBY>
Subject: Re: [Can] WG Review: Computing-Aware Networking (can)
X-BeenThere: can@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CAN- Computing-Aware Networking <can.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/can>, <mailto:can-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/can/>
List-Post: <mailto:can@ietf.org>
List-Help: <mailto:can-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/can>, <mailto:can-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Feb 2023 19:37:45 -0000
Canners (shall we call ourselves "canners", or would "cantanti" on "cantinieri" be better?), This is your last formal chance to make comments on the CAN charter. Cheers, Adrian -----Original Message----- From: IETF-Announce <ietf-announce-bounces@ietf.org> On Behalf Of The IESG Sent: 17 February 2023 18:32 To: IETF-Announce <ietf-announce@ietf.org> Cc: can@ietf.org Subject: WG Review: Computing-Aware Networking (can) A new IETF WG has been proposed in the Routing Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2023-02-27. Computing-Aware Networking (can) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Peng Liu <liupengyjy@chinamobile.com> Adrian Farrel <adrian@olddog.co.uk> Assigned Area Director: John Scudder <jgs@juniper.net> Routing Area Directors: Alvaro Retana <aretana.ietf@gmail.com> John Scudder <jgs@juniper.net> Andrew Alston <andrew-ietf@liquid.tech> Mailing list: Address: can@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/can Archive: https://mailarchive.ietf.org/arch/browse/can/ Group page: https://datatracker.ietf.org/group/can/ Charter: https://datatracker.ietf.org/doc/charter-ietf-can/ Computing-Aware Networking (can) Many service architectures create multiple service instances. These instances are often geographically distributed to multiple sites, and a single site may support multiple instances of a service. The services are provided on computing platforms and are generically referred to as "compute services". The CAN (Computing-Aware Networking) working group (WG) is chartered to consider the problem of how the network edge can steer traffic between clients of a service and sites offering the service. Since, for some services (for example, the evolution of networked AR/VR, and deployment of autonomous and networked vehicles), the performance experienced by clients will depend on both network metrics such as bandwidth and latency, and compute metrics such as processing, storage capabilities, and capacity, there is a need for a solution that can optimize how a network edge node steers traffic based on these metrics, as appropriate to the service. Although the specific optimization function will likely differ between services, implementations, and deployments, there is a need for a general framework for the distribution of compute and network metrics and transport of traffic from network edge to service instance. It also is likely that some set of common metrics can be identified. The CAN WG will concern itself with these issues. The IETF is working on exposing network conditions to endpoints (notably ALTO) and load balancing/service selection at layers 4 and 7 (for example, related to the selection of SIP servers). Specific characteristics that may distinguish CAN from other work include the desire to integrate both network and compute conditions in the optimization function that informs the steering applied by the network edge nodes, and the desire to operate that function on nodes within the service provider's network, logically separated from service operation. Exposure of network and compute conditions to applications is not in the scope of CAN. Because of their experience and prior work in collecting and exposing network conditions for use in selecting paths and servers, the CAN WG will seek advice and expertise from the ART and TSV areas. The assumed model for the CAN WG is an overlay network, where a network edge node makes a decision based on the metrics of interest, and then steers the traffic to a node that serves a service instance, for example using a tunnel. The CAN WG will focus on single domain models. Architectures that require the underlay network to be service-aware are out of scope. The CAN WG will analyze the problem in further detail and produce an architecture for a solution. Ideally, that architecture will be one that can be instantiated using existing technologies. The CAN WG is chartered to work on the following items: o Groundwork may be documented via a set of informational Internet- Drafts, not necessarily for publication as RFCs: * Problem statement for the need to consider both network and computing resource status. * Use cases for steering traffic from applications that have critical SLAs that would benefit from the integrated consideration of network and computing resource status. * Requirements for commonly agreed computing metrics and their distribution across the overlay network, as well as the appropriate frequency and scope of distribution. o Overall CAN framework & architecture: * This work encompasses the various building blocks and their interactions, realizing a CAN control and data plane that addresses the identified problems and requirements in the groundwork, including methods for distributing necessary information to utilize the identified metrics in CAN use cases. This will also cover OAM, scalability, and security aspects. o Additional groundwork to include: * Analyze the suitability and usefulness of computing and networking metrics for traffic steering decisions in CAN with a CAN metrics ontology as a possible outcome. * Analyze methods for distributing the necessary information to utilize the identified metrics in CAN use cases. o Applicability of existing tools and mechanisms: * Analysis of implementing the CAN control and data plane using existing mechanisms, including identifying the limitations of existing tools in fulfilling requirements. * Study potential new approaches for the CAN control and data plane solution that can fill the identified gaps in existing tools and solutions. * Study FCAPS (fault, configuration, accounting, performance, security) requirements, mechanisms, and suitability of existing messaging protocols (NETCONF) and data models (YANG). Milestones: Jul 2023 Adopt the CAN Problem Statement, Use Cases, Gap Analysis, and Requirements documents Jul 2024 Adopt the CAN Framework and Architecture document Nov 2025 Submit the CAN Framework and Architecture document to the IESG for publication _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
- [Can] WG Review: Computing-Aware Networking (can) The IESG
- Re: [Can] WG Review: Computing-Aware Networking (… Adrian Farrel
- Re: [Can] WG Review: Computing-Aware Networking (… duzongpeng@foxmail.com