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

[Hesham ElBakoury <[e-mail]>]

Great to see you engaged Bruce!

You have done good work in the area of energy management in LBL. I still 
recall your IEEE 802.3 tutorials!

One comment below.

Hesham

On 9/25/2022 8:52 PM, Bruce Nordman 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.
>
>   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.
>
>   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>
>
>   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.
>
>   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,
>
*HEB> Recent studies such as this one **The real climate and 
transformative impact of ICT: A critique of estimates, trends, and 
regulations - ScienceDirect 
<https://www.sciencedirect.com/science/article/pii/S2666389921001884>**does 
not show that electronic equipment use 10X what the network equipment 
uses. Are you including E&M devices ? *
>
> so the IETF can make the best contribution by helping to reduce the 
> energy use of hosts.
>
>   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
>
>
>
> On Sun, Sep 25, 2022 at 2:51 PM Toerless Eckert <[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]> 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
>     <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> (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
>     > >>
>     > >
>     > > --
>     > > ---
>     > > [e-mail]
>
>     -- 
>     ---
>     [e-mail]
>
>     _______________________________________________
>     recipe mailing list
>     [e-mail]
>     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