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

Excellent question! It wouldn't be mandatory to send the header in each response. A server could choose to send it only when the corresponding carbon emissions are significant (a threshold would need to be defined by the server developer).

HTTP server developers may have several ways to calculate the value. Best case scenario would be through modern instructions (RAPL) and other techniques. But they could also use pre-calculated numbers for simple requests, like a simple HTTP GET on a funny gif, whose size doesn't change and is always stored at the same place. The header would change for this. The header would be different obviously for application data queries (REST, etc.), but these are not cached anyway.

The cost of the calculation, of course, must not exceed the cost of the producing the response itself. That would counter-productive.

Bertrand Martin
sentrysoftware.com<https://sentrysoftware.com/>

From: Greg Wilkins <gregw@webtide.com>
Sent: Thursday, April 13, 2023 11:50 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Introducing a new HTTP response header for Carbon Emissions calculation


I'm wondering about the numeric sensitivity of a number for a single request to a site handling possibly millions of requests?  What precision is needed on each request so that the sum of millions is even vaguely accurate?

Note also, that the more precision on such a header makes it a really expensive header as it will change on every response and thus not be able to be put into a hpack or qpack table.

Going back to the road construction analogy, isn't this like trying to put a carbon cost onto each piece of gravel rather than working out the cost of the supply of X tonnes of gravel?



On Thu, 13 Apr 2023, 11:36 Bertrand Martin, <bertrand@sentrysoftware.com<mailto:bertrand@sentrysoftware.com>> wrote:
There are 4 main "domains" that we want to tackle when it comes carbon emissions of the IT in a given organization:


  1.  Data centers (on-prem infrastructure) – Scope 2
  2.  External services like public cloud and SaaS – Scope 3

     *   Public cloud
     *   SaaS
     *   External network (Internet)

  1.  Terminals (PCs, phones, etc.) – Scope 2 and 3 (mostly 3)

In a given Web service (say a Google search), the network transport represents typically 30% of the overall energy usage, which is something significant. So it would be good, at some point, to have network routers add information about the energy/carbon emissions used to transmit the data.

However, at the application layer, say a Java Web service will not be able to expose its energy usage and carbon emissions at the IP packet level. Most dev frameworks put everything at the HttpResponse level.

That's why we will eventually need both:

  *   IPv6 for the network transport cost
  *   HTTP for the application, server and storage cost

This I-D covers HTTP only, it's a start.

Thank you!

Bertrand Martin
sentrysoftware.com<https://sentrysoftware.com/>

From: Soni L. <fakedme+http@gmail.com<mailto:fakedme%2Bhttp@gmail.com>>
Sent: Thursday, April 13, 2023 11:20 AM
To: Bertrand Martin <bertrand@sentrysoftware.com<mailto:bertrand@sentrysoftware.com>>
Cc: Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>; Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>>; HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: Introducing a new HTTP response header for Carbon Emissions calculation

This feels like it should be an IPv6 EH honestly. Why not just move away from HTTP to avoid reporting these, and then just cite "technological limitations"? Bonus points for requiring IPv6, as that would wedge in a demand to go IPv6-only to satisfy regulations.

On Thu, Apr 13, 2023, 06:01 Bertrand Martin <bertrand@sentrysoftware.com<mailto:bertrand@sentrysoftware.com>> wrote:
> -----Original Message-----
> From: Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>
> Sent: Tuesday, April 11, 2023 4:16 PM
>
> > On 12 Apr 2023, at 12:10 am, Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>>
> wrote:
> >
> > Have you considered how this might work where there is a chain of servers
> involved in handling a request? We might think of CDNs in this light but it is
> also common for servers to sit in front of something like an app server or cache
> server. Therefore it could benefit this proposal to make it a list of values that
> can comprise the entire lifecycle of a request/response exchange.
>
> I had the same thought. It's probably best specified as a List of Decimals; see:
>   https://httpwg.org/specs/rfc8941.html


List of decimals would allow more details about carbon emissions for each server in the chain. However, proxies that rely on their cache would need to update the value with their own and thus remove the entire list. Also, clients won't need the details on the chain. When calculating Scope 3 carbon emissions, you need the Scope 2 value for the entire supply chain, and not just one step. So if we consider the actual use case, a single value is probably better, imo.

> But, I also wonder if the response is the best place to put this information -- it
> only makes it available after the fact, and scatters information that needs to be
> aggregated for many use cases. More discussion / description of the use cases
> would help guide the design.

The use case is to allow applications and clients to calculate their Scope 3 carbon emissions as per GHG Protocol definition. Laws are put in place (slowly) around the world requiring organizations to produce an annual report on their carbon emissions, including Scope 3. Organizations relying heavily on IT and digital services need proper instrumentation to calculate the carbon emissions associated to their IT. When using only on-prem servers, one could simply use the electricity bill to calculate the carbon emissions of a data center. But most organizations use public cloud services and SaaS platforms heavily. As of now, their no proper way for a client to estimate the carbon emissions associated to the usage of Atlassian Jira services for example, or GitHub. If the IETF defines a standard for reporting carbon emissions associated to an HTTP request/response, it will allow organizations to estimate the carbon emissions associated to all Web services. Clients will pressure providers to expose this information and implement the standard. Without a standard, vendors and service providers are likely to come up with unsatisfactory solutions, like AWS who provides an estimation of carbon emissions every quarter only... on your invoice!

> E.g., if the client is an API consumer and their use case is informing their
> request patterns, it's likely better to get this sort of hint from a description
> (e.g., OpenAPI) rather than in responses.

As of now, the need of the "market" is to get this information: scope 2 carbon emissions. In the future, we may want to get this information beforehand, introduce a negotiation mechanism, or quotas, etc. but at this stage, this is science fiction, unfortunately: no server is able to respond to such request (predict carbon emission of a request, or do not exceed quotas).

> That doesn't mean you shouldn't define the header, of course -- just that it
> might not be useful on its own. Also, adding headers to responses does ever-
> so-slightly increase carbon emissions...

True! it's the observability vs "green coding" debate...

>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/