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

The energy used to process a request comes mostly from the processor. The count of joules (multiplied by the carbon intensity of the electricity provider at that time) is typically done at the process thread level. The total number of joules to process a request is then logically passed in the response to the request (i.e. most of the time in HTTP).

This response is then transported through TCP/IP in *multiple* packets, which is a problem in itself. Also, it is particularly difficult for the network layer (on the server running the Web server) to have any understanding of the CPU workload that was necessary to produce the data that is transported. It may require updating the TCP/IP drivers on all operating systems to allow applications to pass this information.

WRT to SMTP and SSH, that's a very good point! In fact, we may need to define a standard for these as well, but:

* HTTP represents 80-90% of the overall Internet traffic
* SMTP between 10% and 15%
* SSH less than 1%

That's why creating a standard for reporting carbon emissions should be done first at the application layer, in HTTP. Then we could tackle SMTP.

Again, carbon emissions associated to network transport, should be conveyed by the network itself, as you're suggesting.

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

From: Soni L. <fakedme+http@gmail.com>
Sent: Thursday, April 13, 2023 1:36 PM
To: Bertrand Martin <bertrand@sentrysoftware.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Introducing a new HTTP response header for Carbon Emissions calculation

The solution to web frameworks not being able to handle it is to make them able to handle it. Further, most of them expose the underlying connection (fd) in various forms, which helps a lot. This is often used to figure out the IP address or the incoming port for logging reasons but there's no reason it couldn't also be used for energy reporting. Additional concerns include TLS energy reporting (is your TLS constant-power, or does it leak your keys?).

But also, why HTTP? Should we run SMTP over HTTP to satisfy energy reporting requirements? SSH over HTTP? If only HTTP has application energy reporting and it's legally required, then you cannot use anything else. Meanwhile allowing IPv6 to report application energy covers... basically everything, as anything would be able to use it (with varying degrees of effort).
On Thu, Apr 13, 2023, 06:35 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/