Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

Claudio Jeker <cjeker@diehard.n-r-g.com> Tue, 28 March 2023 09:26 UTC

Return-Path: <cjeker@diehard.n-r-g.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC93C151B11 for <sidrops@ietfa.amsl.com>; Tue, 28 Mar 2023 02:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 Cc7F5y0PqWZ2 for <sidrops@ietfa.amsl.com>; Tue, 28 Mar 2023 02:26:03 -0700 (PDT)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AF9C151B0F for <sidrops@ietf.org>; Tue, 28 Mar 2023 02:26:03 -0700 (PDT)
Received: (qmail 44691 invoked by uid 1000); 28 Mar 2023 09:26:00 -0000
Date: Tue, 28 Mar 2023 11:26:00 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Ben Maddison <benm@workonline.africa>
Cc: Martin Hoffmann <martin@nlnetlabs.nl>, Amreesh Phokeer <phokeer=40isoc.org@dmarc.ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, Aftab Siddiqui <Siddiqui@isoc.org>, Max Stucchi <stucchi@isoc.org>, Hanna Kreitem <Kreitem@isoc.org>
Message-ID: <ZCKyqNY4nlUGlujE@diehard.n-r-g.com>
References: <SJ0PR06MB7677230255CC9134CAF94E98D6879@SJ0PR06MB7677.namprd06.prod.outlook.com> <ZBxfj74YFy/5Fhax@diehard.n-r-g.com> <20230323162051.3069b516@glaurung.nlnetlabs.nl> <ZBx7DrM3Vjf/tSms@diehard.n-r-g.com> <20230328085426.dadqyjri7677hbkc@iolcus>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230328085426.dadqyjri7677hbkc@iolcus>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/n7Kf-_V4HpvMrjBpAUARu-B15NA>
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2023 09:26:05 -0000

On Tue, Mar 28, 2023 at 05:54:26PM +0900, Ben Maddison wrote:
> Hi Claudio,
> 
> On 03/23, Claudio Jeker wrote:
> [..]
> > I have a major issue with duplicating the CAS lookup table. The
> > implication for BGP implementations is twice the memory consumption and
> > more then double the computational cost and that in the most latency
> > sensitive portion of the code. A lot of time is spent in getting the most
> > performance out of BGP and so this should be a major consideration when it
> > comes to ASPA validation.
> 
> Would you elaborate on this?
> 
> I get why the memory usage increases with this approach.
> 
> It's not obvious to me why the computational cost of the verification
> process is higher with a per-AFI table.
> Intuitively this seems like it should be a *cheaper* lookup, since you
> don't have to filter for AFI at lookup-time.

The problem is that the tables are close copies of each other.
So you end up needing twice as much cache to handle the same amount of
information. Since cache is king in todays world of high speed CPUs the
fact that twice as much is needed is a problem. Data may no longer fit
and so expensive roundtrips to main memory are needed.
Modern computers do not behave like the CS models behind things like the
Big O() notation.
 
In OpenBGPD we additionally calculate and cache all 4 possible results
in one go. There is little overhead in doing the lookup for both AFI since
our hop functions returns both results in a single lookup.
Doing both downstream and upstream checks adds extra lookups but right now
our code has no prior knowledge to skip these if the path is only used by
one group of roles.

-- 
:wq Claudio