Re: [recipe] FYI: [admin-discuss] REMINDER: IETF carbon emission measurement workshops on 20 and 21 September

Bruce Nordman <bnordman@lbl.gov> Mon, 26 September 2022 18:32 UTC

Return-Path: <bnordman@lbl.gov>
X-Original-To: recipe@ietfa.amsl.com
Delivered-To: recipe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986FCC14CE23 for <recipe@ietfa.amsl.com>; Mon, 26 Sep 2022 11:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.885
X-Spam-Level:
X-Spam-Status: No, score=-6.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=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=lbl-gov.20210112.gappssmtp.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 FjaXEt5paIOA for <recipe@ietfa.amsl.com>; Mon, 26 Sep 2022 11:32:21 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28425C14F72D for <recipe@ietf.org>; Mon, 26 Sep 2022 11:32:21 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id m9so4840540qvv.7 for <recipe@ietf.org>; Mon, 26 Sep 2022 11:32:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lbl-gov.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Oi2/+ley1v5yNPJpg0ixN3l8117eV+sb9okoHY0m9NE=; b=W0/fFmCnnYV11RP0lf9HwJzNVoeiZr1HpdIodJJL0LRHTZ8C9VKVEqs3Hzcd01BEOM L+jRjQHPrVWvRwX1y8Wb2Gebl/lzu8PaPZyLatLfPl+byYdaBAMbeUfyakvMh6rxk4hd TvRaS1w84SDxM6jWa8D7t5m3XKXARLkQJONRMSBrk0ozMfjjEdNqr/3W12bi3sgybvMo N3P+wOOkQBPLjHMCqaQjlhDL45Zf8smYvl6xgRvlFdL5Iv6OQGo3AYQwgfindfUK9+Gq rV4XstOTlLeWGpcJffm8UE1bPY6XhaU+K3boOhtWfaQVqy0VE3g39Npf1/XU+g611WYQ W11Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Oi2/+ley1v5yNPJpg0ixN3l8117eV+sb9okoHY0m9NE=; b=qakaZAfqXMSIHV9BBzOBJSYXVfurKGwESc4dIds02TR+DMOoaUzMwQ+Q1oN4AZhuiR 1FU4HC2+vBJ8JH4/gpXms4A1fm+ylBKuD1ZDaRVtbqDVYWicSedYRuGe8kRpH1W/aNbE rsdvXKqisfhP3JT5IjtE9ccKECMgi+SPhn8RUIJQi0IvC23RHTHDQYll64V6gs2sFIZG XL2BMRnSyMzVqgCgf4rq3euAXZ1cO6bdtfUHXqO0xXy7e/NtcXcDO3npxNVne+QqG/w5 W7Lqw6tFX0vtTRG8SSelVEJrwqR3RrXsSxBAwXM5jMj9qoVg4hUl2HYiJo1M30ZZrgIi j80Q==
X-Gm-Message-State: ACrzQf3Nl5kRocydVibic5ctCoF3bae/9USjXfx2NP6jXEyA5zL+QJx1 o6bOHkSl7pFJneZPNb7sMDL4b4AVjKoy1YnWMOc3NzclYl/Ytbd99RF5dyuUU6umfip/lmVCgM+ LmoWKzLZG7ErfgaVOB49Q/txkefDvG4IWEyxB7xi1wXyPgDKkeQ5zUxQgm7B4lCHhNA8ipw0FKc tgD/xicXPWFBQ=
X-Google-Smtp-Source: AMsMyM6gA6xbHMk/Tn17EI9l+5eTljGdTJ+z18MdSe/4oNyzUeK0sZHFVedco0ZD+/Akajj6vKnnsVuDcoaEoh43N9Q=
X-Received: by 2002:a05:6214:d02:b0:4ac:9bfb:e7ad with SMTP id 2-20020a0562140d0200b004ac9bfbe7admr17780607qvh.88.1664217139536; Mon, 26 Sep 2022 11:32:19 -0700 (PDT)
MIME-Version: 1.0
References: <Yy87opj7tkqfd85I@faui48e.informatik.uni-erlangen.de> <D3A1335A-022C-4F1F-BCCC-3160B1D3BB7C@ifi.uio.no> <YzDNTByMvA9tsE5c@faui48e.informatik.uni-erlangen.de> <CAK+eDP-G5WWCun9bzKyKbLnmy+gCVy5cMiTrsFU9FzzkWQf5Bg@mail.gmail.com> <DAB0D97B-1FB7-4466-A5EC-EF845FD23AAF@ifi.uio.no>
In-Reply-To: <DAB0D97B-1FB7-4466-A5EC-EF845FD23AAF@ifi.uio.no>
From: Bruce Nordman <bnordman@lbl.gov>
Date: Mon, 26 Sep 2022 11:32:08 -0700
Message-ID: <CAK+eDP_MSP5R2zLPXbT28iW5tpWOWnbVckhDTXL4i3DAaxcdkA@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: recipe@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006e87b605e998bf0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/recipe/1OCL2AWPVhkjmzTW_JfSo9FqrQw>
Subject: Re: [recipe] FYI: [admin-discuss] REMINDER: IETF carbon emission measurement workshops on 20 and 21 September
X-BeenThere: recipe@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RECIPE \(Reducing Energy Consumption with Internet Protocols Exploration\)" <recipe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/recipe>, <mailto:recipe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/recipe/>
List-Post: <mailto:recipe@ietf.org>
List-Help: <mailto:recipe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2022 18:32:25 -0000

On Sun, Sep 25, 2022 at 11:44 PM Michael Welzl <michawe@ifi.uio.no> wrote:

> ...
>
>   Estimates of energy/carbon often collide head-on into the average vs
> marginal question. My home network equipment is needed for me to send this
> email, but it is on 24/7 regardless of what I do - and even if I am NOT at
> home. Any incremental use for incremental traffic is tiny in annual energy
> use. Sometimes it is appropriate to use average, but I think more often
> marginal is more appropriate to decisions that could be made using the
> data.
>
>
> Let’s see if I understand this correctly: by “marginal”, do you mean the
> power used by the equipment when you’re not at home?  Don’t devices sleep,
> at least after some time?  Is the power in sleep mode so high over these
> long time periods (e.g., while we’re in the office, in daytime… or while we
> sleep) that this is really significant?  Either way, I have a feeling that
> there’s not much the IETF can do about this.
>

I left out an important NOT above. My network equipment is on continuously
- it doesn't sleep. I don't see entire network eqt. devices as plausibly
going to sleep (at least in res/comm bldgs) though individual links can
(e.g. 802.3az). The power levels of my network equipment probably go up
with higher traffic levels, but I expect that the increment is quite small.
Making up some #s here, if my network equipment uses 20W with no traffic
and 20.5W on average when there is significant traffic, then I should
allocate only the 0.5W as the marginal cost of its use in determining the
impact of more or less traffic. The equipment will use the 20W even if
there is no traffic (but since I have a (very) few IoT devices like my
water heater, there is always some traffic).

This comes up when considering something like streaming a movie vs. mailing
a DVD. There is an issue about long-run effects, e.g. if many people stream
movies, will that induce increases in infrastructure capacity so that one
can consider short-run marginal and long-run marginal. For automobiles, a
lot of costs are fixed no matter if you drive a little or a lot, but when
not having a car at all (I didn't for many years), then the fixed costs can
come into play.

>
>
>   Jon Koomey was mentioned - I have worked with him (sporadically) for
> over 25 years - also with Eric Masanet.
>   For comparing network eqt. energy use to aviation, think of health care.
> Certainly cancer and heart disease are huge problems in industrialized
> countries and deserve a lot of attention, but that doesn’t mean that
> diseases that harm fewer people don’t also deserve some. We need to work on
> all topics, but in proportion to how much progress is achievable. We have
> expertise in certain areas so should focus on that.
>   In rough terms, electronics connected to the Internet use about 10x what
> network equipment uses, so the IETF can make the best contribution by
> helping to reduce the energy use of hosts.
>
>
> I didn’t know about the factor 10, but considering the main finding of
> this paper: ttps://onlinelibrary.wiley.com/doi/10.1111/jiec.12630  and
> some other things I came across, including this often-cited paper which
> makes *extreme* predictions (I have trouble believing them… but then
> predictions are what they are … just guesswork, really):
> https://www.mdpi.com/2078-1547/6/1/117   … I also got the impression that
> the edge is where most of the gains can be achieved.
>
Given the past 20 years of history, the 'realistic' worst case for 2030
does not seem realistic to me.

>
> It would be interesting to know the relationship in terms of energy usage
> between hosts, WiFi APs, and cellular equipment. Is it really just hosts
> where we should reduce energy usage?
>
We should work on them all, though should prioritize hosts since there are
a lot more savings potential there. Network providers do have an incentive
to pay attention to operational energy use (though that doesn't guarantee
that all cost-effective efficiency measures are taken).  Owners of
residential and commercial buildings are much less capable of optimizing
their purchase and use patterns.

--Bruce


-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov <http://nordman.lbl.gov>*
BNordman@LBL.gov
510-486-7089; m: 510-501-7943