Кратко

  • ECMP даёт маршрутизатору несколько следующих узлов с одинаковой стоимостью, но не гарантирует совпадения MTU, задержки, порядка пакетов или роли в multicast-дереве.
  • RFC 2991 сравнивает способы удерживать поток на одном пути и ограничивать переназначение потоков при изменении набора следующих узлов.

Traceroute показывает путь своих пробных пакетов. Он не обязательно раскрывает все варианты, доступные маршрутизатору, и не объясняет, как распределены остальные потоки. Здесь легко расширить смысл слова «равный»: в ECMP оно относится к стоимости маршрута, а не к физическому поведению каждого пути.

В ноябре 2000 года Dave Thaler и Christian Hopps опубликовали информационный документ RFC 2991 о многопутевой пересылке unicast- и multicast-трафика. OSPF и IS-IS прямо допускали Equal-Cost Multipath; некоторые реализации маршрутизаторов применяли его также с RIP и другими протоколами. Если для одного назначения существовало несколько допустимых следующих узлов, устройство пересылки всё равно должно было выбирать узел для каждого пакета.

Круговая отправка пакетов через разные выходы выглядит как распределение нагрузки, но в рамках одного соединения может смешать пути с разными MTU и задержками. Условия для определения MTU пути меняются от пакета к пакету. Если один пакет задержался, а более поздние последовательности пришли первыми, TCP может решить, что произошла потеря, и запустить быстрое повторное передавание. Это расходует полосу и увеличивает потребность в буферах. Ping и traceroute тоже могут пройти разными ветвями и создать неверную картину маршрута.

В multicast ограничение ещё жёстче: описанные в документе протоколы строили единое дерево к источнику, ядру или точке рандеву. Чтобы избежать циклов и дубликатов, у дерева должен был быть один следующий узел по направлению к корню. Выбор для каждого пакета менял не только производительность.

В RFC 2991 «поток» — это та гранулярность, на которой маршрутизатор хранит состояние, если он вообще его хранит. Это не обязательно пятикомпонентный микропоток из RFC 2474. Ключом может быть только адрес назначения или тройка «источник — назначение — протокол». В нефинальных фрагментах могут отсутствовать поля транспортного уровня; включение портов в выбор пути также мешает повторно использовать кэшированные сведения, например MTU, для последующих соединений тех же узлов. Определение потока оставалось за реализацией, но влияло на согласованность пути.

Если пакеты одного потока не расходятся по разным путям, проблема постоянных переключений внутри соединения уменьшается. Зато при добавлении или удалении следующего узла возникает другой вопрос: сколько активных потоков нужно переназначить? ECMP делает изменения большего числа маршрутов непосредственно значимыми для пересылки и может увеличить зону переупорядочения или потерь при колебаниях маршрута. Поэтому RFC рассматривает сразу два требования: уменьшать число затронутых потоков и не перегружать расчётом саму пересылку.

Хеширование modulo-N дёшево: хеш потока берётся по модулю числа следующих узлов. Но при изменении N, согласно RFC, путь меняют (N-1)/N потоков. Метод порогов делит пространство хеш-значений на области и затрагивает потоки около перемещаемых границ; при добавлении или удалении узла, по оценке документа, меняют путь от четверти до половины потоков. В RFC 2992 этот объём перераспределения анализируется отдельно. Highest Random Weight (HRW) вычисляет хеш для каждой пары «поток — кандидат следующего узла» и выбирает наибольший. При изменении одного узла перенос затрагивает примерно 1/N потоков, но вычислительная цена примерно в N раз выше, чем у modulo-N.

Это свойства алгоритмических моделей, а не результаты измерений работающих маршрутизаторов. Считаются потоки, не байты, клиенты или влияние на услугу. Несколько длинных потоков могут нести больше данных, чем тысячи коротких.

Хранение состояния потока определяет, когда оплачивается вычисление. Если состояние уже создаётся, следующий узел можно выбрать при его создании, а не пересчитывать выбор для каждого пакета. RFC рекомендует HRW для unicast-пересылки с состоянием и для multicast, где состояние ведётся по источнику и группе. Если unicast-пересылка не хранит состояние потока, выбор надо вычислять при получении каждого пакета; когда CPU важнее устойчивости пути, документ рекомендует метод порогов. Это рекомендация с условием, а не универсальный рейтинг алгоритмов.

В RFC 6438, опубликованном в 2011 году, вновь описан конфликт между равномерным распределением по путям, сохранением порядка пакетов одного потока и загрузкой всех каналов. Это подтверждает, что компромисс сохранялся, но не доказывает, что каждый маршрутизатор использовал методы RFC 2991.

Исторический вывод — разделять уровни. Стоимость маршрута классифицирует кандидатов; локальный механизм распределяет потоки; реальные пути определяют MTU и задержку; TCP реагирует на полученные пакеты. Устойчивость требует вычислений или допускает перекос нагрузки, а переназначение подвергает уже идущие потоки последствиям изменения топологии. Метка «равная стоимость» не выбирает за сеть, какую цену платить.

Источники