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

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/

Received on Wednesday, 12 April 2023 13:01:00 UTC