Network, IT: сетевое тестирование. Общие концепции (Best/Worst practices, repeatability/reproducibility, reference tests, isolated env), виды нагрузочных тестирований (perfomance, load, stability/reliability, stress), критерии успешности. Заметки IETF BMWG.

• TODO сюда и в другие статьи о сетевом тестировании надо перенести из других заметок все наработки
• Тут только общая специфика, конкретика по конкретным тестам/продуктам в соответствующих множественных статьях

• SUTs – Systems Under Test
• DUTs – Devices Under Test
• TGs – Traffic Generators
• (BMWG IETF 111) Базовые принципы BMWG IETF:
  • “One of the goals generally that we promote in BMWG is having repeatability – it is a keystone of BMWG“.

EANTC Carsten Rossenhoevel
In testing, it is important to document any tiny detail of the test setup and environment. The goal is to ensure reproducibility and comparability of results. An under-specification of details was one of the issues with RFC3511.
Configurable TCP parameters can highly influence benchmarking test results. With the goal to achieve reproducible test results we decided to specify TCP parameter values, by the way aligned with defaults of most of today's operating systems.

• • “Document and move on” – весь тест setup (конфигурации) должен быть задокументирован, но при этом нельзя задокументировать все (длина кабелей, как пример), поэтому калибровочные тестирования (reference test, back to back test, baseline, pretest/pre-tests, etc) и их результаты крайне важны (подробнее ниже отдельно)
  • Все согласны что “minimize the amount of variables that you have in your test bed“, но иногда без доп. устройств не обойтись (несколько генераторов, промежуточные коммутаторы и проч), но в таких случаях ценность “калибровочного” тестирования еще более важна.
  • (тут и в НТ) Повторяемость результатов нагрузочных тестирований в NFV/VNF и тем более в облаке – отдельная боль и история. Подробнее в примерах ниже, но нужно учитывать, что в примерах DUT/SUT полностью под управлением, нет никаких облаков (только виртуализация!) и даже с учетом полного контроля была проблема с повторяемостью результатов для VPP (до тюнинга/мониторинга ОТ –  ограничения hardware, отключение излишних функций процессора, мониторинг счетчиков CPU и методики – судя по описанию линейный поиск вместо дихотомии/binary search)! Поэтому они открыто пишут что даже в таком случае ключ – знание всех компонентов. Примеры (не только мои):
    • BMWG

• I'm not really sure how you would test this with consistent results.

  • • И при тестировании устройств, обрабатывающих пакеты на базе Commodity CPU (servers), например VPP, сложно добиться идеальной повторяемости, так же как zero loss/non drop rate (NDR). При этом VPP тестируют как NDR (0%, zero loss tolerance) и PDR (0.5% loss). Пример тестирования.
    • Результаты CheckPoint NSX CloudGuard CPS (connections per second) (*Accuracy range: +/-15%)
    • Проблема только в commodity servers и все компоненты под управлением, что позволяет измерить/задокументирорвать/частично или полностью исключить факторы, влияющие на производительность.

      Cloud based scenarios. I'm not really sure how you would test this with consistent results.
      
      Benchmarking VNFs - sounds basic and straightforward. They are expected to behave like networking devices. But ... VNFs are not physical devices, they are SW workloads on commodity servers/CPUs.
      
      
      Not basic and straightforward at all
      Need to apply knowledge of the overall system – know your complete Hardware and Software stack (cross-disciplinary).
      Measurement problems encountered ...
      The learning curve
      • Problem: Throughput - test trials yielding non-repeatable results, including RFC2544 tests.
      • Problem: Packet latency and latency variation vary greatly across tested VNF systems. Min/max/avg latency and latency variation (jitter) measurements not enough; they hide periodic latency spikes, and packet latency patterns.
      • Problem: Modern computers/CPUs provide lots of telemetry data and performance counters, BUT readings not always repeatible, which ones do you trust
      
      Resolution - identify and quantify system-under-test bottlenecks
      • HW: NIC, PCI lanes, CPU sockets, Memory channels.
         • Operate within their deterministically working limits - make sure they are not DUTs :)
         • Intelligent CPUs – control their “intelligence” !
      • OS: kernel modules interferring with tests by using shared resources e.g. CPU cores
         • Isolate CPUs, avoid putting DUT workloads on non-isolated cores.
         • Still kernel is interferring - more on this later.
         • Work with CPU hardware vendors to interpret the counters
         • Work with community and vendors on improving network-centric telemetry tools for computers/CPUs
            • Counters accuracy
            • Reporting clarity
            • Measurements repeatibility
      • VM environment:
         • Hypervisor entries/exits: hard to track the impact, but not impossible, just labour intensive
      
      
      Adjust testing methodologies
         • RFC2544 binary search start/stop criteria – LowRate-to-HighRate, HighRate-to-LowRate.
         • Linear throughput, packet loss scans.

  • Предположения – это плохо для RFC. Нужно описывать все явно (explicit).

I am trying to be quite literal and precise here, and my overall sense is that the text has many assumptions built into it that I would like to make explicit.

> DUT during the start of the test. For example it can be 20% or 25% it must not spike to 100%.
As an example, at the start of the test, the CPU usage is 10%. If at any point CPU usage is 100%, it fails, but if it never exceeds 99.9%, it passes?

> As the test says the memory should not increase with respect to time. If it is then it is a failure.
Say the memory usage at the start of the test is 25%.
If it momentarily increases to 25.1% and then goes back down again, is that a failure?
If it ends the test at 25.1%, is that failure?

> All the tests are said to be run for N times and collect N samples. 
Are those N same? What should be the default value for the N samples? How do we decide that there are sufficient samples? 
I find it a bit odd that there is no recommendation provided here. There should be a min and max range of values the N can take so that we know we have done enough tests to conclude on the results. 
Is there are specific waiting time required between running those tests N times? This feel like very under specified to me.

• (forticast подкаст о fortitester) Крупные кастомеры тестируют перфоманс не только при тендере, но и перед апдейтом на мажорные версии ПО для теста именно в тех условиях, в которых продукт работает у них перед обновлением на тысячах устройствах софта.
• The test setup MUST be contained within an Isolated Test Environment (see Section 3 of [RFC6815]): 198.18.0.0/15 (198.18.0.0-198.19.255.255) – Диапазон выделен под лаборатории нагрузочного тестирования (Benchmarking) в соответствии с RFC2544 и уточнением в RFC6815, что данный диапазон не должен быть доступен в Интернет во избежание конфликтов. Опять же, никто при этом не отменяет использование RFC1918, но для больших сетей с крупными лабораториями лишний блок /15 явно не помешает.

The Security Directorate Review usually goes more smoothly when the Security Considerations section (9) re-enforces that the scope of this document is a laboratory Isolated Test Environment (and not production network testing).

• Калибровочный тест = reference test, pre-test, base value, baseline test. О важности калибровочного теста так же написано выше (IETF 111). Важность reference test обозначает и RFC 8219 (исключение проблемы с ограничением производительности генератора путем self-test loopback тестирования).
  • с ними происходит сравнение performance результатов DUT
  • они являются отправной точкой для начала тестирования (проверка корректности сборки стенда)
  • проверяется производительность генератора, например, проверяем, что у нагрузчика есть запас как минимум в 10% от желаемой для нас производительности

The reference test SHOULD be performed before the benchmarking tests (described in section 7) start.

E.g. if one would like to use the Tester let us say up to 5 million frames per second rate,  then first the Tester should be looped back and be tested at 5.5M fps rate, if it can surely transmit and receive the frames within the required duration (The 10% is the performance reserve. It is a high handed choice, I usually use this value.)

 https://datatracker.ietf.org/doc/html/rfc8219
   9.2.1.  Requirements for the Tester
Before a Tester can be used for testing a DUT at rate r queries per second with t seconds timeout, it MUST perform a self-test in order to exclude the possibility that the poor performance of the Tester itself influences the results.  To perform a self-test, the Tester is looped back (leaving out DUT).

• • конфигурация калибровочного тестирования вида “отключение софта и тестирования платформы”,  а не полного исключения из топологии DUT с ожиданием высокий результатов иногда проваливается – в редкой, но реальной практике в таком тестировании могут быть более низкие результаты в сравнении со стандартным тестом т.к. напр. по умолчанию прерывания не распределяются между разными процессами (soft RSS) или настроена одна очередь на сетевом интерфейсе, в отличии от отсутствия режима калибровки (RPi case).

[bpm] The section 5 recommends reference test to ensure that the maximum desired traffic generator's performance. Based on the reference test results it can be identified, if the external device added any impact on traffic generator's performance.
[bpm] Here we discuss the traffic generator performance, and this can be confirmed by doing reference test.
[bpm] We will add more content in section 5 to provide more details about reference test.

• • при этом не все проблемы можно нивелировать pretest/reference test/calibration – пример в виде микроберстов от Vratko Polak (сотрудник Cisco, автор draft MLRsearch), которые формирует DUT, но из-за которых генератор имеет меньшую производительности в сравнении с значением pretest.

    It could be DUT only (no problem, testing DUT as expected), it could be TG only (can be mitigated by TG self-test and using small enough loads).
    
    But it could also be an interaction between DUT and TG. Imagine a TG (the Traffic Analyzer part) which is only able to handle incoming traffic up to some rate, but passes the self-test as the Generator part has maximal rate not larger than that. But what if DUT turns that steady rate into long-enough bursts of a higher rate (with delays between bursts large enough, so average forwarding rate matches the load).
    
    This way TA will see some packets as missing, even though DUT has processed them correctly. And the loss ratio may depend on trial duration (if TA has some buffers before its bottleneck).
    
    Not sure if I described the scenario well enough, but my point is that even with TG self-tests, the MLRsearch results may not describe DUT only.

• Измерение PPS на NGFW довольно сомнительная идея, может пригодиться для сравнения данных тестов между собой, но о характеристиках продукта говорит плохо

Измерение скорости NGFW в PPS.
Иногда меня озадачивают таким вопросом: сколько PPS выдает данная модель NGFW. 

Дело в том, что packet per second - это метрика для измерения скорости роутеров, поскольку они не занимаются анализом трафика. В случае с анализаторами трафика нужно переходить на следующий уровень абстракции: измерять в транзакциях в секунду (TPS). И тогда нужно задавать другой вопрос: "Сколько транзакций HTTP длиной 64 килобайта в секунду может проанализировать ваш NGFW".

Да, я не спорю, что есть индивидуумы, которые умудряются сравнивать NGFW по PPS, но, на мой взгляд, это сравни обсуждению количества еды в атомах. Сколько атомов вы съедаете за день? ) А ведь атомы воды или атомы из колбасы будут по-разному восприняты вашим организмом. Можно ли сказать, что человек употребивший 1 миллиард молекул более прожорливый, чем другой человек, который тоже употребил 1 миллиард молекул? Нет ) Ведь у одного могла быть вода, а у другого стейк ) Точно также и пакет HTTP/1 транзакции или HTTP/2 или SMTP или SMB транзакции по-разному обрабатывается внутри NGFW. И сбор в единое целое файла из разных пакетов внутри HTTP или SMB или HTTPS займет разное время, поэтому важно не число пакетов, а что в них и насколько сложно эти пакеты было собрать в один файл для анализа.

Виды нагрузочных тестирований (НТ)

1. Performance test: по результату получается предельная нагрузка на систему, можно определить ожидаема она или нет.
2. Пример измеряемых величин: THPT, CPS, TPS, PPS, количество пользователей/сек, операций подписи/сек, операций хеширования/сек
3. Пример решаемых задач/типов НТ
   1. Load test (определение производительности): способность системы работать в рамках предъявляемых требований
   2. Scalability (масштабируемость): – есть ли она вообще и как ее можно описать (линейная Big O(x), ближе к логарифму – O( log(x) ), другая)
   3. Stability/Endurance test: способность системы работать с нагрузкой в рамках предъявляемых требований (чаще всего на 10-20% меньше максимальных требований) длительный интервал. Оценка потребления ресурсов (память ОП, память ЖД, деградация по трендам и проч). Оценка восстановления после тестирования.

4. - Функциональные тесты под нагрузкой. Ожидания отсутствия или минимального влияния на обработку трафика функциональных действий (переключения кластера, обновления ПО).

   1. Stress test: способность системы работать с нагрузкой выше заявленных требований без падений (reboot, OOM, BSOD, segfault, etc) и деградаций трендов (или в пределах допустимого падения/деградация). Оценка потребления ресурсов. Оценка восстановления после тестирования.
      • Soak test – продолжительный stress test
      • Spike test – короткий stress test

- Тесты устойчивости под атаками DoS. Ожидания отсутствия влияния на management plane атак на data plane и изоляция между VF (VDOM/Context).

- Ethernet device reliability must be tested under extreme load conditions. (Agilent)

- Stateless DOS SYN FLOOD тестирование при тестировании stateful firewall превращается не совсем в stateless т.к. устройство с коннекциями пытается работать stateful и включает механизмы блокировки атак на основе состояний stateful (напр. от своего лица отправляет syn-ack - см. tcp intercept). Хотя со стороны генератора это чистый stateless тест.

Критерии успешности

Пример критериев успешности bi.zone для тестирований NGFW (personal/cusom appmix – appmix заказчика) в тестирования CPS, CC, THPT, THPT + Attacks (по факту для атак не указаны критерии успешности). Так же они перечислены в самих показателях.

When is a test considered failed?
• Ways to check in a specific test tool & network
     • Failed Connections in tool test summary • Missed packets • Latency
     Something as simple as a ping can help indicate changes in latency through a device as it starts to become overloaded.
     Other network analysis tools can also help detect dropped packets or latency
     Each test tool will have different ways to do this so you will need to learn the tool to know the best way.

• Ways to check on the device itself
     • Full Queues • Dropped packets • CPU Load
         • show asp drop : any ongoing drops here indicate oversubscription and a failed test ((ASP - Accelerated Security Path))
         • show cpu : as cpu gets up above 95% the chance of oversubscription gets higher

По продолжительности Stress/Stability тестов

Продолжительность soak тестирований (на стабильность) – до 72 часов. В среднем 24.

По факту:

• • Стрессом в 10-20 мин мы обнаружим большую часть проблем
  • Но даже на практике мы обнаруживали проблемы (напр. перезагрузки модулей/систем из-за high load) и на интервале 20-30 мин

Из того, что нашел в интернете (от 2 до 72 часов):

• • Сбербанк – 24 часа
  • Neohapsis Lab (сейчас внутри Cisco) использовали двухчасовой тест RFC 2544 на базе Ixia для Soak тестов “Soak tests were configured to run for two hours.”
  • Spirent – «Perform an overnight soak test – send traffic while constantly flapping routes. What happens? Do you find memory leaks?”
  • Viavi  – как расширение к тесту RFC 2544 “ Longer term test or “soak test” which can be run up to 24 hours”
  • JDSU – “Long-term (i.e. 72 hour) soak tests”
  • DRAFT EVPNTEST – The DUT must run with traffic for 24 hours. Причем они раскрыли метрики: проверяют на отсутствие сбоев ПО, всплесков CPU (по spike в графиках) и утечи памяти (по негативному росту использования памяти со временем в графиках).

   Every hour check for memory leak in EVPN process, CPU usage and crashes in DUT.

   Measurement :
   Take the hourly reading of CPU, process memory.  There should not be any memory leak, crashes, CPU spikes.  The CPU spike is determined as the sudden increase of CPU usage to 100 percent compared to the average usage.  The average value vary from device to device.  Memory leak is determined as the increase of memory usage with respect to time.  The expectation is under steady state the memory usage for EVPN process should not increase with respect to time.  The measurement is carried out using external server which polls the DUT using automated scripts which captures the CPU usage and process memory.

подтверждение результата производительности

• • обеспечение повторяемости результатов и декларация стабильного результата в datasheet
  • вылавливание багов
    • примеры с периодической просадкой из-за особенностей реализации обработки/наличия периодических ресурсозатратных задач (java stop the world)
    • регресс производительности со временем (resource leak)
    • тестирование с большого размера буферами, которые способны какое-то время компенсировать всплески трафика (microbursts, back-to-back), но рано или поздно переполняются

One possible cause is an infrequent short pause in DUT processing. (Imagine a Java application doing a "stop the world" garbage collection.) The behavior is bad (inconsistent), because some trial measurements get lucky and avoid the pause, and the probability and/or severity of the pause increases with trial duration.
Stop the World Event - All minor garbage collections are "Stop the World" events. This means that all application threads are stopped until the operation completes. 

Another possible cause is a resource leak of some kind. After a period of good performance, the performance starts declining and the decline accelerates until DUT stops working entirely.

> Such a thing(s) can be the buffering of the SUT
Possible, but the DUTs we test in CSIT have all small enough buffers (thousands of packets, not millions).

Утечки памяти

Как я определял утечку:

Я брал среднее количество (commit & available) между интервалами, сравнивал их между собой и добавлял сравнение с допустимым отклонение - т.е. отклонение менее какого то процента (напр. 5) - who cares.

Можно добавить статистические ‘навороты’, но принцип тот же:

mem_crossing = interval_crossing( { 'min':mem_stats_A['avg']-mem_stats_A['sko'], 'max':mem_stats_A['avg']+mem_stats_A['sko'] }, { 'min':mem_stats_B['avg']-mem_stats_B['sko'], 'max':mem_stats_B['avg']+mem_stats_B['sko'] } )

т.е. происходит сравнение доверительных интервалов + сравнение ср. арифметического на 1 и 3-й стадии, если пересечения есть и ср.ариф первой стадии больше, чем на последней, то рост отсутствует в обратных случаях есть

МЕТОДИКИ (на основе информации от perf. eng. cisco)

Методики должны быть простыми, понятными и полными для простой репликации тестирования/диагностики проблем, это относится в том числе и методикам, реализованным на базе RFC, которые могут быть недостаточно просто/полно описаны.

• The test should be reasonably easy to describe. Complex tests are generally harder to diagnose issues and troubleshoot problems, and much harder to replicate.
• Standards based tests can help if they are well documented and easy to replicate. But if not, they can just obfuscate and confuse.

• When you buy a car, how do you compare two different models?
• Performance: Horsepower, Torque, 0-60, 0-100, quarter mile (402.336 meters!)
• Efficiency: Miles per gallon (or L / 100 km)
• Capabilities: Seats, Carrying capacity, Towing Capacity

To correctly determine the optimum operation of a security device, the performance measures should be mapped over the full operating range of the device. Due to the complexity of more than 26 variables, options and features, and the time and cost impacts resulting from all those permutations (67 million if every variable was binary!), nobody can test every performance variation. And changing just a few of any of these can change the test results drastically!

Example:
     Test specific conditions: In L2 Transparent mode, how many MAC addresses are tracked?
     Deployment mode: L3 routed vs L2 transparent vs NGIPS vs IDS
     Basic Firewalling features: large dynamic routing tables or huge ARP tables
     IPS: Numbers of rules, custom rules, multiple policies
     Network analysis policy: inspection depth, preprocessor settings
     File Policy: are the files known or unknown, size of files inspected
     SSL Decryption policy: Known Key or MITM?
     Dynamic cut-through: Bypassing inspection for some traffic or at a certain point in the flow

REAL WORLD & IDEAL TESTS (на основе информации от perf. eng. cisco)

Подробнее в datasheet.

Интересные заметки из mail list BMWG.

• Большой пул RFC BMWG (44+)

Метры “интернетов” IETF в переписках участвуют еще!

https://www.computer.org/
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>, Scott Bradner
<sob@sobco.com>
Cc: draft-ietf-bmwg-ngfw-performance@ietf.org, bmwg-chairs@ietf.org,
IETF <ietf@ietf.org>, bmwg@ietf.org, The IESG <iesg@ietf.org>

1992 by Network World
https://sobco.com/nww/1992/bradner-1992-12-28.html
First, a bit about my background. I've been working around Harvard University for almost 28 years.

Интересные соображения old’ов IETF – RFC ((а по факту относится и к методикам тестирования)) можно написать по разному: с точки зрения “совместной работы над чем-либо” (good faith) или с точки зрения “зарабатывания денег/получения конкуретного преимущества/уменьшение качества (profit). Зачастую не нужно пытаться зафиксировать каждую возможную деталь – слишком серьезные траты по времени и сомнительный профит.

Some of that ambivalence, IMO, comes from the differences between trying to write specs for implementers who want to work together in good faith to produce interoperable implementations, using those specs for guidance versus writing specs for regulators and contract-enforcers who are concerned about specifications that can identify implementations that try to cut corners or offer variations to gain, e.g., competitive advantage.

I remember some discussions very early on, long before OSI turned into a poster child for the other point of view, about how it was better to reach agreements on a design or protocol, document it mostly for the reference of those who agreed and those who might follow in their footsteps, and then move on rather than spending weeks, months, or longer trying to pin down every possible detail.

Так же писали про Robustness Principle. Из описания wiki это сомнительный принцип с точки зрения ИБ (SQLi? не говоря про пример с TOR даже, описанный ниже), но об этой точке зрения мало кто думал при старте разработки “интернетов”.

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
From 2015 to 2018, in a series of Internet-Drafts, Martin Thomson argues that Postel's robustness principle actually leads to a lack of robustness, including security.
In 2018, a paper on privacy-enhancing technologies by Florentin Rochet and Olivier Pereira showed how to exploit Postel's robustness principle inside the Tor routing protocol to compromise the anonymity of onion services and Tor clients.

Тестирования Gabor iptables.

>>> I used two identical HPE ProLiant DL380 Gen10 (DL380GEN10) servers with the following configuration:
>>> - 2 Intel 5218 CPUs (the clock frequency was set to 2.3GHz fixed )
>>> - 256GB (8x32GB) DDR4 SDRAM @ 2666 MHz (accessed quad channel)
>>> - 2-port BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller (used with 10Gbps DAC cables)

Существенная деградация производительности с ростом количества соединений только при 400-800 МЛН соединениях. И даже это, потенциально, предел связанный с ограничением оперативной памяти, а не размером таблицы. Потом это (отсутсвие этого ограничения в софте) подтвердилось при увеличении количества памяти и разбивки на две NUMA NODE (четные ядра на нулевой, нечетные на первый). По расчетам 2.7 млн. соединений занимают 1GB RAM.

https://mailarchive.ietf.org/arch/msg/v6ops/zwJJGAFG3BRtuO74IyoocP6kAL0/#
The degradation of the throughput is also moderate, except at the last column. I attribute the higher decrease of the throughput at 400,000,000 connections (as well as that of the maximum connection establishment rate) to NUMA issues. In more detail: this time nearly the entire memory of the server was in use, whereas in the previous cases iptables could use NUMA local memory (if it was smart enough to do that). Unfortunately I cannot add more memory to these computers to check my hypothesis, but in a few weeks, I hope to be able to use some DELL PowerEdge R430 computers that have only two NUMA nodes and 384GB RAM, see the "P" nodes here:https://starbed.nict.go.jp/en/equipment/
>>> I wanted to follow my original plan included in my IETF 111 presentation to measure both the maximum connection establishment rate and the throughput using the following number of connections: 1 million, 10 million, 100 million, and 1 billion. However, the DUT became unavailable during my tests with 1 billion connections as the connection tracking table has exhausted its memory. Thus I have reduced the highest number of connections to 500 million.

The CPU has 2 NUMA nodes, cores 0, 2, ... 14 belong to NUMA node 0, and 
cores 1, 3, ... 15 belong to NUMA node 1.
I have also checked that the maximum memory consumption with 400,000,000 
connections was below 150GB, thus I had a chance to perform measurements 
also with 800,000,000 connections (thus I could exceed the 400,000,000 
limit of the HPE server used for the preliminary measurement).

С ростом количества ядер производительность так же росла почти линейно (это хороший признак для масштабирования). Задействованы было 8 ядер из 32.

>>> The servers have 4 NUMA nodes (0, 1, 2, 3) and the NICs belong to NUMA node 1. All the interrupts caused by the NICs are processed by 8 of the 32 CPU cores (the ones that belong to NUMA node 1, that is cores from 8 to 15) thus regarding our measurements, the DUT (Device Under Test) is more or less equivalent with an 8-core server. :-)

I have performed the scale-up tests of iptables using 1, 2, 4, 8, and 16 
CPU cores. I used two "P" series nodes of NICT StarBED, which are DELL 
PowerEdge R430 servers, please see their hardware details here: 
https://starbed.nict.go.jp/en/equipment/

I have done some tuning of the parameters: number of connections: 
4,000,000; src ports: 4,000; dst ports: 1,000; conntrack table size: 
2^23; hash size = connection table size.

I think that the results are quite good, both the number of connections 
per second and throughput scaled up quite well with the number of CPU 
cores.

num. CPU cores 1 2 4 8 16
src ports 4,000 4,000 4,000 4,000 4,000
dst ports 1,000 1,000 1,000 1,000 1,000
num. conn. 4,000,000 4,000,000 4,000,000 4,000,000 4,000,000
conntrack t. s. 2^23 2^23 2^23 2^23 2^23
hash table size c.t.s c.t.s c.t.s c.t.s c.t.s
c.t.s/num.conn. 2.097 2.097 2.097 2.097 2.097
num. exp. 10 10 10 10 10
error 100 100 100 1,000 1,000
cps median 223.5 371.1 708.7 1,341 2,383
cps min 221.6 367.7 701.7 1,325 2,304
cps max 226.7 375.9 723.6 1,376 2,417
cps rel. scale up 1 0.830 0.793 0.750 0.666
thorughput median 414.9 742.3 1,379 2,336 4,557
thorughput min 413.9 740.6 1,373 2,311 4,436
thorughput max 416.1 746.9 1,395 2,361 4,627
tp. rel. scale up 1 0.895 0.831 0.704 0.686

As you can see, the performance of a 16-core machine is about 10x of the 
performance of a single core machine. I think it is very good results 
for the scale-up of a stateful NAT44 implementation.

Проводил BASELINE/REFERENCE тест как я понимаю

- Setting a baseline, e.g. by measuring base IPv4 forwarding would be useful in establishing how much extra work is involved doing the translation.
---
it might be useful to provide a baseline to give an idea of the additional cost associated with the extra treatment of packets.
---
> Linux kernel routing IPv4 IPv6
> thorughput median 9.471 9.064
> thorughput min 9.443 9.029
> thorughput max 9.486 9.088