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

I'll be elaborating on Roy's post in a bit. Meanwhile, what Roy described as an "accounting problem" is more or less how I figured my COGS (Cost Of Goods Sold) when I was in the ISP/Webhost business. Standard 80% capacity was as good an IRL guideline for infrastructure purchasing, as it was an accounting construct for analyzing provisioning "headroom" as opposed to required "bandwidth". Nowadays I'm into small-scale solar steam generation, out on what was until recently my ranch (still mine, but all hat no cattle now). I'm happy to finally have a use-case for blockchain tech...



Thought I'd chime in on this one, because reading through I didn't see anyone bring up that architecturally, this is akin to a hit counter or skin timer. Clearly Code-on-Demand territory, never gonna be solved at the protocol layer. My billing rate did not change in February when my town was on not just its own backup diesel generator, but also the old kayak and parachute factories' gennys (dope-grows now) because "net metering". Otherwise the local creek winds up in Flaming Gorge Reservoir and the Town (being its own electric utility, in the middle of a dying coal-mining area with coal-fired power plants getting decommissioned) gets hydropower at a discount.



Can't look at my power bill and calculate a carbon footprint. Because they sent a lot of water downstream last year to keep Lake Powell above "dead pool", those dying coal plants were feeding our grid on a temporary basis which is so hard to account for, that it's actually why I say blockchain is the only real solution to Carbon cap-and-trade (I call it NFCT). This is resource territory and makes no more sense as a header than hit-count.


-Eric



lol @Willy for "If I was an end user seeing this, I would probably try to develop a browser plugin to flag sites doing this as greenwashers."







---- On Wed, 12 Apr 2023 16:00:38 -0700 Mark Nottingham <mnot@mnot.net> wrote ---



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 <mailto: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 <mailto:mnot@mnot.net> 
>> Sent: Wednesday, April 12, 2023 4:33 AM 
>> To: Tim Bray <mailto:tbray@textuality.com> 
>> Cc: Roy Fielding <mailto:fielding@gbiv.com>; Lucas Pardue 
>> <mailto:lucaspardue.24.7@gmail.com>; Glenn Strauss <gs-lists-ietf-http- 
>> mailto:wg@gluelogic.com>; Michael Sweet <mailto:msweet@msweet.org>; Greg Wilkins 
>> <mailto:gregw@webtide.com>; Bertrand Martin <mailto:bertrand@sentrysoftware.com>; 
>> HTTP Working Group <mailto: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 <mailto: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 <mailto: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/