Re: [recipe] FYI: [admin-discuss] REMINDER: IETF carbon emission measurement workshops on 20 and 21 September

Toerless Eckert <tte@cs.fau.de> Sun, 25 September 2022 21:51 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: recipe@ietfa.amsl.com
Delivered-To: recipe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20FCC1522A1 for <recipe@ietfa.amsl.com>; Sun, 25 Sep 2022 14:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 HKjtTTLfPNfx for <recipe@ietfa.amsl.com>; Sun, 25 Sep 2022 14:51:17 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (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 3BEBBC14CE43 for <recipe@ietf.org>; Sun, 25 Sep 2022 14:51:16 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 0A3AB548500; Sun, 25 Sep 2022 23:51:09 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id E4E134EBB4F; Sun, 25 Sep 2022 23:51:08 +0200 (CEST)
Date: Sun, 25 Sep 2022 23:51:08 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: Cedric Westphal <cedric.westphal@futurewei.com>, recipe@ietf.org
Message-ID: <YzDNTByMvA9tsE5c@faui48e.informatik.uni-erlangen.de>
References: <Yy87opj7tkqfd85I@faui48e.informatik.uni-erlangen.de> <D3A1335A-022C-4F1F-BCCC-3160B1D3BB7C@ifi.uio.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D3A1335A-022C-4F1F-BCCC-3160B1D3BB7C@ifi.uio.no>
Archived-At: <https://mailarchive.ietf.org/arch/msg/recipe/H6mS9j6JKzE8pYDAJhuIe_IpEOs>
Subject: Re: [recipe] FYI: [admin-discuss] REMINDER: IETF carbon emission measurement workshops on 20 and 21 September
X-BeenThere: recipe@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RECIPE \(Reducing Energy Consumption with Internet Protocols Exploration\)" <recipe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/recipe>, <mailto:recipe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/recipe/>
List-Post: <mailto:recipe@ietf.org>
List-Help: <mailto:recipe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2022 21:51:22 -0000

On Sun, Sep 25, 2022 at 11:57:44AM +0200, Michael Welzl wrote:
> > So my
> > primary question is: are there any "natural" limits in linearizing this curve ? Then as a pessimist,
> > i would love to design / evaluate against those limits instead of against the inferior hardware we have
> > today. Especially because i only need to look at mobile device HW/CPU to see that there is a
> > lot of room for improvement (AFAIK).
> 
> I guess this is about evaluating the cost of sleep/awake transitioning over the years…  how has this evolved, will it become miniscule?

Indeed. I am just worried that it do not know that it will not become miniscule, which
makes me somewhat worried into promoting investing into solutions that depend on it
not being miniscule. After all, we have past experiences with betting investments into
assumptions that turned out to be changed inparallel, rendering the investments mostly void.

Aka: Would love to see, if research can also come up with predictions about this factor
(non minisculity of transitioning, if that's even a word ;-)

Cheers
   Toerless

> Cheers, Michael
> 
> > 
> > Cheers
> >    Toerless
> > 
> >> Cedric:
> >> 
> >>>> On Sep 22, 2022, at 11:53 PM, Cedric Westphal <cedric.westphal@futurewei.com> wrote:
> >>> 
> >>> HI Michael & Toerless:
> >>> 
> >>> Michael: thank you very much for the data points.
> >>> 
> >>> Regarding your paper: I really like the idea that protocols can help saving energies. When we wrote our draft https://datatracker.ietf.org/doc/draft-cx-green-ps/ <https://datatracker.ietf.org/doc/draft-cx-green-ps/> we were a bit disappointed that the protocol side of things didn’t have great opportunities for reducing energy consumption – aside of course of facilitating sleep modes as you suggest in your paper. If you have a chance to read it, we would welcome your comments. I’m currently updating it for London.
> >> 
> >> I did read the draft, but didn’t have any comments. I did find it interesting though!  I’ll be in London too, btw, and I’ll give a brief presentation on the relationship between energy saving and congestion control (just the simple result from my paper) to ICCRG there. I think there are plenty of opportunities in protocols - they just need to be worked out, evaluated, …   I mean, you point out some interesting opportunities in your own draft.
> >> 
> >> 
> >>> Your paper seem to argue that short/high bandwidth transmissions are better than longer/slower ones – we wrote something like this in our paperhttps://scholar.google.com/citations?view_op=view_citation&citation_for_view=5WcgOxMAAAAJ:rJyh6hJnyfgC <https://scholar.google.com/citations?view_op=view_citation&citation_for_view=5WcgOxMAAAAJ:rJyh6hJnyfgC> (upon which the draft is based on) and we got some pushback to the extent that: short/fast = burstiness = high buffers = packet loss = re-transmissions.
> >> 
> >> Thanks, i’ll read this.
> >> Regarding bursts, I think we shouldn’t think about “bursts” and even use a different word. Bulk? “Send data in bulk” as opposed to "sending a burst”?
> >> 
> >> This is an important distinction because data in bulk can (and probably should) still be paced - we really shouldn’t be sending bursts if we can avoid them. What I mean is something like sending 100 paced packets in 1 RTT instead of 10 packets per RTT over 10 RTTs.  In fact, the Internet does the latter kind of transmission often enough. Given typical flow lengths and growing capacities, the primary role of congestion control in today’s Internet seems to be to waste our time with round-trips (before transmissions are over).   Some hints about this:  https://ieeexplore.ieee.org/document/9817041 <https://ieeexplore.ieee.org/document/9817041>  (or: http://arxiv.org/abs/2206.06642 <http://arxiv.org/abs/2206.06642> ) … and references therein, e.g. https://dl.acm.org/doi/10.1145/3472305.3472321
> >> 
> >> 
> >>> I checked the spreadsheet on the other paper – they haven’t been updated.
> >> 
> >> I did the same!  Disappointing, isn’t it.
> >> 
> >> 
> >>> It’s a strange paper, that makes a lot of assumption regarding energy consumption, but you have to start somewhere. I’m surprised you’re saying there hasn’t been follow up to that, it’s such an important topic.
> >> 
> >> I don’t think I said that? There are plenty of studies out there, but … it’s a jungle.
> >> 
> >> 
> >>> I definitely will add some paragraph or section on “emergy” in the next version of the draft.
> >>> 
> >>> This paper evaluates the emissions from virtual conferences – to keep in mind when comparing with IETF emissions from combined hybrid/in-person conference:https://forum.legacy-events.com/uploads/short-url/zmI7aFu6X6ojBESqz9IWKke4GW4.pdf <https://forum.legacy-events.com/uploads/short-url/zmI7aFu6X6ojBESqz9IWKke4GW4.pdf>
> >>> This paper assesses the value of in-person vs virtual to be 66 times higher from the travel alone (but that’s 99% of the in-person energy cost!)
> >> 
> >> Thanks!
> >> 
> >>> 
> >>> Toerless: was that paper cited at the workshop???
> >>> 
> >>> Best,
> >>> 
> >>> C. 
> >> 
> >> 
> >> Cheers,
> >> Michael
> >> 
> > 
> > -- 
> > ---
> > tte@cs.fau.de

-- 
---
tte@cs.fau.de