Re: Greening of Streaming

Hey Neil - a few notes inline :)

-- 
Dom Robinson
www.id3as.co.uk <http://www.id3as.co.uk/> 
www.greeningofstreaming.org <http://www.greeningofstreaming.org/> 
uk.linkedin.com/in/domrobinson <http://uk.linkedin.com/in/domrobinson>
Meet >> https://calendly.com/id3as 

> On 13 Nov 2023, at 17:21, Neil Clark <neil.clark@tpximpact.com> wrote:
> 
> Hey Dom and Frédéric, 
> 
> Sorry about being late to this email string! 
> 
> I am very far from a data centre or networks expert so I am trying to come at this from the perspective of explaining it to others in a similar position to me whilst also trying to encourage action on emissions reduction. So here goes a few points which I would love your opinion on. I'm not trying to disagree with anything said so far on this thread, I just want to highlight some of the nuances in the debate because I do think reducing data transfer is a good thing when looking at how to reduce the impact the digital industry has on the planet. 
> If we reduced a website's homepage from say 3MB to 500KB, that will not directly reduce emissions in the network because the overall energy needed to pump data around the internet will not be affected by that reduction; the various pieces of hardware will still be turned on regardless of whether that reduction occurs or not. This might be overly simplistic, but is that broadly true?
I personally think so, and we have already started to gather quite a lot of data looking at this space and it seems to be the case in CDN and telco / operator outside of wireless access.
> Depending on how we achieved that reduction (e.g. image compression, removal of JS etc), can we be confident that we will have reduced battery drain or power usage on the person's device? If we really want to push this point, we could think about how that helps elongate the life of devices? By that I mean, reducing the strain on devices to download and execute excessive code will help them last longer. 
In my world (streaming) we are exploring the effect of codec choices / configuration / delivery as a whole. This is application space stuff that parallels browser / CPU cycles decompressing images or otherwise processing. We are very aware that changing codec can in some cases move video decompression from GPU to CPU and have a 10x? immediate power difference. Certain decisions between GPU / CPU (and DSP / ASIC etc) can make big differences. These are not really bitrate related though. Obviously the quantity of data you might be processing might mean sustained drains in energy - i would venture that this is a difference between monitoring Watts and kWh over time. but thats a detail. Yes it will all affect battery life. 
> I've seen it mentioned before that the thing that increases emissions in the network is when new hardware has to be deployed to cope with high peak loads. Given that page weight has increased 77% on desktop and 149% on mobile <https://httparchive.org/reports/page-weight?start=2015_12_01&end=latest&view=list>, do you think that this level of increase has played a part in increasing that peak load? To ask it another way, perhaps more provocatively, if there had been significant decreases to the average page weight, do you think network emissions would have reduced as a consequence? The IEA says: Estimated global data centre electricity consumption in 2022 was 240-340 TWh, or around 1-1.3% of global final electricity demand, which is a 10-55% increase from 2015. 


From https://www.vox.com/2017/6/8/15757594/future-internet-traffic-watch-live-video-facebook-google-netflix (a quick search - and the figures vary a lot) but i think while every attempt to introduce energy savings matters, the proportion of traffic by type comes in to bear. A 50% increase in page weight might be 9% of web traffic in 2016 and 5.5% in 2021 looking at those, so while there may be gains to be won, a 50% saving in video may impact network scaling by 25-33%. I don’t mean to pit streaming vs web here: just to make sure that we need to focus on the big wins in the right places. IF energy and traffic volumetric do emerge to show correlation - still ’to do’ - then a focus on the larger traffic by volume might bring about bigger wins.

As for theIEA figures also quite similar energy volumes for Telco - these much be added in. the numbers we work to are 6-8% ICT as a whole, and this number contains ~2% DC and ~2.5% telco (yes its actually a little more)  - this means the DC and network are about 4-4.5% of global final electricity and the remaining 2.5 to 4.5% is the rest of ICT (phones / smart TV / laptop / on=premises servers etc). 

So electricity wise if web at 11% o’Global IP traffic’ from charts like ciscos then that is perhaps 11% of (DC 2%+telco 2.5% ) = ~0.5% Internet demand for Electricity. Video is by same extrapolation 67% of DC 2%+telco 2.5% = ~3%.  Plus all the CPE devices - hard to really suggest that 67% of the CPE is dedicated to video. We are conducting a large field experiment to try to get some real work done measure against some of these wildly extrapolated figures. 

The important thing is a sense of order of magnitude about where to focus. Its clear infrastructure is scaling to support video first and foremost. A large video spike will dwarf even the largest page load hits. So the peak capacity planning of the networks (where the TWh really gets committed) is very much looking at those video peaks and large game / software updates. The web data isn’t really impacting the spikes that cause the capacity to be enlarged.

Also the core infrastructure is on 24/7 - this is an observation that many miss. A webpage user can attribute energy to their actions for microseconds. A video user for a few hours. But the actual energy being consumed in making the service available is being consumed 24/7 - when you add up all that availability it is usually much more than the time spent actually browsing / streaming by end users. But that availability-energy is rarely if at all every included in any research… 

In my opinion MOST of the energy is used in offering SLAs rather than transmission of used data.. but the experiments we are undertaking will test that hypothesis..
 
> I've also seen papers where the conclusion is that network devices increase their power consumption by a tiny fraction when data transfer through them increases (this might be out of date thinking if that latest research says that there is no increase at all?). A conclusion that some have drawn is that website page size therefore doesn't matter when thinking about the emissions caused by websites. But with a tiny fraction of power increases based on data passing through the network, a 60% increase in internet users and those users consuming increasingly large websites/software, could data transfer/file size be an important factor alongside aggressively blocking bots, carbon aware computing, genuine renewable energy powered data centres, minimising data centre footprint etc etc? 

The dynamic network intensity variation that can be measured on an unloaded router and a fully loaded router is a tiny fraction of the baseload. So tiny that in most practical tests its almost impossible to measure.

> I know that jumps around a lot but I think this is such an important debate; maybe a call is best for this!? I don't want it to be simplified down to "data transfer doesn't matter" and equally I don't want to use an overly simplified approach to calculations based on data transfer alone. 
> 

> I think there are lots of solutions to the impact of the digital industry and, whilst I want to be realistic about the scale of it's impact, I really think the weight of the code we're producing as an industry is a vital part of the puzzle. I feel a bit uneasy about drawing attention to the production of devices like TVs because that isn't in the sphere of influence of the software industry. Yes it's important to debate but I want us to focus on what we're sending to those devices. We're in every gram counts territory with the climate emergency and I want to empower different people/organisations/industries who have different capabilities to contribute meaningfully. 

I agree - we must all engineer every area to optimal energy efficiency. While there is a swell of interest i strongly feel it is important to focus in on big wins, and for our part at Greening of Streaming naturally that 67% on the graph above sits like a fat target where perhaps a change in CDN planning or codec choices *might* bring about a really significant reduction in the demand for network growth. But web traffic / File sharing and gaming and more all play their part.

The IAB and IETF have some good work going on in the pure network space, and there are some good groups forming around storage and DC too. Collaboration is key! 

Hope some of that thinking was useful / interesting :)

Dom
> 
> Cheers 
> 
> 
> On Wed, 25 Oct 2023 at 15:03, Frédéric Bordage <info@greenit.fr <mailto:info@greenit.fr>> wrote:
>> Hello Dom,
>> 
>> You are right. On fixed links (FTTH / xDSL), there is no linearity / correlation between the quantity of data exchanged and the associated environmental impacts. In France, the most in-depth study ever carried out on this subject demonstrates this “linearity bias”. We carried out this LCA as part of the implementation of article 13 of the AGEC law. All French telecom operators have shared their data.
>> 
>> On the other hand, there is the beginning of a correlation between data quantity and env. impacts on 4G / 5G mobile links.
>> 
>> At the end of the day, the key point is to avoid traffic jams during peak hours so as not to have to deploy a new physical network (migration from 4G to 5G for example or from ADSL to fiber for example). Because it is the deployment of the physical network which concentrates the environmental impacts, particularly the last mile/local loop.
>> 
>> Furthermore, another LCA that we carried out on streaming formally demonstrates that it is the production of the TV which concentrates 70% to 90% of the environmental impacts. The results are more balanced in the smartphone / mobile scenario.
>> 
>> Best, Fred
>> 
>> Frédéric Bordage
>> GreenIT.fr founder
>> +33 6 16 95 96 01
>> 
>> Created in 2004, GreenIT.fr is the non-profit association that brings together the experts at the origin of digital sobriety, digital service eco-design and slow.tech initiatives. GreenIT.fr leads the Club Green IT and co-founded the NegaOctet.org (LCA consortium). Every year we publish the Benchmark Green IT.
>> 
>> Last books published (French)
>> Ecoconception web, les 115 bonnes pratiques, Eyrolles, 2012-2022 (4ème éd.)
>> Tendre vers la sobriété numérique, Actes Sud, 2021
>> Sobriété numérique les clés pour agir, Buchet-Chastel, 2019
>> 
>> Le ven. 29 sept. 2023 à 10:42, Dom Robinson <dom@id3as.co.uk <mailto:dom@id3as.co.uk>> a écrit :
>>> Hi folks
>>> 
>>> I run an organisation www.greeningofstreaming.org <http://www.greeningofstreaming.org/>
>>> 
>>> The Guidelines just out caught my eye https://www.w3.org/community/sustyweb/2023/09/07/web-sustainability-guidelines/
>>> 
>>> I would love to chat a bit more about this.
>>> 
>>> Fundamentally research we have carried out and continue to carry out is clearly showing that in the distribution networks energy is not proportional to data traffic. 
>>> 
>>> This is a common misunderstanding. It leads to digital media companies being quite wed to the idea that saving data saves the planet.
>>> 
>>> We are seeing no evidence that not sending data reduces energy consumption. We have been measuring events like the world cup streaming online and more, and network energy is not related to traffic, it is related to the peak provisioned capacity of the network. Much looks to be similar in cloud.
>>> 
>>> It might be worth exploring that theme and thinking about it in terms of some of the guidelines you have been publishing..
>>> 
>>> Do let me know if you would like to find out more
>>> 
>>> Kind regards
>>> 
>>> Dom
>>> -- 
>>> Dom Robinson
>>> www.id3as.co.uk <http://www.id3as.co.uk/> 
>>> www.greeningofstreaming.org <http://www.greeningofstreaming.org/> 
>>> uk.linkedin.com/in/domrobinson <http://uk.linkedin.com/in/domrobinson>
>>> Meet >> https://calendly.com/id3as 
>>>