Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example

Dom Robinson <dom@id3as.co.uk> Tue, 26 March 2024 06:11 UTC

Return-Path: <dom@id3as.co.uk>
X-Original-To: e-impact@ietfa.amsl.com
Delivered-To: e-impact@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3386C14F69B for <e-impact@ietfa.amsl.com>; Mon, 25 Mar 2024 23:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.009
X-Spam-Level:
X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=id3as-co-uk.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbmZBSIUg6-y for <e-impact@ietfa.amsl.com>; Mon, 25 Mar 2024 23:11:07 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309A7C14F691 for <e-impact@ietf.org>; Mon, 25 Mar 2024 23:11:06 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-341b9f6fb2eso2467747f8f.2 for <e-impact@ietf.org>; Mon, 25 Mar 2024 23:11:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=id3as-co-uk.20230601.gappssmtp.com; s=20230601; t=1711433464; x=1712038264; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=CkDVujvM28jUAl/SAalGIhB/3A7XDwzRHlV8jGEyBT4=; b=YHclWqLWnTXu4gi4lEaxS/WKrccujIsunKxqxuSzhiITrNyVtrOXyEsN94LYfCmMGH a5okdtFE4H7sNcRceZ9+tXe8AvxjD8SLP97TRy1TW52Zi/NWCiqOSBqL0Fmx2zo7Hax9 IHWxPVi8NW9Br7D+H08bXJ6l/+s/wx3fX+DZqu0hl9NRYL2s8XQDmEc2Ooh4/+CCKW2B dNieA62E4r+uayKR7rlXLg/R280vg+D2jHZHxsmU8dWfnEyw8rLPRFRyFB0sWzNN8YY1 MVV7cwlyDCn8BlyazmrZhFP04aUszRKswe1/uZ2qDIh/5ZB+pXLqiHHjrg2i1qOtf6DY x3mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711433464; x=1712038264; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CkDVujvM28jUAl/SAalGIhB/3A7XDwzRHlV8jGEyBT4=; b=iAArsBeoJqba7YzWrd7A43Bgkw5af0cPI2dk/B5RNJP1ZIVh//pvWwEzLO2E+bNC59 mYNWs8HDCczQNoytKSosdALI7mcPhXg/HEKjGuM9DAExaD/tmaKNg4yFIl3AeOp+MlDl Xf/Amtf/SvK8khsuGtt+VcTbyxDExXOQq7WxVtJ5olYW8uUItXFJ/MXvy2VNehfvnvH1 8Ch4egl2EJHLXnQdryZOsgrc7IECPpAGgtXHA1oiOejFIUcJ0/bcav8klJ4HrP16TZPG fosE6Kg2znm0G6Ope+wSa0lhWaG+LD9JSzeHZdUZVvd9V0REA2KxQPkxJGP1X++RWsae cTVA==
X-Gm-Message-State: AOJu0YwadLvRXu3Wvv9KD9A1WBhPjd+mFCJ9YaRYBTkQCi+NFzi4jell 3QKbbGN86+qtYOcNXHoa8j5BXFvwzzN9VRB7yGvq6qrWM7B45rnQlTqm3v9cSaD3mhHPajjrdC2 Coxc=
X-Google-Smtp-Source: AGHT+IF9O4uyEAqX3b3ZzMu//poqe9FWjpMJQ0QPFGdKv1/l/wOLYi/SH6OF4Fd18PXgwHKJXRSBeg==
X-Received: by 2002:adf:cf12:0:b0:341:72b8:83b9 with SMTP id o18-20020adfcf12000000b0034172b883b9mr6228830wrj.68.1711433463971; Mon, 25 Mar 2024 23:11:03 -0700 (PDT)
Received: from smtpclient.apple ([147.148.76.152]) by smtp.gmail.com with ESMTPSA id fc19-20020a05600c525300b004140c161e8dsm10503548wmb.43.2024.03.25.23.11.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Mar 2024 23:11:03 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-DAB0D30A-3C36-44F6-8999-8F32C57B5125"
Content-Transfer-Encoding: 7bit
From: Dom Robinson <dom@id3as.co.uk>
Mime-Version: 1.0 (1.0)
Date: Tue, 26 Mar 2024 06:10:51 +0000
Message-Id: <6E972713-CA73-4D61-AF02-B83E59CCF8AD@id3as.co.uk>
References: <CAKr6gn3Ze0FrskGYouRjP+yRTG7Ts60EPy-LveHOXVRFBXNPew@mail.gmail.com>
Cc: E-Impact IETF <e-impact@ietf.org>
In-Reply-To: <CAKr6gn3Ze0FrskGYouRjP+yRTG7Ts60EPy-LveHOXVRFBXNPew@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
X-Mailer: iPhone Mail (20G81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/jwfhT4uGGuHcrdWvNBeF80VBUPA>
Subject: Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example
X-BeenThere: e-impact@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Environmental impacts of the Internet <e-impact.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e-impact>, <mailto:e-impact-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e-impact/>
List-Post: <mailto:e-impact@ietf.org>
List-Help: <mailto:e-impact-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e-impact>, <mailto:e-impact-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2024 06:11:11 -0000

George - you make some good points very well.

I am simply unconvinced there is substantive
protocol work in energy burden to be done in IETF protocol space at
this time.


I have to say I agree.

As an influencing discussion, e-impact is hugely valuable.

As an intermediary between layers 1/2 and layer 4 (where all the energy is consumed) IP can already carry information (as an ‘application’) that leads to energy saving infrastructure and workload management. In this regard it already does the job perfectly!

But should a data routing protocol confuse its purpose by routing based on its own ‘awareness’ of energy? I think that adds a burden to IP that would weaken it and be out of scope. 

It risks becoming ‘for the sake of it’ rather than because it is really improving the protocol IMHO. 

I think better to continue to focus on how the physical layers and link layers are efficient, and the application layer has information to steer decisions.

l3 routing should be routing, and not try to scope creep into application / infrastructure. It should stick to the end to end principle and leave the ends to decide on energy actions, while facilitating the data exchange.

IPs role is hugely important, but it needs to remain benign else it will become a political tool. Energy information becoming a component of routing data looks like a cyberattack waiting to happen to me. 

BGP tables going wrong causes chaos, but generally ‘only’ impact data access. A DDoS attack on our energy using IP networks could cause real-world problems with much deeper consequences than ‘some data loss’. 



-- 

On 26 Mar 2024, at 02:31, George Michaelson <ggm@algebras.org> wrote:

Without wanting to push too hard, I would personally push back on
E-impact becoming a WG or having any solidity beyond an experimental
ongoing activity. I am simply unconvinced there is substantive
protocol work in energy burden to be done in IETF protocol space at
this time.

* I absolutely believe there is an energy impact issue in DC, in long
distance communications and maintenance of RF carrier, for the IEEE,
for 3GPP, for economies with unreliable power facing the question to
house a CDN or long-line it to somewhere else. These problems lie in
other people's standards bodies.

* I absolutely do believe we can theorise physical and link layer
protocol changes which reduce energy burdens (in many cases with cost,
like no 0RTT responses because we have to re-establish link) -And that
things like delay tolerant networking or 6LOWPAN go into this space
sometimes.

* I also absolutely do believe there may in future be clearer drive to
do work on energy in IETF, in protocol design for DC or other contexts
where it has to be exposed through the protocol stack to the
application. Therefore I can say there COULD be work to be done here,
in the future.

About as far as I would go right now is a problem statement. And, a
watch-and-review status.

I'm not in charge here and I don't have some magic veto card. If
people wanted to continue, I wouldn't oppose a list being hosted, but
I would be uncomfortable with positions being taken in public implying
the IETF or the IAB have substantive work to do here: I don't see it.

Maybe the IAB differs.

-G

--
E-impact mailing list
E-impact@ietf.org
https://www.ietf.org/mailman/listinfo/e-impact