Re: Introducing a new HTTP response header for Carbon Emissions calculation

I haven’t taken part before so I hope I’m doing it correctly! There are a few issues I can see with how this could get implemented. I think it’s a worthwhile target to aim for, there are just numerous complexities surrounding it.

Firstly, groups such as the Green Software Foundation have made a Software Carbon Intensity Specification which may be of use as a methodology: https://github.com/Green-Software-Foundation/sci/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md

Additionally, Cloud Carbon Footprint have a methodology for estimating Cloud emissions: https://www.cloudcarbonfootprint.org/docs/methodology

In terms of the issues:

CO2e vs Energy
As previously mentioned in the thread, CO2e/kWh varies across location as well as time, meaning that either countries’ yearly averages have to be used, or realtime grid data has to be provided to servers. Using CO2e also opens the door to companies offsetting their emissions and including this in their calculations (maybe the value should be > 0 to avoid ‘carbon-positive networking’ becoming a thing). An alternative could be using Watt-hours, as this is what servers would presumably be measuring in order to calculate CO2e anyway. This falls down if you wanted to include embodied emissions of hardware, which is included in the Green Software Methodology, but it means you’re more likely to be comparing apples to apples. It depends what the goal of this metric is.

Total vs Marginal Energy
A traditional web server is on all the time, and consuming power while it is at it (the base load). When a request is made you’ll likely see a small increase in power on top of that (the marginal load). So should a request be responsible for just the marginal load, or should it be allocated a portion of the base load as well? The former doesn’t capture the full power/emissions of the server, but the latter would mean that peak usage appeared less energy intensive than off-peak usage (base load divided by more/less requests). If instead you just returned a calculation based off of the total energy of the server to everyone, then you would be (more than) double counting the emissions across users. The complicated bit is the attribution of responsibility, which is why a single resource per domain as Roy suggested would be simpler in this regard.

Measurement
In order for a server to calculate CO2e it would need to calculate energy. There are methods for doing so such as Intel’s RAPL, but the options are much more limited when using the services of hyperscalers such as AWS. Projects such as Cloud Carbon Footprint try to estimate the power used by cloud instances, but this involves a decent amount of guesswork due to the opacity of cloud providers and the aforementioned attribution problems that they also face. There is a huge diversity of  architectures and stacks across the Internet, so it is hard to imagine a cohesive measurement protocol that wouldn’t require lots of individual effort, error, and scope for manipulation. For example, how do you measure the energy used by a LAMP stack versus a combination of microservices and serverless components? Not impossible – but messy.

Responsibility
Very linked to the attribution problem is the one of responsibility – is the footprint of a request the user’s responsibility or the website’s, or some mixture of the two? Decisions made on the attribution and communication of the metric make implicit judgements on this. For example, solutions such as the single resource per domain cast the responsibility onto the domain owner, but don’t recognise the role that increased consumption plays in the expansion of resources.

So to conclude, I think the goal of the metric needs to be identified, and from there the appropriate compromises can be made. It is a multifaceted issue and so I don’t think a simple answer exists to it. I hope this perspective is useful.

Iain



----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------