Re: [nmrg] [OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics)

Alexander L Clemm <ludwig@clemm.org> Fri, 10 March 2023 00:38 UTC

Return-Path: <ludwig@clemm.org>
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A51C1524DC; Thu, 9 Mar 2023 16:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.1
X-Spam-Level: ***
X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 lC4vYLZptQl3; Thu, 9 Mar 2023 16:38:16 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAEAC169539; Thu, 9 Mar 2023 16:38:15 -0800 (PST)
Received: from [172.16.0.44] ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MFN9m-1pogN617bg-00EJDc; Fri, 10 Mar 2023 01:38:12 +0100
Message-ID: <ec7b7101-9c4f-a65f-8eeb-9d8faea31bfc@clemm.org>
Date: Thu, 09 Mar 2023 16:38:09 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Cc: "draft-cx-green-metrics@ietf.org" <draft-cx-green-metrics@ietf.org>
Content-Language: en-US
To: Haoyu Song <haoyu.song@futurewei.com>, Alexander L Clemm <ludwig@clemm.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "nmrg@irtf.org" <nmrg@irtf.org>
References: <ab8fde51-3268-021e-2c4d-26fb26be8477@clemm.org> <BY3PR13MB478738FB9C218F3B520DAC899AB59@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Alexander L Clemm <ludwig@clemm.org>
In-Reply-To: <BY3PR13MB478738FB9C218F3B520DAC899AB59@BY3PR13MB4787.namprd13.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:lHq/zYbqs6r6fVWAoTrGgbGaaf5UrxTPZiIdmW/K3azFCfnhWgr 26O9qjJnV5cKc3pFLqTOcDrk6+p1Hg4vnri+4HHbP2YYHVjaYXSeFscQ5Wcj+VHNU1uzuKV +8Od+oUXQk1YaaCMOuzrsiYh9aWC7gemCTvq/EfAlWziQSCYnLqRZ/5yLIcW7p5HKCe2fiX /5mF8zfNdpm9IjZwdqKDA==
UI-OutboundReport: notjunk:1;M01:P0:5+NLxNtNa78=;R7al/fwVS7ZMwdNiGPmx14losuB RTOctddp6sSRupPLC/NAf6+Ijx+XnGOZbTY1e9+yqnBfjeb6EOioVIC+341qbsPGp4Ont3f2N cI4qzhbFSivqJKSop0hf8haFpKbHRJzXbhE9YVon+p0Rv/jXM6LJnT1+h/LY0rBKdqbNW15XY qmqiwk9fTmdogQnh0JMSBjsAvBziG7cq5QEbA+kdg9LnZYSwcmSvH7pQ3N1YmIZmSz4E3YM+R xO8JtMrgj9EP5wpu0VoCxLAOjf2/ObjOU6dldQI8JHIA87dozO2wDE5HV/foO2DA4qcH/nyw7 dSUaAioXrcycVPGGTJpIu6+jU/MJTcgYicuV37ze73IGAEiatlGTBSwABMx8cd6pb+As/cxZ1 XFVW/UJVFI79y1pHOw28M8eecH6w04CO4w3Ld8WgJka15vmMRVQ1gTUjyzqab4KtXkMeMFNcF W3H8VLjL+N6XYboJz9TnPaDXVsivXMZRkDrYcUT/hWBkS9VdUlFqwCgF1oi+ovmA4L1bMPTiT dZEjqsFYCik2+ZdSMxOBQGt5UgQD2Gk8nP+sA9IyjvNS4aI92jxKzeay5FOYDYhD9S0ytaGjj vaiGNS40oyrmMxoAxtToNCqP2EqZAyjDyfu+E+qSaqw2GQjYkDMXBQCTBN9xFaZq+K+t0VZSX 8MiWUVjNpxC3OWDadhxmWTVtpLeuzwynt4GLKONMIw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nmrg/6uErqodY9OVpC9Qekp_l7NPEY74>
Subject: Re: [nmrg] [OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics)
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Management Research Group discussion list <nmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nmrg>, <mailto:nmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nmrg/>
List-Post: <mailto:nmrg@irtf.org>
List-Help: <mailto:nmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nmrg>, <mailto:nmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2023 00:38:20 -0000

Hi Haoyu,

thank you for your comments.  A couple of quick replies:

Re: 1) Clearly normalization is important and the challenge there is to 
come up with metrics which are both useful and straightforward to 
implement.  IMHO the starting point will include the "raw" metrics; 
applying any formulas or factors should be done as part of second-order 
metrics.  As for separating out how much carbon footprint should be 
attributed to a computation task versus a networking task for devices 
that perform in-networking computing, I am not sure this will always be 
practical.  However, you could in fact use the metrics that are proposed 
in the draft to account for that at the networking level.   Here you 
look at the overall energy consumption or the network as a whole, not 
just the sum of individual devices.  This will allow you to account for 
"hidden" polluters etc, and use that to apply some factor or "tax" to 
come up with the true holistic picture.  In cases where you have 
networking devices that have a large carbon footprint, but that obviate 
the need for separate devices that would otherwise not be accounted for, 
this factor will be a lot smaller than would otherwise be the case.

Re: 2) The intent here is to focus on the "what" not on the "how". That 
being said I think there are a number of things that can be done to 
measure or at least estimate these.  A simple example would, for 
example, determine what fraction of a device's traffic volume can be 
attributed to a particular flow (this is straightforward), then apply 
that fraction to the carbon footprint of the device overall to determine 
the flow's share of it.

Re: 3) Of course if you send many bits you divide the share among them.  
What is meant here is the incremental cost of sending a bit.  If you 
sent just a single bit, that would involve a high incremental cost 
(which will be incurred even if you send no further bit); if you were to 
send a second bit immediately after that, that one would involve a very 
low incremental cost.

Cheers

--- Alex


On 3/9/2023 11:29 AM, Haoyu Song wrote:
> Hi Alex,
>
> This is an interesting read. Here I provide some comments and observations.
> 1. I think the energy consumption metrics on equipment is more meaningful when it's normalized to the device's capacity and capability. For example, energy per bit can be used to compare which is greener between two devices if they offer the same function. On the other hand, if a device does more processing (e.g., in network computing), it's likely it will consume more energy, but it also makes the overall solution more efficient, so it's still greener in this sense.
> 2. The flow and path energy metrics is interesting but I wonder how it can be measured in reality? If this is doable, then perhaps application/job level energy consumption metrics should also be included (e.g., in HPC DCNs, a job may involves multiple flows and multiple paths). This level of granularity may be more preferred in evaluating  different solution architectures.
> 3. In section 3.1.1, it seems unfair to attribute the cost to only the first bit. It's meaningless to send only one bit anyway so the cost should be shared by all the bits.:)
>
> Best regards,
> Haoyu
>
> -----Original Message-----
> From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of Alexander L Clemm
> Sent: Wednesday, March 8, 2023 5:35 PM
> To: opsawg@ietf.org; nmrg@irtf.org
> Cc: draft-cx-green-metrics@ietf.org
> Subject: [OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics)
>
> Hi,
>
> we just posted an updated revision of "Green Networking Metrics"
> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cx-green-metrics%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=USheN9sfG%2FwDm8Yy9aTy20SacMv%2B1Zd6hbiiPP63iHg%3D&reserved=0), including various editorial improvements and incorporating highly useful feedback and suggestions from a number of people including Eve Schooler, Alexandru Petrescu, and Michael Welzl.  The draft defines a set of "green" networking metrics that will be useful as basis for management and control applications that aim to reduce carbon footprint and hence require visibility into such metrics.
>
> We believe that in terms of scope, this draft falls into the intersection of opsawg and nmrg interest and we hope to have the opportunity to present at IETF 116 in Yokohama, hence we are crossposting to both groups.  Personally I believe that opsawg may be the most suitable landing spot as the draft can be easily operationalized and is not as much concerned with open-ended research questions, but that is of course where we would appreciate feedback from the groups.  Once a decision is made for the proper landing spot, hopefully immediately following IETF 116, we will post a new revision under the respective working group.
>
> FYI, here is the abstract of the draft:
> This document explains the need for network instrumentation that allows to assess the power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it.  It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's energy efficiency and "greenness".
>
> On behalf of the coauthors
> --- Alex
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0T83gXiOGuQnhKkuwbmZ7ex7KTilOComeVuP3XIkn44%3D&reserved=0
>