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

Much as I hate to use more carbon replying...

This reminds me of discussions we had when involved with smart-gridwork 
and the question I think was how to drive use towards the more efficient 
service.

After considering providing all sorts of metrics - which are hard to 
produce and hard to use we settled on a single metric - cost

That's all that really matters - pick the cheapest.

It's also relatively easy to produce. For a hosted site the cost per 
millisecond is monthly cost as billed by the hosting service / total 
number of milliseconds. Some providers allow finer grained - e.g weekly 
cost.

An endpoint could be provided which shows how that cost is broken down - 
e.g. what percentage of power comes from renewable energy and maybe that 
could be factored into the cost per milli.

The other question is how to stop people lying. Whatever metrics you use 
are open to fraud so some sort of certification and audit seems to be 
necessary. The simpler the scheme the easier to audit.

So define a currency - figure out how to represent resources used as 
cost in that currency and display that.

It probably doesn't even need to be a header - make it a well defined 
resource for the site - cost per millisec

On 4/13/23 21:29, gs-lists-ietf-http-wg@gluelogic.com wrote:
> On Thu, Apr 13, 2023 at 11:44:04PM +0000, Bertrand Martin wrote:
>>> -----Original Message-----
>>> From: gs-lists-ietf-http-wg@gluelogic.com <gs-lists-ietf-http-
>>> wg@gluelogic.com>
>>>
>>> Server-Timing already exists for some metrics and might be extended with a
>>> CO2 metric.
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing
>>> https://www.w3.org/TR/server-timing/
>> That's a very good point. However Server-Timing reports timing metrics only, and I don't see how it could specifies other metrics (like energy usage in Joules or carbon emissions in grams). But if that is possible, then yes Server-Timing could be the home for carbon emissions metrics.
>
> Quoting from:
>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing
>>> The Server-Timing header communicates one or more metrics and descriptions for a given request-response cycle. It is used to surface any backend server timing metrics (e.g. database read/write, CPU time, file system access, etc.)
>>>
>>> Syntax
>>> The syntax of the Server-Timing header allows you to communicate metrics in different ways: server metric name only, metric with value, metric with value and description, and metric with description.
>>> The specification advises that names and descriptions should be kept as short as possible (use abbreviations and omit optional values where possible) to minimize the HTTP overhead.
> Given the above, I am confused why you wrote:
>    "I don't see how it could specifies (sic) other metrics"
>
>
> You mentioned elsewhere that there will likely be a minimum threshold
> for reporting.  That makes sense, since measurements can be only so
> precise.  Given that many HTTP requests and responses can be very small,
> and given a minimum threshold, I predict that at least some people may
> waste additional resources "gaming" the system by breaking a single
> request into multiple requests with each request staying beneath the
> threshold.  Therefore, I recommend that each and every request be
> assigned a non-zero implicit cost, without requiring a header to specify
> that non-zero cost.  Better, *resource creation* costs -- which may be
> substantial -- should be separate from HTTP request/response delivery
> costs, and HTTP request/response delivery costs might not be reported
> per-request at all, though should be accounted for in aggregate
> elsewhere, e.g. a cost might be retrieved from DNS or a /.well-known/
> location which reports estimate median overhead costs per request for
> all *overhead*, include idle server costs.  Such a reporting metric
> could be calculated and updated daily on the server as a rolling average
> over the last, say, 7 days.
>
> Cheers, Glenn
>

Received on Friday, 14 April 2023 17:43:45 UTC