[irtf-discuss] Re: [Green] Re: Network Equipment Energy Efficiency Metric

Loa Andersson <loa@pi.nu> Wed, 20 November 2024 08:57 UTC

Return-Path: <loa@pi.nu>
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 35FCFC17A743 for <irtf-discuss@ietfa.amsl.com>; Wed, 20 Nov 2024 00:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 w3fCHpo2i7Wo for <irtf-discuss@ietfa.amsl.com>; Wed, 20 Nov 2024 00:57:12 -0800 (PST)
Received: from srv.pi.nu (srv.pi.nu [IPv6:2a00:1a28:1410:5::1348]) (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 7C218C169424 for <irtf-discuss@irtf.org>; Wed, 20 Nov 2024 00:56:34 -0800 (PST)
Message-ID: <24e988b8-33ee-4e6d-bcb5-977c14a285c0@pi.nu>
Date: Wed, 20 Nov 2024 09:56:30 +0100
MIME-Version: 1.0
To: Toerless Eckert <tte@cs.fau.de>, Dean Bogdanovic <ivandean@gmail.com>
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> <Zz19kZ9_1zaKjYxv@faui48e.informatik.uni-erlangen.de>
Content-Language: sv, en-GB
From: Loa Andersson <loa@pi.nu>
In-Reply-To: <Zz19kZ9_1zaKjYxv@faui48e.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: YUOQSKOC7ZZDB4ZTDXCWLQK2VX74JFGX
X-Message-ID-Hash: YUOQSKOC7ZZDB4ZTDXCWLQK2VX74JFGX
X-MailFrom: loa@pi.nu
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/xyshsLwc2KOatHgZKO35XFVYua8>
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>

All,

inline please.

Den 20/11/2024 kl. 07:11, skrev Toerless Eckert:
> 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.

+1

/Loa

> 
>>> 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
> 

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
loa@pi.nu
loa.pi.nu.@gmail.com