[irtf-discuss] Re: [Green] Re: Network Equipment Energy Efficiency Metric
Toerless Eckert <tte@cs.fau.de> Wed, 20 November 2024 06:11 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4BDC06ECA4 for <irtf-discuss@ietfa.amsl.com>; Tue, 19 Nov 2024 22:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.654
X-Spam-Level:
X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=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_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 f1JPo6tJZkrE for <irtf-discuss@ietfa.amsl.com>; Tue, 19 Nov 2024 22:11:38 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E65AC16940B for <irtf-discuss@irtf.org>; Tue, 19 Nov 2024 22:11:34 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4XtWGB0NtCz1R73V; Wed, 20 Nov 2024 07:11:30 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4XtWG96X7gzkxvJ; Wed, 20 Nov 2024 07:11:29 +0100 (CET)
Date: Wed, 20 Nov 2024 07:11:29 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Dean Bogdanovic <ivandean@gmail.com>
Message-ID: <Zz19kZ9_1zaKjYxv@faui48e.informatik.uni-erlangen.de>
References: <CAFvDQ9ruuSkrxU4wQz21Ldfp4T4s2MnojJ3H9TFBHdBsQdZm5w@mail.gmail.com> <A3A3484C-A348-4722-9247-0D59A7B47B4F@mjmontpetit.com> <f878e072-89a9-4f9f-b104-a8a549d72944@joelhalpern.com> <10B2E78D-1A1D-4124-9F96-78DB4AC1AC7C@gmail.com> <ZzMf1iHjDDS5lsqN@faui48e.informatik.uni-erlangen.de> <AFB30CC1-2BAC-44EE-B10B-38EBB753FE08@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AFB30CC1-2BAC-44EE-B10B-38EBB753FE08@gmail.com>
Message-ID-Hash: KA5H3CFMK6ZITXS3MFZYFZSYBK2QOYLU
X-Message-ID-Hash: KA5H3CFMK6ZITXS3MFZYFZSYBK2QOYLU
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-irtf-discuss.irtf.org-0; header-match-irtf-discuss.irtf.org-1; header-match-irtf-discuss.irtf.org-2; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Hesham ElBakoury <helbakoury@gmail.com>, green@ietf.org, E-Impact IETF <e-impact@ietf.org>, irtf-discuss@irtf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [irtf-discuss] Re: [Green] Re: Network Equipment Energy Efficiency Metric
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/ftP0Wh3_3jT0QbRXNipNcee-d-w>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Owner: <mailto:irtf-discuss-owner@irtf.org>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Subscribe: <mailto:irtf-discuss-join@irtf.org>
List-Unsubscribe: <mailto:irtf-discuss-leave@irtf.org>
On Tue, Nov 19, 2024 at 03:30:54PM -0500, Dean Bogdanovic wrote: > > 1. It is always helpful to mention the name of a draft discussed in the email. Ideally even in the subject line so that searches on the mail archive and data-tracker find the info discussed. > I replied to the thread that was referring the draft I authored, so not sure why to repeat the draft name. Sorry for being a tooling nerd. AFAIK, there are a lot of search functions that only look at subjects in various mail readers etc. Go to the datatracker page of yout draft for example and click on "Search email archive". That will find only those emails to WG/RG mailin lists with your drafts name in the title. > > 2. The draft might need to refer to some BMWG definition of those percentages. aNDR if > > i remember correctly (aggregate non-drop rate). > > From the documents BMWG working on are very specific cases and don’t think are appropriate methodologies for energy testing. That may be true so far, but i think for those of us who want to understand energy, we should also understand already established metrics and use them unless we have a good understanding that they don't fit. And one of those metrics i come to remember especially from software forwarding routers was aNDR (not even sure if/where BMWG may have used it), which is a way to determine 100% and 90% "maximum forwarding capacity". Because you do not define what "maximum forwarding capacity" means. > In my methodology proposal is important to link the throughput with energy consumption, as based on anecdotal evidence, the energy usage is not linear. What are the exact points to take the measurement in the draft are examples. Maybe the testing should be done with continuously increasing the traffic load and measure the energy consumption during the whole process. Of coourse. And i very much like your drafts suggestion to start with three data points to keep it simple. But it needs to be refined to allow reproducable measurements. Hence the suggestion of aNDR. > > 3. It might be useful to ask for a maximum power consumption power value and capture > > an explanation of the condition under which it happens if it is higher than the 100% > > load power consumption. > > Sure, why not. This is something we have to find out what would be the best test methodologies. I’m looking at some NIST and ISO ones. My measurement times for routers a a good time ago, but i would be surprised if there would not still be the approach to use some of those well established labs to get measurments done (by vendors), and so (practically speaking) their methodology might for our industry be more short-term relevant than other bodies specifications (if they differ). > > For example, on devices that use CPU for forwarding, the control plane may consume > > significant amount of power durign reconvergence events, when e.g.: multicore > > parallelized BGP (in good products ;-) tries to reconverge. Or > > during bootstrap when all linecards are initialized or the like. > > I’m not sure we would be able to do that testing, as such granularity is hard to achieve. I would start with more basic one. Certainly not too important for routres where the mayority of energy is consumed by dedicated forwarding chips, but if i was to quantify energy consumption of hardware used to build a 5G core, i wouldn't even want to try start guessing which of the functions in there uses how much CPU and hence energy. Best i can do is to gohalf way to e.e. CPU forwarding mobile edge routers. Cheers Toerless > Dean > > > Cheers > > Toerless > > > > On Tue, Nov 12, 2024 at 09:06:57AM +0000, Dean Bogdanovic wrote: > >> In the draft presented, we are taking different loads into the account > >> > >> Idle State (0 bps): When the device is powered on but not forwarding > >> any data. > >> > >> Low Utilization: A percentage (15%) of the device's maximum > >> forwarding capacity. > >> > >> Medium Utilization: 50% of maximum capacity. > >> > >> High Utilization: Near the device's maximum forwarding capacity > >> (90%). > >> > >> The whole point of testing to see how the performance is related to energy > >> consumption in standardized conditions. If STC can’t be established, the > >> testing conditions (temp, relative humidity, atmospheric pressure) should be > >> reported. > >> > >> Also, we are not looking to report what energy source the network operator > >> is using. This up to them to figure it out. We don’t have the expertise in > >> energy transmission and trying to figure out what energy source to use based > >> on certain conditions. > >> > >> Dean > >> > >> On 12 Nov 2024, at 2:46, Joel Halpern wrote: > >> > >>> I may be missing something, but I presume that one would have separate > >>> measures. One, if it is useful, for kWh/GB. Presumably others for idle > >>> energy consumption, etc. And separately, one would have information > >>> about what sources the site is using for its energy (or more precisely > >>> if the feeds are more segregated.) > >>> > >>> Yours, > >>> > >>> Joel > >>> > >>> On 11/11/2024 3:45 PM, Marie-Jose Montpetit wrote: > >>>> I think any metric should also take into account the type of energy > >>>> that is being used. This is common in how the cost is evaluated in > >>>> energy audits and there are companies who do that. So essentially a > >>>> “bit” produced on a system that uses a gas powered evergy source has > >>>> not the same value a a bit produced under a wind power. > >>>> > >>>> mjm > >>>> Marie-José Montpetit, Ing. Ph.D. > >>>> marie@mjmontpetit.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> On Nov 11, 2024, at 3:13 PM, Hesham ElBakoury > >>>>> <helbakoury@gmail.com> wrote: > >>>>> > >>>>> Dean and Tony presented set of metrics in the GREEN WG meetings > >>>>> one of them is *Network Equipment Energy Efficiency* metric. I > >>>>> think this is the the kWh/GB metric which although it is used, > >>>>> we debated it for quite sometime in e-impact. > >>>>> > >>>>> I recall that Rudolf calls this metric nonsense and should be > >>>>> banned, because "it doesn't convey any comparable and actionable > >>>>> meaning. The numbers are incomparable because traffic and energy > >>>>> use are in no way and have never been related. How is it > >>>>> possible that with the exact same network and equipment the > >>>>> energy use is stable when traffic goes up?" > >>>>> > >>>>> The Journal of Industrial Ecology <http://davidmytton.blog/?action=user_content_redirect&uuid=26a31a773b7bba39c75caf0de4d5c5b2044163406de0898dfdfa2c769ab31970&blog_id=140180607&post_id=4707&user_id=244835025&subs_id=408283364&signature=6485fa34baff8ccaeb16b8eaf6822554&email_name=new-post&user_email=helbakoury@gmail.com&encoded_url=aHR0cHM6Ly9vbmxpbmVsaWJyYXJ5LndpbGV5LmNvbS9qb3VybmFsLzE1MzA5Mjkw> > >>>>> published a new paper co-authored by Dag Lundén and Jens > >>>>> Malmodin. > >>> Paper Title: Network energy use not directly proportional to data > >>> volume: The power model approach for more reliable network energy > >>> consumption calculations <http://davidmytton.blog/?action=user_content_redirect&uuid=85c1e5d13df5d1118d082181ed00f6e7a5ed7a2046c0eb8de4b50f9fb0af4d12&blog_id=140180607&post_id=4707&user_id=244835025&subs_id=408283364&signature=51744c392cee5b2ee750ad1c052559d5&email_name=new-post&user_email=helbakoury@gmail.com&encoded_url=aHR0cDovL2RvaS5vcmcvMTAuMTExMS9qaWVjLjEzNTEy> > >>> . > >>>>> > >>>>> The idea in this paper is that many modelers have assumed a > >>>>> linear relationship between data volume and energy consumption. > >>>>> This fails to account for idle power consumption and other > >>>>> factors. Also, networks are typically too complex to model its > >>>>> energy efficiency with a number as simple as joules/bit. This > >>>>> paper suggests the Power Model which has its limitations. > >>>>> > >>>>> The main conclusion of the paper is that > >>>>> "There is now sufficient evidence from many organizations from > >>>>> a range of different geographies to demonstrate the lack of a > >>>>> connection between network usage and total energy. Combining > >>>>> this with a commonsense approach that total energy of a network > >>>>> device cannot exceed the total maximum power of that device and > >>>>> an understanding of how networks are provisioned for redundancy > >>>>> and peak capacity proves that network energy use is not directly > >>>>> proportional to data volume" > >>>>> > >>>>> Over the years we have seen many publications offering their > >>>>> ideas and suggestions for energy efficiency metrics, but they > >>>>> have their flaws and shrotcomings. I doubt there is a "perfect" > >>>>> metric for systems as complex and multifaceted as a > >>>>> communications network. > >>>>> > >>>>> Comments? > >>>> > >> > >>> _______________________________________________ > >>> Green mailing list -- green@ietf.org > >>> To unsubscribe send an email to green-leave@ietf.org > > > >> _______________________________________________ > >> Green mailing list -- green@ietf.org > >> To unsubscribe send an email to green-leave@ietf.org > > > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de
- [irtf-discuss] Network Equipment Energy Efficienc… Hesham ElBakoury
- [irtf-discuss] Re: Network Equipment Energy Effic… Marie-Jose Montpetit
- [irtf-discuss] Re: Network Equipment Energy Effic… Joel Halpern
- [irtf-discuss] Re: [Green] Re: Network Equipment … Dean Bogdanovic
- [irtf-discuss] Re: [Green] Re: Re: Network Equipm… Toerless Eckert
- [irtf-discuss] Re: [E-impact] Network Equipment E… Michael Richardson
- [irtf-discuss] Re: [Green] Re: [E-impact] Network… Mark Butcher
- [irtf-discuss] Re: [Green] Re: [E-impact] Network… Toerless Eckert
- [irtf-discuss] Re: [Green] [E-impact] Network Equ… Dean Bogdanovic
- [irtf-discuss] Re: [Green] [E-impact] Network Equ… Mark Butcher
- [irtf-discuss] Re: [E-impact] Re: [Green] Network… Hesham ElBakoury
- [irtf-discuss] Re: [Green] Re: [E-impact] Network… Tony Li
- [irtf-discuss] Re: [E-impact] [Green] Re: Network… Tony Li
- [irtf-discuss] Re: [E-impact] [Green] Re: Network… Toerless Eckert
- [irtf-discuss] Re: [E-impact] Re: [Green] Network… Hesham ElBakoury
- [irtf-discuss] Re: [E-impact] Re: [Green] Network… Mark Butcher
- [irtf-discuss] Re: [E-impact] Re: [Green] Network… Hesham ElBakoury
- [irtf-discuss] Re: [Green] Re: [E-impact] Network… Toerless Eckert
- [irtf-discuss] Re: [Green] [E-impact] Network Equ… Dean Bogdanovic
- [irtf-discuss] Re: [Green] Re: Network Equipment … Dean Bogdanovic
- [irtf-discuss] Re: [Green] Re: Network Equipment … Toerless Eckert
- [irtf-discuss] Re: [E-impact] Re: [Green] Network… Mark Butcher
- [irtf-discuss] Re: [Green] Re: Network Equipment … Loa Andersson