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

[Bruce Nordman <[e-mail]>]

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, 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
> <
> 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