Кратко

  • RFC 795 сопоставила исходные поля Type of Service в IP — приоритет, задержку, пропускную способность и надёжность — с возможностями AUTODIN II, ARPANET, PRNET и SATNET.
  • Перевод выявил границы: у PRNET не было признака приоритета, у ARPANET — только один бит, разные запросы превращались в одну услугу, а 111 в двух таблицах означало ошибку.

Пакет IP просит проехать быстро, надёжно и с преимуществом в очереди. Четыре сети читают заявку и открывают четыре разных расписания. В сентябре 1981 года Jon Postel свёл эти расписания в RFC 795. Документ похож на набор служебных таблиц, но в них спрятана большая инженерная задача: как перевести одну заявку в действие там, где у каждого участка свои переключатели.

Исходный Type of Service занимал один байт. Первые три бита указывали ранг от обычного трафика до управления сетью; следующие три выражали предпочтение малой задержки, высокой пропускной способности и надёжности; последние два резервировались. В шкале приоритетов встречался и «Flash Override». Отправителю давали общий бланк заказа. Postel тут же оговаривал конкретный факт: перечисленные сети предлагали очень разные варианты обслуживания. Дальше он показал эти варианты построчно.

В AUTODIN II категория допуска трафика относительно прямо связывалась с приоритетом IP. Тип приложения задавался отдельно: I/A означал малую задержку, B1 — высокую пропускную способность, B2 — ещё и повышенную надёжность, Q/R — обычный вариант. При переводе трёх битов DTR разные их сочетания попадали в один Q/R или I/A. Сочетание 111 давало ошибку. Сеть не обязана была выдавать новый тип услуги только потому, что в заявке заполнены все клетки.

ARPANET располагала одним битом приоритета, сопоставимым со старшим битом ранга IP. Остальные варианты — обычные сообщения Type 0 либо неконтролируемые Type 3, по одному пакету либо по нескольку. Type 3 из нескольких пакетов не допускался. Целый ряд значений DTR превращался в Type 0 с несколькими пакетами; 100 и 110 выбирали Type 3 с одним, 101 — Type 0 с одним, 111 снова завершалось ошибкой. Разные заявки на стойке IP получали одинаковый билет ARPANET.

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

У SATNET ситуация была иной. Признака приоритета тоже не существовало, зато имелись блоковый или потоковый режим, четыре категории задержки, две стратегии удержания и три уровня надёжности. Произведение давало 48 местных сочетаний. Короткая заявка DTR не называла каждое из них. На границе нужна была дополнительная логика выбора конкретной настройки.

Эти таблицы хороши прямотой. Они не прячут ошибку, не выдают два одинаковых результата за разные услуги и не рисуют приоритет там, где сеть его не понимала. IP объединял способы попросить. Postel показал, как четыре сети отвечали на просьбу своим оборудованием. Узкое место интернета иногда видно именно в графе «соответствие».