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

I think that perhaps both Roy and Betrand are correct.

From my initial reading, there is certainly a measurement component to
emissions accounting.  Thus some mechanism to help with that measurement
(perhaps like Betrand's per request header) will be part of the solution.

But the key reason for doing such emission accounting is to drive choice
around the full life cycle costs of using a product or service.    Thus
when designing a new service, being told the emissions for a request
already completed is about as useful for picking a low emission road design
as being told the emissions for a truck load of gravel after it is
delivered to your road construction site.

To drive low emission design and choices, the emissions for given services
need to be known in advance. Thus Roy's known resource approach could be
key in being able to select one data center over another; one service over
another.

Given the sunk costs of idle data centers, this is likely to have both
static and dynamic aspects to it.  The known static costs can be used to
determine if a service/product will be used in a design or not, then the
dynamic costs can be used to route traffic within that design to somewhere
that currently has low per request emissions (e.g. because the wind is
blowing and the sun is shining near that data center).

So mostly Mark is correct... We need to get information from experts so we
design standards that will help drive low emission designs and choices in
an effective way.

cheers










On Tue, 11 Apr 2023 at 22:30, 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
>
>

-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com