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

Roy, I can't bring myself to agree. For two reasons.

First, I know, as a former public-cloud employees, that those operations
already do quite a bit of work on tracking their carbon-loading, and take
into account all that stuff, including amortizing cost of construction and
so on.  So I bet that calls to individual Web services could produce useful
data, and if you're running a lift-and-shift application on a fleet of a
couple hundred of some instance type, you could produce a useful value too.

Second, these days, there are certain classes of requests, for example
those to crypto exchanges and generative-AIs, which have freakishly huge
compute costs, with plausibly-computable carbon-emissions.

So I think this is a useful affordance to provide. Not smart enough to
predict the uptake though. Dependencies include politics.

On Tue, Apr 11, 2023 at 1:31 PM Roy T. Fielding <fielding@gbiv.com> wrote:

> It's a complete waste of time and energy. Carbon emissions are not
> relevant on a
> per request basis, even if they could be measured by a running process.
>
> The cost of a service is an accumulation of everything that goes into
> providing it,
> including the overhead of unused provisioning for availability. It will
> depend on
> location of server, time of day, source of power, and co-location with
> other services.
> It can be overwhelmed by the cost of design (such as AI model generation)
> or by
> failure to deallocate unused servers. It even depends on the cost of
> eventual
> decommissioning the service when it is no longer wanted.
>
> Only the tiniest possible fraction of that is due to whatever processes
> happen
> to be triggered by a given request. Unless it is mining-as-a-service, which
> doesn't seem to be the right audience.
>
> If you want to know the carbon footprint of a service, you need the total
> cost of
> its provision, and then amortize that across time and customer demand.
> This is an
> accounting job, and the information belongs in a resource that a site can
> provide
> to anyone who wants that information (or might cause a government to
> demand it be provided). In a standard format, like accountants understand.
> In a standard location, like a well-known URL.
>
> This is a resource, not a header field.
>
> Otherwise, it is far more useful to send factual information that can be
> tested
> for accuracy, such as power usage within the server stats field, and let
> the
> recipient project from those facts to some estimate of carbon equivalence.
>
> That guess is going to be far more accurate than anything a service might
> advertise on its own, short of accounting laws.
>
> ....Roy
>
>
>