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

Toerless Eckert <tte@cs.fau.de> Tue, 12 November 2024 16:25 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 D71F6C14F6E3 for <irtf-discuss@ietfa.amsl.com>; Tue, 12 Nov 2024 08:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.657
X-Spam-Level:
X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 XuKeuO0zuGhC for <irtf-discuss@ietfa.amsl.com>; Tue, 12 Nov 2024 08:25:18 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff: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 E51A8C17C8B0 for <irtf-discuss@irtf.org>; Tue, 12 Nov 2024 08:25:17 -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 4XnsG16HvTz1R70c; Tue, 12 Nov 2024 17:25:13 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4XnsG15cTDzkxqk; Tue, 12 Nov 2024 17:25:13 +0100 (CET)
Date: Tue, 12 Nov 2024 17:25:13 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <ZzOBaQSBNHxdugoV@faui48e.informatik.uni-erlangen.de>
References: <CAFvDQ9ruuSkrxU4wQz21Ldfp4T4s2MnojJ3H9TFBHdBsQdZm5w@mail.gmail.com> <361466.1731421949@dyas>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <361466.1731421949@dyas>
Message-ID-Hash: V3IO3R4W6CQNXVQADAQVLOMHYVOKVQ5U
X-Message-ID-Hash: V3IO3R4W6CQNXVQADAQVLOMHYVOKVQ5U
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: 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: [E-impact] 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/LxP8ubuJ54u56_fz206hrFuvDLI>
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 12, 2024 at 02:32:29PM -0000, Michael Richardson wrote:
> 
> Is is useful for network planners to know kWh/peak-GB for an entire infrastructure?

I think so. That's why i was just suggesting to Dean to have not only
0%/15%/100% throughput utilization, but also a definition for max-power use
of a device. How much power is it, and what's needed so that the device will 
use that much power.

> This doesn't try to model reaction of network equipment to increased flows,
> but rather to model how infrastructure grows to accomodate higher peak loads?

Not sure about that use-case. Can you give an example ? I fear that all
expansion may involve new equipment with yet-unknown power parameters...

I was primarily thnking of provisioning powr for peak use. Or as necessary do
peak shaving. For example, if there atually is a significant peak after e.g.
a power failure, as there is in traditional servers with spinning disks, then
this can typically be shaved through software/control mechanisms. I am not aware
of anything like this for traditional network devices, but always good to
know upfront that there is no such situation where power use is higher than
power use during e.g.: 100% utilization, for which one does plan the power supply
of the room/

Cheers
   Toerless

> There is also an induced demand issue.  Networks grow when they fill,
> assuming there is revenue to support it.  This is akin to transportation:
>       https://www.vtpi.org/gentraf.pdf
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> 
> 
> 



> _______________________________________________
> Green mailing list -- green@ietf.org
> To unsubscribe send an email to green-leave@ietf.org


-- 
---
tte@cs.fau.de