Re: [E-impact] routing around high-power links (was Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example)

Toerless Eckert <tte@cs.fau.de> Thu, 28 March 2024 15:52 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 A0C5EC151548 for <e-impact@ietfa.amsl.com>; Thu, 28 Mar 2024 08:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 XosMVCvNwHVw for <e-impact@ietfa.amsl.com>; Thu, 28 Mar 2024 08:52:51 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 620E5C14CE31 for <e-impact@ietf.org>; Thu, 28 Mar 2024 08:52:49 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4V57NC5lvkznkM2; Thu, 28 Mar 2024 16:52:43 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4V57NC4p7wzknDn; Thu, 28 Mar 2024 16:52:43 +0100 (CET)
Date: Thu, 28 Mar 2024 16:52:43 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: E-Impact IETF <e-impact@ietf.org>
Message-ID: <ZgWSS6Z_w0ZbXs0W@faui48e.informatik.uni-erlangen.de>
References: <CAKr6gn3Ze0FrskGYouRjP+yRTG7Ts60EPy-LveHOXVRFBXNPew@mail.gmail.com> <6E972713-CA73-4D61-AF02-B83E59CCF8AD@id3as.co.uk> <9d3f52c06a274680a0762d65baa1308b@huawei.com> <3BB20F26-CC7B-4467-8C89-3622A08347B6@id3as.co.uk> <f279b87f5a394657a5285e8f914baf0b@huawei.com> <A26397BE-A568-4A40-8897-611BC18B91E7@id3as.co.uk> <CC2DF697-19ED-4FE5-9A22-EB16630E373C@ifi.uio.no> <LV8PR11MB8536590F9C9EB518A9F62A89B5352@LV8PR11MB8536.namprd11.prod.outlook.com> <142C9E5A-16AB-46AF-92B4-61EA5B3A4942@ifi.uio.no> <538769.1711586098@dyas>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <538769.1711586098@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/sSz5J1kTPMDGKvXMOhX3zNngf6g>
Subject: Re: [E-impact] routing around high-power links (was Re: [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: Thu, 28 Mar 2024 15:52:53 -0000

Michael: The fallacy of your argument is that upgrading to higher speed
typically means less joule per bit, at least from the data that i remember.

This may be more pronounced over longer terms than short term.
The first-gen of some higher speed link may have a higher
energy utilization than a later gen, simply because on the MIC side
you have a lot of modem-type computation and the initial chip may have
higher energy consumption than a later chip, both because of possible lower
size of the later chip as well as ASICification of the compute (if that's
a permitted word ;-). Think watching video with CPU decode vs. hardwired
decode.

The one thing that's going to come to an end some time is the chip
size. In San Francisco's ANRW keynote there was a good explanation how
this already is the case for memory, but for network chips we still
have some good runway, so that discuss point will IMHO become relevant for us
in 10 years.

But what is already prevalent IMHO is that you're not going to have complex
topologies where you do need a lot of path computation in most networks
because you do try to design your network for the minimum number of
maximum speed links you can physcially deploy. This is good for cost
and energy, but it is not good for resilience/reliability. 

In Germany some attacker actually managed to cut two fiber that where easily
openly accessible beside railway tracks and took down (if i remember corectly)
not only German Rail ticketing and other operations, but also other services
running over those fibers. So to me, the most important reason for more
diverse network topologies is really redundancy of criticial infrastructures.

As a fan of QoS, i would of course love to find reasons for distinguishing
latency critical and non-latency criticial traffic in the network, but i
don't believe that we will create that need/benefit in WAN/national nework
cores any time soon. If there is any reason to do that distinction, i think
it would be in metropolitan networks, e.g.: between users and edge-compute
or user-to-user. Anything beyond that is way too difficult to create
a critical mass sufficient to build a business case around it (IMHO).

Sure, you may have metropolitan networks with non-equal cost paths, such as
when using subtended rings, but the latency differences are more likely
dominated by packet queuing/scheduling and not physical propagation latency.

Of course, all of this could change if we would go towards more hybrid
optical/electrical networks, where we optically switch packets and electrically
only look at packet haders to do routing. In such networks, you'd need a lot
longer packets to exploit the energy saving and speed upgrades of pure optical switching.
Think packets of hundreds of kilobytes. And then we will have some nice
agg/deag technology problem on our hands. But alas, i think this research
direction will also take at least another 10 years minimum to come to
any fruition.

Cheers
    toerless


On Thu, Mar 28, 2024 at 11:34:58AM +1100, Michael Richardson wrote:
> 
> One of the things that people have tried to do since ATM was new and fancy
> was to provide for more bandwidth by taking the not-shortest path.  That is,
> go around the circle rather than across it.   That has mutated into MPLS and
> SRv6 efforts.  And SDN. I never was clear if anyone actually was able to do
> this.
> 
> For latency-tolerant bulk traffic (think backups, but also recorded video [youtube]
> might apply), going around is not that big a deal.  Particularly if one can
> get a lower price.  Ha, price: we don't charge for traffic today, so any
> efficies are not reflected in revenue (operator) or expense (user).
> 
> Why is this an energy issue?  Well, the shortest path links are likely to get
> congested, and as a result may get upgraded to higher speeds, which often
> means more energy used.  Meanwhile the circular, higher latency links might
> go underused, yet still consuming energy.
> 
> So for me, this is where some new routing algorithm (or application of the
> many circuit-link systems) would make significant sense.  But to make any of
> this work, we need an interface from the network to the host.  Some people
> thought APN was going to do this, but so far we have only
> herbert-host2netsig.  Tom was planning a BOF.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> 
> 
> 



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


-- 
---
tte@cs.fau.de