IETF Logo Mail Archive

[bmwg] Scalability measurement results of the Jool stateful NAT64 solution

Gábor LENCSE <lencse@hit.bme.hu> Mon, 21 February 2022 21:01 UTC

Return-Path: <lencse@hit.bme.hu>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B033A0147 for <bmwg@ietfa.amsl.com>; Mon, 21 Feb 2022 13:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgFox1r0FxED for <bmwg@ietfa.amsl.com>; Mon, 21 Feb 2022 13:01:25 -0800 (PST)
Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8403A059F for <bmwg@ietf.org>; Mon, 21 Feb 2022 13:01:23 -0800 (PST)
Received: from [192.168.1.146] (host-79-121-40-106.kabelnet.hu [79.121.40.106]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 21LL1Agl083571 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <bmwg@ietf.org>; Mon, 21 Feb 2022 22:01:16 +0100 (CET) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-40-106.kabelnet.hu [79.121.40.106] claimed to be [192.168.1.146]
Content-Type: multipart/mixed; boundary="------------XF2ZnAIVH0uAQw6rTYfR7drO"
Message-ID: <92240261-0a63-7b53-42ec-3fdaa92c9442@hit.bme.hu>
Date: Mon, 21 Feb 2022 22:01:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-US
References: <9a857a06-d3b8-f06e-6fc7-49428ea1f7cd@sze.hu>
To: "bmwg@ietf.org" <bmwg@ietf.org>
From: Gábor LENCSE <lencse@hit.bme.hu>
In-Reply-To: <9a857a06-d3b8-f06e-6fc7-49428ea1f7cd@sze.hu>
X-Forwarded-Message-Id: <9a857a06-d3b8-f06e-6fc7-49428ea1f7cd@sze.hu>
X-Virus-Scanned: clamav-milter 0.103.2 at frogstar.hit.bme.hu
X-Virus-Status: Clean
Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.40.106; helo=[192.168.1.146]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10;
X-DCC--Metrics: frogstar.hit.bme.hu; whitelist
X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/fIxv-174v0O3zlpzdmKqNk73opE>
Subject: [bmwg] Scalability measurement results of the Jool stateful NAT64 solution
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Feb 2022 21:01:30 -0000

Dear All,

As an application of you draft "Benchmarking Methodology for Stateful 
NATxy Gateways using RFC 4814 Pseudorandom Port Numbers", I have 
measured the peformance of the Jool stateful NAT64 implementation. I 
have examined, how its performance metrics (maximum connection 
establisment rate and throughput) scale up with the number of CPU cores, 
and how the number of connections degrade its performance. (Jool scaled 
up much less well than iptables.)

Taday I have uploaded the updated version of my v6ops I-D about the 
results. You can find the new results in its Section 3: 
https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability-01#section-3

Any comments, recommendations, questions, etc. are welcome!

We plan to update our BMWG draft about the methodology in 1-2 weeks (by 
adding the method for measuring connection tear down rate).

Best regards,

Gábor

-------- Továbbított üzenet --------
Tárgy: 	New Version Notification for 
draft-lencse-v6ops-transition-scalability-01.txt
Dátum: 	Mon, 21 Feb 2022 05:13:54 -0800
Feladó: 	internet-drafts@ietf.org
Címzett: 	Gabor Lencse <lencse@sze.hu>




A new version of I-D, draft-lencse-v6ops-transition-scalability-01.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

Name: draft-lencse-v6ops-transition-scalability
Revision: 01
Title: Scalability of IPv6 Transition Technologies for IPv4aaS
Document date: 2022-02-21
Group: Individual Submission
Pages: 12
URL: 
https://www.ietf.org/archive/id/draft-lencse-v6ops-transition-scalability-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-lencse-v6ops-transition-scalability/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-lencse-v6ops-transition-scalability-01

Abstract:
Several IPv6 transition technologies have been developed to provide
customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their
advantages and disadvantages, and depending on existing topology,
skills, strategy and other preferences, one of these technologies may
be the most appropriate solution for a network operator.

This document examines the scalability of the five most prominent
IPv4aaS technologies (464XLAT, Dual Stack Lite, Lightweight 4over6,
MAP-E, MAP-T) considering two aspects: (1) how their performance
scales up with the number of CPU cores, (2) how their performance
degrades, when the number of concurrent sessions is increased until
hardware limit is reached.



The IETF Secretariat

v2.23.0 | Report a Bug | By Email