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
>