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

[Romain Jacob <[e-mail]>]

I agree with Michael.

Cheers,
-- 
Romain

On 26/03/2024 12:12, Michael Welzl wrote:
> Hi everyone!
>
> Many good points here. Just to bring one more view to the table:
>
> I agree with George that it’s hard to see the actual "protocol work” 
> that would help - but I think that this may just be because we’re used 
> to think of algorithmic solutions.
>
> E.g., what routing strategy is “better” - based on energy? based on 
> carbon efficiency? based on a mix between these and “traditional” 
> metrics?  (well of course - e.g. shortest path will never cease to be 
> important, but how to mix these?) People have already come up with 
> example cases where these metrics *can* be useful. But how useful are 
> they really, and how realistic is it to apply them at a larger scale? 
> WOULD a larger scale be what we should aim for, or is this inherently 
> limited-scope stuff?
>
> It doesn’t seem like we have overall answers to these questions, and I 
> don’t think we can expect to find them anytime soon; and should *we*, 
> as engineers? Hesham has pointed at sociology and marketing; Rudolf 
> has pointed at economics.
>
> Concluding from all this, it seems to me that useful work can already 
> be done in the IETF to *instrument* protocols to provide, or enable 
> use of, sustainability-related information (at least energy, but 
> perhaps also carbon efficiency or some such metric if we do have hope 
> to come up with a useful definition…).  I.e., define a routing metric; 
> offer management information (see the proposed YANG model and ICMP 
> extension);  ... and then it would be up to others to see what they 
> can do with it.
>
> Here’s another way of looking at this: if we don’t instrument 
> protocols with such information, nobody can even try to deploy any 
> strategy because the tools are just not available - and nothing will 
> happen.
>
> So, IMO, such “instrumentation” work should indeed happen in the IETF, 
> soon - and in addition, we should keep having this mailing list to 
> inform the discussion on how the newly offered instruments could be 
> brought to good use.
>
> Cheers,
> Michael
>
>
>> On Mar 26, 2024, at 11:46 AM, Dom Robinson <[e-mail]> wrote:
>>
>> 100%
>> -- 
>> 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 10:45, Dirk Trossen <[e-mail]> wrote:
>>>
>>> Dom,
>>> Yes, it is a slippery slope from dumb to aware to (artificially) 
>>> intelligent😉
>>> But given that constraint-based routing already represents awareness 
>>> (e.g., to latency), adding energy in a limited scope is not a big 
>>> slide down that slope IMO. And we may find other opportunities on 
>>> the dry end of that slope before slippery kicks in.
>>> The reason for having this discussion in an engineering forum is to 
>>> get the balance of views right between the crazy desires and the 
>>> actual working things.
>>> Dirk
>>> *From:*Dom Robinson <[e-mail]>
>>> *Sent:*26 March 2024 11:39
>>> *To:*Dirk Trossen <[e-mail]>
>>> *Cc:*George Michaelson <[e-mail]>; E-Impact IETF 
>>> <[e-mail]>
>>> *Subject:*Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: 
>>> concrete usage example
>>> 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 <[e-mail]>
>>>     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
>>>     (seehttps://www.semanticscholar.org/paper/Routing-on-Multiple-Optimality-Criteria-Sobrinho-Ferreira/8ce4650878576839d61d0be35a364e019c18318b
>>>     <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-mail]>*On Behalf Of*Dom
>>>     Robinson
>>>     *Sent:*26 March 2024 07:11
>>>     *To:*George Michaelson <[e-mail]>
>>>     *Cc:*E-Impact IETF <[e-mail]>
>>>     *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 <https://calendly.com/id3as>
>>>
>>>
>>>
>>>         On 26 Mar 2024, at 02:31, George Michaelson
>>>         <[e-mail] <mailto:[e-mail]>> 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-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/e-impact
>>>         <https://www.ietf.org/mailman/listinfo/e-impact>
>>>
>>
>> -- 
>> E-impact mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/e-impact
>
>
-- 
Romain JACOB
Postdoctoral Researcher
ETH Zurich
Networked Systems Group (NSG)
Lead: Prof. Laurent Vanbever
www.romainjacob.net <https://www.romainjacob.net/>
@RJacobPartner <https://twitter.com/RJacobPartner>
@[e-mail] <https://discuss.systems/@jacobr>
Gloriastrasse 35, ETZ G81
8092 Zurich
[phone]