Re: [E-impact] kWh/GB should be banned and the IETF should warn against its use

Romain Jacob <jacobr@ethz.ch> Fri, 12 May 2023 09:43 UTC

Return-Path: <jacobr@ethz.ch>
X-Original-To: e-impact@ietfa.amsl.com
Delivered-To: e-impact@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DA2C151B2F for <e-impact@ietfa.amsl.com>; Fri, 12 May 2023 02:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 2y9d7LfF5voc for <e-impact@ietfa.amsl.com>; Fri, 12 May 2023 02:43:32 -0700 (PDT)
Received: from mailg110.ethz.ch (mailg110.ethz.ch [IPv6:2001:67c:10ec:5605::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCD2C1522AA for <e-impact@ietf.org>; Fri, 12 May 2023 02:43:32 -0700 (PDT)
Received: from mailm113.d.ethz.ch (2001:67c:10ec:5602::25) by mailg110.ethz.ch (2001:67c:10ec:5605::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 12 May 2023 11:43:30 +0200
Received: from [10.6.60.243] (10.6.60.243) by mailm113.d.ethz.ch (2001:67c:10ec:5602::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 12 May 2023 11:43:30 +0200
Message-ID: <407de8a0-ccca-8a2a-7376-bc3bd97ca441@ethz.ch>
Date: Fri, 12 May 2023 11:43:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>
CC: e-impact@ietf.org
References: <3a34fac0-3a7e-e7c1-806f-7332cdafdbd9@ethz.ch> <AA10EF49-A2A6-456B-82C7-B3C2ACF0C6B0@tzi.org>
From: Romain Jacob <jacobr@ethz.ch>
In-Reply-To: <AA10EF49-A2A6-456B-82C7-B3C2ACF0C6B0@tzi.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070308020000010301020309"
X-Originating-IP: [10.6.60.243]
X-ClientProxiedBy: mailm212.d.ethz.ch (2001:67c:10ec:5603::26) To mailm113.d.ethz.ch (2001:67c:10ec:5602::25)
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/pUj7BThystR-Yt6mDjaDckioH10>
Subject: Re: [E-impact] kWh/GB should be banned and the IETF should warn against its use
X-BeenThere: e-impact@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Environmental impacts of the Internet <e-impact.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e-impact>, <mailto:e-impact-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e-impact/>
List-Post: <mailto:e-impact@ietf.org>
List-Help: <mailto:e-impact-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e-impact>, <mailto:e-impact-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2023 09:43:36 -0000

Please see below.

>> Now, the trick is that this **must not** ultimately results in 
>> increasing the capacity of existing networks! Sadly, this is what's 
>> happening today. This must stop--that's the degrowth mindset that 
>> Vesna is referring to AFAIU.
>
> Uh oh. I’m not interested in networks that are based on the prime 
> directive “punish all use”. I’m old enough to have experienced these 
> networks, until they were all swept away by the Internet.
>
> The efficiency of the network will only improve by investments. 
> Investments generally can only be justified by growth. The “punish all 
> use” approach gets you stuck with X.25 and its colossal inefficiency.

I don't understand the “punish all use” counter-argument. What I meant 
is that we should not just increase network capacity "because we can," 
but only when we rationally need it. How should "rational" be defined is 
a political question (and a tricky one, which is not the topic of the 
thread).

Cheers,

-- 
Romain JACOB
Postdoctoral Researcher
ETH Zurich
Networked Systems Group (NSG)
Lead: Prof. Laurent Vanbever
www.romainjacob.net <https://www.romainjacob.net/>
@RJacobPartner <https://twitter.com/RJacobPartner>
@jacobr@discuss.systems <https://discuss.systems/@jacobr>
Gloriastrasse 35, ETZ G81
8092 Zurich
+41 7 68 16 88 22