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

Michael Welzl <michawe@ifi.uio.no> Sat, 24 September 2022 14:43 UTC

Return-Path: <michawe@ifi.uio.no>
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 0A7FDC152579 for <recipe@ietfa.amsl.com>; Sat, 24 Sep 2022 07:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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
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 YUIdJAKINLU3 for <recipe@ietfa.amsl.com>; Sat, 24 Sep 2022 07:43:32 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 21632C14F612 for <recipe@ietf.org>; Sat, 24 Sep 2022 07:43:31 -0700 (PDT)
Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <michawe@ifi.uio.no>) id 1oc6NJ-000giN-8u; Sat, 24 Sep 2022 16:43:25 +0200
Received: from [185.176.244.72] (helo=smtpclient.apple) by mail-mx05.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.95) (envelope-from <michawe@ifi.uio.no>) id 1oc6NH-000EW9-Uh; Sat, 24 Sep 2022 16:43:25 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <A61FAA0A-20B6-4C77-B78C-B320CABB321B@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1ED1D673-CF8E-420C-9103-2BA18977D45C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Sat, 24 Sep 2022 16:43:23 +0200
In-Reply-To: <Yyykn/QtPqCohiOp@faui48e.informatik.uni-erlangen.de>
Cc: Cedric Westphal <cedric.westphal@futurewei.com>, "recipe@ietf.org" <recipe@ietf.org>
To: Toerless Eckert <tte@cs.fau.de>
References: <YynVI79e1yOgqjOo@faui48e.informatik.uni-erlangen.de> <FB2BDEC9-8E07-44ED-B53E-CFF58BC9FAE9@ifi.uio.no> <YynbBRBOwZd0pcgo@faui48e.informatik.uni-erlangen.de> <SN4PR13MB5811E6CCFE475BD1345AD2C2FF4C9@SN4PR13MB5811.namprd13.prod.outlook.com> <YyoYS3WhpuMd3T/w@faui48e.informatik.uni-erlangen.de> <BC48ED92-9D74-4BE2-A22A-0A1B6B01D32D@ifi.uio.no> <Yyykn/QtPqCohiOp@faui48e.informatik.uni-erlangen.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 185.176.244.72 is neither permitted nor denied by domain of ifi.uio.no) client-ip=185.176.244.72; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=-0.106, HTML_MESSAGE=0.001, UIO_HTTP=0.2, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 722A3B5B12BEC1413974C80FC422E8E4041FB20D
X-UiOonly: C8BEB126B8015480805E69A12C2EC750DED79450
Archived-At: <https://mailarchive.ietf.org/arch/msg/recipe/7vfkLjZ0lghFyM5T7g2-HD2si9k>
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: Sat, 24 Sep 2022 14:43:37 -0000

Hi !

I’m answering to both Toerless and Cedric in one email here.

Toerless:

> On Sep 22, 2022, at 8:08 PM, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> Michael:
> 
> There where unfortunately only very few folks attending the IETF LLC admin meeting here
> the current IETF plan to simply start to estimate the IETF meetings CO2/greenhouse-emissions
> was presented. But it did look like a good first small step on a long road.
> 
> For something like IETF meetings the next logical step IMHO is to discuss if or how there
> is a benefit in some form of carbon offsetting. I think they've planned that as a next step.
> I'd certainly like to learn more about that option because all i've read so far about it
> is that most carbon offsetting seems to look fairly problematic to me. But maybe there are
> some good options.

Sure, such things is a useful thing to discuss - but still, to me, it may only be a drop in the bucket compared to the potential that the IETF has when it comes to reducing energy for the Internet.
Whether the Internet truly makes up half, 1/4, even 1/10 of the aviation industry’s GHG emissions… just imagine the potential impact if we manage to even only reduce its energy by a small amount, but at a global scale!


> On the admin-discuss mailing list there was also an interesting pointer to a european
> conference recommendations how to minimize carbon emissions for meetings. It looked
> pretty good except that it didn't put different options into perspective. E.g.: it said
> that reduccing video conference resolution from HD/4k to SD would reduce up to (forgot, e.g.:)
> 70% energy consumption. Which i think may be true that lets say some 5% of the total
> video stream network required energy might be changing based on resolution, even the whole
> 100% of the network/end-user energy requirements. Which in itself would likely be just a small
> portion of the energy of in-person meeting. In my draft-eckert-ietf-and-energy-overview,
> i cited https://www.sciencedirect.com/science/article/pii/ S0140366414000620 which is a bit
> old by now (aka: energy consumption of video likely having gone down already due to lower energy
> per bit now), but still a good example of a comparative approach.

I would be against trading quality of online meetings: as you say, this is a tiny portion of the energy of in-person meeting … so it’s probably more important to ensure the best possible online experience.
I think we shouldn’t focus on trade-offs too much. There are ways to reduce energy that do not embed a trade-off, and in some cases it can even be a win-win (shorter FCT = more sleep time for devices).

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