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

[Carlos Pignataro <[e-mail]>]

Hi, Rob,

On Wed, Mar 27, 2024 at 7:19 AM Rob Wilton (rwilton) <rwilton=
[e-mail]> wrote:

> HI Michael, others,
>
>
>
> There are various comments on this thread saying that it is too early to
> modify routing algorithms for energy efficiency and I would say that I
> broadly agree.  In fact, I’m not entirely sure whether solving this in the
> routing plane makes practical sense at all due to the complexity involved,
> but certainly if it does it is a far more complicate solution that needs
> more discussion before anything useful can be standardized.  I see this
> topic as being perfect for discussion within the e-Impact program within
> the IAB.
>
>
>
> In terms of an IETF WG, what is being proposed for short term
> standardization with the IETF is a simple YANG configuration model for
> turning on/off parts of the device when they don’t need to be used (e.g.,
> as a starting idea, perhaps see draft-li-ivy-power-01 - A YANG model for
> Power Management (ietf.org)
> <https://datatracker.ietf.org/doc/draft-li-ivy-power/>, by Tony Li and
> Ron Bonica).  Many networks that use traffic engineering or a configuration
> controller based architecture could make use of these data models, along
> with operational data models that report current energy usage of
> components, to optimize the energy usage of their networks by draining
> certain links or linecards and then powering them off when the overall load
> on the network is lower.  I see this as being directly analogous to mobile
> providers who are reducing some of their radio capability at night when the
> demand on their network is much lower to reduce energy consumption.
>

Is this a WG proposal targeting a single RFC, already scoped to the YANG
model for on/off?

Would a DT be more effective (and less overhead) if that is the goal?

Thanks,

Carlso.


>
>
> If we do ever get to trying to solve some of this in the routing plane,
> then I believe that both metrics on actual energy being consumed, and the
> ability to depower links, forwarding ASICs, linecards, fabric planes, and
> entire chassis, would be a key component to such as solution.  I.e., the
> proposed work that we are aiming to do now would seem to be required
> foundation steps for this future work anyway.  And to be clear, personally,
> I think that if we try and optimize traffic away from devices without the
> ability to turn off components, or put them into a lower power state, then
> we would end up with a much more complicated solution achieving only
> minimal energy savings, because as has been widely reported on the e-impact
> list many network devices have a high base load, with a much smaller
> proportion of overall power being directly related to actual traffic load.
> For me, the most interesting aspect of this is how to depower elements of
> the system whilst still keeping sufficient knowledge of their existence in
> the routing state, being able to bring components back ready into a
> forwarding state quickly (before they are actually needed), and how to
> maintain sufficient redundancy in the network.  I believe that similar
> topics are probably being discussed in the TVR WG.
>
>
>
> But for the moment, the aim of the new WG within the IETF is to
> standardize what can be clearly scoped and where the problem and rough
> solution are already well understood.  I don’t believe that it should
> impact the scope, or usefulness of the e-Impact IAB program in anyway, I
> think that it can, and should be, entirely complementary.
>
>
>
> Regards,
>
> Rob
>
>
>
>
>
> *From: *E-impact <[e-mail]> on behalf of Michael Welzl <
> [e-mail]>
> *Date: *Tuesday, 26 March 2024 at 11:13
> *To: *Dom Robinson <[e-mail]>
> *Cc: *Dirk Trossen <[e-mail]>, George Michaelson <
> [e-mail]>, E-Impact IETF <[e-mail]>
> *Subject: *Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics:
> concrete usage example
>
> 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
>
> www.greeningofstreaming.org
>
> 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
>
> www.greeningofstreaming.org
>
> 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 (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-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
>
> www.greeningofstreaming.org
>
> uk.linkedin.com/in/domrobinson
>
> Meet >> https://calendly.com/id3as
>
>
>
> On 26 Mar 2024, at 02:31, George Michaelson <[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]
> https://www.ietf.org/mailman/listinfo/e-impact
>
>
>
> --
> E-impact mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/e-impact
>
>
> --
> E-impact mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/e-impact
>