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>
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
>       1. Public cloud
>       2. SaaS
>       3. External network (Internet)
>    3. 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
>
>
>
> *From:* Soni L. <fakedme+http@gmail.com>
> *Sent:* Thursday, April 13, 2023 11:20 AM
> *To:* Bertrand Martin <bertrand@sentrysoftware.com>
> *Cc:* Mark Nottingham <mnot@mnot.net>; Lucas Pardue <
> lucaspardue.24.7@gmail.com>; HTTP Working Group <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>
> wrote:
>
> > -----Original Message-----
> > From: Mark Nottingham <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>
> > 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/
>
>