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
- Re: [E-impact] [OPSAWG] side meeting #119: Power … George Michaelson
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Dirk Trossen
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Michael Richardson
- Re: [E-impact] [OPSAWG] side meeting #119: Power … George Michaelson
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Dom Robinson
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Dom Robinson
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Dirk Trossen
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Dom Robinson
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Michael Welzl
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Romain Jacob
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Suresh Krishnan (sureshk)
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Michael Welzl
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Dirk Trossen
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Michael Welzl
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Rob Wilton (rwilton)
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Michael Welzl
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Rob Wilton (rwilton)
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- [E-impact] routing around high-power links (was R… Michael Richardson
- Re: [E-impact] routing around high-power links (w… Toerless Eckert
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Tony Li
- Re: [E-impact] routing around high-power links (w… Toerless Eckert
- Re: [E-impact] routing around high-power links (w… Tony Li
- Re: [E-impact] routing around high-power links (w… Toerless Eckert
- Re: [E-impact] routing around high-power links (w… Toerless Eckert
- Re: [E-impact] routing around high-power links (w… Adrian Farrel
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Suresh Krishnan (sureshk)
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Tony Li
- Re: [E-impact] routing around high-power links (w… Michael Richardson
- Re: [E-impact] routing around high-power links (w… Tony Li
- Re: [E-impact] routing around high-power links (w… Colby Barth
- Re: [E-impact] routing around high-power links (w… 'Toerless Eckert'
- Re: [E-impact] routing around high-power links (w… Michael Richardson
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Tony Li
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Michael Welzl
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Tony Li
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Tony Li
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Suresh Krishnan (sureshk)
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Colby Barth
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Suresh Krishnan
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Tony Li
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Chengen (William, FixNet)
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Hesham ElBakoury
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Chengen (William, FixNet)
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Rudolf van der Berg
- Re: [E-impact] [OPSAWG] side meeting #119: Power … Carlos Pignataro