Re: Network Energy Management - research paper

Hesham ElBakoury <helbakoury@gmail.com> Sat, 06 August 2022 15:42 UTC

Return-Path: <helbakoury@gmail.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 57587C157B39 for <ietf@ietfa.amsl.com>; Sat, 6 Aug 2022 08:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=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, 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=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 WWOoFW25UjAt for <ietf@ietfa.amsl.com>; Sat, 6 Aug 2022 08:42:25 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 65E95C14CF06 for <IETF@ietf.org>; Sat, 6 Aug 2022 08:42:25 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id b21so3888854qte.12 for <IETF@ietf.org>; Sat, 06 Aug 2022 08:42:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fnfkuX+LoxGRvIvhbPiRl6E4K1rDxJPLMb0IgyRbxvQ=; b=n/yGlZhgIfX6CuPkMcdFCUvdEKzMQAmc2ViwCrWDyIOXRItPidf7EcMab3ZxmXwPJQ O63+2kT9e4aalgRkee6CZZC8MMmEHKgayu1j6ifKue1G9IDqfDQAXSeWj9wkvYvI5NMO pn1poMBV5jStSZP5VEgV6JN8aD7nHZmJjPsK1/c86LKj9ap3EFQJ7iOGCa39gHADZO6z 8ggoLCYcjFO/OHsE6UhAYpPDfI6AitCg4k9OXQx449V+999g7fT87JYoubMWpjiZXwoy tE3r5GGlFIkAArHYLwBMp5m7DKPw68uEktcIiDR6PTyKJwRh1ihQGU50qJ5ZTX87QfQi E2nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fnfkuX+LoxGRvIvhbPiRl6E4K1rDxJPLMb0IgyRbxvQ=; b=Tb5XOnGAfmmBzfqo0vBUds60GiRp2ibma14SdHb+V85HQjBfyckmkev9xM4cZ+fwn5 1+ykioyJOIkXJbOYrVorTg04eruO62CtQUb0HiOQ6YX+rMD6svC1cjJpiOhKxirClvya OG6I4FCNgfREE4HAeXLwP4EdU3X75c343cKL965fezjcVFYxkjNpKH9Dj85tYAJIWSKZ eao7V2ZlPRyGLNK2k9ox5oo/NIXQYomEe1IW1BAzUBCmTRXpvC1nQKUoz+oE7bCeS71O RKcfoAXQhipRsM59MVIHIotIb6EC86uGuUWIVhBfnfjWYLaqyVJOGnyanrfYgWrDjtby BFXQ==
X-Gm-Message-State: ACgBeo26GwhEQEzn4AKc2GIYuAZ14m6hqPKvht1TVG3hNxmKYGOuYoDv esBVmtQh5e/0gkFimbUh/YoCPU0qNTvMq9uJLnJrZxJa
X-Google-Smtp-Source: AA6agR5z9wOzSlsGhyVQPB5Dt/TpQcG+sxhAbciEYx/H76LsDlRhPsYsivXV11VA32qZv1dz6CKWyoaHnDjvIusMThs=
X-Received: by 2002:ac8:5dcd:0:b0:31f:4cbc:d9e4 with SMTP id e13-20020ac85dcd000000b0031f4cbcd9e4mr9704178qtx.615.1659800544280; Sat, 06 Aug 2022 08:42:24 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <7bb97a18-3301-d560-1efd-a19a8da01b92@joelhalpern.com>
From: Hesham ElBakoury <helbakoury@gmail.com>
Date: Sat, 06 Aug 2022 08:42:10 -0700
Message-ID: <CAFvDQ9oP1fN_JctTFM8g5nix1Hzr_d-053oRCQKMmxvmu1foEw@mail.gmail.com>
Subject: Re: Network Energy Management - research paper
To: Joel Halpern <jmh.direct@joelhalpern.com>
Cc: IETF <IETF@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7037305e5946d37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NO4C3jouTEw0kAdKaGlKWLzyVoM>
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 15:42:29 -0000

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>
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.
>
> 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?
>>>
>>>