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

Dean Bogdanovic <ivandean@gmail.com> Tue, 19 November 2024 19:59 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 96C68C151533 for <irtf-discuss@ietfa.amsl.com>; Tue, 19 Nov 2024 11:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 ntWH5TlnlxYf for <irtf-discuss@ietfa.amsl.com>; Tue, 19 Nov 2024 11:59:00 -0800 (PST)
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 95B63C151527 for <irtf-discuss@irtf.org>; Tue, 19 Nov 2024 11:59:00 -0800 (PST)
Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6eebae6f013so3961587b3.0 for <irtf-discuss@irtf.org>; Tue, 19 Nov 2024 11:59:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732046340; x=1732651140; 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=aC9QTtI3oUK12xDeMS7EpIhPdC3626mnPHT5rWp2XWA=; b=EJ7LzpicMtsVupaHoa4kbO8MgisslyDR38WlksVhSKv/ycOIF3rvwSrQ4X6/hnFQby 84XLhWP9p4UTXUiEssROwsKZ9sT1zXt3OFjHtYrqwJ4QPe+TJlOC0OqhsQEPpPCwqdrc Ujh+7FrWIVdQ0bJDqfkqesEn5j/QslEdCx1IUP+dYO7ijduK4eMie/VErs5bvi3nhHVy ntAX3BISmq9kjzyMaxpEWx3TOw/y0cH/Y5j0LXcMkNOwJqUR1WvsnIx08ezU0DITXiUx 1ZYLxi8R48hYZGhBpziboGYljFM5azE5IbIdaebbWS5/hDDi6rzwXPjXnMjsJaAIW9dn BnIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732046340; x=1732651140; 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=aC9QTtI3oUK12xDeMS7EpIhPdC3626mnPHT5rWp2XWA=; b=rvb/L0/ne01o/Jb2bt7lI3p3ZKfXtKoc60l0d8Y6T4ZEvRajdUhZfZai+PnFlmVNTY tw0OcduArHOwaqBAzIsN7K3udFLFZkVbBqfN4W3vUTo+vtITXZR9oWCzHezV4iO9MVew k75ssCghHilmLtE9lgenKmOzRb1fQuOTizWJfZjyrBt72lSNZ5Zbd8ssVUKCwABQ67z6 Y3oYr5O9T8orKWe7EYaJLhodBCSIk623cFUsfuSZETzRoVMfzmZ8btRqkuRCIn+jN8+k S6TW42bLhx8jxvk7lYtOxLQsc0MsCM44ViOy9caFuDqdOzvbY7Uta/WPl02AzFlvUeBz kX+A==
X-Forwarded-Encrypted: i=1; AJvYcCVhP0vpT4PjBVIv+RFviy3eSREECiN0M2lCpOy8bDZm1mrBjcE7Xd2iAFbllqvJPd8byBduUvD4Oid6090=@irtf.org
X-Gm-Message-State: AOJu0YyWVoMBkPQzTKwq9EJ/DQIDhkIYA4rHQEj/D+NBk1YXnwdWfYzF su2xUBFssqZebAbeWRcKEDUd4gG3ntHFeaofd5lhQAC+/LSOfb8kmKgXreti
X-Google-Smtp-Source: AGHT+IF3RqDpbgtgLEzpXv+dgpQLFrxMLF2uBomRITrLM7cLt0WmQlGv9qmkQGUURkdLj/EVuRiOBQ==
X-Received: by 2002:a05:690c:6ac8:b0:6ea:c928:771 with SMTP id 00721157ae682-6eebd2cd32amr1554737b3.28.1732046339678; Tue, 19 Nov 2024 11:58:59 -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 6a1803df08f44-6d40dc47d14sm52207806d6.63.2024.11.19.11.58.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2024 11:58:59 -0800 (PST)
From: Dean Bogdanovic <ivandean@gmail.com>
To: Mark Butcher <mark@posetiv.co.uk>
Date: Tue, 19 Nov 2024 14:58:58 -0500
X-Mailer: MailMate (1.14r5895)
Message-ID: <98CCE957-5291-4CBE-8173-1BE670B09A3A@gmail.com>
In-Reply-To: <CWLP123MB46267CADC557DE2A5DE89F8C9F592@CWLP123MB4626.GBRP123.PROD.OUTLOOK.COM>
References: <CAFvDQ9ruuSkrxU4wQz21Ldfp4T4s2MnojJ3H9TFBHdBsQdZm5w@mail.gmail.com> <361466.1731421949@dyas> <LO2P123MB4634D0A59EB238D2BFD8E9E19F592@LO2P123MB4634.GBRP123.PROD.OUTLOOK.COM> <DCB3A12B-3F46-4782-A9B7-19363B247F74@gmail.com> <CWLP123MB46267CADC557DE2A5DE89F8C9F592@CWLP123MB4626.GBRP123.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: GOWZHFWNMMMKBHUDB74P6FZBV3M57NIS
X-Message-ID-Hash: GOWZHFWNMMMKBHUDB74P6FZBV3M57NIS
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: Michael Richardson <mcr+ietf@sandelman.ca>, 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] [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/KnFucu8VFH5WY4P0dT3U5r28WjU>
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 13:26, Mark Butcher wrote:

> Hello!
>
> I’m definitely never going to claim to be a grid expert, but… understanding the grid’s dynamics, especially active, reactive, and apparent power is definitely essential if the objective is to get a better handle on power usage across networks. It’s obvs. not just about energy efficiency; translating this into carbon emissions gets even more critical when you consider how different power sources impact the grid's overall carbon intensity. I’ve had some interesting chats with operators this year around how they are planning to move from supply side to demand side shaping.
>
> I don’t envy the Grid operators facing the balancing act between cost, stability, emissions targets, and resilience (especially as the subject of renewables come into play). Getting even vaguely accurate carbon intensity metrics from them isn’t easy and there’s lot of sweeping assumptions. What’s your view on the regional info shared by operators like the National Grid? I don’t think it’s perfect but it’s at least more accurate than a national average as it reflects their understanding of the flows/mix.
>
> Starting with simpler elements, like SFPs, and then scaling up to more complex topologies makes sense. Tracking energy consumption at this granular level, from individual components up to entire network sections, could provide the data points needed to make informed decisions on reducing emissions, rather than just measuring usage (if we assume we can use intensity metrics from the operators).
This is what the draft (draft-bogdanovic-green-energy-metrics-00) suggests.

>
> Do you think breaking it down into energy consumption at the element, group, and network levels would give insights we could actually use and more importantly to act on?
I don’t think all elements use same power. Some use more, some less. From some anecdotal evidence, the power consumption is not linear with performance, but that is something that needs more evidence. We don’t know too many energy consumption data points. The service providers release their network wide information (https://sustainability.att.com/priority-topics/energy-management) but to start optimizing based on energy, more data is needed.


> Or is this overkill without an agreed structure/approach on what to do with the data and how to interpret it?
Lets start collecting first and come to conclusions later.
>
> Have you got any good examples where you’ve seen this work? I’m doing a lot of work in data centres on this subject
First, really happy to hear that you have actual hands on experience with energy management.

> and the networks teams are often excluded because of the complexity of their operations (outside of core DC networks).

This is where I disagree. Everyone loves to boil the ocean, instead of start collecting simple data points and do analysis what is going on.

>
> Looking forward to discussing this further! I personally believe there’s definitely a lot we can do. It would also be good to consider how the data that’s collated can be rolled into the reporting within IT and the wider business.

I’m in full agreement and that is the reason why draft is out there.

Dean

>
> Thanks
>
> Mark
>
>
>
> From: Dean Bogdanovic <ivandean@gmail.com>
> Date: Tuesday, 12 November 2024 at 17:20
> To: Mark Butcher <mark@posetiv.co.uk>
> Cc: Michael Richardson <mcr+ietf@sandelman.ca>, green@ietf.org <green@ietf.org>, E-Impact IETF <e-impact@ietf.org>, irtf-discuss@irtf.org <irtf-discuss@irtf.org>
> Subject: Re: [Green] [E-impact] Network Equipment Energy Efficiency Metric
>
> I’m really curious how many people understand how electrical grid operates,
>
> the difference between active, reactive and apparent power in electrical grid. And how the grip operators are balancing power plants to maintain the needed power levels, how the operators decide between economic dispatch, grid stability and frequency regulation, environmental regulations and emissions , operational flexibility at the power plants etc.
> Until we do, I would not speak about CO2 emissions and other complex energy and traffic engineering relations.
>
> Lets first figure out how to report energy consumption by the networks, from very basic power consumers (SFPs) to more complex, like topologies. And provide the ability to provide the energy consumption information about an element, group of elements, part of network or even whole network to people who will know what to do with the info.
>
> Dean
>
> On 12 Nov 2024, at 14:59, Mark Butcher wrote:
> What’s interesting is seeing how kWh/GB is so variable – either based on network demand, the reality of the power curve and most importantly for me, when translated into CO2e how the variability massively increases (time and location)
>
>
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Date: Tuesday, 12 November 2024 at 14:32
> To: green@ietf.org <green@ietf.org>, E-Impact IETF <e-impact@ietf.org>, irtf-discuss@irtf.org <irtf-discuss@irtf.org>
> Subject: [Green] Re: [E-impact] Network Equipment Energy Efficiency Metric
>
> Is is useful for network planners to know kWh/peak-GB for an entire infrastructure?
>
> 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?
>
> 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