Re: Network Energy Management - research paper

Simon Pietro Romano <spromano@unina.it> Tue, 09 August 2022 16:40 UTC

Return-Path: <spromano@unina.it>
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 8E5F7C14F720 for <ietf@ietfa.amsl.com>; Tue, 9 Aug 2022 09:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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
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 8S6UUlIhqRz8 for <ietf@ietfa.amsl.com>; Tue, 9 Aug 2022 09:40:09 -0700 (PDT)
Received: from leas1.unina.it (fmvip.unina.it [192.132.34.7]) (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 EA945C14F719 for <IETF@ietf.org>; Tue, 9 Aug 2022 09:40:08 -0700 (PDT)
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by leas1.unina.it with ESMTP id 279Ge383021816-279Ge385021816 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=CAFAIL); Tue, 9 Aug 2022 18:40:03 +0200
Received: from smtpclient.apple (2-237-150-174.ip239.fastwebnet.it [2.237.150.174]) (authenticated bits=0) by smtp2.unina.it (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 279GeFmf2001486 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Aug 2022 18:40:18 +0200
From: Simon Pietro Romano <spromano@unina.it>
Message-Id: <5E3726A6-69DC-4667-AD4E-3F603F2E7552@unina.it>
Content-Type: multipart/signed; boundary="Apple-Mail=_93DBB25A-4605-4B98-BAF1-A436C3C1C7B8"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: Network Energy Management - research paper
Date: Tue, 09 Aug 2022 18:39:57 +0200
In-Reply-To: <CAFvDQ9oP1fN_JctTFM8g5nix1Hzr_d-053oRCQKMmxvmu1foEw@mail.gmail.com>
Cc: Joel Halpern <jmh.direct@joelhalpern.com>, IETF <IETF@ietf.org>
To: Hesham ElBakoury <helbakoury@gmail.com>
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> <7bb97a18-3301-d560-1efd-a19a8da01b92@joelhalpern.com> <CAFvDQ9oP1fN_JctTFM8g5nix1Hzr_d-053oRCQKMmxvmu1foEw@mail.gmail.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-Virus-Scanned: clamav-milter 0.103.6 at smtp2.unina.it
X-Virus-Status: Clean
Authentication-Results: leas1.unina.it; spf=pass (unina.it: domain of spromano@unina.it designates 192.132.34.62 as permitted sender) smtp.mailfrom=spromano@unina.it
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nuDq7xtkMswHn3fXbvvKs82cdJE>
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: Tue, 09 Aug 2022 16:40:14 -0000

Hello everyone,

I just discovered that this IETF thread was mentioning a paper of mine from a few years ago, whose official reference is here:

https://www.sciencedirect.com/science/article/abs/pii/S1084804516300662

As usual, also for the mentioned GOSPF proposal we made running code available for people who wanted to play with it (https://wpage.unina.it/spromano/gospf/). It was based on the beautiful Quagga suite and I am afraid it would need some tweaking in order to work with the current releases of the software.

> Also note that the coauthor of this paper is Professor Simon Pietro Romano who is the cofounder of Meetecho.  He acively participates in IETF standardization activities.

I can proudly confirm that! Even though I have to admit I have not always been so lucky with my proposals. Recently I struggled a lot, e.g., with a proposal for multipath in QUIC, which was strongly bounced back by the community (this was a couple of years before multipath QUIC became latest fashion at the IETF, unfortunately). This just to tell you, Hesham, that I often work as a good "counter-example” IETF-wise :-))

Cheers,

Simon







							_\\|//_
                          				   ( O-O )
     ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                   				Simon Pietro Romano
            				 Universita' di Napoli Federico II
               		     Computer Engineering Department
	             			     Phone: +39 081 7683823
                                          e-mail: spromano@unina.it

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
              			                     oooO
      ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                      (_/

> Il giorno 6 ago 2022, alle ore 17:42, Hesham ElBakoury <helbakoury@gmail.com> ha scritto:
> 
> Thank Joel!
> The approach used by this paper is an engineering approach.  The paper says "The al-gorithm we devised represents our engineering approach to the solution of the well known (though still open) issue of dynamic network topology adaptation to improve energy efficiency."
> 
> Also note that the coauthor of this paper is Professor Simon Pietro Romano who is the cofounder of Meetecho.  He acively participates in IETF standardization activities.
> 
> I think IETF has very smart people; some has relevant skill set, knowledge and expertise to look at infrastructure energy efficiency problems.
> 
> As you mentioned, the issue is to find a problem that needs to be solved and the solution should be standardized for customers to deploy it. We can argue whether the solution described in this paper for the well-known infrastructure energy and QoS management problem should be standardized or not.  But if it needs to be standardized, I think IETF already has and can bring in the right experts to do the standardization work.
> 
> I think Jari's workshop on energy management is a good start to brainstorm what IETF can do to address energy management problems in IP networks. Jari also mentioned during IETF 114 NMRG meeting that IETF should work on energy management.
> 
> Thanks
> Hesham
> 
> 
> On Sat, Aug 6, 2022, 6:48 AM Joel Halpern <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>> wrote:
> 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 <https://arxiv.org/pdf/2207.00035>.
>> 
>> Thanks
>> Hesham
>> 
>> On Fri, Aug 5, 2022, 4:22 PM Joel Halpern <jmh@joelhalpern.com <mailto: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 <mailto: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 <mailto:stewart.bryant@gmail.com>> wrote:
>>> >
>>> > Perhaps it is time for a new mandatory section in RFCs: sustainability?
>>>