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

Hesham ElBakoury <helbakoury@gmail.com> Sun, 25 September 2022 15:45 UTC

Return-Path: <helbakoury@gmail.com>
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 40919C14CE35 for <recipe@ietfa.amsl.com>; Sun, 25 Sep 2022 08:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.108
X-Spam-Level:
X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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, URI_DOTEDU=1.997] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gJ_natEykWZd for <recipe@ietfa.amsl.com>; Sun, 25 Sep 2022 08:45:25 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 8C97EC14CF1F for <recipe@ietf.org>; Sun, 25 Sep 2022 08:45:25 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id h3so5065207lja.1 for <recipe@ietf.org>; Sun, 25 Sep 2022 08:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=R5jXTZ+6bSqDKZfMGMuXJZTwOWUK2gVBs62vqqw805E=; b=IoY4C3gYD2I73RMQDxQkRbubOw0RlK1g3C5nGrc67cIjj4jnr+GezKIdHJRBkANq9f UjwVsg4AVmFF9brq3RFNeXtMyLScFhMVqXKUiN5t5EtMmrFYH6OkFG97VMsL05rbT+d+ HE0ByVKZIJbxkHIWGgOgcN3mN+H3bywo4UyhfT8fnLwdwvaXgsrNDfEkSjmVF0MCWSTH iyQIfdG+FZfkknR4LY+kv4s2c00XWVe8jLeKZjRgPMoYwX7WOpaj0UTcDwgFRPQAMKjL 7+TjvSAj1vEnwB3BIvetFm3RauajusmiXSyzuWWrcr4b1Ceql2h+NbRxjZv9D3l/Kgpu NaYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=R5jXTZ+6bSqDKZfMGMuXJZTwOWUK2gVBs62vqqw805E=; b=VBiHqlfkwI6G/R6fpY5AqhXpw+oUJ8zQDYjt6lCxkphS+4Dp2fafFIQkEkWK49YF0X DcX9ClD0IHZ5D/o+LKCLpXC2tjVj+xLm5JvINEBQP8BS1Ixz3rrMOSSzAsaVzZcgZlxa M0JG47F2bSKYNSeSirSdsHf7la5q1zerS/D5HswXyO58ReZmxDWhfoe4IhaVe/nVcdnJ yLA7D9LAHojUauVXAW3FIkwTMsRBqIQ/C8cdt5dOnYMtqKpc+Z9+Q/xLLedRbkkW9pr6 B8lmHekir/TBLDFjw0qUuds9qlAlnD8aWwUF3fuVi7k3eiClcaaxaezmfABET1VZNEb2 G4GA==
X-Gm-Message-State: ACrzQf2G8r2j4i1FOihtUohE4sNSxfQxAzaq7hPB5fNJ9apVVNYes+25 B4RwwEvF89nvSzMfPwb7py6/K+PMvBrEv/3+Uub+exI8Djw=
X-Google-Smtp-Source: AMsMyM5q3pBUol2mhelHF2vF+I0YHdwIdfi0nkFiVbfgSwXM4xJHFmcSk1rTtmXdUUV+lVndLogJg0gpLSN7sHo6MZw=
X-Received: by 2002:a2e:98ce:0:b0:26b:e763:27d1 with SMTP id s14-20020a2e98ce000000b0026be76327d1mr5808036ljj.306.1664120722702; Sun, 25 Sep 2022 08:45:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAFvDQ9qcYLDDMqT+8hAqt512spkNjfDRN5305HA0uRt=_JPtcg@mail.gmail.com> <DB87FF4E-582D-4664-A75A-B3AE70FA3A67@ifi.uio.no> <CAFvDQ9rMPs3-7CrATodjyJiyhJZ3EwDB36YMRbgW9_uPT9usBw@mail.gmail.com> <FD2F1594-5490-4D4D-82A6-6135C7CE361C@ifi.uio.no>
In-Reply-To: <FD2F1594-5490-4D4D-82A6-6135C7CE361C@ifi.uio.no>
From: Hesham ElBakoury <helbakoury@gmail.com>
Date: Sun, 25 Sep 2022 08:45:10 -0700
Message-ID: <CAFvDQ9pzVKpJXK9zTWqEk1tB-zpUfA3VnHNODJnT_oSELk6GqQ@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: Toerless Eckert <tte@cs.fau.de>, recipe@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008a481e05e9824cfe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/recipe/7GOnG_N69nEwnafr8qqFCFxCWc4>
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 15:45:30 -0000

Thanks Michael,
I plan to be in London.

We should start looking at the issues that Colin and you mentioned below.
My main focus now is how to get accurate energy measurements.

There are 3 technical problems that affect energy efficiency:

1) Energy proportionality.
2) The end of Moore's Law (although Intel keeps on saying that the law is
still well and alive).
3) Shannon-von Neumann-Landauer (SNL) thermal limit.

There is currently no solution to address #3. Intel and other startups are
looking into innovations to extend the life of Moore's Law.

Over the last few years, a number of techniques have been developed to
address energy proportionality, especially for CPUs (this includes make
server processors more efficient using better manufacturing techniques and
the use of Dynamic Voltage and Frequency Scaling (DVFS) for runtime power
optimization).

I think the biggest threats to mankind are basically more aligned with
selfishness and not caring about others.  Let’s hope communication systems’
ultimate best use is for  people to  learn to cherish one another through
communication - that will solve a lot of problems.

Hesham



On Sun, Sep 25, 2022, 8:16 AM Michael Welzl <michawe@ifi.uio.no> wrote:

>
> On Sep 25, 2022, at 1:29 PM, Hesham ElBakoury <helbakoury@gmail.com>
> wrote:
>
> Hi Mike,
> Of course I know that you are in expert in CC. In fact I have your book "*Network
> Congestion Control -- Managing Internet Traffic". *You may need to update
> it to add new developments in this area (if you did, please let me know
> where I can get the new edition).
>
>
> “Expert", tsk…   :)   but thanks for the kind words!  :-)
> Thanks also for getting my book!!  How nice :)  I hope you liked it!    I
> agree with you that it needs to be updating - by now, it’s way out of date.
> This said, frankly, I don’t want to update it - that would be a LOT of work
> by now!
>
>
> I also attended the presentatipn of your paper* "Is it Really Necessary
> to Go Beyond A Fairness Metric for Next-Generation Congestion Control?" *during
> the anrw session in IETF 114.
>
>
> Oh, nice!  I couldn’t be there myself, though. Are you going to be in
> London?
>
>
> This paper does not mention energy saving,  but I agree with you that
> energy saving could be one of the criteria to select CC algorithm for
> deployment. It can also be used for admission control.
>
> Last time I spoke to Raj Jain about Jain index he told me that the paper
> itself was  rejected and researchers cite the report he published when he
> was in DEC.
>
>
> :-)
>
>
> When I mentioned to Colin the idea of having a RG on Energy Aware
> Networking his response was "lt is impossible to say without knowing more
> details on what would be the goals and research directions for such a
> group, the potential community, and some ideas why hosting such a group in
> the IRTF might add value." I agree with him. If we can address his issues
> we may get support for such RG.
>
>
> Indeed, I agree with this too; we’ll need to do some community building,
> plan a charter that an RG could have … just plan what we want to do.
> I do think that clarifying the importance, by 1) calling out nonsensical
> energy-related statements that have “poisoned the waters”, and 2) trying to
> give a reasonable estimate of what the REAL number is… very very very
> rough, but within reason…   could be good.
>
> For example, from looking at the literature on that topic, I came to the
> conclusion that there’s perhaps useful to focus at the last mile (e.g. WiFi
> APs and such), but this is just an educated guess… a deeper analysis could
> and should be made, IMO.  Also, I like the idea of analysing along the
> lines of what Toerless mentioned - “will the energy efficiency curve become
> linear?”.  Such stuff is good to start with, I’d say.
>
> Cheers,
> Michael
>
>
>
> Thanks
> Hesham
>
>
>
>
>
>
>
> On Sun, Sep 25, 2022, 2:52 AM Michael Welzl <michawe@ifi.uio.no> wrote:
>
>> Hi,
>>
>> Below:
>>
>> Sent from my iPhone
>>
>> On 24 Sep 2022, at 21:07, Hesham ElBakoury <helbakoury@gmail.com> wrote:
>>
>> 
>> I agree that that FCT is the right metric for congestion control. Please
>> refer to Nandita and Nick McKeown 2006 paper
>> https://people.eecs.berkeley.edu/~sylvia/cs268-2019/papers/rcp-ccr.pdf
>>
>> They proposed RCP (Rate Control Protocol) which minimizes FCT. But I am
>> not sure if RCP is deployed in operator networks.
>>
>>
>> Thanks; I know this (cc. is my main background  :-)  )     No I don’t
>> think this is deployed.
>>
>>
>> Minimizing FCT can help reduce energy consumption by maximizing the sleep
>> time of network resources such as routers/switches or their interfaces. The
>> problem is that the activation cost of turning on these resources from a
>> sleep state can be very expensive and time consuming which may disrupt
>> running services. How we can achieve the best balance between FCT and
>> energy consumption without impacting running services?
>>
>>
>> Good question!
>> First, I think we’d need a more general notion of energy cost than just
>> measuring systems x and b. Could we derive a model?
>>
>> I find it interesting to imagine if energy could be a cc metric. How
>> would that have to look, as a useful general metric? (on par with:
>> throughput, fct, packet loss ratio, jain’s fairness index….)
>>
>> an “energy index“?
>>
>>
>> In general there are papers in the literature which study the adaptive
>> network topology problem where network resources are put to sleep to reduce
>> energy consumption. I do not think any of these papers have solutions that
>> operators can deploy in their network. Moreover, operators may not trust
>> software to put network resources to sleep specially in critical parts of
>> their networks.
>>
>>
>> depends….  if this software can save their money?  Also, trade-offs are
>> less likely to be deployable than win-win schemes, or schemes which at
>> least don’t trade performance…
>>
>>
>> It is worth noting that there are papers which look into using
>> optimization techniques (e.g.dynamic programming) in the data center to
>> provide balance between energy consumption and FCT. Here is a recent one
>> https://arxiv.org/pdf/2206.01360
>>
>>
>> Thanks!
>>
>>
>> What IETF can do to address these issues?
>>
>>
>> At this point, IMHO, an RG would be a good idea.
>>
>> Cheers,
>> Michael
>>
>>
>> Thanks
>> Hesham
>>
>> On Sat, Sep 24, 2022, 7:43 AM Michael Welzl <michawe@ifi.uio.no> wrote:
>>
>>> 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/ 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 paper
>>> 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  (or:
>>> 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
>>> 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
>>>
>>> _______________________________________________
>>> recipe mailing list
>>> recipe@ietf.org
>>> https://www.ietf.org/mailman/listinfo/recipe
>>>
>>
>