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

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 01:29:18 UTC