Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

Christian Hopps <> Tue, 09 March 2021 01:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D88C3A1B4E for <>; Mon, 8 Mar 2021 17:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JMlVxJEsYhid for <>; Mon, 8 Mar 2021 16:59:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7D33A3A1B48 for <>; Mon, 8 Mar 2021 16:59:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id B44D1600E6; Tue, 9 Mar 2021 00:59:55 +0000 (UTC)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_6EE5F5E0-6C74-4699-9297-CCCF5E97101F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 08 Mar 2021 19:59:54 -0500
In-Reply-To: <>
Cc: Christian Hopps <>, "" <>
To: Linda Dunbar <>
References: <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Mar 2021 01:00:01 -0000

> On Mar 8, 2021, at 7:40 PM, Linda Dunbar <> wrote:
> Christian,
> You said at LSR session today that there might be concern of network optimizing ANYCAST traffic to better balance among multiple App Layer Load Balancers.
> First of all, only the Applications that need to leverage the network condition to balance among their multiple Load Balancers will get the benefit of path selection that are based on the combination of routing distance and other dynamic running status. The networks (e.g. 5G EC Local Data Networks)  only optimize the ANYCAST traffic for the registered addresses.
> The network is already responsible for selecting the shortest path to one Application Load Balancer. draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes to add additional weight in path selection.
> ANYCAST makes it possible to dynamically load balance across server locations based on network conditions. With multiple servers having the same ANYCAST address, it eliminates the single point of failure and bottleneck at the application layer load balancer that has the shortest routing distance. Another benefit of using ANYCAST address is removing the dependency on how UEs get the IP addresses for their Applications. Some UEs (or clients) might use stale cached IP addresses for extended period.
> Network service providers can even offer this as a value added service, making network information more useful to deliver services to applications.
> Isn’t it a win-win approach for both network service providers and the applications owners?

As WG member,

It's not a win when their network fails.

At a high level I think the idea of a smart network is interesting. I don't have good initial feelings though about trying to achieve that by adding application load based metrics into the routing protocol. There's all sort of layer violations going on there for one, but perhaps more importantly, our routing protocols have not been tried and tested over the decades with this use in mind.

One could imagine designing a higher layer distributed load balancing application/protocol that utilized routing information though, something like that would align more closely with the layering we've been designing to all these years. It probably would not rely on anycast exclusively, but instead use anycast to talk to a server that implemented this LB protocol (something anycast is good at) which would provide a unicast address for the requested application, with the ability to adjust (reacquire a new unicast address, whatever) as conditions (either at the routing or application layer) change through notifications or polling. Just brainstorming here, but there are lots of ways one could imagine this working.


> Linda Dunbar