From nobody Tue May 16 09:08:10 2023 Return-Path: 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 EBADDC151543 for ; Tue, 16 May 2023 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 fc5fUFK0dG0r for ; Tue, 16 May 2023 09:08:05 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 26652C151988 for ; Tue, 16 May 2023 09:08:05 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-64a9335a8e7so6790023b3a.0 for ; Tue, 16 May 2023 09:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684253284; x=1686845284; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7qLI2QYLjEKlfLJjqXvRceLKpoaP2RLkDlQETkQdARA=; b=UBEafAukQiqTVlmxI8351NFIcoGhC4KJlRVqd9wrcyic8rM/1NiWjRl/4bXGjkl2ki 8EC+3aqWgf4P359mAs1fW3EzF1fRxW5hAvm9dCsFzEhEvzwZMMpIPZE5NZJsU5EjFnPe SLjyVE55QXJsioTGUflSOsciAjPV7rpna65eyN62D9f4NUzoySt8nMg918ab18/6G6Eh l7npag5XINQMRlHdlRk6knOovcoadxnJZmyiejHNQVKHd1gaAdI9XB7vqpQzOZytoqYx NcxnrW3LaFiosi6XfPjPx+tNJECN/0UAYIVqHljVoQpSwoDvDbe2MtySPOkWBccF9Zuz XjAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684253284; x=1686845284; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7qLI2QYLjEKlfLJjqXvRceLKpoaP2RLkDlQETkQdARA=; b=bATEYlCykVf7szlEK/oWmPOdtiqfktSXnpWOd/3QHIzgzrQ8AOO5nHDm/y+hsZ8pQ3 WbC2AIGxU8DtyIVrjP+QQl5GAE6Y6Pz7X+m8glJTGOIzW9hjhzQ1kMdope3TrMa1PYEz NC09KjjlNa5lbeTlW68vSZKzEfPYPRYKcvQ8WxDHLdd23Os8SdeomQ2beOwHywum5GuT HUajD8v+sXwlgIkkH+HEwbZMWm+wRDCrMESCZ3eQ+vpISUJOVWDrivWQd8BG/mKBv+0K mOfA7Am07G5rhG5e+JS8qOEGZRmntPYrP2OikJl1+lZ7/Kwgt5wqedm4I+WZlNNIzxIr DTCQ== X-Gm-Message-State: AC+VfDzacq0fIppTcoU4EItY8JjCAwl6zBKoddwWA2Sao44jOjpF6T6h pvCHUDk3OAlC0vJmrq6G2IZpd1to5hfHblr3Zn0= X-Google-Smtp-Source: ACHHUZ77BVoFXhdPpkPH3uZ9ALLXNdkmX2e5Iull2Wnem/y9QwyQeUZgwL9H8mkla1/Q8P4r+uPSXsueEo5RjG4jNqQ= X-Received: by 2002:a17:90b:1804:b0:24e:2759:8dbe with SMTP id lw4-20020a17090b180400b0024e27598dbemr47701991pjb.7.1684253284159; Tue, 16 May 2023 09:08:04 -0700 (PDT) MIME-Version: 1.0 References: <316EB934-ED4E-4C4E-AB38-C74BA1FC96B7@id3as.co.uk> <4E6A89C6-8345-4E52-B35A-D421CF3AF680@aalto.fi> <4B66DCFE-087B-4574-BA3E-9FCCAC33CD8C@aalto.fi> In-Reply-To: <4B66DCFE-087B-4574-BA3E-9FCCAC33CD8C@aalto.fi> From: Hesham ElBakoury Date: Tue, 16 May 2023 09:07:51 -0700 Message-ID: To: Manner Jukka Cc: Toerless Eckert , Jari Arkko , e-impact@ietf.org Content-Type: multipart/alternative; boundary="000000000000b6d53f05fbd1c6cd" Archived-At: Subject: Re: [E-impact] kWh/GB should be banned and the IETF should warn against its use X-BeenThere: e-impact@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Environmental impacts of the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2023 16:08:09 -0000 --000000000000b6d53f05fbd1c6cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are many publications about energy efficient protocol design for wireless sensor networks. We can benefit from the ideas in these publications when we design protocols for other type of networks. Hesham On Tue, May 16, 2023, 8:46 AM Manner Jukka wrote: > Hi, I agree this is a hard case to solve, but something that needs to be > done, over time. > > Your point about the same solution for constrained/unconstrained networks > is very good, and nicely put. > > My latest works (years ago) were related to NSIS and RSVP, and in > particular in NSIS (as in many other protocols), there was the baseline a= nd > extensions, binary encoded. > > Encoding is one thing, keep-alives and other such continuous signalling i= s > another. > > I could see that there could be a place for a BCP that would discuss > administrative, architectural and configuration topics that could lower a= t > least a little bit the energy consumption and load in the networks. > > br, > Jukka > > > On 16. May 2023, at 17.50, Toerless Eckert wrote: > > > > I hope we would have a hard time finding someone in the community to > disagree > > with these as principles. Alas, once we get to actual ideas what we cou= ld > > still do beyond all that we have already done, work gets a lot harder. > > > > For example, is it really worthwhile for energy saving to ask the whole > > JSON application layer world/standards we have to evolve to CBOR > (binary) ? > > > > I think the energy saving in high-speed networks would be negligible an= d > > likely outweight by the energy spent by the additional IETF efforts > > meeting time, travel, brains involved,... do add CBOR definitions for > > all the existing JSON work. And figure out interop. > > > > On the other hand, we are re-doing many protocols as "low-power" IoT > > protocols after they've already been defined in high-speed networks, > > so we already know (and hate) the drill. And alas, it is not only just > > procedural but constrained networks/nodes/deployments do have additiona= l > > impacts on the protocols. > > > > So, maybe the question would be if we could reduce the amount of > > duplicated work by requiring future non-constraineed protocol work to > also > > be built to support constrained environments from day 1. Which alas > > today means that we need to bring communities within the IETF together > > that so far haveworked often in separate silos. And that may have > different > > goals anyhow. > > > > Aka: This is certainly something that looks for an IETF strategy and/or > > at least experiments. > > > > I bring up this example, because it was also raised several times > > in the IAB workshop - and of course in my own working group we're also > > redoing a lot of work across constrained/unconstrained networks, and > > so i am always pondering if/how we could have done, or can do better > > to avoid duplication ... > > > > Any good recent success stories from other WGs welcome - e.g.: where ha= s > > work that wanted to originally to be done unconstrained also taken > > requirements from constrained networks into account ? > > > > Cheers > > Toerless > > > > On Tue, May 16, 2023 at 11:03:54AM +0300, Jari Arkko wrote: > >> I just wanted to say that I agree with Jukka below: > >> > >>> Fundamentally, if networking equipment would have better scalability > in terms of energy use per traffic and even sleeping modes, the IETF coul= d > at least > >>> > >>> a) look into making protocols and the signalling use less bytes, and > >>> b) not prohibit hardware to go to sleep if no user traffic is being > transmitted. > >>> > >>> For point a, I have not done the analysis, but expect that fy far mos= t > of the protocols are binary encoded, so already almost there. HTTP is not= , > for example. For point b, for example broadcasting and various keep-alive= s > may prohibit sleep modes in hardware. > >>> > >>> This discussion should probably be moved to another thread, and not > discussed under this debate on one metric. > >> > >> (There=E2=80=99s of course some additional things that we do discuss a= s well, > such as measurements/awareness.) > >> > >> Jari > >> > > > >> -- > >> E-impact mailing list > >> E-impact@ietf.org > >> https://www.ietf.org/mailman/listinfo/e-impact > > > > > > -- > > --- > > tte@cs.fau.de > > -- > E-impact mailing list > E-impact@ietf.org > https://www.ietf.org/mailman/listinfo/e-impact > --000000000000b6d53f05fbd1c6cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are many publications about energy efficient protoc= ol design for wireless sensor networks. We can benefit from the ideas in th= ese publications when we design protocols for other type of networks.

Hesham

On Tue, May 16, 2023, 8= :46 AM Manner Jukka <jukka.mann= er@aalto.fi> wrote:
Hi, I ag= ree this is a hard case to solve, but something that needs to be done, over= time.

Your point about the same solution for constrained/unconstrained networks i= s very good, and nicely put.

My latest works (years ago) were related to NSIS and RSVP, and in particula= r in NSIS (as in many other protocols), there was the baseline and extensio= ns, binary encoded.

Encoding is one thing, keep-alives and other such continuous signalling is = another.

I could see that there could be a place for a BCP that would discuss admini= strative, architectural and configuration topics that could lower at least = a little bit the energy consumption and load in the networks.

br,
Jukka

> On 16. May 2023, at 17.50, Toerless Eckert <tte@cs.fau.de> wrote:=
>
> I hope we would have a hard time finding someone in the community to d= isagree
> with these as principles. Alas, once we get to actual ideas what we co= uld
> still do beyond all that we have already done, work gets a lot harder.=
>
> For example, is it really worthwhile for energy saving to ask the whol= e
> JSON application layer world/standards we have to evolve to CBOR (bina= ry) ?
>
> I think the energy saving in high-speed networks would be negligible a= nd
> likely outweight by the energy spent by the additional IETF efforts > meeting time, travel, brains involved,... do add CBOR definitions for<= br> > all the existing JSON work. And figure out interop.
>
> On the other hand, we are re-doing many protocols as "low-power&q= uot; IoT
> protocols after they've already been defined in high-speed network= s,
> so we already know (and hate) the drill. And alas, it is not only just=
> procedural but constrained networks/nodes/deployments do have addition= al
> impacts on the protocols.
>
> So, maybe the question would be if we could reduce the amount of
> duplicated work by requiring future non-constraineed protocol work to = also
> be built to support constrained environments from day 1. Which alas > today means that we need to bring communities within the IETF together=
> that so far haveworked often in separate silos. And that may have diff= erent
> goals anyhow.
>
> Aka: This is certainly something that looks for an IETF strategy and/o= r
> at least experiments.
>
> I bring up this example, because it was also raised several times
> in the IAB workshop - and of course in my own working group we're = also
> redoing a lot of work across constrained/unconstrained networks, and > so i am always pondering if/how we could have done, or can do better > to avoid duplication ...
>
> Any good recent success stories from other WGs welcome - e.g.: where h= as
> work that wanted to originally to be done unconstrained also taken
> requirements from constrained networks into account ?
>
> Cheers
>=C2=A0 =C2=A0 Toerless
>
> On Tue, May 16, 2023 at 11:03:54AM +0300, Jari Arkko wrote:
>> I just wanted to say that I agree with Jukka below:
>>
>>> Fundamentally, if networking equipment would have better scala= bility in terms of energy use per traffic and even sleeping modes, the IETF= could at least
>>>
>>> a) look into making protocols and the signalling use less byte= s, and
>>> b) not prohibit hardware to go to sleep if no user traffic is = being transmitted.
>>>
>>> For point a, I have not done the analysis, but expect that fy = far most of the protocols are binary encoded, so already almost there. HTTP= is not, for example. For point b, for example broadcasting and various kee= p-alives may prohibit sleep modes in hardware.
>>>
>>> This discussion should probably be moved to another thread, an= d not discussed under this debate on one metric.
>>
>> (There=E2=80=99s of course some additional things that we do discu= ss as well, such as measurements/awareness.)
>>
>> Jari
>>
>
>> --
>> E-impact mailing list
>> E-impact@ietf.org
>> https://www.ietf.org/mailman/listi= nfo/e-impact
>
>
> --
> ---
> = tte@cs.fau.de

--
E-impact mailing list
E= -impact@ietf.org
https://www.ietf.org/mailman/listinfo/e-imp= act
--000000000000b6d53f05fbd1c6cd--