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

Bertrand,

I'm sharing the concern of Willy (and others) of the overhead of this
approach.   You state that the aim of this is:

we're looking for a way to know the carbon emissions of our supply chain
> (external Web services).


That is laudable, but why does that need to be done per response?      The
per response approach has the following issues:

   - It is after the fact, thus it does not allow emissions to be estimated
   in advance, nor to be part of the design process when choice about which
   services are used and how often they are used can be made.
   - It excludes fixed costs of an idle service.
   - It increases the data size by a percentage. Once stage-3 emissions are
   included, this impact will be larger.
   - The header value will either be quantized and inaccurate, or it will
   be precise and always changing, thus being a difficult value to compress.
   - It suffers from numerical insensitivity, as the sum of millions of
   small amounts is unlikely to be an accurate reflection of the total.
   - It suffers from brevity, so any additional information that might be
   available or added over time, is not included.


On the other hand, having a well known resource on a service could address
these issues:

   - Average/estimated emissions can be included  for planning/design
   of new services or for dynamic selection of a service with current low
   emissions.
   - Both fixed and per request emissions can be listed.
   - Total historic emission can be given per session / per connection /
   per identity etc.
   - By providing a real total, numeric insensitivity is avoided
   - No data overhead for clients that do not care.
   - Overhead for clients that do care need only be once per session /
   connection / period
   - The resource can be an extensible format so new fields can be
   standardized and added


Thus I'd very much prefer to explore a well known resource solution rather
than a per response one.

















On Fri, 14 Apr 2023 at 05:43, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Apr 13, 2023 at 11:26:30PM +0000, Bertrand Martin wrote:
> > Possible alternatives:
> >
> > * Carbon-Emissions-Scope-2
> > * CO2-Emissions-Scope-2
> > * CO2-Scope-2
> > * Carbon-Scope-2
> > * Carbon-S2
> > * C02-S2
> >
> > It doesn't seem to me that the proposed "Carbon-Emissions-Scope-2" is too
> > long, but it's just an opinion. Are there any rules or standard on this?
>
> Quite frankly, seeing that the average response header block size on my
> server is 189 bytes, inflating them by 12.7% *just for a header field name*
> without even counting the size of the value, for the sake of pretending
> to care about energy usage would sound like an oxymoron to me. If I was
> an end user seeing this, I would probably try to develop a browser plugin
> to flag sites doing this as greenwashers.
>
> That's often the problem: waste a lot of energy to spread a message
> claiming we're careful about it, like cities installing big displays
> in the street, powered night and day showing messages like "do not
> forget to turn off the lights, every effort matters". Please at least
> make sure not to replicate such absurd practises. If you emit something,
> it must cost almost zero to produce (calculation and emission), certainly
> not 12-20% of each response header block!
>
> Also, indicating power usage would be more realistic and accurate than
> supposed emissions which have no measurable grounds for most operators.
> Use a "uj" header to report micro-joules as an integer for example, then
> in the future we could imagine that a site's certificate will contain
> extra information such as the site's average energy sources distribution
> so that the client can apply a rough estimate if they want to guess how
> much this request might use of each source.
>
> Regards,
> Willy
>
>

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