RFC 2681 A Round-trip Delay Metric for IPPM

Network Working Group                                           G. Almes
Request for Comments: 2681                                  S. Kalidindi
Category: Standards Track                                   M. Zekauskas
                                             Advanced Network & Services
                                                          September 1999

A Round-trip Delay Metric for IPPM

Метрика круговой задержки для IPPM

PDF

Статус документа

Этот документ содержит проект стандартного протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях совершенствования протокола. Текущий статус стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Введение

Этот документ определяет метрику для круговой (round-trip) задержки пакетов на путях Internet. Документ основан на понятиях, введённых и описанных в документе IPPM Framework (RFC 2330) [1] и близко соответствует соответствующему показателю односторонней задержки (A One-way Delay Metric for IPPM [2]). Предполагается знакомство читателя с обоими документами.

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

Этот документ рассчитан на повторение структуры в будущих документах по измерению потерь пакетов.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [6]. Хотя RFC 2119 относится к протоколам, использование ключевых слов в этом документе очень похоже. Это служит для обеспечения сравнимости результатов разных измерений и выявления случаев, когда реализация может нарушать работу сети.

Структура документа представлена ниже.

• Вводится одиночный (singleton*) аналитический показатель Type-P-Round-trip-Delay для однократного наблюдения круговой задержки.

• С использованием этого показателя определяется выборка (sample*) Type-P-Round-trip-Delay-Poisson-Stream для последовательности измерений круговой задержки в соответствии с выборкой Пуассона.

• С использованием выборки определяется и рассматривается статистика (statistics*).

Такой переход от одиночных измерений через выборки к статистике с их чётким разделением имеет важное значение.

Когда в этом документе первый раз используется термин из IPPM Framework, он помечается звёздочкой в конце. Например, term* указывает термин term, определённый в IPPM Framework.

1.1. Мотивация

Знать круговую задержку пакетов Type-P* от хоста-источника (host*) к хосту-получателю полезно по нескольким причинам.

• Некоторые приложения не работают хорошо (или совсем), если сквозная задержка между хостами превышает определённый порог.

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

• Чем больше задержка, тем сложнее протоколам транспортного уровня поддерживать высокую пропускную способность.

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

• Минимальное значение этого параметра указывает задержку, которая вероятно возникает при прохождении слабо загруженного пути (path*).

• Значение параметра выше минимального указывают наличие перегрузки на пути.

Измерение круговой задержки вместо односторонней имеет несколько недостатков, указанных ниже.

• В современной сети Internet путь от источника к получателю может отличаться от обратного пути (асимметрия путей) и на этих путях используются разные последовательности маршрутизаторов.

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

• Производительность приложения может сильнее зависеть от производительности в одном из направлений.

• В сетях с поддержкой QoS качество обслуживания в разных направлениях может существенно различаться. Независимые измерения для путей позволяют проверить обслуживание в обоих направлениях.

С другой стороны, измерение круговой задержки обеспечивает два преимущества.

• Простота развёртывания. В отличие от односторонних измерений круговую задержку часто можно измерить без установки специальных измерительных программ на целевом хосте-получателе. Хорошо известно множество подходов, включая ICMP Echo или методы на основе TCP (подобные описанным в «IPPM Metrics for Measuring Connectivity» [4]). Однако в некоторых случаях могут возникать существенные погрешности, связанные с задержкой отклика получателем (см. параграф 2.7.3).

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

1.2. Общие вопросы, связанные со временем

При упоминании в документе времени (т. е. момента в истории) имеется в виду значение в секундах (и долях) для часового пояса UTC.

Как описано в документе IPPM Framework, есть 4 разных, но связанных понятия неопределённости часов (времени).

synchronization* – синхронизация

Степень согласованности часов в части текущего времени. Например, часы одного хоста могут опережать часы другого на 5,4 мсек.

accuracy* – точность

Степень соответствия данных часов времени UTC. Например, часы хоста могут отставать от UTC на 27,1 мсек.

resolution* – разрешение (дискретность)

Наименьшая единица, на которую могут изменяться показания часов. Это определяет нижнюю граничу неточности часов. Например, часы в старых системах Unix могут «тикать» лишь каждые 10 мсек, поэтому они будут иметь дискретность 10 мсек.

skew* – перекос

Мера изменения точности или синхронизации с течением времени. Например, часы хоста могут отставать на 1,3 мсек за час и отставать на 27,1 мсек от UTC в данный момент, а через час они будут отставать от UTC лишь на 25,8 мсек. В этом случае мы говорим, что часы данного хоста имеют перекос в 1,3 за час относительно UTC в плане точности. Можно также говорить о перекосе одних часов относительно других в плане синхронизации.

2. Определение для одиночного измерения круговой задержки

2.1. Имя показателя

Type-P-Round-trip-Delay – круговая задержка для пакетов Type-P.

2.2. Параметры показателя

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

TT

Время.

2.3. Единицы измерения

Значение Type-P-Round-trip-Delay является действительным числом, либо неопределённым (неформально, бесконечным) числом секунд.

2.4. Определение

Для действительного числа dT, «задержка Type-P-Round-trip-Delay от Src до Dst в момент T равна dT» означает, что Src передаёт первый бит пакета Type-P получателю Dst в момент времени в линии (wire time*) T, а Dst принимает этот пакет и сразу же передаёт пакет Type-P обратно Src, а Src получает последний бит этого пакета в момент момент времени в линии T+dT.

«Задержка Type-P-Round-trip-Delay от Src до Dst в момент времени T не определена (неформально, бесконечна)» означает, что Src передаёт первый бит пакета Type-P получателю Dst в момент времени в линии T, а Dst не получает этот пакет, не передаёт пакет Type-P в ответ или Src не получает отклика.

«Задержка Type-P-Round-trip-Delay от Src до Dst в момент времени T» означает задержку кругового обхода от Src к Dst или от Dst к Src в момент времени T. При использовании такого понятия роли Src и Dst неоднозначны. {Комментарий. Эта неоднозначность обычно является небольшой платой за возможность выполнить одно измерение с Src или Dst вместо двух.}

Предложения о включении значений метрики в отчёт приводятся в параграфе 3.8 после обсуждения метрики, методики измерения и анализа ошибок.

2.5. Обсуждение

Type-P-Round-trip-Delay представляет собой относительно простую аналитическую метрику, для которой предполагается возможность использовать эффективные методы измерения.

На практике могут возникать указанные ниже проблемы.

• Значениям временных меток (T), по которым измеряется задержка, следует быть достаточно точными, чтобы можно было делать осмысленные выводы о состоянии сети в момент T. Поэтому хосту Src нужно знать точное время. NTP [3] может обеспечить точность синхронизации в несколько миллисекунд. В зависимости от сервера NTP точность может быть повышена, например, за счёт использования серверов NTP, синхронизируемых от GPS. Отметим, что NTP корректирует часы измерительной системы. Если корректировка происходит во время измерения (между получением начальной и конечной временной метки) это будет вносить погрешность в измерение задержки. Такие погрешности следует учитывать при калибровке инструментария.

• Методика должна включать способ определения, является значение очень большим (пакет ещё не прибыл в Dst) или оно бесконечно. Как отметили Mahdavi и Paxson [4], можно использовать простую верхнюю границу (например, теоретическое ограничение срока существования пакетов IP в 255 секунд [5]). Но на практике требуется понимать сроки существования пакетов. {Комментарий. Отметим, что для многих применений этого показателя негативное влияние трактовки очень большой задержки как бесконечно, может отсутствовать или быть совсем незначительным. Например, пакет данных TCP, полученный после нескольких периодов RTT, можно считать потерянным.}

• Если пакет дублируется в пути (путях) и к получателю приходит несколько неповреждённых копий, пакет считается полученным и одностороннюю задержку определяет приём первой копии.

• Если пакет фрагментирован и по какой-то причине сборка не выполняется, пакет считается потерянным.

2.6. Методики

Как и для всех иных показателей Type-P-*, конкретная методика будет зависеть от Type-P (например, номера протокола, порта UDP/TCP, размера, предпочтений).

В общем случае для данного Type-P методика будет действовать, как указано ниже.

• На хосте Src выбираются IP-адреса Src и Dst и создаётся тестовый пакет Type-P с этими адресами. Дополняющую часть пакета (padding), служащую для создания нужного размера тестового пакета, следует заполнять случайными битами, чтобы предотвратить сжатие пакетов в пути, которое может повлиять на измерение задержки. Тестовый пакет должен включать те или иные сведения для идентификации, чтобы на хосте Src можно было распознать отклик на этот пакет. Одним из способов идентификации является включение в пакет временной метки непосредственно перед отправкой пакета.

• На хосте Dst организуется приём пакета и отправка отклика на него. На хосте Src организуется приём соответствующего пакета с откликом.

• На хосте Src берётся исходная метка времени и подготовленный пакет Type-P передаётся в направлении Dst. Отметим, что метка может помещаться в пакет или сохраняться отдельно, если в пакете имеется подходящий идентификатор, чтобы полученную временную метку можно было сравнить с исходной (момент передачи).

• Если пакет прибывает на Dst, соответствующий отклик передаётся от Dst к Src как можно скорее.

• Если пакет отклика приходит в разумные сроки, как можно скорее берётся временная метка момента получения пакета. Вычитая значение одной метки из значения другой, можно рассчитать круговую задержку. При анализе ошибок реализации метода следует учитывать точность синхронизации часов Src и Dst. Если известна разница между исходной временной меткой Src и фактическим временем передачи пакета, это значение можно вычесть из полученной величины задержки. Неопределённость разницы времени генерации метки и отправки пакета должна учитываться при анализе ошибок. Точно так же при известной разнице времени приёма пакета и создания финальной временной метки её можно вычесть из значения задержки. Неопределённость этой разницы должна учитываться при анализе ошибок. Дополнительные сведения приведены в параграфе 2.7. Ошибки и погрешности.

• Если пакет не прибыл в разумные сроки, круговая задержка считается неопределённой (неформально, бесконечной). Порог «разумности» срока является параметром методики.

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

{Комментарий. Отметим, что в общем случае нельзя сложить два значения Type-P-One-way-Delay (см. [2]) для получения Type-P-Round-trip-Delay. Чтобы получить значение Type-P-Round-trip-Delay, получение пакета от Src должно вызывать передачу отклика.}

{Комментарий. В соответствии с этим определением ping является средством измерения круговой задержки с Type-P в виде 60-байтовых пакетов с запросами и откликами ICMP. Однако погрешности, связанные с типичными программами ping, нужно анализировать в соответствии со следующим параграфом, включая учёт типа точки отражения (маршрутизаторы могут не обслуживать запросы ICMP по быстрому пути) и влияние её загрузки.}

2.7. Ошибки и погрешности

В описание любого конкретного метода измерения следует включать учёт и анализ различных источников ошибок и погрешностей. В документе IPPM Framework даны общие рекомендации по этим вопросам, а здесь отмечены:

• ошибки и погрешности часов на хосте Src;

• ошибки и погрешности, связанные с разницей времени в линии (wire time) и на хосте (host time);

• ошибки и погрешности, связанные со временем, затрачиваемым хостом Dst на приём пакета от Src и отправку соответствующего отклика.

Кроме того, на результаты может влиять пороговое значение потерь. Каждый из этих вопросов более подробно рассмотрен ниже, а в параграфе 2.7.4. Калибровка рассмотрен учёт этих ошибок и погрешностей.

2.7.1. Ошибки и погрешности, связанные с часами

Погрешность измерения круговой задержки отчасти связана с часами хоста Src. Далее часы, используемые для фиксации момента отправки с хоста Src называются часами источника, время, наблюдавшееся при отправке пакета источником обозначается как Tinitial, а время, наблюдавшееся при получении отклика источником, – как Tfinal. В предположении синхронизации часов с учётом их точности, дискретности и перекоса отметим указанное ниже.

• Хотя при измерении односторонней задержки возникает проблема синхронизации часов источника и получателя, при определении круговой задержки важнее (более простая) «самосинхронизация» между временем отправки тестового пакета по часам источника и временем получения отклика по тем же часам. Теоретически ошибки здесь могут возникать лишь из-за очень сильного перекоса. На практике более серьёзным источником ошибок может быть прерывание работы часов источника (по любой причине) в интервале между фиксацией начальной и финальной временной метки. Это может быть связано, например, с некоторыми реализациями NTP.

• Точность часов важна для определения момента измерения задержки. Сама по себе, точность часов не влияет на точность измерения задержки.

• Разрешение (дискретность) часов добавляет погрешность к любому измерению времени этими часами. Таким образом, если часы источника имеют разрешение 10 мсек, это добавит погрешность в 10 к любому времени, измеренному этими часами. Разрешение часов будет обозначать Rsource.

С учётом сказанного естественный расчёт Tfinal – Tinitial будет давать погрешность 2*Rsource.

2.7.2. Ошибки и погрешности, связанные с временем в линии и на хосте

В соответствии с определением круговой задержки нужно измерить время между выходом тестового пакета из сетевого интерфейса Src и прибытием (полностью) соответствующего отклика на сетевой интерфейс Src – это называется временем в линии (wire time). Однако измерение времени выполняется программами на хосте Src, который могут лишь фиксировать время между созданием (получением) временной метки на Src перед отправкой пакета и после получения отклика – это называется временем хоста.

Другой вклад в ошибку связан со временем, которое проходит между получением хостом Dst тестового пакета и отправкой отклика на него. В идеале это время равно 0 и более подробно рассматривается в следующем параграфе.

Данные о разнице времени между хостом и линией можно использовать для корректировки измерения времени на хосте для повышения точности оценки желаемого показателя (время в линии).

Неопределённость различия времени между хостом и линией должна учитываться при анализе погрешности измерения для данного метода. Обозначим верхнюю границу этой неопределённости на хосте Src при отправке пакета как Hinitial, а при получении отклика – как Hfinal. Совместно они вносят погрешность Hinitial + Hfinal. Эту оценку общей погрешности разницы времени на хосте и в линии обычно следует включать в анализ ошибок и погрешностей любой реализации измерения.

2.7.3. Ошибки и погрешности, связанные с временем отклика Dst

Время, прошедшее на хосте-получателе от приёма и распознавания пакета от Src до создания и отправки соответствующего отклика вносит дополнительную ошибку в измерение круговой задержки. Ошибка равна разнице между временем в линии для момента поступления первого бита тестового пакета в Dst и временем в линии для момента отправки первого бита отклика от Dst. Когда эта разница известна, её можно использовать для корректировки измеряемого показателя. Неопределённость этого времени должна учитываться при анализе ошибок в реализации измерения. Обозначим эту неопределённость как Hrefl. Оценку этой погрешности следует включать в анализ ошибок и погрешностей любой реализации измерения.

2.7.4. Калибровка

3.7.3. Калибровка ошибок и погрешностей

В общем случае измеренное значение можно представить в форме

   измеренное значение = истинное значение + систематическая ошибка + случайная ошибка

Если систематическую ошибку (постоянное отклонение измеряемых значений) можно определить, можно компенсировать её в получаемых (reported) результатах.

   полученный результат = измеренное значение - систематическая ошибка

Из этого следует, что

   полученный результат = истинное значение + случайная ошибка

Целью калибровки является определение систематических и случайных ошибок, вносимых хостами, как можно более подробно. Как минимум следует найти границу (e), указывающую, что полученное значение находится в диапазоне от (истинное значение – e) до (истинное значение + e) не менее 95% времени. Будем называть «e» ошибкой калибровки для измерений. Эта ошибка представляет степень повторяемости значений, создаваемых измерительным хостом, т. е. близость полученных значений к реальным. {Комментарий. Значение 95% выбрано потому, что (1) желательно иметь некий уровень доверия для удаления выбросов, которые могут возникать при измерении любого физического свойства и (2) нужно указать определённый уровень доверия для возможности сравнения результатов независимых измерений.}

В соответствии с тремя предыдущими параграфами ошибка измерений может быть ограничена определением отдельных погрешностей и их сложением в виде

       2*Rsource + Hinitial + Hfinal + Hrefl.

Разумные границы неопределённостей, связанных с часами (первые 3 члена выражения) и хостом (2 последних члена), можно оценить, тщательно подбирая методику и калибруя хосты с использованием известной сети в лабораторных условиях.

Связанные с хостом погрешности Hinitial + Hfinal + Hrefl можно ограничить соединением хостов напрямую через высокоскоростной последовательный канал или изолированный сегмент ЛВС. В этом случае повторяющиеся измерения будут давать одинаковую круговую задержку.

Если тестовые пакеты малы, такое соединение будет вносить очень малую задержку, которую можно аппроксимировать значением 0. Поэтому измеряемая задержка будет включать лишь систематические и случайные ошибки на измерительных хостах. «Среднее значение» повторяющихся измерений будет определять систематическую ошибку, а вариации – случайную.

Одним из способов рассчитать систематическую ошибку и случайную ошибку с уровнем доверия 95% является многократное повторение измерений (по меньшей мере сотни раз). Систематическая ошибка будет определяться медианой, а случайную ошибку можно определить, исключив систематическую из полученных значений. Доверительный интервал 95% будет диапазоном процентилей от 2,5 до 97,5 для отклонений от истинного значения. Ошибкой калибровки (e) можно считать большее абсолютное значение из этих двух с добавлением погрешности, связанной с часами. {Комментарий. Как указано выше, эта привязка является относительно слабой, поскольку погрешности складываются и используется абсолютное значение большего отклонения. Пока полученное значение не составляет значимую часть измеряемых значений, это будет разумной границей. Если же значение погрешности составляет существенную часть измеряемых величин, требуются более точные методы расчёта ошибок калибровки.}

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

Отметим ещё раз, что эта статистическая трактовка относится к калибровке хоста и определяет степень соответствия результатов измерений реальным значениям.

Помимо калибровки хостов для измерения конечной задержки следует выполнить ещё две проверки, чтобы не было ложных сообщений о потере пакетов. Во-первых, следует проверить пороговое значение потерь. В частности, нужно убедиться, что «разумный» порог действительно является разумным и очень маловероятно поступление пакета по достижении порога и, следовательно, число теряемых за интервал пакетов, не зависит от связанных с измерением ошибок. Во-вторых, следует учесть вероятность того, что пакет приходит на сетевой интерфейс, но теряется в результате перегрузки на этом интерфейсе или нехватки на хосте иных ресурсов (например, буферов).

2.8. Отчёты об измерениях

Калибровка и контекст выполнения измерений должны тщательно рассматриваться и их следует включать в отчёт вместе с измеренными значениями. Далее представлены 4 элемента, которые следует включать в отчёт: Type-P для тестовых пакетов, порог бесконечной задержки (при наличии), калибровка ошибок и путь, по которому проходят пакеты. Список не является исчерпывающим и следует включать в отчёт любые дополнительные сведения, которые могут быть полезны при интерпретации показателей.

2.8.1. Type-P

Как указано в документе IPPM Framework [1], значение показателя может зависеть от типа пакетов IP, применяемых для измерений – Type-P. Значение Type-P-Round-trip-Delay может меняться при смене протокола (UDP или TCP), номера порта, размера пакетов или особых условий (например, поле предпочтений IP или RSVP). В отчёт должно включаться точное указание Type-P при измерениях.

2.8.2. Пороговое значение потерь

В отчёт должно включаться пороговое значение (или метод) для различия конечной задержки и потери.

2.8.3. Результаты калибровки

• Если систематическую ошибку можно определить, её следует исключить из измеренных значений.

• Следует указывать в отчёте ошибку калибровки e так, чтобы истинным значением было указанное в отчёте значение плюс-минус e с уровнем доверия 95%.

• По возможности следует включать в отчёт условия, при которых тестовый пакет с конечной задержкой указывается как потерянный в результате нехватки ресурсов на измерительном хосте.

2.8.4. Путь

В отчёте следует по возможности указывать путь, по которому проходят пакеты. В общем случае сложно узнать точный путь, по которому данный пакет прошёл через сеть. Точный путь может быть известен для некоторого Type-P на коротком и стабильном участке. Если Type-P включает опцию записи маршрута (или loose-source route) в заголовке IP, путь достаточно короток и все маршрутизаторы (router*) на пути поддерживают опцию source route (или loose-source route), путь будет записан точно. Это непрактично, поскольку требует достаточно короткого пути, многие маршрутизаторы не поддерживают опцию записи маршрута (или она отключена), а применение этого свойства зачастую снижает производительность. Однако частичные сведения о пути обеспечивают значимый контекст. Например, если хост может выбирать между двумя каналами (link*) и, следовательно, двумя разными маршрутами от Src к Dst, используемый канал обеспечивает значимый контекст. {Комментарий. Например в Merit NetNow Src, являющийся одной из точек доступа в сеть (Network Access Point – NAP) может достичь Dst в другой точке NAP по любой из сетевых магистралей.}

3. Определение выборки для круговой задержки

На основе одиночной (singleton) метрики Type-P-Round-trip-Delay определим конкретную выборку таких одиночных измерений. Идея выборки (sample) заключается в отборе конкретной связки параметров Src, Dst, Type-P и определении выборки значений параметра T. Способ определения T состоит в выборе начального (T0) и конечного (Tf) времени, а также средней частоты lambda и последующем задании псевдослучайного процесса Пуассона со скоростью lambda в интервале от T0 до Tf. Интервал времени между последовательными значениями T имеет среднее значение 1/lambda.

{Комментарий. Выборка Пуассона является лишь одним из вариантов. Преимуществом её является ограничение смещения (bias), но в других ситуациях могут оказаться лучше иные методы выборки. Всем, кто находит соответствующие случаи, рекомендуется использовать эту общую схему и представить свой метод выборки для стандартизации.}

3.1. Имя показателя

Type-P-Round-trip-Delay-Poisson-Stream

3.2. Параметры показателя

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

T0

Время (начала).

Tf

Время (завершения).

lambda

Число измерений в секунду.

3.3. Единицы измерения

Последовательность пар (T, dT), где T указывает время, а dT является действительным числом или неопределённым числом секунд. Значения T в последовательности измерений возрастают монотонно. Отметим, что параметры T и dT действительны также для метрики Type-P-Round-trip-Delay.

3.4. Определение

На основе T0, Tf и lambda рассчитывается псевдослучайный процесс Пуассона, начинающийся не позже T0, включающий среднюю частоту прибытия пакетов lambda и завершающийся не раньше Tf. Значения времени выборки относятся к диапазоны от T0 до Tf. В каждый из выбранных моментов измеряется одно значение Type-P-Round-trip-Delay. Значением выборки является последовательность пар (время, задержка).

3.5. Обсуждение

Читателю следует ознакомиться с углублённым обсуждением выборки Пуассона в документе IPPM Framework [1], где рассмотрены методы расчёта и проверки псевдослучайных пуассоновских процессов.

Значение lambda осознанно не ограничивается за исключением указания крайних точек. Если частота слишком велика, тестовый трафик будет нарушать работу сети и сам вызывать перегрузки. При слишком малой частоте могут быть упущены некоторые интересные детали поведения сети. {Комментарий. Предполагается описать опыт и предложения для значений lambda в отдельном документе серии BCP.}

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

Выборка определяется как пуассоновский процесс, чтобы избежать самосинхронизации и обеспечить выборку, статистически наиболее достоверную (unbiased). {Комментарий. Конечно не принимается допущений о том, что реальный трафик Internet прибывает в соответствии с распределением Пуассона.} Пуассоновский процесс служит для планирования измерений задержки. Тестовые пакеты в общем случае не будут приходить на Dst в соответствии с распределением Пуассона, поскольку сеть оказывает влияние на их доставку.

Все одиночные (singleton) показатели Type-P-Round-trip-Delay в последовательности измерений будут иметь одни значения Src, Dst, Type-P.

Отметим также, что данная выборка с момента T0 до Tf и субпоследовательность от T0′ до Tf’, где T0 <= T0′ <= Tf’ <= Tf, также будет действительной выборкой Type-P-Round-trip-Delay-Poisson-Stream.

3.6. Методики

Методика включает указанные ниже действия.

• Выбора конкретных значений времени измерения с использованием заданного процесса Пуассона для прибытия.

• Методика, рассмотренная для одиночного (singleton) измерения Type-P-Round-trip-Delay.

Следует корректно обрабатывать нарушения порядка прибытия тестовых пакетов. Src может передать тестовый пакет в момент TS[i], а затем передать следующий в момент TS[i+1], при этом Dst может получить сначала второй пакет в момент TR[i+1], а позднее – первый в момент TR[i].

3.7. Ошибки и погрешности

В дополнение к ошибкам и погрешностям, связанным с методом одиночных измерений, входящих в выборку, необходимо тщательно проанализировать точность процесса Пуассона в части времени в линии при отправке тестовых пакетов. Проблемы в этом процессе могут быть связаны с несколькими обстоятельствами, включая метод генерации псевдослучайных чисел для процесса Пуассона и вариации значения Hsource (рассмотрено выше для одиночных измерений). В документе IPPM Framework показано, как использовать тест Anderson-Darling для проверки точности пуассоновского процесса в коротких интервалах времени. {Комментарий. Цель состоит в передаче тестовых пакетов «достаточно близко» к планированию Пуассона без возникновения периодической отправки.}

3.8. Отчёты об измерениях

Калибровка и контекст для одиночных измерений должны указываться в отчёте (см. 2.8. Отчёты об измерениях).

4. Определения статистики для односторонней задержки

На основе выборки Type-P-Round-trip-Delay-Poisson-Stream предлагается несколько вариантов статистики. Описание статистики служит в основном для иллюстрации того, что можно сделать.

4.1. Type-P-Round-trip-Delay-Percentile

Для данной выборки Type-P-Round-trip-Delay-Poisson-Stream и значения X от 0% до 100% – это X-й процентиль от всех значений dT в потоке. При расчёте процентиля неопределённые значения считаются бесконечно большими. Это означает, что процентиль также может быть неопределённым (неформально, бесконечным). Кроме того, Type-P-One-way-Delay-Percentile будет неопределённым для пустой выборки.

Предположим в качестве примера выборку, показанную ниже.

   Stream1 = <
   <T1, 100 msec>
   <T2, 110 msec>
   <T3, undefined>
   <T4, 90 msec>
   <T5, 500 msec>
   >

50-й процентиль будет иметь значение 110 мсек, поскольку 90 и 100 мсек меньше, а 500 мсек и undefined больше него. Расчёт процентилей описан в параграфе 11.3 [RFC2330].¹

Отметим, что при наличии вероятности того, что пакет с конечной задержкой, указанный как потерянный, является значимым, высокий процентиль (90-й или 95-й) можно указать как бесконечный вместо конечного.

4.2. Type-P-Round-trip-Delay-Median

Для данной выборки Type-P-Round-trip-Delay-Poisson-Stream – это медиана всех значений dT в потоке. При расчёте медианы неопределённые значения считаются бесконечно большими. Как и Type-P-Round-trip-Delay-Percentile, медиана Type-P-Round-trip-Delay-Median не определена для пустой выборки.

Как указано в документе IPPM Framework, медиана отличается от 50-го процентиля только для выборов с сетным числом значений (в этом случае используется среднее значение двух «центральных» измерений.

Предположим в качестве примера выборку, показанную ниже.

   Stream1 = <
   <T1, 100 msec>
   <T2, 110 msec>
   <T3, undefined>
   <T4, 90 msec>
   >

Медиана будет иметь значение 105 мсек (среднее между 100 и 110 мсек).

4.3. Type-P-Round-trip-Delay-Minimum

Для данной выборки Type-P-Round-trip-Delay-Poisson-Stream – это минимальное значение dT в потоке. При расчёте неопределённые значения считаются бесконечно большими. Это означает, что минимум также может быть неопределённым (неформально, бесконечным), если все значения dT являются неопределёнными. Значение Type-P-Round-trip-Delay-Minimum будет неопределённым для пустой выборки.

В приведённом выше примере минимальное значение составляет 90 мсек.

4.4. Type-P-Round-trip-Delay-Inverse-Percentile

Для данной выборки Type-P-Round-trip-Delay-Poisson-Stream и порога продолжительности часть всех значений dT в потоке будет не выше порога. Значение может быть от 0% (все значения dT выше порога) до 100%. Значение Type-P-Round-trip-Delay-Inverse-Percentile будет неопределённым для пустой выборки.

В приведённом выше примере Inverse-Percentile для 103 мсек составляет 50%.

5. Вопросы безопасности

Проведение измерений в Internet создаёт проблемы безопасности и приватности. Этот документ не задаёт реализацию показателей, поэтому он напрямую не влияет на безопасность Internet и приложений Internet. Однако при реализации измерений требуется учитывать вопросы безопасности и приватности.

Имеется два типа проблем, связанных с безопасностью – потенциальные угрозы в результате проведения измерений и возможные угрозы для самих измерений. Измерения могут наносить вред, поскольку они являются активными и внедряют свои пакеты в сеть. Параметры измерений должны выбираться осторожно и тщательно, чтобы объем внедряемого в сеть трафика был мал по сравнению с обычным трафиком. Внедрение «слишком большого» трафика может искажать результаты измерений, а в пределе вызывать перегрузки и отказы в обслуживании.

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

Проблемы приватности при сетевых измерениях не возникают при описанных в этом документе активных измерениях. Эти они отличаются от пассивных измерений, где могут просматриваться данные пользователей.

6. Благодарности

Большое спасибо Vern Paxson и Will Leland за полезные предложения.

7. Литература

[1] Paxson, D., Almes, G., Mahdavi, J. and M. Mathis, “Framework for IP Performance Metrics”, RFC 2330, May 1998.

[2] Almes, G., Kalidindi,S. and M. Zekauskas, “A One-way Delay Metric for IPPM”, RFC 2679, September 1999.

[3] Mills, D., “Network Time Protocol (v3)”, RFC 1305, April 1992.

[4] Mahdavi, J. and V. Paxson, “IPPM Metrics for Measuring Connectivity”, RFC 2678, September 1999.

[5] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

[6] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

8. Адреса авторов

Guy Almes

Advanced Network & Services, Inc.

200 Business Park Drive

Armonk, NY 10504

USA

Phone: +1 914 765 1120

EMail: almes@advanced.org

 

Sunil Kalidindi

Advanced Network & Services, Inc.

200 Business Park Drive

Armonk, NY 10504

USA

Phone: +1 914 765 1128

EMail: kalidindi@advanced.org

 

Matthew J. Zekauskas

Advanced Network & Services, Inc.

200 Business Park Drive

Armonk, NY 10504

USA

Phone: +1 914 765 1112

EMail: matt@advanced.org

9. Полное заявление авторских прав

Copyright (C) The Internet Society (1999). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru