Comments 10
Услышал ipv6 закрыл доклад =) Нигде кроме как в Яндексе не применимо
TLDR: после распознанной разовой потери пакета меняем маршрут по каскадным резервированным свитчам, для динамического управления выбором маршрута используем поле flow label из ipv6-заголовка, для ускорения распознавания потерь ставим микроскопический RTO с помощью eBPF.
Услышал ipv6 закрыл доклад =) Нигде кроме как в Яндексе не применимо
В ipv4-заголовке тоже есть подходящее ненужное поле — ToS. У него конечно меньше разрядность, но думаю хватит. Ядро надо будет пропатчить чуть-чуть для такого использования.
Есть некоторое соображение, но видимо несущественное раз всё и так работает: RTO может случиться из-за потери и на обратном маршруте, в итоге отправитель будет зря прыгать по свитчам, хотя это ничему скорее всего не навредит, за исключением небольшой вероятности перепрыгнуть на битый свитч с небитого.
Т.е там, где настроен End-to-End QoS — такая парадигма абсолютно не применима.
А там, где не настроен — следует сначала настроить QoS, чтобы гарантировать приоритет обслуживания, не было TCP Global Sync и прочих артефактов связанных с природой TCP\UDP.
Ну ладно, тогда можно какие-нить биты поля identifier под это задействовать.
Или, поскольку это всё про TCP — залезть в его заголовок (порты же учитываются значит можно) и использовать urgent pointer (при флаге URG=0) — обычно это поле игнорируется, ну а в тех редчайших случаях, когда оно используется по изначальному назначению, ну будет некоторая рандомизация маршрута, не страшно.
Получится без инкапсуляции.
Про ip/tcp options наверно лучше не вспоминать, думаю с ними хуже чем инкапсуляция выйдет, хотя может и ошибаюсь.
Я допускаю что перенастроить сетевое железо на учёт полей не из какого-то стандартного списка может оказаться затруднительно, а то и вообще невозможно без замены какого-нить чипа с реализацией этих хешей в железе для скорости. Соображения выше в таком случае теоретические — сделать можно, но готовых реализаций нет.
Интересно, заставляет задуматься. Ho есть пара комментариев.
Всё это работает прекрасно, если и отправитель, и получатель находятся в дата центре (контролируемой среде). Тогда отправляющий хост может исправить flow label.
Как быть, если отправитель снаружи? Хост, делающий инкапсуляцию, не всегда (почти никогда) не будет видеть обратного потока, и не сможет узнать о потеряx.
И относительно балансировки по flow label на сетях оператора. В целом, все документы, те же RFC 6437, 6438 говорят о том, что маршрутизаторы должны принимать во внимание метку при балансировке. Чего нe стоит ожидать — тaк это замены flow label в середине потока.
Так что, с одной стороны это технология (замены flowlabel) прекрасна внутри DC, с другой стороны не стоит ожидать, что она решит проблемы с внешними подключениями. Скорее наоборот
Вероятно правильным было бы иметь механизм согласования: может ли в течение жизни TCP соединение менять FL, но в данный момент такой механики нет ни в ядре, ни в IETF.
Плохой сценарий — если у нас возникают постоянные потери, и автоматика проблемы не замечает. Чтобы понять, как это влияет на приложение, нам придется потратить немного времени на обсуждение того, как работает протокол TCP.
Не понял — если для транзитного трафика возникают постоянные дропы, связанные с проблемой по оборудованию или перегрузкой линка, то и local-link BFD их должен «заметить» — и погасить линк, на котором возникают потери. Разве не так?
2. Концептуальный вопрос — ведь у нас могут быть потери не только по причине
«некой» проблемы с промежуточными коммутаторами, а рамках природы TCP и переполнения буфера\WRED\RED для выделенной очереди. Например, когда отправитель штатно увеличивает окно — и происходит сброс части пакетов — туда может попасть наша Unhappy TCP.
Причем этот сброс может проходить где угодно — на любом коммутаторе в пути и даже на конечном хосте.
И в таком сценарии выходит, что для трафика нет четкого пути следования — и он постоянно будет перестраиваться между различными путями.
И это на мой взгляд большой минус данной реализации — непредсказуемость End-to-End потока трафика в конкретный момент времени.
Как решается данный вопрос — о предсказуемости потока трафика?
3. Мне кажется такое поведение сети будет довольно сложно трабшутить, ибо self-healing это круто, но не решает root-cause — где проблема и из-за чего возникла. Расскажите, что с траблшутингом?
4.
Нарисовали правило, сказали — теперь ты теряешь все пакеты. Как можно видеть слева, у нас per-packet monitoring, который просел до значения 75%, то есть 25% пакетов теряются.
Если вы пробовали ставить ACL на 3 минуты — то, на мой взгляд, эксперимент не совсем точный. Т.к если дропается трафик «всех префиксов» проходящих через данный линк, то и автоматика в виде «local-link» BFD тоже отработает — положит линк, просигнализурует в NOC о проблеме. А путь TCP перестроится на другую «ветку». Был ли включен BFD в данном эксперименте?
Сеть, которая лечит себя сама: магия Flow Label и детектив вокруг ядра Linux. Доклад Яндекса