Кратко

  • IntServ получал точность ценой состояния на поток; DiffServ получал масштаб ценой меньшего знания об отдельном запросе.
  • RFC 2990 обнаружил два неопределённых канала: от ядра к границе о ресурсах и от границы к приложению о результате допуска.
  • Метка класса, решение, обработка, измеренная доставка, отнесение расхода и счёт требовали разных доказательств.

Поведение без допуска не создавало ресурс

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

Integrated Services связывал ограничение нагрузки с запросом приложения. Приложение описывало поток, RSVP проводил резервирование по пути, а узлы держали состояние ресурсов, классификаторов и измерителей. Запрос можно было принять или отклонить.

Точность увеличивала стоимость с каждым резервированием. В высокоскоростном ядре сходилось особенно много потоков, поэтому память, классификация и планирование становились препятствием.

Differentiated Services переносил подробную работу на границу, а внутри использовал несколько агрегатов. Код пакета выбирал поведение без сохранения переговоров каждого приложения в каждом маршрутизаторе.

Масштаб достигался сокращением знания. Если сеть не могла исполнить запрос, она могла не сообщать об этом. Приложение должно было догадаться по задержке, потерям или скорости. Неполученная услуга и явный отказ — не одно и то же: только отказ позволяет осмысленно изменить поведение.

Граница нуждалась в двух сообщениях

RFC 2990 назвал DiffServ моделью, сосредоточенной на границе. Там оператор классифицировал, ограничивал и допускал трафик; ядро эффективно обслуживало агрегаты.

Не было определено, как внутренняя доступность ресурсов достигает пограничных кондиционеров. После аварии или смены пути статическая оценка могла устареть, а допуск продолжался. Не было определено и то, как пограничное решение достигает приложения.

Нужны были два перехода: ядро сообщает границе актуальную ёмкость; граница сообщает приложению принятие, ухудшение или отказ. Сведения о ёмкости ещё не решение. Решение ещё не доказательство доставки.

Маршрут надо было сначала обнаружить

Обе архитектуры обычно использовали путь, выбранный маршрутизацией best effort. При частичном развёртывании один путь мог поддерживать услугу, а другой — нет. Минимальная метрика не означала нужных свойств.

RFC 2990 не видел надёжного способа опросить несколько путей. Метка просила обработку на существующем пути, но не находила другой. Резервирование на выбранном пути не доказывало, что он лучший.

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

Обнаружение, выбор и допуск оставались отдельными актами.

TCP вернул вторую половину услуги

Отправитель TCP регулирует данные по возвращающимся ACK. Если данные получают один профиль, а подтверждения другой, итог зависит от обоих направлений. Джиттер обратного пути может сжать ACK, вызвать всплеск данных и снова нагрузить прямой путь.

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

Сначала измерить доставку

RFC 2990 разделил измерение ресурсов для допуска и измерение доставленного сервиса. Оператору требовались объективные данные, чтобы подтвердить соответствие спецификации. Клиенту — чтобы понять, оправдалась ли доплата улучшением приложения.

Документ ожидал надбавки за премиальный сервис, но отметил отсутствие модели QoS-учёта и метода привязки использования к клиенту.

Идентичность, право, запрос, допуск, выделение, наблюдение, отнесение использования, тариф и счёт образовывали цепь. Верно посчитанные пакеты ещё не означали верно оплаченное обещание.

Перевод между потоком и агрегатом

Схема IntServ поверх DiffServ делила обязанности. RSVP сохранял разговор с приложением, а DiffServ-регион выглядел агрегированным элементом пути. Граница сопоставляла индивидуальный профиль классу.

При статической ёмкости можно было загрузить лимит. При динамической требовался сигнал из ядра. Если допуск внутри региона проваливался, результат должен был вернуться приложению, чтобы оно снизило запрос или остановилось.

Перевод успеха был лишь половиной работы. Перевод отказа соединял точность края с масштабом ядра.

Разнообразие без молчания

RFC 2990 не ожидал единственной технологии для всего Интернета. При островах и мостах обнаружение возможностей, вызов сервиса и измерение результата были одинаково важны.

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

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

Сеть могла отказать. Архитектура должна была вернуть этот отказ.

Источники