Кратко

  • В отчёте BBN № 7080 1989 года Craig Partridge доказывал: сама по себе гигабитная скорость не требует новой сетевой архитектуры. Вместо одного внушительного показателя он проверял скорость обработки пакетов, запас инструкций, движение данных, объём информации в пути и время выхода на доступную пропускную способность.
  • Вывод опирался на открыто названные предположения: достаточно крупный средний пакет, RISC-процессоры на 60–70 MIPS, 64-битные тракты и доступная память. Скорость распространения сигнала не росла, поэтому произведение полосы на задержку и время обучения отправителя оставались настоящими ограничениями.
  • В 1998 году команда BBN MultiGigabit Router описала полнодуплексную коммутационную систему на 50 Гбит/с и до 32 миллионов пакетов в секунду. Это был ограниченный свидетельствами результат коллективной реализации, а не личное изобретение Partridge и не обещание автоматического масштабирования любой будущей нагрузки.

Сначала возник порог, и только потом стали искать поломку

Partridge начал не с отказавшей машины, а с убеждения. Переход от локальных сетей на 10 Мбит/с к скорости свыше гигабита, как ожидалось, должен был особенно тяжело ударить по дейтаграммным архитектурам. Однако предполагаемую границу редко сопровождали профиль пакетов, рабочая нагрузка или повторяемое измерение. Гигабит стал удобным масштабом, на котором замена архитектуры выглядела неизбежной ещё до испытания.

Отчёт How Slow Is One Gigabit Per Second?, датированный 5 июня 1989 года и сохранившийся в материалах четырнадцатой встречи IETF, проверял именно этот переход от величины к выводу. Partridge не отрицал сложность гигабитных сетей. Он спрашивал, настолько ли их задачи необычны, чтобы понадобилась иная архитектура. Между дейтаграммами и виртуальными каналами автор старался сохранять нейтралитет: если обе модели способны достичь цели, выбор между ними определяется свойствами и предпочтениями, а не технологической необходимостью.

В этом различии заключено правило принятия решений. Архитектуру можно менять, когда она не выполняет заданную работу. Но крупное число ещё не доказывает, что нужно отказаться от совместимости, инвестиций и накопленного операционного контроля.

Линейная скорость стала сроком для каждого пакета

Отчёт явно назвал две предпосылки. Средний пакет в гигабитной сети будет не меньше среднего интернет-пакета того времени, а компоненты в опытном производстве позволят судить о возможностях начала 1990-х. В качестве осторожного ориентира использовались RISC-процессор на 60–70 MIPS и 64-битные тракты данных. Это были прогнозы своего времени, а не гарантии и не современные показатели.

Для маршрутизатора полезным знаменателем оказалось число пакетов. Производительность в 6–10 тысяч пакетов в секунду между двумя или тремя сетями Ethernet экстраполировалась до 600 тысяч–1 миллиона пакетов в секунду на гигабитной скорости. Процессору на 60 MIPS оставалось около 60–100 инструкций на пакет — 1–1,6 микросекунды до прихода следующего.

Так спор приобрёл проверяемую форму. Быстрый путь виртуального канала мог распределить стоимость установления соединения. Базовая IP-пересылка оценивалась примерно в 100–150 инструкций на распространённых тогда 32-битных процессорах, без учёта драйвера. Более широкие операции, простые драйверы, конвейер или аппаратная помощь могли сдвинуть границу. Поток коротких пакетов сдвигал её обратно. Гигабит подтверждений и гигабит крупных передач предъявляли к одному процессору разное число решений в секунду.

Хост платил за байты, которых не касался маршрутизатор

Маршрутизатору обычно достаточно заголовка. Принимающему приложению нужны данные. Partridge разделил обработку протокола, работу операционной системы и приложения. На основе более ранних измерений TCP он построил иллюстративную модель: около тысячи фиксированных инструкций на пакет плюс работа, пропорциональная длине пакета, делённой на размер машинного слова.

В исторической модели хост на 60 MIPS мог заполнить гигабитную линию при среднем пакете около 3 КБ. Пакеты по 512 байт позволяли использовать почти четверть линии, а по 100 байт — около 50 Мбит/с. Эти величины ничего не обещают современному оборудованию. Они показывают, почему линейную скорость, частоту пакетов и скорость обращения к данным нельзя сводить к одной характеристике.

Ранее Partridge вместе с Bob Braden и David Borman написал RFC 1071. Среди практических рекомендаций там было совмещение копирования с вычислением контрольной суммы: одни и те же данные извлекаются из памяти один раз для двух операций. Арифметика может казаться основной работой, хотя дефицитным ресурсом оказывается перемещение байтов. RFC 4297 позднее суммировал свидетельства этого класса, включая старое измерение на Sun-3/60: операции обращения к данным составляли 64% измеренных накладных расходов, копирование — 48%. Эти числа относятся к цитируемой работе Clark, а не к собственному измерению Partridge и не к нынешним компьютерам.

Сохранившийся вывод уже исходного утверждения: учитывать следует путь через память, а не только инструкции протокола.

Расстояние не ускорилось вместе с интерфейсом

Более быстрая линия не сокращала волокно. За то же время прохождения в сети оказывалось больше битов. В примере с самым длинным маршрутом отчёт получал около 5,9 МБ данных в пути; для задержки оператора, соответствовавшей как минимум 120 мс туда и обратно, — 15 МБ. В условиях 1989 года это были серьёзные, но мыслимые объёмы. Они относятся к геометрии и предположениям статьи, а не служат универсальной рекомендацией по буферам.

Задержка распространения была отделена от задержки коммутации. Даже сто пересылающих элементов, каждый из которых вносил малую допустимую задержку, вместе потребовали бы примерно 12,5–20 КБ дополнительного буфера. Запас определял дальний путь, а не последовательность быстрых локальных решений.

У управления потоком были собственные часы. Отправителю предстояло узнать, какую скорость примет путь. В отчёте рассматривалась дейтаграммная передача, начинавшаяся с восьмибайтовой пробы и удваивавшая объём каждый цикл. До гигабитного масштаба она могла дойти менее чем за две секунды. Для долгой передачи это обнадёживало; для части коротких и интерактивных задач две секунды были слишком долгими. Архитектура ещё не провалилась, но приложению могла понадобиться более быстрая и достоверная информация о доступной ёмкости.

Через девять лет расчёт встретился с аппаратурой

В 1998 году Partridge и большая команда BBN представили статью A 50-Gb/s IP Router. MultiGigabit Router заявлял до 32 миллионов пересылок пакетов в секунду и полнодуплексную внутреннюю систему на 50 Гбит/с. Авторы одновременно указывали, что служебный трафик поглощал примерно четверть её пропускной способности.

Архитектура ограничивала дорогое перемещение. Входная линейная карта удерживала тело пакета, а механизму пересылки отправляла заголовок. Механизм искал маршрут, обновлял заголовок и возвращал инструкции; только затем полный пакет переходил к выходной карте. Полные таблицы пересылки находились в каждом таком механизме, чтобы централизованный поиск не стал обходным путём, дорожающим с каждой новой линией. Коммутируемая фабрика заменила общую шину. Механизмы пересылки отделили от линейных карт, заголовки канального уровня приводили к общей форме до быстрого пути, а классификацию QoS отделили от планирования выхода.

Степень готовности была частью результата. На момент публикации всё оборудование, кроме интерфейсных карт, изготовили и испытали; большая часть программ работала. Задержка в семь-восемь микросекунд для 128-байтовой дейтаграммы оставалась оценкой, собранной из измерений ПО, наблюдений при отладке аппаратуры и моделирования: внешних интерфейсов и полной внутренней временной картины ещё не было. Если назвать маршрутизатор просто готовым, исчезнет самое ценное различие — между измеренным, выведенным и незавершённым.

Команда показала осуществимость просмотра каждого IP-заголовка на высокой скорости и оспорила тезис об устаревании маршрутизаторов. Но она не доказывала одинаковое поведение всех таблиц, отказов, смесей пакетов и будущих скоростей. И это не была одиночная работа: статья перечисляет множество авторов, хотя биографические источники называют Partridge техническим руководителем проекта.

Человек, который искал правильный знаменатель

Internet Hall of Fame связывает с Craig Partridge маршрутизацию почты по доменным именам, руководство первой командой многогигабитного маршрутизатора, участие в создании anycast и работу над измерением времени в TCP. Colorado State University сегодня указывает его профессором, исследующим перемещение битов, пакетов, блоков и файлов между машинами. Такая широта помогает понять отчёт 1989 года: это была не защита одной коробки, а метод против категориальной ошибки.

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

Здесь аргумент совпадает с приоритетом работающего кода. Организация, производитель или орган стандартизации вправе предпочесть новую архитектуру. Но предпочтение не становится необходимостью от пугающего масштаба. Тот, кто просит других пожертвовать совместимостью, капиталом или контролем, должен показать исполняемый путь, который перестал работать, и сохранить измерения, делающие отказ проверяемым. Partridge не обещал бесконечного масштабирования Интернета. Он показал, почему единица скорости не должна принимать архитектурное решение сама.

Источники