[bmwg] An improved version of our I-D: draft-lencse-bmwg-benchmarking-stateful-02

Gábor LENCSE <lencse@hit.bme.hu> Sun, 10 October 2021 18:11 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 182DC3A0BB3 for <bmwg@ietfa.amsl.com>; Sun, 10 Oct 2021 11:11:37 -0700 (PDT)
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 SE6LfcIkls7N for <bmwg@ietfa.amsl.com>; Sun, 10 Oct 2021 11:11:32 -0700 (PDT)
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 3D3933A0BB2 for <bmwg@ietf.org>; Sun, 10 Oct 2021 11:11:31 -0700 (PDT)
Received: from [192.168.1.146] (host-79-121-40-197.kabelnet.hu [79.121.40.197]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 19AIBJSH069604 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <bmwg@ietf.org>; Sun, 10 Oct 2021 20:11:24 +0200 (CEST) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-40-197.kabelnet.hu [79.121.40.197] claimed to be [192.168.1.146]
References: <163388281019.324.12493516140419452318@ietfa.amsl.com>
To: "bmwg@ietf.org" <bmwg@ietf.org>
From: Gábor LENCSE <lencse@hit.bme.hu>
X-Forwarded-Message-Id: <163388281019.324.12493516140419452318@ietfa.amsl.com>
Message-ID: <0b76d24f-90b1-0cff-57a8-d8b3c5ffda92@hit.bme.hu>
Date: Sun, 10 Oct 2021 20:11:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <163388281019.324.12493516140419452318@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------F9AC2EFD61648FC71EEF1E22"
Content-Language: en-US
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.197; 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-wuwien-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/s3ymGlXDNEJq0XrFMsS7g-mGpVI>
Subject: [bmwg] An improved version of our I-D: draft-lencse-bmwg-benchmarking-stateful-02
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: Sun, 10 Oct 2021 18:11:37 -0000

Dear BMWG List Members,

We have gained some practical experience with the methodology for 
stateful NATxy gateways by measuring the scale-up of iptables. There 
were two similar measurement series:

1. Examining how the performance of iptables scales up with the number 
of CPU cores. The results are available from: 
https://mailarchive.ietf.org/arch/msg/v6ops/zwJJGAFG3BRtuO74IyoocP6kAL0/

2. Examining how the performance of iptables scales (degrades) with very 
high number of connections (up to 800 million). The results are 
available from: 
https://mailarchive.ietf.org/arch/msg/v6ops/axKSI8hnEbQPzPZGxPoS7KaLmXM/

Based on the experience of the about tests, we have refined the 
methodology. The novel thing is how to ensure repeatable results by the 
proper setting of the timeout values. Now we can guarantee that the 
connection tracking table of the DUT always contains the required number 
of elements, if its size is large enough and no connection tear down 
happens due to timeout during the measurements.

Section 4.3 was completely rewritten, and Section 4.4 was also adjusted 
as needed. Please see the details here: 
https://www.ietf.org/rfcdiff?url2=draft-lencse-bmwg-benchmarking-stateful-02

We welcome all comments!

Best regards,

Gábor


-------- Továbbított üzenet --------
Tárgy: 	New Version Notification for 
draft-lencse-bmwg-benchmarking-stateful-02.txt
Dátum: 	Sun, 10 Oct 2021 09:20:10 -0700
Feladó: 	internet-drafts@ietf.org
Címzett: 	Gabor Lencse <lencse@sze.hu>, Keiichi Shima <keiichi@iijlab.net>




A new version of I-D, draft-lencse-bmwg-benchmarking-stateful-02.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

Name: draft-lencse-bmwg-benchmarking-stateful
Revision: 02
Title: Benchmarking Methodology for Stateful NATxy Gateways using RFC 
4814 Pseudorandom Port Numbers
Document date: 2021-10-10
Group: Individual Submission
Pages: 15
URL: 
https://www.ietf.org/archive/id/draft-lencse-bmwg-benchmarking-stateful-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-lencse-bmwg-benchmarking-stateful/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-lencse-bmwg-benchmarking-stateful-02

Abstract:
RFC 2544 has defined a benchmarking methodology for network
interconnect devices. RFC 5180 addressed IPv6 specificities and it
also provided a technology update, but excluded IPv6 transition
technologies. RFC 8219 addressed IPv6 transition technologies,
including stateful NAT64. However, none of them discussed how to
apply RFC 4814 pseudorandom port numbers to any stateful NAT (NAT44,
NAT64, NAT66) technologies. We discuss why using pseudorandom port
numbers with stateful NAT gateways is a hard problem and recommend a
solution.



The IETF Secretariat