From nobody Tue May 9 07:04:13 2023 Return-Path: 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 24BFAC1516F2 for ; Tue, 9 May 2023 07:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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=ripe.net 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 8y3Sb82jkgkM for ; Tue, 9 May 2023 07:04:07 -0700 (PDT) Received: from mail-mx-2.ripe.net (mail-mx-2.ripe.net [IPv6:2001:67c:2e8:11::c100:1312]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 CD5BFC14CF09 for ; Tue, 9 May 2023 07:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Content-Type:Subject:From:Cc:To:MIME-Version:Date:Message-ID ; bh=zn+0/WULCcWniclrU494RBpEmp0ExPnMcj3cDc3iFZI=; b=dXs8aAbUj3EDLyIBh32/1629 w2LI3/psndB2/t8Vag6vEWUHs5E3dZ+5jfq9mxvl29k++X6QzvrpXeWFiV7qkrdPK+9Gq4y59pzC/ 0PnGhNIvTeXTUcfSm75LzTIMSTTyhrQ4DiOBPB4wprp4/9/deEBauz/Xz7vEW+Tq2sPi+28XRICDw cD5EPTPXmD1w+y+9HDz2mgbVSJV3mrkz8c70zmmtuzTEV+QMpFEBDJKXYjUS85rlnTpOCbrmXTARA sp+G0i9b72zulZ/SKvB3V06zPimbUqZlFqRkl2enboLy9kcrssBJTvQ2HzSQK2z0STfE/FmjPgwZJ eRS1iba6Bg==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:33632) by mail-mx-2.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1pwNwj-007utM-2e; Tue, 09 May 2023 14:04:05 +0000 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPV6:2001:67c:2e8:1200::831]) by bufobufo.ripe.net with esmtp (Exim 4.96) (envelope-from ) id 1pwNwj-0007eL-21; Tue, 09 May 2023 14:04:05 +0000 Message-ID: Date: Tue, 9 May 2023 16:04:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-US To: Dom Robinson , Daniel Schien Cc: e-impact@ietf.org, Paul Shabajee References: <4D1C76EF-76F0-4FAC-8AAD-90C06CE11AB1@id3as.co.uk> From: Vesna Manojlovic In-Reply-To: <4D1C76EF-76F0-4FAC-8AAD-90C06CE11AB1@id3as.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Signature: 63c376d8fe7b052a5a65f88a9765b61ae759514bee80ab3dd79fdd70821eb2ba Archived-At: Subject: Re: [E-impact] Carbon-Intelligent Global Routing in Path-Aware Networks X-BeenThere: e-impact@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Environmental impacts of the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2023 14:04:12 -0000 Hi Don, all, On 09/05/2023 15:02, Dom Robinson wrote: > acknowledge that it’s easier for accounting firms to correlate carbon to > data transfer, because Network economics account for money in terms of > data transfer. But there is no relation between carbon and GB. If you isolate just one aspect (data transfer) then this might be true. But there is relation between carbon & size of data *storage*. (isn't there?) (see (*)) And in the other aspects of the whole "streaming" experience... ... and all those aspects could benefit form "degrowth", if we want to minimise "e-impact", to stay within the limits of Paris Agreement. And, as you say yourself further on: > Obviously this does not consider embedded emissions in the rollout and > physical deployment of such networks. > In fact, counterintuitively there is a stronger argument that using > “more data” commercially drives a swift migration to new technologies, You say that as if it's a good thing ;-) then all the older devices are either overheating, or have to be dumped, and have to be replaced with new devices... made from non-renewable materials, shipped across half-world, etc etc... ... which, of course, is out of the scope of what _we_ can do -- but, we can influence our own part of the process! > which almost invariably, save energy once utilisation passes an > equivalent point on the legacy network.  Newer IT is almost invariably > more efficient. I have to again refer to Jevons Paradox: https://en.wikipedia.org/wiki/Jevons_paradox "increases (in) the efficiency with which a resource is used , but the falling cost of use increases its demand, increasing, rather than reducing, resource use." > #catamongpigeons :) (*) Here's an interesting presentation, but I am not sure what the conclusion is -- I am curious what you read from it? Energy optimisation in GÉANT https://geant.app.box.com/s/budgt80vyjzlchxk16hs5v6b876r9iuf >> X5 capacity for same power draw but >> Power growth ~10% p/a accounting for planned line cards Regards, Vesna