Кратко

  • RFC 3006 оставил исходную спецификацию трафика отправителя неизменной, но добавил подсказку о сжимаемости, которую каждый маршрутизатор мог учитывать только там, где его собственный канал поддерживал названный способ сжатия.
  • Маршрутизатор, принявший поток по уменьшенной сжатой ставке, должен был контролировать этот бюджет как граница сети, оставляя последствия неточного заявления потоку, который получил скидку.

Запрос на резервирование выглядел слишком большим, пока один маршрутизатор не учитывал факт, который конечный узел не мог безопасно записать в единое число для всего пути. В расчёте из RFC 3006 отправитель описывал поток 48 кбит/с с пакетами по 120 байт. На узком интерфейсе 40-байтный заголовок IP, UDP и RTP можно было сжать до четырёх байт. На этом переходе пакет занимал 70 процентов исходного размера, и маршрутизатор мог планировать 33,6 кбит/с вместо 48.

Арифметика показывала не просто экономию 14,4 кбит/с, а разделение знания. Отправитель знал предполагаемую структуру своего трафика. Маршрутизатор знал, работает ли нужный компрессор на определённом выходном интерфейсе. Ни один из них не мог правомерно переписать сквозной запрос для всех переходов. Одни каналы могли сжимать заголовки, другие — нет. Если бы отправитель заявил только 33,6 кбит/с, он занизил бы стоимость на несжимаемых участках. Маршрутизатор, видящий только 48, мог отвергнуть поток, который его собственный канал способен нести.

RFC 3006 устранил разрыв, не сделав ни одного участника глобальным арбитром. Передаваемая Sender TSpec оставалась прежней в соответствии с использованием RSVP из RFC 2210. Новый параметр указывал возможный вид сжатия и, при желании, процентный коэффициент. Сетевой элемент мог включить эту информацию в локально рассчитанную сжатую TSpec. Термин «подсказка» был точным: это не приказ и не доказательство того, что ожидаемая экономия обязательно возникнет.

Такое устройство продолжало разделение труда RSVP. RFC 2205 переносил сведения между конечными и сетевыми элементами, а admission control и traffic control решали, достаточно ли ресурсов и как их защищать. RFC 3006 поместил подсказку в Sender TSpec, поскольку отправителю доступна вероятная форма потока, а нужна информация механизму управления трафиком, не просто обработчику сообщения RSVP. Общий объект переносил заявление; исполняемый код на переходе определял его полезность.

Пример позволял проверить каждый шаг. Исходная скорость token bucket r равнялась 48 кбит/с, глубина b — 120 байтам, максимальный размер пакета M — 120 байтам, минимальная контролируемая единица m — 64 байтам. Коэффициент 70 процентов уменьшал r до 33,6 кбит/с, а b и M — до 84 байт. Для m требовалось другое действие: из 64 вычиталась та же экономия заголовка в 36 байт, получалось 28. Правило не сводилось к умножению каждого поля на 0,7.

Для компрессора заголовков с фиксированной экономией N байт RFC 3006 масштабировал скорость и глубину всплеска через f/100, оставлял пиковую скорость прежней и вычитал N из максимального и минимального размеров. Документ предупреждал: такая модель подходит не каждой схеме. Наличие контрольной суммы UDP, линейность временных меток RTP и распределение размеров пакетов меняют результат. Маршрутизатор мог выбрать консервативный расчёт вместо процента отправителя. Нулевой коэффициент прямо передавал расчёт маршрутизаторам; 100 означал, что экономия не ожидается.

Механизм должен был выдержать и множество отправителей. TSpec каждого отправителя сначала уменьшалась по его коэффициенту, и лишь затем применимые спецификации объединялись. Для guaranteed service по RFC 2212 скорость получателя могла масштабироваться средним коэффициентом, взвешенным по размерам всплеска отправителей. Но одно уменьшение R увеличило бы вклад C/R в задержку, поэтому переход должен был обратно увеличить собственную погрешность C. Скидка по пропускной способности действительна лишь пока сохранён смысл обещанной задержки.

Главный абзац начинается там, где заканчивается оптимистичный расчёт. Сжатие не полностью детерминировано. Допустим, маршрутизатор принял поток 48 кбит/с в расчёте на 33,6, но фактический компрессор выдал 35. Дополнительные 1,4 кбит/с не были зарезервированы. Это избыточный трафик, который обрабатывается по правилам выбранного класса Integrated Services. Оценка, открывшая допуск, не превращается в право на лишнюю ёмкость.

Ошибочное заявление может быть и стратегическим. Отправитель способен назвать сжимаемыми данные, которые не сжимаются, или завысить ожидаемую экономию. Тогда сеть допустит поток, который следовало отклонить, и честным резервированиям не хватит ресурсов. RFC 3006 возложил последствия на заявление, создавшее скидку: любой маршрутизатор, использовавший подсказку, должен контролировать поток по сжатой TSpec так, словно сам является границей сети.

Ответственность переместилась очень точно. RSVP не требовал policing на каждом переходе. Однако именно осведомлённый о сжатии переход создал новый локальный предел, невидимый исходной границе. Контроль выше по пути мог доказать, что отправитель не превысил 48 кбит/с; он не доказывал, что следующему каналу досталось не больше скидочных 33,6. Тот, кто потратил экономию при допуске, становился точкой её проверки.

Максимальный размер datagram сохранял ещё одну асимметрию. Сервис, использующий M для policing, должен был брать несжатое значение: отдельные пакеты могли не сжаться. Модель могла уменьшить повторяющуюся стоимость на проводе, не притворяясь, будто каждый пакет всегда станет короче. Средняя эффективность и допустимость худшего случая оставались разными квитанциями.

Контур замыкала обратная совместимость. Старому маршрутизатору, не понимающему подсказку, предпочтительно было игнорировать её локально, переслать неизменной и резервировать по исходной TSpec. Следующий способный переход всё ещё мог её использовать. Но RFC 2210 не до конца определял действие с неизвестными параметрами, и некоторые реализации могли отвергнуть сообщение PATH. RFC 3006 допускал PathErr и повторную попытку без подсказки. Расширение возвращалось к более дорогому, но понятному контракту, а не изобретало скрытую скидку.

Соседние документы очерчивают границу этой истории. RFC 2688 рассчитывал фактическую стоимость PPP на линии после кадрирования, фрагментации, вставки байтов и изменения скорости канала. RFC 2689 объяснял, почему на малоскоростных каналах должны вместе работать кадрирование, сжатие и явное знание приложения. RFC 3006 занимал более узкий участок между заявлением и исполнением: кто описывает сжимаемость, кто переводит её в локальную ёмкость и кто отвечает, если перевод не оправдался.

Позже RFC 3241 выделил семейство значений RSVP для ROHC поверх PPP и нормативно использовал RFC 3006. Это доказывает расширяемость пространства подсказок для другой схемы сжатия. Это не доказывает широкого внедрения, рыночного успеха или прямой причинной линии к современному QoS. Историческая ценность находится в структуре решения, доступной в самом стандарте.

Через оптику Running-Code Primacy Лу Хэна полномочие маршрутизатора возникало из исполнимой способности, а не из обладания числом в сигнальном объекте. Минимальный общий слой переносил достаточно данных для местного решения и не заставлял каждый переход разделять одно будущее. Проверка стабильности была столь же конкретной: резервирование оставалось операционно устойчивым, пока наблюдаемое сжатие подтверждало скидку, на которой держался допуск.

RFC 3006 тем самым представил ресурсное обещание как цепь ограниченных квитанций. Отправитель описывает. Переход проверяет способность. Admission control рассчитывает. Traffic control контролирует. Совместимость определяет, переживёт ли необязательное заявление весь путь. Ни одна квитанция отдельно не доказывает итог услуги. Вместе они позволяют использовать локальную эффективность, не превращая её в невидимый риск для остальных потоков.

Sources