Re: Network Energy Management - research paper

Joel Halpern <jmh.direct@joelhalpern.com> Sat, 06 August 2022 13:49 UTC

Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6167AC157B40 for <ietf@ietfa.amsl.com>; Sat, 6 Aug 2022 06:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Level:
X-Spam-Status: No, score=-2.827 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=joelhalpern.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 oWgv5XzfwifK for <ietf@ietfa.amsl.com>; Sat, 6 Aug 2022 06:48:56 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 3369DC157B44 for <IETF@ietf.org>; Sat, 6 Aug 2022 06:48:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4M0P2H5ZfQz1pNyX; Sat, 6 Aug 2022 06:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1659793735; bh=itc2qAYi6M6IzqEy+ki2UyegTCzdow5Fy42Sdld4NaU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gQYv5seVx31qytaEW7L4GDk2C5rSsYu/xWgaa0u6rbeLz0NPpGHcmd7uzpLqdVOEG ato7FRY8+TGMKfZh3+ZxpfSRnBoOxrgahyugC+Nbr5tzcUFeZ0QPov9e46SRSfedFJ PD4alDAMbiyzodwBm5jeJWn5TI8z7KL0FCXcWEFU=
X-Quarantine-ID: <FSlfmvZaPfru>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.23.181] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4M0P2H1wZ8z1pNkW; Sat, 6 Aug 2022 06:48:55 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------uMGathvp0XqvMN0u6YM2S14E"
Message-ID: <7bb97a18-3301-d560-1efd-a19a8da01b92@joelhalpern.com>
Date: Sat, 06 Aug 2022 09:48:54 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Subject: Re: Network Energy Management - research paper
Content-Language: en-US
To: Hesham ElBakoury <helbakoury@gmail.com>
Cc: IETF <IETF@ietf.org>
References: <8FBAF87A-2690-4543-9713-0F22D1423B8E@gmail.com> <A8687A4E-BA7A-4375-B7E2-C57ADD396842@gmail.com> <CAFvDQ9r-G8O8dzYBvrdzorVHyAE=Edbb7FZkCzrhTzLh98DyAQ@mail.gmail.com> <8f308769-ad04-8f97-7a84-5f98ba27afee@joelhalpern.com> <CAFvDQ9oU-cLeiHRyhyVjabj8K6ENv2PXyRb+5RyTm4TfkheDoA@mail.gmail.com>
From: Joel Halpern <jmh.direct@joelhalpern.com>
In-Reply-To: <CAFvDQ9oU-cLeiHRyhyVjabj8K6ENv2PXyRb+5RyTm4TfkheDoA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9K9ih9lG2DyKwn8pu0rIz5-lEwc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2022 13:49:01 -0000

As a research paper, I can not argue with that.  But as an engineering 
paper, trying to adjust routing based on instantaneous load is a known 
non-starter.  But that is what the paper says it does.  Which strongly 
suggests that this problem space is still not ready for engineering.  (I 
am reminded of the wonderfully elegant work on  compact routing which 
could have reduced our routing table size.  If only the topology would 
stay put.  But it doesn't.)

I am not saying folks shouldn't do research.  they should. Whether such 
research is even ready for the IRTF is a different question I leave to 
researchers and the IRSG.  Whether we even know what questions to be 
asking to try to improve the situation in ways that are relevant to the 
IETF is also a reasonable question.  But not one for engineering.  If 
the IAB thinks it can get a good discussion among people at different 
layers of protocol design and people who actually deal with energy and 
resource tradeoffs, ,to start working on finding the right questions is 
up to them.

Yours,

Joel

On 8/6/2022 1:51 AM, Hesham ElBakoury wrote:
> Hi Joel,
> Why IETF does not have the skill set to define extensions to OSPF to 
> be more energy efficient ? Example of such extensions is described in 
> this recent paper https://arxiv.org/pdf/2207.00035.
>
> Thanks
> Hesham
>
> On Fri, Aug 5, 2022, 4:22 PM Joel Halpern <jmh@joelhalpern.com> wrote:
>
>     I can't speak for Fred, but I don't think we as a community even
>     know what "energy efficient protocol" means.  Much less how that
>     trades off against all the other aspects of protocol design.
>
>     We do consider message size and frequency when we design
>     protocols.  We consider those aspects along with lots of others. 
>     if that is "designing energy efficient protocols" then we already
>     do so.  On the other hand, design for issues such as to to
>     partially wake up a sleeping device is generally outside our remit
>     and skill set.  And is meaningless for many of our devices.
>
>     Yours,
>
>     Joel
>
>     On 8/5/2022 7:18 PM, Hesham ElBakoury wrote:
>>     Hi Fred,
>>     Do you think  IETF engineers have the skill sets to design energy
>>     efficient protocols or enhance existing ones to be more energy
>>     efficient ?
>>
>>     Thanks,
>>     Hesham
>>
>>     On Fri, Aug 5, 2022, 1:22 PM Fred Baker
>>     <fredbaker.ietf@gmail.com> wrote:
>>
>>         Echoing a previous post, I’m not sure sustainability is part
>>         of our skill set. If we were to try to forcibly add it, I
>>         suspect we’d get the same level of response security
>>         originally got: “sustainability is not specified in this
>>         document”.
>>
>>         Sent using a machine that autocorrects in interesting ways...
>>
>>         > On Aug 5, 2022, at 2:26 AM, Stewart Bryant
>>         <stewart.bryant@gmail.com> wrote:
>>         >
>>         > Perhaps it is time for a new mandatory section in RFCs:
>>         sustainability?
>>