[E-impact] Delay Tolerant Users / Services and Flexiblity
Alexander PELOV <alexander.pelov@imt-atlantique.fr> Wed, 14 February 2024 15:41 UTC
Return-Path: <alexander.pelov@imt-atlantique.fr>
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 A0E67C14CF12 for <e-impact@ietfa.amsl.com>; Wed, 14 Feb 2024 07:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=imt-atlantique.fr
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 Z2rlNB1CM-Fu for <e-impact@ietfa.amsl.com>; Wed, 14 Feb 2024 07:41:35 -0800 (PST)
Received: from zproxy3.enst.fr (zproxy3.enst.fr [IPv6:2001:660:330f:2::de]) (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 4C590C14F5FC for <e-impact@ietf.org>; Wed, 14 Feb 2024 07:41:34 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by zproxy3.enst.fr (Postfix) with ESMTP id F3919A0649 for <e-impact@ietf.org>; Wed, 14 Feb 2024 16:41:30 +0100 (CET)
Received: from zproxy3.enst.fr ([IPv6:::1]) by localhost (zproxy3.enst.fr [IPv6:::1]) (amavis, port 10032) with ESMTP id LOLPWc_Eij42 for <e-impact@ietf.org>; Wed, 14 Feb 2024 16:41:30 +0100 (CET)
Received: from localhost (localhost [IPv6:::1]) by zproxy3.enst.fr (Postfix) with ESMTP id 6F288A0630 for <e-impact@ietf.org>; Wed, 14 Feb 2024 16:41:30 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy3.enst.fr 6F288A0630
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1707925290; bh=O6N4mNlHvrVpLaoOAmH7yOOndSArSe1pVNplgxrR7gc=; h=Date:From:To:Message-ID:MIME-Version; b=WaO2ZTeZ0Ta9KHjO02Nfz0ZdO8bygCy+X0DPe6+QyAeIOLoUZAyc2ksrEVwWhRw06 otFzSKYUGtPItl26m0DgXCIg0BA2+t1/uAxO7iO6m+eV/Ymusmuf1CSZka2Fabvsyg c7QW49308h58NrFE4m3vxS02/Be0fCj1Wi+w1mug=
X-Virus-Scanned: amavis at enst.fr
Received: from zproxy3.enst.fr ([IPv6:::1]) by localhost (zproxy3.enst.fr [IPv6:::1]) (amavis, port 10026) with ESMTP id X0crRMPqelrS for <e-impact@ietf.org>; Wed, 14 Feb 2024 16:41:30 +0100 (CET)
Received: from zmail-imta1.enst.fr (zmail-imta1.enst.fr [137.194.2.216]) by zproxy3.enst.fr (Postfix) with ESMTP id 5ADEDA060B for <e-impact@ietf.org>; Wed, 14 Feb 2024 16:41:30 +0100 (CET)
Date: Wed, 14 Feb 2024 16:41:30 +0100
From: Alexander PELOV <alexander.pelov@imt-atlantique.fr>
To: e-impact <e-impact@ietf.org>
Message-ID: <1224198816.2403212.1707925290304.JavaMail.zimbra@imt-atlantique.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [2a02:8428:26fc:1401:24c7:8f14:3f:988f]
X-Mailer: Zimbra 9.0.0_GA_4583 (ZimbraWebClient - FF122 (Mac)/9.0.0_GA_4583)
Thread-Index: GFGUi1eq5iT/HDAYnYyNoarnMn10rQ==
Thread-Topic: Delay Tolerant Users / Services and Flexiblity
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/XyLPvRpc1efca0TH8pbBFGKtpSI>
Subject: [E-impact] Delay Tolerant Users / Services and Flexiblity
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: Wed, 14 Feb 2024 15:41:39 -0000
Hi all, On a separate topic, and somewhat related to the elasticity of energy consumption with the served trafic, a couple of years ago we worked on the notion of Delay Tolerant Users [1]. We considered the fact that the energy consumption is not really elastic and instead focused on what can we do to turn off parts of the network. We used the notion that we can ask some uses (or users) to wait. This allowed to define a network, where base stations were sleeping more often and for longer periods. The idea is that some types of traffic can be deferred with (almost) no consequences (such as file downloads), but others - such as voice or video calls - can keep a cell "on" even for very small amounts of trafic.. and explicitly stating that some users are willing to wait for 30 sec. before getting connectivity may actually be worth it. In remote places where base stations are powered by off-grid diesel generators, the cost gains can make people tolerate such delays. It is akin the Smart Gird, where one of the major changes in the way customers are regarded, is the possibility to ask them to change their behaviors to help the grid (vs. the traditional Power Grid, where the customers' demand must be met at all cost). We actually did some work on how this could be coupled with Renewable Energy generation, and on paper it works really well. It is of course difficult to imagine today in an always-connected world to ask people to WAIT for 30 seconds... Moreover, there are requirements for coverage, so it will not be possible to completely turn off all the infrastructure, even during the night, even if we know there is noone there. But what if we can have a very tiny channel for messaging/signaling, sleep everything around, allow the establishment of calls/connections/requesting a resource, etc., and provide some kind of *WAIT* indication from the network to the end-users/applications, which indicates them that things are being set up and the call will be established in X seconds (or the file/page download will start in that time). In the mean time, the phone at the other end can even start ringing.. I don't think core routers will be put to sleep, but MAYBE there could be more flexibiliy in the system if there is a TRUSTED way to signal to the end-user that things are being prepared and will be ready in a given deadline. And, of course, I'm not really talking about QoS, but probably questions such as net neutrality and the possibility to abuse with these kinds of messages should be studied carefully. Also, sorry if this already exists or was proven to not work at all. Cheers, Alexander [1] S. Gamboa, A. Pelov, P. Maillé, X. Lagrange and N. Montavont, "Reducing the Energy Footprint of Cellular Networks with Delay-Tolerant Users," in IEEE Systems Journal, vol. 11, no. 2, pp. 729-739, June 2017, doi: 10.1109/JSYST.2015.2476376.
- [E-impact] Delay Tolerant Users / Services and Fl… Alexander PELOV
- Re: [E-impact] Delay Tolerant Users / Services an… Michael Richardson
- Re: [E-impact] Delay Tolerant Users / Services an… Toerless Eckert
- Re: [E-impact] Delay Tolerant Users / Services an… Hesham ElBakoury
- Re: [E-impact] Delay Tolerant Users / Services an… Alexander PELOV
- Re: [E-impact] Delay Tolerant Users / Services an… Alexander PELOV
- Re: [E-impact] Delay Tolerant Users / Services an… Hesham ElBakoury
- Re: [E-impact] Delay Tolerant Users / Services an… Alexander PELOV
- Re: [E-impact] Delay Tolerant Users / Services an… Chris Adams
- Re: [E-impact] Delay Tolerant Users / Services an… Hesham ElBakoury
- Re: [E-impact] Delay Tolerant Users / Services an… Toerless Eckert
- Re: [E-impact] Delay Tolerant Users / Services an… Hesham ElBakoury
- Re: [E-impact] Delay Tolerant Users / Services an… Romain Jacob