Кратко

  • RFC 1363 описывал заявку на сетевой сервис для мультимедийной конференции и других распределённых задач. Заявка касалась одного направления; поле задержки указывало, когда её дальнейшее снижение перестаёт помогать, а не обещало общий предел доставки.
  • Нагрузка, разброс времени прихода, потери и уровень гарантии записывались отдельно. Последний участок Ethernet мог работать хорошо и всё же перегрузиться во время разговора, поэтому полезный маршрут не всегда означал гарантию на каждом переходе.

У фразы «задержка не больше 100 миллисекунд» приятный вид: конкретное число, понятная проверка. Крэйг Партридж в RFC 1363 от сентября 1992 года заставил её уточнить адрес. Для связи США с Японией сто миллисекунд могли устроить собеседников; для звонка в пределах города та же цифра могла раздражать. Это пример из рассуждения автора, не журнал измерений. Он показывает, почему приложение не вправе заранее объявить один верхний предел разумным для любой географии.

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

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

Затем отправитель должен был показать собственные аппетиты. Устойчивая скорость по модели корзины токенов, максимальная скорость и примерный размер всплеска описывали входящий поток. В RFC приведена жесткая проверка: поток более 10 мегабит в секунду нельзя вести по линии T1 в 1,5 мегабита в секунду. Каким бы ни был желаемый срок доставки, узкая линия шире не станет.

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

Отдельное поле Quality of Guarantee отвечало за силу самого обещания. Были возможны пожелание без гарантии, неполная гарантия, прогнозируемый сервис и твёрдая гарантия. Партридж упоминал эксперименты конференц-связи IETF: Ethernet на последнем переходе часто давал приемлемую работу. Та же общая среда могла насытиться в течение звонка. Такой маршрут можно использовать, понимая риск; нельзя делать вид, что каждый переход отвечает одинаково. Прогнозируемый сервис предполагал сотрудничество устройств и ограниченное ухудшение под нагрузкой. Неполная гарантия включала участок, способный выйти из этой дисциплины.

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

RFC 1363 описывал язык заявки, а не уже развёрнутую службу резервирования. Он оставил полезную привычку: требовать от приложения профиль нагрузки и от сети точное имя гарантии. Сто миллисекунд без этих сведений — красивое число, за которое последний общий сегмент не подписывался.

Источники: RFC 1363; официальная карточка RFC 1363.