Кратко

  • RFC 2212 строил верхнюю границу задержки в очереди из контракта трафика (r,b,p,m,M), зарезервированной скорости R и максимальных отклонений каждого элемента от идеального непрерывного обслуживания.
  • Зависящая от скорости ошибка C входила как C/R, независимая ошибка D — непосредственно; по пути они суммировались в Ctot и Dtot.
  • Граница действовала лишь при соблюдении профиля, размера пакетов, допуска, ресурсов и неизменности пути. Она не обещала нулевого джиттера, не подтверждала личность и не доказывала доставку конкретного пакета или успех приложения.

Число начиналось с заведомо нереальной модели

В идеальной модели поток обслуживается непрерывно со скоростью R, словно ему выделили отдельный провод. Если поток ограничен корзиной токенов с устойчивой скоростью r и глубиной b, то при R >= r задержка в очереди такого fluid-сервера не превышает b/R.

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

C описывал накопленную работу, временная стоимость которой зависит от зарезервированной скорости. Поэтому в формуле появляется C/R; типичный источник — пакетизация. D описывал наихудшее локальное отклонение, не уменьшающееся от роста R, например ожидание назначенного слота или фиксированный разрыв обслуживания. Для одного элемента задержка должна была оставаться ниже:

b/R + C/R + D

Это не средние показатели и не телеметрия одного пакета. C и D — заявленные максимумы. Элемент мог работать лучше, но гарантия должна была выдерживать его худшее поведение в пределах контракта.

У трафика было пять измерений, а не один класс приоритета

TSpec задавал скорость токенов r, глубину корзины b, пиковую скорость p, минимальную учитываемую единицу m и максимальный размер соответствующей условиям дейтаграммы M. За любой интервал T соответствующий поток не мог превысить:

M + min[pT, rT + b - M]

m не позволял множеству маленьких дейтаграмм обходить учёт: при контроле каждая из них считалась не меньше m. M ограничивал другой край. Если запрошенный максимум превышал MTU звена, запрос следовало отвергнуть; слишком большой пакет не получал гарантию только потому, что носил то же имя потока.

RSpec добавлял (R,S). Резерв R должен был быть не меньше r; увеличение R обычно уменьшало задержку. Slack S выражал допустимое дополнительное время относительно результата при запрошенной скорости.

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

Суммирование создавало границу пути

Параметры элементов складывались: Ctot = ΣC, Dtot = ΣD. Если p > R >= r, максимальная сквозная задержка в очереди определялась выражением:

[(b-M)/R × (p-R)/(p-r)] + (M+Ctot)/R + Dtot

При r <= p <= R оставалось:

(M+Ctot)/R + Dtot

Если пик был неизвестен или его сознательно не учитывали, использовалась консервативная форма:

b/R + Ctot/R + Dtot

Формула не смешивала причины. b, p и M принадлежали профилю трафика. R был решением о ресурсе. Ctot/R переводил зависящую от скорости ошибку реализации во время. Dtot уже было временем. Поэтому два пути с одинаковым R для одинакового потока могли иметь разные верхние границы.

Постоянная задержка распространения, передачи и неизбежной обработки находилась вне этой оценки очереди. Чтобы получить максимальную сквозную задержку, её нужно было добавить отдельно. И сама граница оставалась стабильной лишь пока не менялся сквозной путь. RFC 2212 не выбирал маршрут и не замораживал его; это делали механизмы маршрутизации и установки состояния.

Система, которая хранит Ctot, Dtot и R, но теряет идентификатор и версию пути, сохраняет арифметику и утрачивает основание применять её сейчас.

Slack разрешал обменять ресурс на время, но не списать долг

Промежуточный элемент мог использовать часть S, снизить локальный резерв и принять дополнительную задержку. Однако преобразование должно было сохранить неравенство. Для входных (Rin, Sin) и выходных (Rout, Sout) требовалось:

Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin

при r <= Rout <= Rin.

Элемент расходовал Sin - Sout, а не создавал новый запас. Эта бухгалтерия важнее самого слова «slack»: она не позволяла дважды потратить один и тот же временной бюджет или утверждать, что меньший резерв сохраняет исходную границу без доказательства.

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

Частичные суммы обслуживали reshaping, а не историю доставки

Ctot и Dtot относились ко всему пути. Csum и Dsum накапливались только с последней точки повторного формирования трафика. Они помогали оценить буфер reshaper-а. Без оптимизации по пиковому значению консервативный размер составлял b + Csum + Dsum × R.

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

Если трафик переставал соответствовать TSpec, сеть не обязана была сохранять ему гарантированную обработку. На границе несоответствующие дейтаграммы обычно следовало перевести в best effort. Внутри сети контроль должен был учитывать искажения bursts и, как правило, применять повторное формирование.

Самый поздний срок не задавал ровный ритм

RFC 2212 контролировал максимум задержки в очереди, но не минимизировал разницу между минимальной и максимальной задержкой. Большинство пакетов могло приходить намного раньше крайнего срока. Для воспроизведения получателю всё равно требовался буфер.

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

Слово «Guaranteed» относилось к узко описанному максимуму при этих предпосылках. Оно не расширяло область доказательства.

Между запросом и исходом оставались отдельные стадии

RFC 2212 не предписывал единственный протокол установки. Параметры мог переносить RSVP, но резервирование могло появиться из ручной конфигурации или системы управления. RFC 2210 отдельно определял объекты RSVP и отделял аутентификацию, учёт и policy от объектов управления QoS.

Последовательность доказательств поэтому выглядела так: TSpec описывал допустимый трафик; RSpec запрашивал ресурс и запас; решение допуска выделяло ресурс; C и D характеризовали элементы; формула вычисляла условный максимум; измерение показывало поведение конкретных пакетов; приложение решало, состоялся ли полезный результат.

Корректный FLOWSPEC был запросом, а не доказательством допуска. Допуск не доказывал последующее соответствие. Расчёт не доказывал прибытие пакета. Прибытие не удостоверяло отправителя и его полномочия. Доставка не гарантировала декодирование, показ, сохранение или действие пользователя.

Заслуга RFC 2212 состояла не в стирании этих границ. Он сделал одну из стадий достаточно точной, чтобы её можно было проверить и оспорить.

Источники и пределы вывода

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