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

[Michael Welzl <[e-mail]>]

Such an interesting discussion!


> On Sep 26, 2022, at 5:52 AM, Bruce Nordman <[e-mail]> wrote:
> 
> All--
>   I think thinking about the carbon consequence of IETF meetings is a useful thought exercise, but the amount of energy potentially leveraged by IETF RFCs is orders of magnitude larger and so should be the follow-on, and much more in depth, exercise. I will stay out of the carbon offset question.

+1


>   The phrase ‘energy use of the Internet’ really makes no sense. I think that when people use this they really mean one of a variety of other questions. These include some combination of:
> -A: Energy use of network equipment
> -B: Energy use servers dedicated to web serving (directly or indirectly).
> -C: Energy use of network equipment and telecom infrastructure
> -D: Energy use of electronics with an IP connection
> -E: Energy use of any device with an IP connection
> E is the most silly since it includes things like water heaters and many automobiles, but regardless, I think it is most helpful to focus on A as what is most central to the Internet.

True.


>   The last time I waded into this territory quantitatively, was 2014 - with data mostly from about 2010: Light at the end of the tunnel for electronics energy use? <https://www.aceee.org/files/proceedings/2014/data/papers/9-889.pdf> Before that: Network equipment energy use - U.S. total estimate for 2008 <https://drive.google.com/open?id=0B8B9XW6B7prlR0x3N0JaZ3pCMDg>
Thanks for these pointers!  So much reading material… my list is growing and growing... but it’s all very interesting!


>   Estimates of energy/carbon often collide head-on into the average vs marginal question. My home network equipment is needed for me to send this email, but it is on 24/7 regardless of what I do - and even if I am home. Any incremental use for incremental traffic is tiny in annual energy use. Sometimes it is appropriate to use average, but I think more often marginal is more appropriate to decisions that could be made using the data.  

Let’s see if I understand this correctly: by “marginal”, do you mean the power used by the equipment when you’re not at home?  Don’t devices sleep, at least after some time?  Is the power in sleep mode so high over these long time periods (e.g., while we’re in the office, in daytime… or while we sleep) that this is really significant?  Either way, I have a feeling that there’s not much the IETF can do about this.


>   Jon Koomey was mentioned - I have worked with him (sporadically) for over 25 years - also with Eric Masanet.
>   For comparing network eqt. energy use to aviation, think of health care. Certainly cancer and heart disease are huge problems in industrialized countries and deserve a lot of attention, but that doesn’t mean that diseases that harm fewer people don’t also deserve some. We need to work on all topics, but in proportion to how much progress is achievable. We have expertise in certain areas so should focus on that.
>   In rough terms, electronics connected to the Internet use about 10x what network equipment uses, so the IETF can make the best contribution by helping to reduce the energy use of hosts.

I didn’t know about the factor 10, but considering the main finding of this paper: ttps://onlinelibrary.wiley.com/doi/10.1111/jiec.12630 <ttps://onlinelibrary.wiley.com/doi/10.1111/jiec.12630>  and some other things I came across, including this often-cited paper which makes *extreme* predictions (I have trouble believing them… but then predictions are what they are … just guesswork, really):  https://www.mdpi.com/2078-1547/6/1/117 <https://www.mdpi.com/2078-1547/6/1/117>   … I also got the impression that the edge is where most of the gains can be achieved.

It would be interesting to know the relationship in terms of energy usage between hosts, WiFi APs, and cellular equipment. Is it really just hosts where we should reduce energy usage?


>   I should engage with the ID underway.
>   I am happy to get individual emails in addition to reading this list.
>   My work of late has shifted to coordinating energy use and buildings with variable renewable supply on the grid - or microgrid operation. This and the use of Direct Current power.
>   Thanks.
> --Bruce

Cheers,
Michael


> 
> 
> On Sun, Sep 25, 2022 at 2:51 PM Toerless Eckert <[e-mail] <mailto:[e-mail]>> wrote:
> 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 <[e-mail] <mailto:[e-mail]>> 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/> <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 <http://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 <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> <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> <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 <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> <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
> > >> 
> > > 
> > > -- 
> > > ---
> > > [e-mail] <mailto:[e-mail]>
> 
> -- 
> ---
> [e-mail] <mailto:[e-mail]>
> 
> _______________________________________________
> recipe mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/recipe <https://www.ietf.org/mailman/listinfo/recipe>
> 
> 
> -- 
> Bruce Nordman
> Lawrence Berkeley National Laboratory
> nordman.lbl.gov <http://nordman.lbl.gov/>
> [e-mail]
> 510-486-7089; m: 510-501-7943
> _______________________________________________
> recipe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/recipe