> 1. В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адаптерами и свичами, аппаратно.При помощи магии что ли? Нет. Это требует обязательной настройки QoS, потому что единственный живой Ethernet Flow Control - это Priority-based Flow Control (PFC). Раньше был Ethernet Pause (802.3x), но сейчас на всем новом оборудовании по умолчанию блокируется EtherType 0x8808, чтобы никакая железка не смела это выдать. Сначала эту неудаху, которая каскадно блокирует порты по всей инфраструктуре просто предали забвению, но когда у людей начали появляться дешевые и глупые "Smart"-телевизоры в которых сетевки глючили и слали эту дрянь, её начали не просто не настраивать, а явно блокировать повсюду.
Еще раз, Pause-фреймы штормят:
- Конечное устройство блокирует порт коммутатора паузой
- У коммутатора переполняется очередь на отправку на этот порт
- Коммутатор шлёт паузу вышестоящему коммутатору
- Вся сеть встала колом
Проблема еще и в том, что когда сеть ляжет целиком, вы не зайдёте никуда и весь служебный трафик тоже ляжет.
Для разрешения подобных проблем нужно делить трафик на приоритеты и разрешать паузы только на некоторых. На каждом устройстве должен висеть Watchdog-сервис, который мониторит очереди и буферы, дропает пакеты и блокирует приём и отправку пауз, а все паузы теперь привязаны к приоритетам QoS либо на L2 (PCP-приоритеты) либо через маппинг PCP к DSCP на L3. Сложности добавляет расчет резервирования буферов для PFC, то есть для этого нужно сначала ETS настроить и подстроиться под его процентовки. Ничего из этого не работает из коробки и должно быть настроено вручную. Все вендоры оборудования имеют следующий дефолт:
- весь трафик Best Effort
- PFC отключен
- Pause запрещен
То есть никакого аппаратного Flow Control у вас нету, пока вы его сами не настроите. Когда вы подняли ETS в связке с PFC и поделили трафик на вашем сервере, сцепив его с QoS на оборудовании, которое тоже настроили сами, вот тогда вы можете отрубить себе Slow Start и слать пакеты потоком сразу со скоростью линка. ETS вам сделает полисинг в случае перегрузки, а PFC не даст потеряться пакетам на том приоритете, где он настроен. И всё это надо настраивать.
> это сильно зависит от используемого СС.
И какой у вас выбор по Congestion Control, я стесняюсь спросить? Обычный ECN или более продвинутый QCN или их полное отсутствие.
Давайте так. Если у вас нет ECN, то первичное снижение Transmission Rate после Slow Start у вас произойдёт по факту получения первого запроса на ретрансмит (первого дропа). Дроп пакета вам устроил вышестоящий коммутатор, которому ваш TCP-поток либо очередь зашатал, либо потому что там стоит полисер, который настроил сетевой администратор и он режет пропускную способность. Если у вас есть ECN и вы используете RED-алгоритмы, то коммутатор начнёт считать вероятности дропа (по настройкам сетевого администратора) и помечать пакеты, которые возможно дропнутся, если поток начнет расти. Пометка проставится в биты ECN и назначение потока должно прислать на источник Congestion Notification Packet, чтобы сетевой стек ОС источника, на котором, конечно же тоже вы заблоговременно включили и настроили ECN отреагирует на это и снизит Transmission Rate не дожидаясь дропов. QCN при этом, это когда есть WRED (Weighted Random Early Detection) на очередях коммутатора и одновременно по всей инфраструктуре настроен DCB. QCN предупреждает заранее, а если сервер-источник никак не угомонится, то тогда в дело вступит PFC и попробует сохранить пакеты в зарезервированных буферах на некоторое время. А если и в этой ситуации оно у вас захлёбывается, то тогда придет Watchdog и дропнет ваши пакеты.
Так к чему это я... ах да. Биты ECN они где? Правильно, они часть DSCP? А что вам сделает ваш провайдер во внешней сети? Удалит их к чёртовой бабушке, потому что он в своей CLOS-фабрике имеет свой Diffserv, а на вас ему начхать, если вы только не L1 берете или не L2VPN.
Поэтому сферическое в вакууме дуплексное TCP-соединение идущее через несколько независимых друг от друга сегментов сети:
- не имеет никакого CC, только TCP Retransmit, только хардкор.
- использует CUBIC, если только вы лично не пришли и не настроили это одновременно на всех участниках
> а причём тут задержки?!
> а причём тут TCP!?
И действительно, а причем... А при том! В изначальную спецификацию TCP заложена простая логика. Получили ретрансмит - снижаем скорость. И каждый ретрансмит приводит к потере очередности потока и возникновению задержки на соединении. Ретрансмит требует перезапросить часть сегментов, и время на их повторную отправку не равно нулю.
И это фича вообще-то. Это так работает по умолчанию на современных устройствах. Вариант замены Flow Control и Congestion Control для части собственного внутреннего трафика у вас есть, но писать, что это реализуется свитчами аппаратно, будто это работает... само? Нет, просто нет. Flow Control по умолчанию работает только в InfiniBand.
Вы же не думаете, что включение DCTCP как СС без всех настроек на сетевой фабрике, которые я описал выше имеет хоть какой-то смысл? Автоматически и аппаратно ничего не работает.
> а уж мой любимый RACK
Гы-гы, оно же пришло из QUIC, емнип, или наоборот, не помню. Я просто изначально отвечал человеку, которого повальный переход на UDP удивляет...
А вообще, если вы там реально используете RACK-TLP в проде, то вы наверное используете FreeBSD или Server 2022, потому что это всё не про Linux. MS-то понятно. Она же везде QUIC себе пихает, а это его CC и они одни из первых подготовили рабочую реализацию. Причем учитывая что реализации QUIC у MS под MIT, не понятно, кто у кого код таскает... Хотя сетевой стек последние годы Windows тащит у FreeBSD. Опять же... это не отменяет того факта, что это CC на основе потерь. То есть ретрансмиты там будут, а с ними и задержки на выполнение ретрансмитов. А про использование SACK вообще можно отдельную дискуссию открывать, потому что не всё так однозначно.
И, кстати, нет ничего сложного в RACK-TLP... Вот только он _просто работает_ в QUIC, а в TCP для эффективной работы нужно, чтобы сетевой стек поддерживал его с обеих сторон. То есть FreeBSD 12+ и Windows 11+ совместимы. =)
