Протестировал работу TCP Congestion Control в Linux в различных по качеству окружениях, поделюсь результатами.

Сетап следующий:

  • cubic как алгоритм контроля перегрузки, дефолтный в Linux;
  • две ВМ с 10гбитными сетевыми картами;
  • iperf для вычисления пропускной способности;
  • tcpretrans для определения объема ретрансмитов;
  • tcpcong чтобы понять как чувствует себя cubic ;
  • утилита tc имитирует соединения разного уровня качества, через дроп сетевых пакетов.

Тест синтетический, но масштаб трагедии подсвечивает. Все данные собирал с клиента.

Всего сделало пять замеров, каждый по 15 секунд, отличаются объемом отброшенных через tc пакетов - 0%, 1%, 5%, 10%, 15%.

Для воспроизведения тестов

# Для запуска iperf
server:~# iperf --port 7575 --server
client:~# iperf --client server --port 7575 --time 15

# Для настройки потери пакетов
client:~# sudo tc qdisc del dev eth0 root # если требуется очистить правила
client:~# sudo tc qdisc add dev eth0 root netem loss 15%

# Сбор информации по ретрансмитам
client:~# tcpretrans-bpfcc -c

# Сбор информации по работе Congestion Control
client:~# tcpcong-bpfcc -R 7575

Результаты тестов

| Drop (%) | Retransmits (count) | Throughput (GBit/s) | Open (ms) | Recv (ms) | Loss (ms) |
|----------|---------------------|---------------------|-----------|-----------|-----------|
| 0        | 1420                | 8.59                | 12736     | 454       | 1         |
| 1        | 6011                | 2.36                | 13228     | 1245      | 5         |
| 5        | 11524               | 0.512               | 6898      | 7248      | 437       |
| 10       | 2003                | 0.028               | 3863      | 9051      | 2128      |
| 15       | 396                 | 0.002               | 3774      | 8803      | 3048      |

Легенда:

  • Open - время в стадии роста окна перегрузки (cwnd), чем больше тем лучше;
  • Recv - время в стадии восстановления после получения трех DUP ACK (duplicated acks), ответная реакция в виде fast ретрансмита, замедление относительно небольшое. Чем меньше тем лучше;
  • Loss - время в стадии восстановления после потери пакетов, ответная реакция через RTO ретрансмит. Самый негативный вариант. Чем меньше тем лучше.

cwnd

Выводы

  1. потери пакетов для распределенных сетевых взаимодействий это ОК, вопрос в их объеме;
  2. даже незначительное кол-во дропов (~1%) способно замедлить скорость взаимодействия в несколько раз, при потерях в 10% в сотни раз;
  3. после определенного % дропов пакетов скорость настолько замедляется, что число ретрансмитов идет вниз, что чревато ложными интерпретациями;
  4. без понимания как чувствует себя Контроль Перегрузки невозможно понять почему скорость в моменте падает/растет. Отслеживания только лишь пропускной способности и ретрансмитов недостаточно.

Для любопытных