Re: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814
Gabor LENCSE <lencse@hit.bme.hu> Fri, 22 July 2022 11:59 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 3B345C16ED01 for <bmwg@ietfa.amsl.com>; Fri, 22 Jul 2022 04:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.806
X-Spam-Level:
X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 dZtlSyXE4T04 for <bmwg@ietfa.amsl.com>; Fri, 22 Jul 2022 04:59: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 DC8F6C14792F for <bmwg@ietf.org>; Fri, 22 Jul 2022 04:59:30 -0700 (PDT)
Received: from [192.168.0.192] (host-88-132-252-9.hirsat.hu [88.132.252.9]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 26MBxF7V052622 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <bmwg@ietf.org>; Fri, 22 Jul 2022 13:59:21 +0200 (CEST) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-88-132-252-9.hirsat.hu [88.132.252.9] claimed to be [192.168.0.192]
Content-Type: multipart/alternative; boundary="------------2n4e5Yu8H0HAg9VvGnKDSQWt"
Message-ID: <dd3aa7b5-eebf-5f30-8b44-568f19ce5e39@hit.bme.hu>
Date: Fri, 22 Jul 2022 13:59:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: "bmwg@ietf.org" <bmwg@ietf.org>
References: <CH0PR02MB798001E3E9D0D9977474DFF3D3CF9@CH0PR02MB7980.namprd02.prod.outlook.com> <147F6665B1980A4496AE5D06F45C002A025698F66C@hold.ahol.co.hu> <cc1ddc52-6e3b-585a-711c-1f7c7aef05f5@hit.bme.hu> <CH0PR02MB7980AD83F6EC030548630D8AD38E9@CH0PR02MB7980.namprd02.prod.outlook.com> <1bb27f3e9788472180cd3ea39251d839@huawei.com>
From: Gabor LENCSE <lencse@hit.bme.hu>
In-Reply-To: <1bb27f3e9788472180cd3ea39251d839@huawei.com>
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=88.132.252.9; helo=[192.168.0.192]; 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/v-GK8HyBweydV7DXFPscLmYWvtQ>
Subject: Re: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 22 Jul 2022 11:59:36 -0000
Dear Vasilienko, Thank you very much for your review and support for the draft! I will need to think about your suggestion to include other stateful connections than NATxy (e.g. load balancers, IPS/IDS, FWs). I did not think of them at all. My original aim was to address stateful NAT64. Stateful NAT44 came into the picture through the resilient nature of siitperf: the user can specify the IP version for each side independently. As for its stateful branch, currently it covers NAT64 and NAT44, but I have omitted the support for stateful NAT66 or NAT46 to save work. In the draft, I wanted to talk about the general case, that's why is has NATxy in its title. What does the WG think about this extension? Is there such a need? Should they be addressed by the same document, or should another one started? As for the speeds you mentioned below, currently siitperf uses DPDK to achieve high enough performance, and it is workable up to a few MPPs, please see its self-test results in: G. Lencse, "Design and Implementation of a Software Tester for Benchmarking Stateful NATxy Gateways: Theory and Practice of Extending Siitperf for Stateful Tests", /Computer Communications/, vol. 172, no. 1, pp. 75-88, August 1, 2022, DOI: 10.1016/j.comcom.2022.05.028 Full paper in PDF <http://www.hit.bme.hu/~lencse/publications/ECC-2022-SFNATxy-Tester-published.pdf> As for my measurement results, they are in the v6ops draft: https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability In the table shown in Figure 2, you can see the results of the iptables stateful NAT44 implementation. At 16 CPU cores, they are about 4.5Mppps. (It is to be interpreted as the number of all frames per second using bidirectional traffic. The number of packets per direction is the half of it.) As for mentioning RFC 4814, perhaps it is somewhat subjective. I was not aware of it, when I implemented the very first version of siitperf. And it made a great impression on me, when Al mentioned RFC 4814. It the title of the draft, I wanted to emphasize that our method aims to comply with the requirements of RFC 4814. Of course, "using RFC 4814Pseudorandom Port Numbers" may be omitted from the end of the title, while the support of RFC 4814 is being kept. Best regards, Gábor On 7/21/2022 10:03 AM, Vasilenko Eduard wrote: > > Hi Gábor and Keiichi, > > Your draft is covering a new and unique topic: “*stateful connections > benchmarking*”. > > Hence, I believe that it is a good topic for BMWG adoption. > > But I believe that the name of the draft has too high a scope. > > All stateful devices our days are software-based (I remember a few > hardware-based in history, but they have not become successful). > > Hence, all of them have limitations on: > > 1.Gbps > > 2.Mpps > > 3.Cps (connections per second) > > 4.Upper size of the connection table > > You are addressing only the last two (most challenging) in the draft > that is enough (IMHO). > > I do not propose to extend the draft for Gbps and Mpps, the draft is > already big enough. > > But the name of the draft may mislead people that you are covering all > aspects of NAT benchmarking that is not the case. > > You are covering a unique and most challenging part. > > The name that I have proposed above generalizes for all stateful > devices, I have omitted “NAT”. > > Because your methodology could be easily extended to load balancers, > IPS/IDS, FWs. > > If you do not want to generalize then the proper name may be “stateful > connections benchmarking for NAT”. > > PS: “Pseudorandom Port Numbers” is not so big a topic to insert into > the document name. > > Eduard > > -----Original Message----- > > From: bmwg<bmwg-bounces@ietf.org> <mailto:bmwg-bounces@ietf.org> On Behalf Of MORTON JR., AL > > Sent: 2022. május 16., hétfő 19:06 > > To:bmwg@ietf.org > > Cc:bmwg-chairs@ietf.org > > Subject: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814 > > BMWG, > > This message begins a WG Adoption call for > > Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 > > Pseudorandom Port Numbers > > https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful-03 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful-03__;!!BhdT!hTy1710CSgJdNMXvPEnKSSPUIXWuOEyvP-PYfCpB5VTet3Pfz7Eg5gzNqWpY5wymkbiGNCa9Db6Pusw$> > > The WG Adoption will run from May 16 to June 20, 2022. > > BMWG has discussed this draft at several meetings and on the list. There has been a moderate level of interest. > > Please review the latest draft and send comments and/or indications of support to the bmwg-list (bmwg@ietf.org) and/or to me (acmorton(at)att.com). > > Thanks and best regards, > > Al > > bmwg co-chair >
- [bmwg] WG Adoption Call: Stateful NATxy Gateways … MORTON JR., AL
- Re: [bmwg] WG Adoption Call: Stateful NATxy Gatew… Sandor R. Repas Dr.
- Re: [bmwg] WG Adoption Call: Stateful NATxy Gatew… Gábor LENCSE
- Re: [bmwg] WG Adoption Call: Stateful NATxy Gatew… MORTON JR., AL
- Re: [bmwg] WG Adoption Call: Stateful NATxy Gatew… Vasilenko Eduard
- [bmwg] the potential falsifying effect of storing… Gabor LENCSE
- Re: [bmwg] WG Adoption Call: Stateful NATxy Gatew… Gabor LENCSE
- Re: [bmwg] WG Adoption Call: Stateful NATxy Gatew… Gabor LENCSE
- Re: [bmwg] WG Adoption Call: Stateful NATxy Gatew… Vasilenko Eduard