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

Hi Bertrand,

It's probably easiest for you and everyone else if you respond in the medium that the comment / question was made, but it's up to you.

As I said before, we're looking for input from folks with expertise on gathering and using this kind of data; concrete use cases / experience will have more weight.

Cheers,


> On 12 Apr 2023, at 11:00 pm, Bertrand Martin <bertrand@sentrysoftware.com> wrote:
> 
> Thank you all for the interest, for your comments and questions! Should I answer some of the questions in the GitHub issue, or in the corresponding email threads?
> 
> Thanks!
> 
> Bertrand
> 
>> -----Original Message-----
>> From: Mark Nottingham <mnot@mnot.net>
>> Sent: Wednesday, April 12, 2023 4:33 AM
>> To: Tim Bray <tbray@textuality.com>
>> Cc: Roy Fielding <fielding@gbiv.com>; Lucas Pardue
>> <lucaspardue.24.7@gmail.com>; Glenn Strauss <gs-lists-ietf-http-
>> wg@gluelogic.com>; Michael Sweet <msweet@msweet.org>; Greg Wilkins
>> <gregw@webtide.com>; Bertrand Martin <bertrand@sentrysoftware.com>;
>> HTTP Working Group <ietf-http-wg@w3.org>
>> Subject: 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/
> 

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

Received on Wednesday, 12 April 2023 23:00:47 UTC