Кратко

  • RFC 1046 предлагала держать очередь низкой задержки достаточно малой, чтобы ограничить время ожидания принятых датаграмм. Переполнение означало отбрасывание, а доля класса в канале оставалась ограниченной ради остальных.
  • Несколько запросов Type-of-Service не складывались в набор гарантий. При конкуренции они означали OR: узел выбирал одну очередь, а запасной вариант повышал шанс приёма ценой перестановки пакетов и иной задержки.

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

W. Prue и J. Postel выпустили документ в феврале 1988 года как статью для обсуждения идеи. Она не доказывала широкого внедрения и не закрепляла единственных параметров. Зато она честно показывала, что название класса само по себе не производит услугу.

Поле сообщало предпочтение, а не наличие ресурса

RFC 791 определила в IPv4 precedence и пожелания низкой задержки, высокой пропускной способности и высокой надёжности. Три свойства были названы компромиссом: улучшение одного могло ухудшить другое.

В пакете не было глубины буфера, скорости линии или выделенной доли. RFC 1046 добавляла возможную дисциплину выходного узла. Отправитель описывал желаемое; узел видел конкурентов и нёс последствия выбора.

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

MGD ограничивала ожидание после приёма

Целью для low delay был Maximum Guaranteed Delay на каждом узле при условии, что датаграмма успешно проходит Интернет. Это условие не обещало принять каждую помеченную датаграмму и не обещало доставку.

Класс был однонаправленным. Низкая задержка запроса не означала низкий RTT: ответ или ACK мог нести другую характеристику.

Формула выглядела так:

Максимальная задержка = N / (P × R)

N — размер очереди, P — доля ресурсов канала, R — скорость в датаграммах за секунду. Если доля или скорость уменьшались, для прежней цели требовалось сократить N. Собственная задержка линии также съедала бюджет.

Граница существовала в локальных настройках и физических условиях. Бит не мог сам выделить буфер или полосу.

Быстро обслуживались лишь те, кто поместился

Предложение делало очередь low delay малой и ограничивало её скорость обслуживания, чтобы класс не поглотил чрезмерную часть ресурса. После заполнения новые датаграммы отбрасывались. Для столь короткой очереди Source Quench считался слишком медленным и в базовой схеме не применялся.

High reliability использовала обратный выбор: более длинный буфер, ранний Source Quench и отбрасывание только после полного заполнения. Вероятность пережить перегрузку росла вместе с возможным ожиданием. Ошибки физического канала эта очередь не исправляла.

High throughput получала в примере наибольшую частоту обслуживания и больший буфер, соглашаясь на более высокую среднюю задержку в узле. Идея отправлять burst компактно сопровождалась оговоркой: очередь могла неверно предположить свойства верхнего протокола.

Классы выбирали не уровни престижа, а место ущерба — раннюю потерю, долгое ожидание или большую долю отправки.

OR не позволяло получить всё сразу

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

На одном узле датаграмма попадала в одну классовую очередь. Предлагался порядок: low delay, high throughput, high reliability. Если пакет просил задержку и надёжность, но короткая очередь была полной, его можно было принять в длинную. Вторая возможность приёма меняла исходную сделку.

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

Приоритет получал предел внутри узла

Восемь уровней precedence позволяли новому пакету пройти вперёд внутри выбранного класса. Чтобы низкий приоритет не голодал бесконечно, каждому обойдённому пакету начислялись локальные «frustration points». После достаточного числа обходов его уже нельзя было так же оттеснить.

Поправка не переходила на следующий узел и не меняла заголовок. Приоритет также не выталкивал уже принятую датаграмму из полной очереди: отбрасывался новый приход.

Но само обхождение разрушало простую границу MGD. В примере пакет low delay без соответствующего высокого приоритета мог ждать от одного до 28 исходных интервалов. Фраза «запрошена низкая задержка» не описывала фактического режима ожидания.

Открытые параметры оставались властью оператора

Разделение 17% для low delay, 50% для throughput и 33% для reliability было иллюстрацией. Пропорциональные chits должны были сглаживать обслуживание. Документ всё ещё спрашивал: какую MGD выбрать, кто назначает доли, как ограничить привлекательные классы, допустима ли сложность и какие модели нужны.

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

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

Позднейшие нормы ограничивают историческое чтение

RFC 1349 позднее назвала TOS строго рекомендательным механизмом, непригодным для запроса гарантий. RFC 2474 и RFC 2475 заменили старую трактовку полем DS и развели codepoint, per-hop behavior, сервис, conditioning и механизм узла.

Это не доказывает внедрение RFC 1046 или прямое наследование её очередей DiffServ. Это сохраняет различие между переносимой меткой и локальным исполнением.

RFC 1016 даёт современный тому периоду контекст Source Quench. RFC 6633 впоследствии запрещает отправку и реакцию и отдельно говорит, что подход RFC 1016 нельзя реализовывать.

Источники и границы

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