Re: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814

[Vasilenko Eduard <[e-mail]>]

Please, do not restrict the draft to “NAT on DPDK only”.
You are already general enough to claim benchmarking for *any* NAPT.
Ed/
From: bmwg [mailto:[e-mail]] On Behalf Of Gabor LENCSE
Sent: Friday, July 22, 2022 2:59 PM
To: [e-mail]
Subject: Re: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814


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 <[e-mail]><mailto:[e-mail]> On Behalf Of MORTON JR., AL

Sent: 2022. május 16., hétfő 19:06

To: [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

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 ([e-mail]<mailto:[e-mail]>) and/or to me (acmorton(at)att.com).



Thanks and best regards,

Al

bmwg co-chair