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

Dom Robinson <dom@id3as.co.uk> Tue, 26 March 2024 10:39 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 9A1D6C1D4A80 for <e-impact@ietfa.amsl.com>; Tue, 26 Mar 2024 03:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=ham 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 9yZhW2L2z68U for <e-impact@ietfa.amsl.com>; Tue, 26 Mar 2024 03:39:30 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 5A513C180B68 for <e-impact@ietf.org>; Tue, 26 Mar 2024 03:39:29 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2d68651e253so86514991fa.0 for <e-impact@ietf.org>; Tue, 26 Mar 2024 03:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=id3as-co-uk.20230601.gappssmtp.com; s=20230601; t=1711449567; x=1712054367; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=sdOZmpVd5LwIpKcmEWwYJLpFnS5RaAXzP9LB14udveg=; b=lx9p0DboHx6r4KMddHNpOayEanXEzwRVvol7XHJncm+yxKFiBAvfAPfsZEw3PfD8Af eDWkkceHwu6oc7HkRG17KviB10LJaKLNoL/msgfwEaswZb/8xQYGMHs6FFkoRZ3XiUn0 24jtDe2mgjq97Ii4m76attC2kDW9a+KxBIy04cUs9iUtG6gxeBeVFWTCZQaLh+kccPSj 3mstHIMZFdot4EJyNU2SFS16/hwaO21BS6uqG9M0QUbDszZbxj3LvXgLogBM+DdDnUnj TFA7k86wPWT/B8J1AdHOek0Uo1H/Lm2f1RXrgo9eODJ0LSOg7b1NyfPjFBCeJ5FAdKOn 3iug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711449567; x=1712054367; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sdOZmpVd5LwIpKcmEWwYJLpFnS5RaAXzP9LB14udveg=; b=ms+LzEj9tAdfMasDuJUXWPT8ZKRolOCOqL4mRYTur4uD/CqVE9PA2DslwVxGkxhMUf ryxSxdckYsXKQggPeDEO/gSEoJ7/ptRbd0lfj+2Ya62vPlw7sRzpWKEOAn7K8XQZqQGW tuwYnrU6qtSbhsv0ABWvJUO6aPkm450UjlWtZ20NVp7BUSX82oRjT1InEH2X5O+gJN29 PvYt7NwmbMc70AUY/oinxZ0js4VO1ZGQEibYgzN2iwUwCJuxrz90NpY+fv6xiBvf2BLL SYsFS5S0ADJLFyTR8FNe2OZygIgz+2FmtIene4nPIsz6F7GDGDaDKvKcCF9HnEB0csSt NHPA==
X-Forwarded-Encrypted: i=1; AJvYcCWSA7RfrHyBN7z+vgYvHNjpo666bbr6Ia6M1S/bn5M6mYLqAnFypYBp90n4x1mJPtwL9iSVX+2D/KMzoPl90O2kQQ==
X-Gm-Message-State: AOJu0Yzw1G4osulc/fynIJhoM9cG1MpzgtJRHCfnwfpYUyKsv9EPELDy L4Gwn7WeGmPNT4ckijHj/7S6Q4mrXw00ngyrUjcUJiPbpjoLsoMDHHNWnZGDzco=
X-Google-Smtp-Source: AGHT+IG8Zrf++pJSS7mkRKIZ7hxMI0JQRqEedSAQnBiIcB4Gz/jIBrXhBhWWmN52KQ9q82UcIpm0pg==
X-Received: by 2002:a2e:310a:0:b0:2d4:5f50:1fa with SMTP id x10-20020a2e310a000000b002d45f5001famr6129565ljx.41.1711449567178; Tue, 26 Mar 2024 03:39:27 -0700 (PDT)
Received: from smtpclient.apple ([2a00:23c8:a59c:9701:d5fb:5286:57d7:a990]) by smtp.gmail.com with ESMTPSA id bg28-20020a05600c3c9c00b00412a31d2e2asm11177552wmb.32.2024.03.26.03.39.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2024 03:39:26 -0700 (PDT)
From: Dom Robinson <dom@id3as.co.uk>
Message-Id: <3BB20F26-CC7B-4467-8C89-3622A08347B6@id3as.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF16EDA7-5FC8-4A3D-BDD2-B7289863B61D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Tue, 26 Mar 2024 10:39:16 +0000
In-Reply-To: <9d3f52c06a274680a0762d65baa1308b@huawei.com>
Cc: George Michaelson <ggm@algebras.org>, E-Impact IETF <e-impact@ietf.org>
To: Dirk Trossen <dirk.trossen@huawei.com>
References: <CAKr6gn3Ze0FrskGYouRjP+yRTG7Ts60EPy-LveHOXVRFBXNPew@mail.gmail.com> <6E972713-CA73-4D61-AF02-B83E59CCF8AD@id3as.co.uk> <9d3f52c06a274680a0762d65baa1308b@huawei.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/mlWQmOgGKZlrK4uS7XlL_tcMh-o>
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 10:39:34 -0000

Dirk

> So I agree on being careful about the scope of energy considerations in protocol design (to avoid feature creep, to avoid raising new security considerations) but I cannot agree that it is not potentially substantive protocol work for the IETF.

More good points: better made than my own! 

I stand by giving the whole idea of giving the seemingly inexorable merge of energy operations with IP (as far as this group is concerned) a solid kick-test. Without that check and balance i do fear an unending scope creep in trying to bring ever-deeper decisioning / awareness into the routing layer. 

"Dumb-networks" have proven very successful for a long while and while it’s tempting to add (A)intelligence to everything these days it may take us toward using a particle accelerator to crack a nut :)

But i happily cede to the points you make about prior form for such ‘awareness' already being present as far as traffic flow is concerned.



-- 
Dom Robinson
www.id3as.co.uk <http://www.id3as.co.uk/> 
www.greeningofstreaming.org <http://www.greeningofstreaming.org/> 
uk.linkedin.com/in/domrobinson <http://uk.linkedin.com/in/domrobinson>
Meet >> https://calendly.com/id3as 

> On 26 Mar 2024, at 08:41, Dirk Trossen <dirk.trossen@huawei.com> wrote:
> 
> Dom, all,
>  
> Chiming in here as a passive observer so far on this list. 
>  
> When you say: “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.” I wonder why you limit the scope of IP routing constraints (which do exist, right?) to NOT consider energy? 
>  
> Why is it that we cannot envision energy costs associated to links in the same manner we assign latency budgets to select one path over another? If one considers multi-constraint routing work (see https://www.semanticscholar.org/paper/Routing-on-Multiple-Optimality-Criteria-Sobrinho-Ferreira/8ce4650878576839d61d0be35a364e019c18318b for what is hopefully working as a non-paywall reference), even multiple constraints in combination with latency or bandwidth are foreseeable IMO. 
>  
> When you say: “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.”, it confuses me since I was under the impression that routing is exactly about infrastructure, while it is also about application requirements (highest BW or lowest latency, or maybe even lowest energy) to make the right data exchange decisions.
>  
> An example of work in the IETF, where we can see (down the line) an active consideration of energy is that of traffic steering, i.e., the selection of one of possibly several choices of network locations where traffic could go to. If you see several (e.g., virtualized) instances of a service residing at those different network locations, picking the ‘best’ of the choices is key here. Isn’t it a good thought to consider energy as a possible ‘best’ choice here?
>  
> The CATS WG is one such body of work in the IETF right now. Its very name limits it to ‘compute-awareness’ but isn’t the energy consumption of compute endpoints not one such possible awareness metric? Of course, works like CATS but also ALTO need to work out the signaling of such application/service metrics to network nodes to act upon them, but that’s (in part) why those WGs exist.
>  
> So I agree on being careful about the scope of energy considerations in protocol design (to avoid feature creep, to avoid raising new security considerations) but I cannot agree that it is not potentially substantive protocol work for the IETF.
>  
> Best,
>  
> Dirk
>  
> From: E-impact <e-impact-bounces@ietf.org> On Behalf Of Dom Robinson
> Sent: 26 March 2024 07:11
> To: George Michaelson <ggm@algebras.org>
> Cc: E-Impact IETF <e-impact@ietf.org>
> Subject: Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example
>  
> 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’. 
>  
>  
>  
> -- 
> Dom Robinson
> www.id3as.co.uk <http://www.id3as.co.uk/> 
> www.greeningofstreaming.org <http://www.greeningofstreaming.org/> 
> uk.linkedin.com/in/domrobinson <http://uk.linkedin.com/in/domrobinson>
> Meet >> https://calendly.com/id3as 
> 
> 
> On 26 Mar 2024, at 02:31, George Michaelson <ggm@algebras.org <mailto: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 <mailto:E-impact@ietf.org>
> https://www.ietf.org/mailman/listinfo/e-impact