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

[Hesham ElBakoury <[e-mail]>]

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).

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

Thanks
Hesham







On Sun, Sep 25, 2022, 2:52 AM Michael Welzl <[e-mail]> wrote:

> Hi,
>
> Below:
>
> Sent from my iPhone
>
> On 24 Sep 2022, at 21:07, Hesham ElBakoury <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <
>> [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/ 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/recipe
>>
>