Re: [E-impact] WindEurope Annual Event

Jari Arkko <jari.arkko@gmail.com> Tue, 26 March 2024 23:27 UTC

Return-Path: <jari.arkko@gmail.com>
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 EFC1FC14F6B6 for <e-impact@ietfa.amsl.com>; Tue, 26 Mar 2024 16:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 0rl2A6okuDc5 for <e-impact@ietfa.amsl.com>; Tue, 26 Mar 2024 16:27:02 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 894FBC14F6AA for <e-impact@ietf.org>; Tue, 26 Mar 2024 16:27:02 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1e0511a4383so45448355ad.2 for <e-impact@ietf.org>; Tue, 26 Mar 2024 16:27:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711495622; x=1712100422; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UZn++OxeB88vJS0kciz0Pcmt2rBYI1C2XFlS2udzXf8=; b=gH6D8kfcOKFrBgyp84Z+uPiCQP/xZmI17Gcn4NHXJ2GujV/gmIe3WIM/o7phME2Omk nHBVBDB+4foQqJQ2XA9J43uAoA/NokDNwv4ae/3fvnzEgEp23encpDGclFPVT9EFhU3M WCIWcv+UXMxjK3WMdVdWNEtr8fIISyrJjMyTtPlZUylCE7LuNmduWso+5RozbmtkuAuc lx2MI5XjnYd+nlvPevKEUo1x9MeFg+t7xOa2/4bS/NZvDObS0qiOcWzmtO4zd+lsXB8h /DEMAq3xBTkpR1mL67oiLcj8FtyaAs2RP+dLsGwx8gyBtkVCuHlM6W/H/HdOjuKH0voP PeBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711495622; x=1712100422; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UZn++OxeB88vJS0kciz0Pcmt2rBYI1C2XFlS2udzXf8=; b=r5Y4B2TdbD3uMNCg+Y3BkyyVRrmgcmKyeFhpUFU4BLioAcwszz3qPt/J66sIKqZs9v jGNG3T2hCEz+FdX2G4MEzAKfyib92B0U143Np8bnikANDqhrJ4PVSt5RjZA7c9FG//Uz RDQQO2qHFLaY2AD37Ahs3LmAu7kR1ET9O48f9ZfOW+FXmUiFu8/dB9Nl1z0tTe2yq+r/ qjqzbOwAEl4f4R/xkUClKMv5t16NANBAena2dm23jo+YXfbqI11Yn9LnImwU6z06kEM8 3y2rxkjbVbEoIN8qS8tpgE0QHSlZ+X4b8bJmOQrm6OwQL4fAmVO/355Imhbw23x+CzvG ZTVg==
X-Forwarded-Encrypted: i=1; AJvYcCV9luzeY6vbLlO1/z8FPZ6IoX5LAyB+Z1qlKe19BpViARNXHFrbYHJPC1aZI2qs40vnLzTT0Ju3d0dGdwXBvg0wkg==
X-Gm-Message-State: AOJu0Yy4IUcXNpVwQZQreT5JQuygfIluag0qs29rQ6KqSonOOWqYHSc/ Mb+C1hVyA/gDA8n0nCyIuPieMmeF4u1S2w2Oz4IDUS40tSEoPVGY
X-Google-Smtp-Source: AGHT+IHLTE1sQJ3i6LhVidbmOFfW3WOR/CSfWLr1af+BifOHpM2sqrPh9MZi0QPtwHh3TeW8UK+BCg==
X-Received: by 2002:a17:902:f64c:b0:1e0:1486:e80c with SMTP id m12-20020a170902f64c00b001e01486e80cmr3218225plg.7.1711495621841; Tue, 26 Mar 2024 16:27:01 -0700 (PDT)
Received: from smtpclient.apple (194-223-161-170.static.tpgi.com.au. [194.223.161.170]) by smtp.gmail.com with ESMTPSA id j5-20020a170902da8500b001e0c568ae8fsm4102216plx.192.2024.03.26.16.27.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2024 16:27:01 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Jari Arkko <jari.arkko@gmail.com>
In-Reply-To: <CAFvDQ9p819UvUvoSxUdXjyV5HDCPg2xJhOdgvi4k624pJrhPzg@mail.gmail.com>
Date: Wed, 27 Mar 2024 09:26:45 +1000
Cc: Manner Jukka <jukka.manner@aalto.fi>, E-Impact IETF <e-impact@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BA2832A-1722-4051-8C54-188146D2BC7F@gmail.com>
References: <CAFvDQ9rGKP_Cieip=11yFaAJc0fqDFnPT7Cce2YVQ=UG1Vf=ww@mail.gmail.com> <B6E79AC1-FC28-48BD-B634-1B4A7470A1DB@aalto.fi> <CAFvDQ9rhF5VynmoXuXxUJ8swAv-DgVdT5qm2SYhme5XL7-nHrw@mail.gmail.com> <F0102A08-1217-4682-9BC0-B5F37EAF9C1B@aalto.fi> <CAFvDQ9p819UvUvoSxUdXjyV5HDCPg2xJhOdgvi4k624pJrhPzg@mail.gmail.com>
To: Hesham ElBakoury <helbakoury@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/BFb94KXz0hLDYIb329NpyC0HFkk>
Subject: Re: [E-impact] WindEurope Annual Event
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: Tue, 26 Mar 2024 23:27:03 -0000

Of course the variability of green power sources is an issue. To an extent we can deal with by varying consumption, e.g., turn the aluminum melters off when power is non-green or scarce, etc. Or data centers :-) 

Part of the problem is of course information sharing, to make sure consumption knows about the state of production. Here Internet helps, obviously :-) But of course there are also local means, e.g., a site that has its own green power knows how much it can consume, but even so, it may still need to communicate to parties it is serving, e.g., it may not accept new jobs unless there’s enough energy and so on.

Then a follow-up on this:

> In 5G we can have low and high power slices which are configured to consume high or low power respectively. For example, Low-power slices may use narrower channels, lower frequencies, and simpler antenna configurations to reduce energy consumption. Traffic is shifted to low or high power slices based on availability of renewable energy.
> 
> Does this work?

You can of course have network equipment configurations or virtual configurations that are geared towards a particular tradeoff. This is true of slicing as well.

However, for 5G perhaps a bigger question is what radios are on and how often and when they can sleep. The radio part is the largest fraction of energy use. But there’s a lot of radios, antennas, sites, coverage, even overlapping coverage and the usage can vary wildly. Think of city business district during work hours and a lot off demand, but more empty in the night when demand shifts to other areas. Potential energy savings don’t come from a particular user group but rather the aggregate. When we can design our system architectures so that the number of must-always-be-broadcasting-every-millisecond parts is minimized, that the overall number of radios on at all  can be scaled according to user demand, that equipment can fall asleep and wake up in extremely short time periods so that it can save energy when there are no packets to send, etc. And remember that packet transmission in mobile networks is highly scheduled/controlled which helps the equipment make well-informed decisions at least in short timescales.

Jari