Кратко

  • RFC 3432 случайно выбирал T0 в окне [T,T+dT], после чего отправлял пакеты с номинально постоянным интервалом incT до Tf. Непредсказуемость начала снижала риск ожидания и некоторой синхронизации, но не превращала периодический поток в несмещённую выборку Пуассона.
  • Интерпретация требовала Type-P, порога dTloss, правил допустимых singleton-наблюдений, калибровки часов и хостов, сведений о маршруте и фоновой нагрузке. Среднее без этих условий не могло служить вердиктом о сети в целом.

Сначала жребий, затем метроном

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

Эту конструкцию описал RFC 3432, опубликованный в ноябре 2002 года как «Network performance measurement with periodic streams». Текстовая версия, карточка RFC Editor, страница IETF, история документа, ссылки и поиск исправлений фиксируют метод Standards Track. Это не отчёт о конкретной современной сети и не рейтинг оператора.

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

Известное смещение было частью замысла

Архитектура IPPM в RFC 2330 предупреждала: равномерно расставленные singletons наблюдают лишь часть спектра производительности. Для общей несмещённой картины предпочтительно пуассоновское расписание. RFC 3432 принял это ограничение, но сформулировал другую цель: аккуратный выбор периодических параметров создаёт известное смещение, представляющее интерес.

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

Периодический сбой может каждый раз совпадать с пробой и казаться сильнее обычного. При другой фазе он может всегда попадать в промежуток и исчезнуть. Активный поток способен сам создать нагрузку, синхронизировать реагирующих на перегрузку отправителей или получить особую обработку из-за узнаваемости. Независимый выбор T0 и остановка в Tf уменьшают часть риска. Они не делают случайным каждый incT, поэтому фазовое смещение остаётся в результате.

Type-P определял, какой пакет участвовал в опыте

Слова «задержка пакета» было недостаточно. Метрика называлась Type-P-One-way-Delay-Periodic-Stream. Type-P мог включать версию IP, UDP или TCP, порт, размер, приоритет и особую обработку. После смены пакета могли измениться очередь, маршрут и итог.

Если активный тест использовал несколько размеров, он должен был воспроизвести нужное распределение. Пассивное наблюдение наследовало фактический пользовательский трафик. RFC 2679 и обновивший его RFC 7679 сохраняют эту дисциплину для односторонней задержки; RFC 2680 и RFC 7680 — для односторонней потери. Маленькая приоритетная проба не могла молча представлять большой прикладной пакет.

Отсутствующее значение не равнялось нулю

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

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

Среднее поэтому считалось лишь по допустимым singletons. Исключённые наблюдения не получали нулевую задержку. Вариация для соседней пары также не определялась, если отсутствовал один компонент. RFC 3393 и анализ применимости RFC 5481 показывают, почему разные определения вариации задержки нельзя смешивать.

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

dTloss проводил границу между опозданием и потерей

В ожидаемый момент получения наблюдатель ещё не знает, не придёт ли пакет никогда или придёт очень поздно. RFC 3432 использовал dTloss — максимальный период ожидания, после которого задержку интерпретируют как потерю. Отчёт обязан назвать порог либо способ его выбора.

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

Прибор имел собственные часы и нагрузку

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

RFC рекомендовал устранять известную систематическую ошибку и сообщать ошибку калибровки e, чтобы истинное значение с доверительной вероятностью 95 процентов лежало в пределах результата плюс-минус e. Калибровать следовало под нагрузкой, близкой к полевому измерению, а не только на простаивающем стенде. Позднее RFC 7312 расширил рамку потоковых измерений, а RFC 2119 дал нормативный язык для сопоставимых реализаций.

Пять контекстов сопровождали число

В отчёт входили Type-P, порог задержки, эквивалентной потере, результаты калибровки, маршрут и фоновые условия. Точный путь мог оставаться неизвестным. Опция Record Route нередко не поддерживалась и могла включить особую обработку, изменив сам измеряемый объект. Даже частичное знание, например первого канала, оставалось полезным.

Фоновый трафик у источника, назначения и в промежуточных сетях тоже влиял на смысл. Измерение IP отделяло вклад сети от части работы кодека и операционной системы, но не описывало само по себе человеческое восприятие. Поздние пакеты, дубликаты, перестановка, повреждение и лишние пакеты имели разный эффект для разных приложений.

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

Этот разбор опирается также на эссе Heng Lu об уровнях реальности и о работающем коде как первичном источнике. Спецификация, реально созданная проба, наблюдаемый пакет, откалиброванный singleton, агрегат и пользовательский эффект связаны, но не взаимозаменяемы.

Источники определяют методику и контекст метрик. Они не доказывают текущее внедрение, аварию на названном маршруте, механизм QoS, манипуляцию или универсальный пользовательский опыт. Случайный старт уменьшает одну форму предсказуемости; он не устраняет фазу и обязанность раскрывать условия.