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

<chair hat on>

This proposal seems to have the interest of at least some WG members. However, determining whether this solution is appropriate is dependent on knowledge and experience that is largely absent in this group, and so we're reluctant to issue a Call for Adoption without broader participation. 

A reasonable next step, then, is for folks to identify those with such expertise and start a conversation. To make that easier for those who aren't subscribed to the list, I've created a tracking issue:
  https://github.com/httpwg/admin/issues/52

If you know someone who has such expertise, please encourage them to participate on-list or on the issue above. 

That discussion might result in confirmation that this is the right place for such work, or that another venue is more appropriate (where we would play more of a consulting role on HTTP specifics). If you know of (or find) an external venue that is relevant, please bring it to the Chairs' attention.

I'd also encourage folks to consider and expand upon the use cases, rather than jumping to the potential solutions.

Cheers,


> On 12 Apr 2023, at 7:21 am, Tim Bray <tbray@textuality.com> wrote:
> 
> 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
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 12 April 2023 02:32:51 UTC