[irtf-discuss] Re: [Green] Re: Network Equipment Energy Efficiency Metric
Dean Bogdanovic <ivandean@gmail.com> Tue, 19 November 2024 20:31 UTC
Return-Path: <ivandean@gmail.com>
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 AFBC3C151532 for <irtf-discuss@ietfa.amsl.com>; Tue, 19 Nov 2024 12:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, FREEMAIL_FROM=0.001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NIwQAOTc4USq for <irtf-discuss@ietfa.amsl.com>; Tue, 19 Nov 2024 12:30:56 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7F5C1D4A9D for <irtf-discuss@irtf.org>; Tue, 19 Nov 2024 12:30:56 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id d75a77b69052e-460b16d4534so8197361cf.3 for <irtf-discuss@irtf.org>; Tue, 19 Nov 2024 12:30:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732048255; x=1732653055; darn=irtf.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kqdmu6kYXPlsTJga/1PoH8CxdUg4evpabr0y63yIgRc=; b=JghnBr2iieq9avn4dIjQNaMMqJl+hRSn7x4OaerYvfOTr87Vp20gis/nItSIlNCk8H ER2tzgJlwcwauDFfIgPnKSz23gFCP8jUXb533F0zsrbxm43FdQniFAMpFAZB9wSw4aFj DoSChsGgem4X79XeeeGTDI6abW9a7tEQOwoDAwqnkfnmf/zdhZLFS+6kN3JPZIHojW2c s3WBtpDGtGhlS6TpCJkQ1aylPuJrzRDV17FPP/xRjmowRnkNFsj7Kze2+scS8Be9m+de 78qRhA4/5IluyKByrkcPANGymsj+79yQZ+HZH3nKQ3X7w9nCf/xp6up55Cd7y4S/qX85 aJhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732048255; x=1732653055; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kqdmu6kYXPlsTJga/1PoH8CxdUg4evpabr0y63yIgRc=; b=sPDStYAEf3uPNleuNbJGvjCIcARfuiNmApFDr0tx42HOqKtOWFBV0YjlTV5EjDQYLz a5IO2TeKiQHTdn+0iP6MyNmFDyERkv0koLN49PwWoyMYaph0hZw+niXo8SwBDjgza1j5 0/uBICni5A82DRCruZ5C1lUvB/yvLIQ8DsN6qqnkop6CibWeAFaSN7GXC7oWs+TnimI+ gw2yFw6LPfePK2WGQmnXqp3dn0xlIq2LOKz2vwCBD7yi+pGLbuD7wQkiTH54kaWktnAq Gkm2PVTLjcnLiyE8BBiLrG3Nm6MDBgn5ploXWGJzw7ZCiGiGcTjMQf7pMnmB5Tmt7kmw RGJg==
X-Forwarded-Encrypted: i=1; AJvYcCWU1jqnbQGH9jJ+fCpugaQWY1HvJAfiIjuNWE65T7eWnuUH4s9vlWeTDzLu3ChivPJ0e3w3Y7hU2/HIrsM=@irtf.org
X-Gm-Message-State: AOJu0YxbuEnNsO4LOWv850Czfd60E5yBUlsVoi/iwW1fALOz+zhD93rQ D+PWXmHC7xhNQzGxeptMn9hosLvADfo3VhY0wps0R9EDA6MmWMjh
X-Google-Smtp-Source: AGHT+IH9bl7E3LlsL/aHGyb+1/t0z6lApVWzQfPwR7TTdPUMwZ9Xb13srl5tdbJRm3Fc5ZBpWuOvTA==
X-Received: by 2002:ac8:5754:0:b0:461:15fc:7f85 with SMTP id d75a77b69052e-46479563df0mr43161cf.42.1732048255421; Tue, 19 Nov 2024 12:30:55 -0800 (PST)
Received: from [192.168.0.122] (209-6-128-112.s366.c3-0.bkl-cbr1.sbo-bkl.ma.cable.rcncustomer.com. [209.6.128.112]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4646a544c30sm196001cf.57.2024.11.19.12.30.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2024 12:30:55 -0800 (PST)
From: Dean Bogdanovic <ivandean@gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Date: Tue, 19 Nov 2024 15:30:54 -0500
X-Mailer: MailMate (1.14r5895)
Message-ID: <AFB30CC1-2BAC-44EE-B10B-38EBB753FE08@gmail.com>
In-Reply-To: <ZzMf1iHjDDS5lsqN@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 7SHAU47LPAATO4QNMKDOGRW4AHYCQYCG
X-Message-ID-Hash: 7SHAU47LPAATO4QNMKDOGRW4AHYCQYCG
X-MailFrom: ivandean@gmail.com
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/nmN-vleaC_pD9itOtaRVvwbWafA>
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 12 Nov 2024, at 4:28, Toerless Eckert wrote: > Thanks, Dean > > Some thoughts: > > 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. > > 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. 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. > > 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. > > 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. 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
- [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