Network: сетевое тестирование. Метрики и показатели (throughput/goodput, delay RTT/OWD, jitter, CPS/tear down, CC, TPS). Инструменты тестирования задержки (PING, OWAMP, SockPerf)

  • Про измерение MOS отдельно в статье Voice
  • Точность определения показателя обычно не менее 5% (между попытками подряд или между fail/success результатами)

Логичный слайд из презентации Кода Безопасности.

Summary bi.zone для NGFW.

Очень крутой слайд bi.zone с тем, что в среднем нужно измерять на устройствах разного уровня модели OSI (отсюда), так же укладывается и информация с результатами.

Он же с дополнениями:

    • L7 (NGFW, PROXY, Stateful FIREWALL) – CC, RPS, THPT/TT (CPU/memory)
    • L5-6 – TPS, RPS, (De)Compression (SSL ASIC/Compression ASIC/CPU/Memory)
    • L4 – CPS, CC (FPGA)
    • L3 – (packet broker, switches) – Packets, THPT (FPGA)
    • L2 – Frames, THPT (NIC, FPGA)
  • Производительность безусловно отличается от “режима” (функций работы) устройства.

 

5 Considerations: Sizing Your Next-Gen Firewall (NGFW) – хорошее видео от практика. Наибольший акцент делает на CPS, наименьший на CC.

 

Задержка (Delay, latency)

  • Ixia в своем отчете IxNetwork по задержке включает все итерации тестирования – задержка с потерями даже в случае если потери были выше порога туда так же попадает.
  • Величины:
    • sec : number of seconds
    • msec : number of milliseconds
    • usec : number of microseconds
    • nsec : number of nanoseconds
  • SFP модуль вносит задержку порядка 200 нс
Виды/способы измерения задержки one-way delay (OWD)
    • Cut through latency (bit forwarding) – FIFO RFC 1242 (ixia default, spirent default new, industry practice). Method: the time interval starting when the first bit of the frame leaves the sending port and ending when the first bit of the frame is seen on the receiving port (FIFO).
    • Store and forward latency – LIFO RFC 1242. Method: the time interval starting when the last bit of the frame leaves the sending port and ending when the first bit of the frame is seen on the receiving port (LIFO).
    • MEF frame delay – FILO RFC 3382, MEF 10.1. Method: the time interval starting when the first bit of the frame leaves the sending port and ending when the last bit of the frame is seen on the receiving port (FILO).
    • Forwarding Delay – LILO RFC 4689 (spirent default old). Method: the time interval starting when the last bit of the frame leaves the sending port and ending when the last bit of the frame is seen on the receiving port (LILO).

https://tools.ietf.org/html/rfc4689#section-3.2.5 (в определении используется Forwarding Delay – он определен на странице выше в п 3.2.4)

https://community.mellanox.com/s/article/what-happened-to-the-good-old-rfc2544-x

A Final Word About Latency Note that this report also uses a methodology to measure latency that is unusual at best, and bordering on deceptive. It is standard industry practice to measure latency from the first bit into the switch to the first bit out (FIFO). By contrast here they took the unusual approach of using a last in first out (LIFO) latency measurement methodology. Using LIFO measurements has the effect of dramatically reducing reported latencies. But unlike the normal FIFO measurements the results are not particularly enlightening or useful. For example you cannot just add latencies and get the results through a multi-hop environment. Additionally for a true cut-through switch such as the Mellanox Spectrum, using LIFO measurements would actually result in negative latency measurements – which clearly doesn’t make sense. The only reason to use these non-standard LIFO measurements is to obscure the penalty caused by switches not able to perform cut-through switching and to reduce the otherwise very large reported latencies that result from store and forward switching.
Приемлемая и предельная задержка с точки зрения пользователя
  • Для анализа причин высокой задержки можно использовать консоль или специальные сайты, производящие оценку сайта, напр. https://pagespeed.web.dev
  • Если брать в среднем по больнице, то
    • цель иметь задержку/response time = 100 мсек или менее
    • менее 500 мсек =  имеет смысл разбираться

Взято из презентации Fortitester, исходные данные тут и тут.

    • Under 100 milliseconds – is perceived as instantaneous
    • 100 ms to 300 ms – delay is perceptible
    • 1 second – is about the limit for the user’s flow of thought to stay uniterrupted
    • 2 seconds – users expect a site to load in 2 seconds (or less)
    • After 3 seconds – 40% of visitors will abandon your site
    • 10 seconds – is about the limit for keeping the user’s attention
Kissmetrics found 47% of customers expect a website to load in 2 seconds or less. Not only do consumers EXPECT your website to load in 2 seconds or less, but 40% of users will also abandon your website if it takes more than three seconds to load.

100 milliseconds is Google’s stated goal when it comes to page load times.

According to Nielsen, 0.1 seconds gives us the illusion of instantaneous response, 1 second keeps our flow of thought seamless, and 10 seconds is enough to keep our attention—barely. After 10 seconds, our minds wander, making it harder to get back on task once a page finally loads (Figure 1-4). Today, 49% expect load times of 2 seconds or less, and 18%—one out of five—expect pages to load instantly (Figure 1-2).3

WordPress – выше 600 мсек – плохо. Алерты есть в dashboard статусе самого сервера Site Health weril.me, копирую: Median server response time was 359 milliseconds. This is less than the recommended 600 milliseconds threshold. 

APDEX JMETER default тресхолды приближены к этим значениям и по сути даже жеще т.к. после 1.5 сек попадают в frustrated и это оценивается как 0 в формуле:

    • 0.5 sec apdex_satisfied_thresholds
    • 1.5 sec apdex_tolerated_thresholds

Расчет RTT в зависимости от расстояния

О зависимости TCP от RTT и размера окна можно почитать по линку выше. Влияние же задержки на throughput можно посмотреть по тестам bi.zone – оно крайне драматичное.

(tcp, impairment, metrics) Грубо говоря (взято отсюда):

    • без задержек с 2% потерями полоса деградирует в 20 раз,
    • с задержками 100мс и без потерь канал так же деградирует в 20 раз
    • каждые 30мс уменьшают производительность в +5 раз от исходных эталонных
    • когда в канале и задержки и потери – все, очевидно, еще печальней

This table shows the straight-line distance between two locations. In networks, the distance is typically longer than the straight-line distance. Here's a simple formula to calculate minimum RTT as governed by the speed of light:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

You can use 200 for the speed of propagation. This is the distance, in kilometers, that light travels in 1 millisecond. Let's take New York to San Francisco as an example. The straight-line distance is 4,148 km. Plugging that value into the equation, we get the following:

Minimum RTT = 2 * (4,148 / 200)

The output of the equation is in milliseconds.

If you want to get the best network performance, the logical option is to select destinations with the shortest distance between them. You should also design your virtual network to optimize the path of traffic and reduce latency.

 

 

Компенсация задержки

Хотели вычитать какое-то значение из полученного значения задержки для уменьшения задержки, которую показывает генератор трафика DPDK (по сути аналог intrinsic latency compensation ixia). Но для нашей микросекундной (десятки микросекунд) задержки плюс в наносекунды сомнительный. Тем более по факту как я понял мы только среду, по сути, можем исключить т.к. кто-то считает, что DAC модуль задержку не вносит (в отличии от SFP), а медные SFP мы не используем (там в теории могли бы вычитать 300нс).

Данную компенсацию реализовали в fortitester, подробнее в отдельной статье поиском по baseline.

«We consider the copper direct-attach cable to have zero latency in the SFPs, since the twinax cable is soldered directly to the pins on the SFP module itself.»

 

Спутниковая задержка
  • Аналоги Минсвязи – ITU, ETSI

В среднем считается равной порядка 500-700мс при средних 30мс в проводных сетях. В приказе Мининформсвязи РФ от 27.09.2007 N 113 регламентируется передача интерактивного трафика с максимальной средней задержкой в 400мс по спутниковым каналам.

https://normativ.kontur.ru/document?moduleId=1&documentId=112613
Typically, during perfect conditions, the physics involved in satellite communications account for approximately 550 milliseconds of latency round-trip time. 
The ping on satellite internet is usually around 638 ms, compared to ping of 30 ms or less on a typical cable network.

 

Измерение OWD используя OWAMP

owping – Client application to request one-way latency tests, One-Way Ping based on OWAMP. OWAMP stands for One-Way Active Measurement Protocol. It is standardized under RFC 4656. Compared to its counterpart ping/traceroute, OWAMP measures the network latency in one direction and does not rely on the ICMP protocol to calculate it. In conclusion, OWAMP provides more precise data, as it uses UDP packets in one direction to measure the latency. And of course, it is easy to detect any network problem related to a specific traffic direction by performing the same test in both directions separately.

Если вкратце – не рекомендую использовать OWAMP. Если вам все таки это нужно и под рукой нет другого способа измерения учтите главные вещи:

  • OWAMP не поддерживает NAT. Как со стороны клиента (по факту), так и со стороны сервера. Зато они поддержали IPv6 (ржач)!
  • для работы ОБЯЗАТЕЛЬНА синхронизация времени по NTP или другим способом между клиентом и сервером.
  • во время работы OWAMP время на устройствах обновляться не должно
NAT is currently unsupported
server# owampd -f -Z -c conf
owampd[20133]: FILE=policy.c, LINE=696, WARNING: No limits specified.
owampd[20264]: FILE=sapi.c, LINE=725, Test Denied: OpenMode recieve_addr(172.31.1.101) != control_client(172.31.1.253)

OWAMP prefers that NTP (ntpd) be running to synchronize the system clock. NTP must be setup correctly on the system for NTP to calculate a reasonable estimate of the time error and for it to stabilize the clock. NTP MUST be configured with no fewer than 4 clocks for this purpose. (See details.html for more specific information on configuring NTP.) Some measurements will still be meaningful if the clocks are not synchronized. For example, jitter measurements are still valid.
OWAMP prefers a synchronized clock for measurements to be meaningful. But, more importantly, the clock needs to be stable. If the system clock is stepped during an OWAMP session, the results can be misleading.

Установка

$ git clone https://github.com/perfsonar/owamp.git
$ cd owamp/
$ git submodule update --init
$ apt install automake
$ ./bootstrap
$ ./configure --prefix=/usr/local
$ make ## no errors here
$ make install

Запуск сервера

ip a # get ip of a server (for client usage)

# config
cp conf/owampd.conf conf/owamp-server.conf
vim.tiny conf/owamp-server.conf # http://software.internet2.edu/owamp/owampd.conf.man.html
#user owamp
#group owamp
authmode O
owampd -f -Z -c /owamp/conf # start as daemon

Запуск клиента, параметрами можно указать направление передачи, размер пакета, количество отправляемых пакетов и продолжительность тестирования.

# commands
owping -t -c 1000 -i 0.01 172.31.1.52 # OWD от клиента к серверу
owping -f -c 1000 -i 0.01 172.31.1.52 # OWD от сервера к клиенту
owping -c 10 -i 1 172.31.1.52 # 10 ping пакетов за 10 секунд (1 пакет в секунду)
owping -c 10000 -i 0.01 172.31.1.52 # 10000 ping пакетов за 100 секунд (100 пакетов в секунду)

# real example
client# owping -c 10000 -i 0.01 172.31.1.52
Approximately 102.9 seconds until results available

--- owping statistics from [172.31.1.101]:9889 to [172.31.1.52]:9905 ---
SID: ac1f0134e48f0b0660ca64f1a96dcc11
first: 2021-07-06T13:01:59.347
last: 2021-07-06T13:03:41.201
10000 sent, 0 lost (0.000%), 0 duplicates
one-way delay min/median/max = 6.73/7.6/15.7 ms, (err=0.201 ms)
one-way jitter = 0.8 ms (P95-P50)
hops = 1 (consistently)
no reordering

--- owping statistics from [172.31.1.52]:9241 to [172.31.1.101]:8886 ---
SID: ac1f0865e48f0b065f5d3ae1939461a8
first: 2021-07-06T13:01:59.339
last: 2021-07-06T13:03:38.639
10000 sent, 0 lost (0.000%), 0 duplicates
one-way delay min/median/max = -8.16/-7.3/-4.37 ms, (err=0.201 ms)
one-way jitter = 0.7 ms (P95-P50)
hops = 1 (consistently)
no reordering

 

SOCKPERF, PSPING, lATTE для измерения TCP RTT

Основной плюс в сравнении с PING у этих утилит – они не используют ICMP, а работают поверх TCP.

Publicly available tools such as SockPerf (for Linux) and latte.exe (for Windows) can isolate and measure network latency while excluding other types of latency, such as application latency. 

You can use PsPing to test TCP RTT. For more information, see PsPing.

Other common connectivity tools, such as Ping, might measure latency, but their results might not represent the network traffic that's used in real workloads. That's because most of these tools employ the Internet Control Message Protocol (ICMP), which can be treated differently from application traffic and whose results might not apply to workloads that use TCP and UDP.
By using two VMs, one as sender and one as receiver, you create a two-way communications channel. With this approach, you can send and receive packets in both directions and measure the round-trip time (RTT).
You can use this approach to measure network latency between two VMs or even between two physical computers.

Установка SockPerf.

sudo apt-get install build-essential -y
sudo apt-get install git -y -q
sudo apt-get install -y autotools-dev
sudo apt-get install -y automake
sudo apt-get install -y autoconf

git clone https://github.com/mellanox/sockperf
cd sockperf/
./autogen.sh
./configure --prefix=
make
sudo make install

Использование SockPerf.

Сначала смотрим задержку Ping – 0.01 ms.

root@serv-01:~/sockperf# ping 10.3.1.29
PING 10.3.1.29 (10.3.1.29) 56(84) bytes of data.
64 bytes from 10.3.1.29: icmp_seq=1 ttl=64 time=0.117 ms
64 bytes from 10.3.1.29: icmp_seq=2 ttl=64 time=0.099 ms
64 bytes from 10.3.1.29: icmp_seq=3 ttl=64 time=0.096 ms
64 bytes from 10.3.1.29: icmp_seq=4 ttl=64 time=0.094 ms
64 bytes from 10.3.1.29: icmp_seq=5 ttl=64 time=0.092 ms
64 bytes from 10.3.1.29: icmp_seq=6 ttl=64 time=0.092 ms
--- 10.3.1.29 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 111ms
rtt min/avg/max/mdev = 0.092/0.098/0.117/0.011 ms

Далее смотрим задержку SockPerf – 106 usec (+- тоже самое).

root@serv-02:~/sockperf# sudo ./sockperf sr --tcp -i 10.3.1.29 -p 12345
sockperf: == version #3.7-7.git05c62507670b ==
sockperf: [SERVER] listen on:
[ 0] IP = 10.3.1.29 PORT = 12345 # TCP
sockperf: Warmup stage (sending a few dummy messages)...
sockperf: [tid 25418] using recvfrom() to block on socket(s)
root@serv-01:~/sockperf# ./sockperf ping-pong -i 10.3.1.29 --tcp -m 350 -t 101 -p 12345 --full-rtt
sockperf: == version #3.7-7.git05c62507670b ==
sockperf[CLIENT] send on:sockperf: using recvfrom() to block on socket(s)
[ 0] IP = 10.3.1.29 PORT = 12345 # TCP
sockperf: Warmup stage (sending a few dummy messages)...
sockperf: Starting test...
sockperf: Test end (interrupted by timer)
sockperf: Test ended
sockperf: [Total Run] RunTime=101.000 sec; Warm up time=400 msec; SentMessages=949604; ReceivedMessages=949603
sockperf: ========= Printing statistics for Server No: 0
sockperf: [Valid Duration] RunTime=100.550 sec; SentMessages=945121; ReceivedMessages=945121
sockperf: ====> avg-rtt=106.340 (std-dev=29.968)
sockperf: # dropped messages = 0; # duplicated messages = 0; # out-of-order messages = 0
sockperf: Summary: Round trip is 106.340 usec
sockperf: Total 945121 observations; each percentile contains 9451.21 observations
sockperf: ---> <MAX> observation = 9628.599
sockperf: ---> percentile 99.999 = 3853.703
sockperf: ---> percentile 99.990 = 722.515
sockperf: ---> percentile 99.900 = 172.209
sockperf: ---> percentile 99.000 = 154.956
sockperf: ---> percentile 90.000 = 154.410
sockperf: ---> percentile 75.000 = 105.273
sockperf: ---> percentile 50.000 = 103.376
sockperf: ---> percentile 25.000 = 90.757
sockperf: ---> <MIN> observation = 88.269

 

Jitter

Jitter – вариация задержки, доверительный интервал задержки.

«Абсолютное значение разности задержки прохождения через ОТ двух последовательных пакетов.»

Значит:

  • Джиттер рассчитывается для пары пакетов
  • Джиттер рассчитывается для пары последовательных пакетов

Там же написано, что в условиях потерь считать без учета последовательности (как считать джиттер при перемешивании, а не потерях?), видимо надо различать джиттер при потерях и джитер без потерь.

 

throughput (полоса пропускания)

  • Throughput в IxChariot = Goodput. Вот так 🙂
IxChariot measures the throughput associated with packet payload, ignoring headers. This is referred to as Goodput in RFC 2647.

Throughput is calculated as the number of received bits per second. Only the TCP or UDP payload is considered, without the Layer 2 or IP headers (this is referred to as Goodput in RFC 2647).
  • В RFC 2544 нет throughput как такового в mbit/gbit, есть только PPS.
При обсуждении в IETF предлагаемого RFC MLRSearch.
The following definition is controversial "Bandwidth throughput rate bw_rate = pkt_rate * (frame_size + L1_overhead) * 8".I think there was a reason RFC2544 did not go into details and just used packets per second. We can do the same.

Throughput = THPT = TT (bi.zone). Пишут очевидное (скорость генерации pps/cps и объем thpt зависят друг от друга; слайд в начале статьи и ниже), но важное:

    • Сессии с небольшими запросами по объему максимизируют CPS (создают высокую нагрузку на CPS), аналогично пакеты с небольшим payload генерируют максимальный PPS
    • Крупные по размеру сессии максимизируют THPT (создают высокую нагрузку на THPT), аналогично пакеты с большим payload генерируют максимальный THPT

Критерии успешности обычно (примеры netsecopen в отдельной статье):

– потери пакетов (stateless), потери транзакций (stateful) – проценты разные 0% (RFC 2544), 0.001% (netsecopen), 0.1% (bi.zone), 0.5% (bi.zone)

– распределение смеси AppMix

– обычно допускаются TCP Retransmit (в каком то уровне или полностью игнорируются), но не допускаются TCP Reset

– задержка * (требует определение порогов; напр. 5 мс или 100 мс)

– пропуски атак * (требует понимания что такое успешный и неуспешный результат)

 

CC – Concurrent connections

Различают L4/L7 CC. Это важно т.к. в одном L4 соединении по факту может быть несколько L7 соединений – HTTP1.1 pipelined connection это уже поддерживает давно. Так же bi.zone пишет о AppMix CC как о сумме соединений всех протоколов AppMix.

Критерии успешности обычно (примеры netsecopen в отдельной статье):

– передача данных после открытия

– проверка закрытия всех соединений

– проверка на удержания соединений в течении n (10) мин (tcp keepalive or/and HTTP get)

– TCP fail 0

 

CPS – connections per second

Аналогично с вышестоящим разделом про CC bi.zone различают L4/L7 CPS и пишут о AppMix CPS как о сумме CPS всех протоколов AppMix.

Критерии успешности обычно (примеры netsecopen в отдельной статье):

– передача данных после открытия

– проверка закрытия всех соединений

– TCP fail 0

В качестве основы для презентации результатов (cps, connection tear-down, thpt) коллеги из IETF BMWG в draft RFC использовали median и сохраняют все ключевые значения – median/max/min.

cps (median/min/max) maximum connection establishment rate

Хотя в netsecopen только average (не показатель что только так и должно быть).

TCP Connections Per Second
      The average number of successfully established TCP connections per second between hosts across the DUT/SUT, or between hosts and the DUT/SUT.

Денис Батранков все правильно пишет (в данном случае).

Размер транзакций влияет на число одновременных сессий и соответственно на нагрузку на процессоры устройства анализа.
Для примера 10 Гбит/с это 1.25 Гбайт/с, соответственно для создания такого потока можно генерировать на тестовом устройстве
1 сессию длиной 1.25 Гбайт в секунду
10 сессий длиной 125 Мбайт в секунду
100 сессий длиной 12,5 Мбайт в секунду
1000 сессий длиной 1,25 Мбайт в секунду
10000 сессий длиной 125 Кбайт в секунду
И все эти сессии будут создавать одинаковый в сумме трафик 10 Гбит/с, но давать разную нагрузку на движки анализа: антивируса, детекта приложений, IPS, контроля передачи файлов, IPS, URL фильтрации, SSL Decrypt, DLP и так далее. Ну хотя бы потому, что обмен ключами SSL для 1 сессии и для 10000 сессий - разные задачи. Или запустить антивирус внутри устройства 1 раз или 10000 раз - разные задачи. Особенно, если эти задачи нужно выполнить за 1 секунду.

Подробнее тут
https://www.youtube.com/watch?v=rjMumSRSowk
Connection tear down rate

Подробнее написано тут. Там так же рассмотрен пример настроек iptables, когда CPS высокий, а tear down низкий.

 

TPS – transactions per second

Количество одновременных исполняемых транзакций/запросов приложений (HTTP, SSL, AppMix) обрабатываемых устройством в секунду. Описание ниже от bi.zone ошибочное – завершенные TCP соединения к TPS отношения не имеют.

 

Leave a Reply