RFC 8912 Initial Performance Metrics Registry Entries

Internet Engineering Task Force (IETF)                         A. Morton
Request for Comments: 8912                                     AT&T Labs
Category: Standards Track                                     M. Bagnulo
ISSN: 2070-1721                                                     UC3M
                                                              P. Eardley
                                                                      BT
                                                              K. D'Souza
                                                               AT&T Labs
                                                           November 2021

Initial Performance Metrics Registry Entries

Исходные записи реестров показателей производительности

PDF

Аннотация

Этот документ определяет набор начальных записей реестра IANA для показателей производительности (Performance Metrics). Набор включает UDP Round-Trip Latency and Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss, ICMP Round-Trip Latency and Loss, TCP Round-Trip Delay and Loss.

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

Документ содержит проект стандарта Internet (Standards Track).

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8912.

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

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Этот документ определяет исходный набор записей в реестре метрик производительности (Performance Metrics Registry). Документ использует термины и определения из литературы по параметрам производительности IP (IP Performance Metrics или IPPM), прежде всего [RFC2330].

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

Поэтому в [RFC8911] определён общий формат Performance Metrics Registry и в разделе 5 [RFC8911] даны рекомендации для запросов регистрации метрик, т. е. создания записей в Performance Metrics Registry.

По сути, должно быть доказано, что (1) кандидат на регистрацию метрики представляет отраслевой интерес или уже внедрён и (2) имеется согласие по части того, что метрика-кандидат служит предусмотренной цели.

Процесс, заданный в [RFC8911], требует также администрирования новых записей агентством IANA по процедуре Specification Required [RFC8126], которая обеспечит чёткое определение показателей.

1.1. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Область действия

Этот документ задаёт исходный набор показателей производительности (Performance Metrics Registry Entriy). Большинство показателей относятся к активным (Active Performance Metrics), которые основаны на RFC, подготовленных рабочей группой IETF IPPM, в соответствии с моделью [RFC2330] и её обновлениями.

3. Категории и столбцы реестра

В этом документе применяются термины, определённые в [RFC8911].

Этот раздел описывает категории и столбцы реестра для упрощения ссылок на них. Запись (строка) даёт полное описание зарегистрированного показателя (Registered Metrics). Формат категорий и столбцов показан ниже.

       Категория
       ------------------...
       Столбец |Столбец |...

   Сводка
   ---------------------------------------------------------------
   Идентификатор| Имя | URI |Описание| Ссылка |Контролёр| Версия |
                |     |     |        |        |изменений|

   Определение показателя
   ----------------------------------------------
   Ссылка на определение|Фиксированные параметры|

   Метод измерения
   ---------------------------------------------------------------------
   Ссылка на | Генерация  | Фильтр  | Распределение| Рабочие    | Роль |
   метод     | потока     | трафика | выборки      | параметры  |      |
             | пакетов    |
   Вывод
   -----------------------------------------
   Тип  | Ссылка на  |Единицы| Калибровка  |
        | определение|       |             |

   Административная информация
   --------------------------------------
   Статус |Запросчик|Выпуск|дата выпуска|

   Комментарии и примечания
   ------------------------


4. Записи для времени кругового обхода и потерь UDP

В этом разделе описаны исходные записи реестра для времени кругового обхода (UDP Round-Trip Latency) и потерь при круговом обходе (UDP Round-Trip Loss Ratio).

Примечание. Каждая запись реестра создаёт лишь необработанный (raw) вывод или статистическую сводку. Для эффективного описания необработанных и статистических результатов категории Identifier, Name, Output могут быть расщеплены, а в одном параграфе могут быть описаны несколько тесно связанных показателей. Например, в этом параграфе заданы две записи реестра, столбцы которых во многом совпадают. Пример задания записей реестра с совпадением многих столбцов приведён в разделе 7.

Записи во всех столбцах кроме ID, Name, Description, Output Reference Method совпадают. Таким образом, этот раздел задаёт две тесно связанных записи в реестре. В результате IANA выделяет соответствующие URL для каждого из двух именованных показателей (Named Metric).

4.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

4.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 1 и 2 для именованных записей раздела 4. Сопоставление идентификаторов с именами приведено в параграфе 4.1.2.

4.1.2. Имя

1: RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile

2: RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio

4.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile

URL: https://www.iana.org/assignments/performance-metrics/RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio

4.1.4. Описание

RTDelay

Показатель оценивает задержку для потока пакетов между двумя хостами (точки измерения). Выводом служит время кругового обхода для всех успешно переданных пакетов в форме 95-го процентиля от условного распределения задержки.

RTLoss

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

4.1.5. Контролёр изменений

IETF

4.1.6. Версия (формата реестра)

1.0

4.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

4.2.1. Ссылки на определения

Задержки

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

В параграфе 2.4 [RFC2681] приведено определение одноэлементного (одно значение) показателя времени кругового обхода (round-trip delay). В параграфе 3.4 [RFC2681] дано расширенное определение с несколькими выборками. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

Отметим, что определение времени кругового обхода между источником (Source или Src) и получателем (Destination или Dst) в параграфе 2.4 [RFC2681] намеренно неоднозначно, этот показатель сужает определение, указывая, что хост в роли Src передаёт первый пакет хосту в роли Dst и в конечном итоге получает соответствующий пакет возврата от Dst (когда ничего не теряется).

Переменная dT в [RFC2681] указывает значение времени кругового обхода в определениях показателя и методах. Это имя переменной также применяется в других документах IPPM для других величин и не может служить в качестве глобального имени переменной.

Потери

Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>. [RFC6673]

Оба показателя Delay и Loss используют максимальное время ожидания для полученных пакетов, поэтому отношение числа потерянных пакетов к числу переданных является основой для расчёта коэффициента потерь в соответствии с параграфом 6.1 в [RFC6673].

4.2.2. Фиксированные параметры

Определение Type-P приведено в разделе 13 [RFC2330]

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Общий размер 100 байтов.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

4.3. Метод измерения

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

4.3.1. Ссылки на методы

Методология для этого показателя (эквивалент Type-P-Round-trip-Delay и Type-P-Round-trip-Delay-Poisson-Stream) задана в параграфе 2.6 [RFC2681] (для одиночных измерений) и параграфе 3.6 [RFC2681] (для выборок) с использованием Type-P и Tmax, заданных в столбцах Fixed Parameters. Однако периодический поток будет создаваться в соответствии с [RFC3432].

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя RTLoss [RFC6673].

Расчёты задержки (RTT) нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта RTT должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

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

В параграфе 4.4 [RFC6673] подробно рассматриваются инструкции по отправке пакетов Type-P обратно в Src как можно быстрее в соответствии с параграфом 2.6 в [RFC2681]. В разделе 8 [RFC6673] указаны дополнительные требования, которые должны быть включены в метод измерения для этого показателя.

4.3.2. Генерация потока пакетов

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

В разделе 3 [RFC3432] предписан метод генерации периодических потоков с использованием связанных параметров.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).

dT

Продолжительность интервала для разрешённого времени начала выборки со значением 1,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).
Примечание. Процесс инициирования с множеством управляющих обменов ведёт к непредсказуемому времени старта (в пределах заданного интервала) может предотвратить ненужную синхронизации периодических потоков и послужить заменой выбору времени старта как случайного времени старта из фиксированного интервала.

Параметр T0 будет возвращаться в отчёте как измеренный, параметры incT и dT являются фиксированными.

4.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

4.3.4. Распределение выборки

Неприменимо

4.3.5. Рабочие параметры и формат данных

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

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

4.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет.

4.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

4.4.1. Тип

Percentile – персентиль

Для условного распределения всех пакетов с действительным значением времени обхода (неопределённые значения исключаются) это одно значение, соответствующее 95-му процентилю, как указано ниже.
В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. Значение percentile = 95 показывает, что указанная задержка 95Percentile является наименьшим временем кругового обхода (round-trip delay), при котором эмпирическая функция распределения (Empirical Distribution Function) EDF(95Percentile) не меньше 95% одиночных значений round-trip delay в условном распределении. Определение статистики процентилей с использованием EDF дано в параграфе 11.3 [RFC2330].
Для LossRatio отношения числа потерянных пакетов к числу переданных является основой при расчёте коэффициента потерь в соответствии с параграфом 6.1 [RFC6673].

4.4.2. Ссылки на определения

Для всего вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

TotalPkts

Число пакетов, переданных от Src к Dst в интервале измерений.

95Percentile

Время из результата, выраженное в секундах, как положительное число типа decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек).

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

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

95-й процентиль времени кругового обхода (round-trip delay) в секундах.

Коэффициент потерь при круговом обходе выражается долей потерянных пакетов в процентах.

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

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

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

4.5. Административные элементы

4.5.1. Статус

Действует

4.5.2. Запросчик

RFC 8912

4.5.3. Выпуск

1.0

4.5.4. Дата выпуска

2021-11-17

4.6. Комментарии и заметки

Нет

5. Запись для вариаций задержки пакетов

В этом разделе описана исходная запись реестра для вариаций задержки пакетов (Packet Delay Variation или PDV).

5.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

5.1.1. ID (идентификатор)

Агентство IANA выделило идентификатор 3 для именованных записей раздела 5. Сопоставление идентификаторов с именами приведено в параграфе 5.1.2.

5.1.2. Имя

3: OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile

5.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile

5.1.4. Описание

Этот показатель оценивает вариации относительно минимальной задержки, наблюдаемой в периодическом потоке. Вывод представляется 95-м процентилем распределения задержки пакетов в одном направлении.

5.1.5. Контролёр изменений

IETF

5.1.6. Версия (формата реестра)

1.0

5.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

5.2.1. Ссылки на определения

Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, “Framework for IP Performance Metrics”, RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>. [RFC2330]

Demichelis, C. and P. Chimento, “IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)”, RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>. [RFC3393]

Morton, A. and B. Claise, “Packet Delay Variation Applicability Statement”, RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>. [RFC5481]

Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. [RFC5905]

См. параграфы 2.4 и 3.4 в [RFC3393]. Измеренные различия одиночных значений задержки обозначаются переменной ddT (применима ко всем формам вариаций задержки). Однако эта запись задаёт форму PDV, определённую в параграфе 4.2 [RFC5481], где одиночное значение PDV для пакета i обозначается как переменная PDV(i).

5.2.2. Фиксированные параметры

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Общий размер 200 байтов.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

F

Функция выбора, однозначно определяющая пакеты из потока для показателя (см. параграф 4.2 в [RFC5481] для формы PDV).

Два дополнительных фиксированных параметра приведены в параграфе «Генерация потока пакетов».

5.3. Метод измерения

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

5.3.1. Ссылки на определения

В параграфах 2.6 и 3.6 of [RFC3393] описаны базовые расчёты для одиночных элементов (singleton). Эта запись реестра требует реализации формы PDV, определённой в параграфе 4.2 [RFC5481]. Измерения рассмотрены также в разделе 8 [RFC5481].

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя RTLoss [RFC6673].

Расчёты задержки в одном направлении нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта односторонней задержки должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

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

5.3.2. Генерация потока пакетов

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

В разделе 3 [RFC3432] предписан метод генерации периодических потоков с использованием связанных параметров.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек).

dT

Продолжительность интервала для разрешённого времени начала выборки со значением 1,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).
Примечание. Процесс инициирования с множеством управляющих обменов ведёт к непредсказуемому времени старта (в пределах заданного интервала), может предотвратить ненужную синхронизации периодических потоков и послужить заменой выбору времени старта как случайного значения из фиксированного интервала.

Параметр T0 будет возвращаться в отчёте как измеренный, параметры incT и dT являются фиксированными.

5.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

5.3.4. Распределение выборки

Неприменимо

5.3.5. Рабочие параметры и формат данных

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

5.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет (когда это нужно протоколу тестирования).

5.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

5.4.1. Тип

Percentile – персентиль

Для условного распределения всех пакетов с действительным значением времени обхода (неопределённые значения исключаются) это одно значение, соответствующее 95-му процентилю, как указано ниже.
В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. Значение percentile = 95 показывает, что указанная задержка 95Percentile является наименьшим временем кругового обхода (round-trip delay), при котором эмпирическая функция распределения (Empirical Distribution Function) EDF(95Percentile) не меньше 95% одиночных значений round-trip delay в условном распределении. Определение статистики процентилей с использованием EDF дано в параграфе 11.3 [RFC2330].

5.4.2. Ссылки на определения

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

95Percentile

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

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

95-й персентиль одностороннего значения PDV в секундах.

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

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

time_offset

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

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

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

5.5. Административные элементы

5.5.1. Статус

Действует

5.5.2. Запросчик

RFC 8912

5.5.3. Выпуск

1.0

5.5.4. Дата выпуска

2021-11-17

5.6. Комментарии и заметки

Потеря пакетов создаёт проблемы для измерения вариаций задержки. Расширенный анализ и сравнение PDV с межпакетными вариациями задержки (IPDV или Inter-Packet Delay Variation) приведены в параграфе 4.1 [RFC3393] и заявлении о применимости вариаций задержки в [RFC5481].

6. Записи для задержек и потерь для откликов DNS

В этом разделе описаны исходные записи реестра для задержек и потерь откликов DNS на запросы пользователей для именованного ресурса. Показатель может измеряться с повторением для разных именованных ресурсов. Метрика круговой задержки (round-trip delay) определена в [RFC2681] и применяется здесь в качестве основы с указанием нескольких входных параметров для точного определения двух показателей задержки и потерь для откликов DNS.

Все записи столбцов, кроме категорий ID, Name, Description, Output Reference Method одинаковы. Таким образом, этот раздел определяет 2 тесно связанных записи реестра. В результате агентство IANA выделило соответствующие URL для каждой из двух именованных метрик.

6.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

6.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 4 и 5 для именованных записей раздела 6. Сопоставление идентификаторов с именами приведено в параграфе 6.1.2.

6.1.2. Имя

4: RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw

5: RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw

6.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw

URL: https://www.iana.org/assignments/performance-metrics/RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw

6.1.4. Описание

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

RTDNS

Этот показатель оценивает время отклика по интервалу между отправкой запроса и получением отклика.

RLDNS

Этот показатель говорит о том, что отклик сочтён потерянным. Иными словами, время отклика превысило максимальное время ожидания.

6.1.5. Контролёр изменений

IETF

6.1.6. Версия (формата реестра)

1.0

6.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

6.2.1. Ссылки на определения

Задержки

Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035> (и обновления). [RFC1035]

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

В параграфе 2.4 [RFC2681] дано определение метрики круговой задержки при одном измерении (singleton). В параграфе 3.4 [RFC2681] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

Для задержки отклика DNS Response объекты [RFC1035] должны сопоставляться с объектами [RFC2681]. Локальный хост с пользовательской программой и распознавателем (Resolver) играют роль источника (Src), а внешний сервер имён (Foreign Name Server) – роль получателя (Dst).

Хотя определение круговой задержки между Src и Dst в T, как указано в параграфе 2.4 [RFC2681], является намеренно неоднозначным в тексте, этот показатель делает определение более строгим, указывая, что хост в роли Src передаёт первый пакет хосту в роли Dst и в конечном итоге получает от того соответствующий пакет возврата Dst (если он не будет потерян).

Потери

Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>. [RFC6673]

Для потерь откликов DNS объекты [RFC1035] должны сопоставляться с объектами [RFC2681]. Локальный хост с пользовательской программой и распознавателем (Resolver) играют роль источника (Src), а внешний сервер имён (Foreign Name Server) – роль получателя (Dst).

Показатели времени отклика и потерь используют максимальное время ожидания для полученных откликов, поэтому отношение числа потерянных пакетов к числу переданных является основой для расчёта коэффициента потерь в соответствии с параграфом 4.3 в [RFC6673].

6.2.2. Фиксированные параметры

Определение Type-P дано в разделе 13 [RFC2330].

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Source port: 53
Destination port: 53
Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Поле данных

Поле данных содержит сообщение DNS, как определено в [RFC1035], с приведёнными ниже значениями.
Раздел заголовка DNS включает:
Identification (см. столбец Runtime)
QR = 0 (запрос)
OPCODE = 0 (стандартный запрос)
AA: не задано
TC: не задано
RD = 1 (желательна рекурсия)
RA: не задано
RCODE: не задано
QDCOUNT = 1 (только одна запись)
ANCOUNT: не задано
NSCOUNT: не задано
ARCOUNT: не задано
Раздел Question содержит:
QNAME: полное доменное имя (Fully Qualified Domain Name или FQDN), указанное при запуске теста (см. столбец Runtime)
QTYPE: тип запроса, указанный при запуске теста (см. столбец Runtime)
QCLASS = 1 (для IN)
Остальные разделы не содержат записей о ресурсах (Resource Record или RR).

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Observation

Пакеты отклика будут содержать DNS Response и могут включать записи RR.

6.3. Метод измерения

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

6.3.1. Ссылки на определения

Методология для этой метрики (эквивалент Type-P-Round-trip-Delay-Poisson-Stream) определена в параграфе 2.6 [RFC2681] (для одиночных измерений) и параграфе 3.6 [RFC2681] (для выборки) с использованием Type-P и Timeout, указанных в столбце Fixed Parameters.

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

Расчёты задержки (RTT) нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта RTT должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

Сообщения DNS с запросами представляют случайное значение ID Number в поле заголовка Identification, поэтому при использовании ID Number можно вводить новый запрос до завершения обработки предыдущего. Следовательно, значение ID Number должно сохраняться в Src и включаться в каждый пакет отклика для устранения нарушений порядка доставки пакетов, если они возникают.

Если отклик DNS не приходит в интервале Tmax, время RTDNS становится неопределённым, а RLDNS = 1. Нужно использовать идентификаторы сообщений, чтобы различать идентичные последовательные запросы. Поскольку поле ID Number имеет лишь 16 битов, это ограничивает число одновременных запросов DNS при нагрузочных тестах с одного адреса Src.

В параграфе 4.4 [RFC6673] даны подробные инструкции по «возврату пакетов Type-P устройству Src как можно быстрее» в соответствии с параграфом 2.6 в [RFC2681]. Однако от сервера DNS ожидается выполнение всех задач подготовки и отправки отклика, поэтому время отклика будет включать обработку и задержку в сети. В разделе 8 [RFC6673] приведены дополнительные требования, которые нужно включать в метод измерения для этого показателя.

В дополнение к операциям, описанным в [RFC2681], отправитель (Src) должен анализировать заголовки DNS в отклике и готовить данные из отклика для отчёта о результатах измерения вместе с круговой задержкой.

6.3.2. Генерация потока пакетов

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

В параграфе 11.1.3 [RFC2330] представлено 3 метода генерации интервалов выборки Пуассона. Обратное lambda значение является средним интервалом между пакетами, т. е. рабочий параметр Reciprocal_lambda = 1/lambda (в секундах).

Использовать нужно метод 3. Если задано время начала (Runtime), время последующих передач рассчитывается до измерения путём вычисления псевдослучайного распределения времени между пакетами (с отсечкой распределения, указанной параметром Trunc) и Src передаёт каждый пакет в расчётное время. Отметим, что Trunc задаёт верхнюю границу интервала между пакетами при распределении Пуассона. Случайные значения больше Trunc уменьшаются до Trunc.

6.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

6.3.4. Распределение выборки

Неприменимо

6.3.5. Рабочие параметры и формат данных

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

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

Reciprocal_lambda

Средний интервал между пакетами в потоке Пуассона, выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Trunc

Верхний предел для распределения Пуассона выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Значения выше этого предела отсекаются до заданного пределом значения.

ID

16-битовый идентификатор, задаваемый программой, которая создаёт запрос. Значение ID должно меняться от запроса к запросу (при необходимости поддерживается список), см. параграф 4.1.1 в [RFC1035]. Этот идентификатор копируется в соответствующий отклик и может применяться запрашивающей стороной (Src) для сопоставления откликов с незавершёнными запросами.

QNAME

Доменное имя для запроса в формате, заданном в разделе 4 [RFC6991].

QTYPE

Тип запроса, соответствующий семейству адреса IP (1 для IPv4, 28 для IPv6) в формате uint16, как указано в параграфе 9.2 [RFC6020].

6.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет.

6.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

6.4.1. Тип

Raw

Для каждого пакета с запросом DNS устанавливаются значения, указанные в следующем столбце (параграф 6.4.2), а значения задержки присваиваются лишь для пакетов, на которые получен отклик.

6.4.2. Ссылки на определения

T

Время отправки запроса DNS в интервале измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

dT

Время задержки получения отклика DNS, выраженное в секундах, как положительное число типа decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек. (1,0 нсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Это значение будет неопределённым, когда Src не получает отклика в интервале Tmax секунд.

RCODE

Значение поля RCODE из заголовка DNS Response в формате uint64, как указано в параграфе 9.2 of [RFC6020]. Ненулевые значения указывают ошибку в отклике и их нужно анализировать отдельно.

Logical

Численное значение из результата, выраженное как логическое – 1 = Lost (потеря), 0 = Received (получено) целым числом типа uint8 (значения от 0 до 255 включительно, см. параграф 9.2 в [RFC6020]). Для запросов с результатом 1 (потеря), в dT и RCODE устанавливаются максимальные значения decimal64 и uint64, соответственно.

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

RTDNS

Круговая задержка dT в секундах.

RLDNS

Логическое значение – 1 = Lost (потеря), 0 = Received (отклик получен).

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

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

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

6.5. Административные элементы

6.5.1. Статус

Действует

6.5.2. Запросчик

RFC 8912

6.5.3. Выпуск

1.0

6.5.4. Дата выпуска

2021-11-17

6.6. Комментарии и заметки

Нет

7. Записи UDP Poisson для односторонней задержки и потерь

В этом разделе описаны исходные записи реестра для UDP Poisson One-Way Delay и UDP Poisson One-Way Loss.

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 6 тесно связанных записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

7.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

7.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 6-11 для именованных записей раздела 7. Сопоставление идентификаторов с именами приведено в параграфе 7.1.2.

7.1.2. Имя

6: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile

7: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean

8: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min

9: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

10: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev

11: OWLoss_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Percent_LossRatio

7.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev

URL: https://www.iana.org/assignments/performance-metrics/OWLoss_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Percent_LossRatio

7.1.4. Описание

OWDelay

Этот показатель оценивает задержку потока пакетов между двумя хостами (или точками измерения) и сообщает статистическую (<statistic>) одностороннюю задержку для всех успешных обменов пакетами на основе условного распределения задержки. Статистика может иметь форму:
  • 95Percentile
  • Mean
  • Min
  • Max
  • StdDev

OWLoss

Этот показатель оценивает коэффициент потерь для потока пакетов между двумя хостами (точками измерения). Выводом является доля потерь в одном направлении, выраженная отношением числа потерянных пакетов к числу переданных в процентах.

7.1.5. Контролёр изменений

IETF

7.1.6. Версия (формата реестра)

1.0

7.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

7.2.1. Ссылки на определения

Задержки

Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Delay Metric for IP Performance Metrics (IPPM)”, STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>. [RFC7679]

Morton, A. and E. Stephan, “Spatial Composition of Metrics”, RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>. [RFC6049]

В параграфе 3.4 [RFC7679] дано определение метрики односторонней задержки при одном измерении (singleton). В параграфе 4.4 [RFC7679] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

В выборку включаются лишь успешные передачи с конечной задержкой, как указано в параграфе 4.1.2 [RFC6049].

Потери

Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Loss Metric for IP Performance Metrics (IPPM)”, STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>. [RFC7680]

В параграфе 2.4 [RFC7680] дано определение метрики односторонних потерь при одном измерении (singleton). В параграфе 3.4 [RFC7680] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

7.2.2. Фиксированные параметры

Type-P

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Пакеты в формате TWAMP-Test (параграф 4.1.2 в [RFC5357])
Используемые функции защиты влияют на число октетов заполнения (Padding)
Общий размер составляет 250 октетов, включая тип формата TWAMP, который должен указываться.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Два дополнительных фиксированных параметра приведены в параграфе «Генерация потока пакетов».

7.3. Метод измерения

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

7.3.1. Ссылки на определения

Методология для этого показателя (эквивалент Type-P-One-way-Delay-Poisson-Stream) определена в параграфе 3.6 [RFC7679] (для одиночных измерений) и параграфе 4.6 [RFC7679] (для выборок) с использованием Type-P и Tmax, указанных в столбце Fixed Parameters.

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

Расчёты задержки в одном направлении нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта односторонней задержки должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

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

7.3.2. Генерация потока пакетов

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

В параграфе 11.1.3 [RFC2330] представлено 3 метода генерации интервалов выборки Пуассона. Обратное lambda значение является средним интервалом между пакетами, т. е. рабочий параметр Reciprocal_lambda = 1/lambda (в секундах).

Использовать нужно метод 3. Если задано время начала (Runtime), время последующих передач рассчитывается до измерения путём вычисления псевдослучайного распределения времени между пакетами (с отсечкой распределения, указанной параметром Trunc) и Src передаёт каждый пакет в расчётное время. Отметим, что Trunc задаёт верхнюю границу интервала между пакетами при распределении Пуассона. Случайные значения больше Trunc уменьшаются до Trunc.

Reciprocal_lambda

Средний интервал между пакетами в потоке Пуассона, выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Reciprocal_lambda = 1 секунда.

Trunc

Верхний предел для распределения Пуассона выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Значения выше этого предела отсекаются да заданного пределом значения. Trunc = 30,0000 секунд.

7.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

7.3.4. Распределение выборки

Неприменимо

7.3.5. Рабочие параметры и формат данных

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

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

7.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst. Примером является TWAMP Session-Sender.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет. Примером является TWAMP Session-Reflector.

7.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

7.4.1. Тип

Типы рассматриваются ниже.

7.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Для LossRatio отношение числа потерянных пакетов к числу переданных служит основой для расчёта коэффициента потерь в соответствии с параграфом 4.1 в [RFC7680].

Для каждого значения <statistic> или Percent_LossRatio применяется один из последующих параграфов.

7.4.2.1. Percentile95

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3 [RFC3393] приведены детали расчёта статистики процентилей (круговую задержку следует заменить ipdv).

percentile = 95, означающее, что сообщённая задержка 95Percentile является наименьшей односторонней задержкой, для которой эмпирическая функция распределения (Empirical Distribution Function) или EDF(95Percentile) даёт результат не меньше, чем 95% одиночных значений задержки в условном распределении. Определение статистики с использованием EDF дано в параграфе 11.3 [RFC2330].

95Percentile

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.2. Mean

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.3. Min

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.4. Max

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.5. Std_Dev

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 6.1.4 of [RFC6049] описан тесно связанный метод расчёта этой статистики. Формула представляет собой классический расчёт стандартного отклонения, как показано ниже.

                        _                                       _
                       |            N                            |
                       |           ---                           |
                       |     1     \                          2  |
       Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                       |    (N)    /                             |
                       |           ---                           |
                       |          n = 1                          |
                       |_                                       _|

где все пакеты с n от 1 до N имеют значение Delay[n], величина MeanDelay рассчитывается в соответствии с параграфом 7.4.2.2, SQRT[] указывает извлечение квадратного корня.

Std_Dev

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.6. Percent_LossRatio

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

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

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • 95Percentile
  • Mean
  • Min
  • Max
  • StdDev

Потери в одном направлении указывается процентным отношениям числа потерянных пакетов к числу переданных.

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

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

time_offset

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

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

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

7.5. Административные элементы

7.5.1. Статус

Действует

7.5.2. Запросчик

RFC 8912

7.5.3. Выпуск

1.0

7.5.4. Дата выпуска

2021-11-17

7.6. Комментарии и заметки

Нет

8. Записи для UDP Periodic One-Way Delay и UDP Periodic One-Way Loss

В этом разделе описаны исходные записи реестра для UDP Periodic One-Way Delay и UDP Periodic One-Way Loss.

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 6 тесно связанных записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

8.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

8.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 12-17 для именованных записей раздела 8. Сопоставление идентификаторов с именами приведено в параграфе 8.1.2.

8.1.2. Имя

12: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile

13: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Mean

14: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min

15: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max

16: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_StdDev

17: OWLoss_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Percent_LossRatio

8.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_StdDev

URL: https://www.iana.org/assignments/performance-metrics/OWLoss_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Percent_LossRatio

8.1.4. Описание

OWDelay

Этот показатель оценивает задержку потока пакетов между двумя хостами (или точками измерения) и сообщает статистическую (<statistic>) одностороннюю задержку для всех успешных обменов пакетами на основе условного распределения задержки. Статистика может иметь форму:
  • 95Percentile
  • Mean
  • Min
  • Max

OWLoss

Этот показатель оценивает коэффициент потерь пакетов между парой хостов (точки измерения). Результатом служит доля теряемых в одном направлении пакетов, выраженная в процентах.

8.1.5. Контролёр изменений

IETF

8.1.6. Версия (формата реестра)

1.0

8.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

8.2.1. Ссылки на определения

Задержки

Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Delay Metric for IP Performance Metrics (IPPM)”, STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>. [RFC7679]

Morton, A. and E. Stephan, “Spatial Composition of Metrics”, RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>. [RFC6049]

В параграфе 3.4 [RFC7679] дано определение метрики односторонней задержки при одном измерении (singleton). В параграфе 4.4 [RFC7679] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

В выборку включаются лишь успешные передачи с конечной задержкой, как указано в параграфе 4.1.2 [RFC6049].

Потери

Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Loss Metric for IP Performance Metrics (IPPM)”, STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>. [RFC7680]

В параграфе 2.4 [RFC7680] дано определение метрики односторонних потерь при одном измерении (singleton). В параграфе 3.4 [RFC7680] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

8.2.2. Фиксированные параметры

Type-P

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Пакеты в формате TWAMP-Test (параграф 4.1.2 в [RFC5357])
Используемые функции защиты влияют на число октетов заполнения (Padding)
Общий размер составляет 142 октетов, включая формат TWAMP, который должен указываться при использовании.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Три дополнительных фиксированных параметра приведены в параграфе «Генерация потока пакетов».

8.3. Метод измерения

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

8.3.1. Ссылки на определения

Методология для этого показателя (эквивалент Type-P-One-way-Delay-Poisson-Stream) определена в параграфе 3.6 [RFC7679] (для одиночных измерений) и параграфе 4.6 [RFC7679] (для выборок) с использованием Type-P и Tmax, указанных в столбце Fixed Parameters. Однако применяется периодический поток, определённый в [RFC3432].

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

Расчёты задержки в одном направлении нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта односторонней задержки должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

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

8.3.2. Генерация потока пакетов

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

В разделе 3 [RFC3432] предписан метод генерации периодических потоков с использованием связанных параметров.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

dT

Продолжительность интервала для разрешённого времени начала выборки со значением 1,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

T0

Фактическое время запуска периодического потока, определяемое из T0 и dT.
Примечание. Процесс инициирования с множеством управляющих обменов ведёт к непредсказуемому времени старта (в пределах заданного интервала), может предотвратить ненужную синхронизации периодических потоков и послужить заменой выбору времени старта как случайного значения из фиксированного интервала.
Параметр T0 будет возвращаться в отчёте как измеренный, параметры incT и dT являются фиксированными.

Эти параметры потока задаются как рабочие (Runtime).

8.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

8.3.4. Распределение выборки

Неприменимо

8.3.5. Рабочие параметры и формат данных

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

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

8.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst. Примером является TWAMP Session-Sender.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет. Примером является TWAMP Session-Reflector.

8.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

8.4.1. Тип

Типы задержки и потерь, описанные в последующих параграфах.

8.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Для LossRatio отношение числа потерянных пакетов к числу переданных служит основой для расчёта коэффициента потерь в соответствии с параграфом 4.1 в [RFC7680].

Для каждого значения <statistic> или Percent_LossRatio применяется один из последующих параграфов.

8.4.2.1. Percentile95

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3 [RFC3393] приведены детали расчёта статистики процентилей (круговую задержку следует заменить ipdv).

percentile = 95, означающее, что сообщённая задержка 95Percentile является наименьшей односторонней задержкой, для которой эмпирическая функция распределения (Empirical Distribution Function или EDF(95Percentile)) дает результат не меньше, чем 95% одиночных значений задержки в условном распределении. Определение статистики с использованием EDF дано в параграфе 11.3 [RFC2330].

95Percentile

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.2. Mean

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.3. Min

Минимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже. В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.4. Max

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.5. Std_Dev

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 6.1.4 of [RFC6049] описан тесно связанный метод расчёта этой статистики. Формула представляет собой классический расчёт стандартного отклонения, как показано ниже.

                        _                                       _
                       |            N                            |
                       |           ---                           |
                       |     1     \                          2  |
       Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                       |    (N)    /                             |
                       |           ---                           |
                       |          n = 1                          |
                       |_                                       _|

где все пакеты с n от 1 до N имеют значение Delay[n], величина MeanDelay рассчитывается в соответствии с параграфом 8.4.2.2, SQRT[] указывает извлечение квадратного корня.

Std_Dev

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.6. Percent_LossRatio

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

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

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • 95Percentile
  • Mean
  • Min
  • Max
  • StdDev

Потери в одном направлении указывается процентным отношениям числа потерянных пакетов к числу переданных.

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

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

time_offset

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

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

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

8.5. Административные элементы

8.5.1. Статус

Действует

8.5.2. Запросчик

RFC 8912

8.5.3. Выпуск

1.0

8.5.4. Дата выпуска

2021-11-17

8.6. Комментарии и заметки

Нет

9. Записи для ICMP Round-Trip Latency и ICMP Round-Trip Loss

В этом разделе описаны исходные записи реестра для ICMP Round-Trip Latency и ICMP Round-Trip Loss Ratio.

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 4 тесно связанные записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

9.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

9.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 18-21 для именованных записей раздела 9. Сопоставление идентификаторов с именами приведено в параграфе 9.1.2.

9.1.2. Имя

18: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean

19: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min

20: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

21: RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio

9.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio

9.1.4. Описание

RTDelay

Этот показатель оценивает задержку потока пакетов ICMP, передаваемых между парой хостов (точки измерения). Выводом служит круговая задержка для всех пакетов с успешным обменом, выраженная как статистика условного распределения, где статистикой может быть :
  • Mean
  • Min
  • Max

RTLoss

Этот показатель оценивает коэффициент потери пакетов, передаваемых между двумя хостами (точки измерения). Выводом является доля теряемых в обоих направлениях (round-trip) пакетов, выраженная в процентах.

9.1.5. Контролёр изменений

IETF

9.1.6. Версия (формата реестра)

1.0

9.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

9.2.1. Ссылки на определения

Задержки

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

В параграфе 2.4 [RFC2681] дано определение метрики круговой задержки при одном измерении (singleton). В параграфе 3.4 [RFC2681] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

Хотя определение круговой задержки между Src и Dst в параграфе 2.4 [RFC2681] является намеренно неоднозначным в тексте, этот показатель делает определение более строгим, указывая, что хост в роли Src передаёт первый пакет хосту в роли Dst и в конечном итоге получает от того соответствующий пакет возврата Dst (если он не будет потерян).

Переменная dT в [RFC2681] указывает значение времени кругового обхода в определениях показателя и методах. Это имя переменной также применяется в других документах IPPM для других величин и не может служить в качестве глобального имени переменной.

Потери

Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>. [RFC6673]

Показатели времени отклика и потерь используют максимальное время ожидания для полученных откликов, поэтому отношение числа потерянных пакетов к числу переданных является основой для расчёта коэффициента потерь в соответствии с параграфом 6.1 в [RFC6673].

9.2.2. Фиксированные параметры

Определение Type-P дано в разделе 13 [RFC2330].

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 01 (ICMP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 128 (десятичное, ICMP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок ICMP

Type: 8 (Echo Request)
Code: 0
Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.
(Идентификатор и порядковый номер, устанавливаемые при работе)

ICMP Payload:

32 байта случайных данных, не меняющиеся в течение теста

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

9.3. Метод измерения

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

9.3.1. Ссылки на определения

Методология для этой метрики (эквивалент Type-P-Round-trip-Delay-Poisson-Stream) определена в параграфе 2.6 [RFC2681] (для одиночных измерений) и параграфе 3.6 [RFC2681] (для выборки) с использованием Type-P и Timeout, указанных в столбце Fixed Parameters.

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

Расчёты задержки RTD нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта RTD должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

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

В параграфе 4.4 [RFC6673] даны подробные инструкции по «возврату пакетов Type-P устройству Src как можно быстрее» в соответствии с параграфом 2.6 в [RFC2681]. Однако от сервера DNS ожидается выполнение всех задач подготовки и отправки отклика, поэтому время отклика будет включать обработку и задержку в сети. В разделе 8 [RFC6673] приведены дополнительные требования, которые нужно включать в метод измерения для этого показателя.

9.3.2. Генерация потока пакетов

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

Показатели ICMP используют дисциплину передачи SendOnRcv (Send On Receive) – передача в ответ на получение. Это является модификацией требований раздела 3 в [RFC3432], задающего метод генерации периодических потоков с использованием связанных параметров, как указано ниже.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита).

dT

Длительность интервала разрешённого времени начала выборки.

Параметр потока incT задаётся как рабочий (Runtime), а dT не применяется в SendOnRcv.

Отправитель SendOnRcv ведёт себя так же, как генератор периодического потока, пока все пакеты откликов приходят с RTD < incT, а межпакетный интервал является постоянным. Если пакеты отклика приходят с RTD >= incT, межпакетный интервал для времени следующей передачи номинально составляет RTD. Если пакет отклика не приходит в интервале Tmax, межпакетный интервал для времени следующей передачи номинально составляет Tmax.

Для незамедлительной отправки при получении отклика (Send On Reply) устанавливается incT = 0.

9.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

9.3.4. Распределение выборки

Неприменимо

9.3.5. Рабочие параметры и формат данных

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

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Count

Общее число переданных пакетов ICMP Echo Request в формате uint16, как указано в параграфе 9.2 [RFC6020].

Дополнительные рабочие параметры описаны в параграфе «Генерация потока пакетов».

9.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет ((ICMP Echo Reply, типа 0).

9.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

9.4.1. Тип

Типы для задержки и потерь описаны в последующих параграфах.

9.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

TotalCount

Число пакетов, переданных фактически от Src к Dst в течение интервала измерения.

Для каждого значения <statistic> или Percent_LossRatio применяется один из последующих параграфов.

9.4.2.1. Mean

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
9.4.2.2. Min

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
9.4.2.3. Max

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
9.4.2.4. Percent_LossRatio

Для LossRatio отношение числа потерянных пакетов к общему числу переданных пакетов служит основой при расчёте коэффициента потерь в соответствии с параграфом 4.1 в [RFC7680].

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

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

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • Mean
  • Min
  • Max

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

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

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

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

9.5. Административные элементы

9.5.1. Статус

Действует

9.5.2. Запросчик

RFC 8912

9.5.3. Выпуск

1.0

9.5.4. Дата выпуска

2021-11-17

9.6. Комментарии и заметки

Нет

10. Записи для TCP Round-Trip Delay и TCP Round-Trip Loss

В этом разделе описаны исходные записи реестра для пассивной оценки круговой задержки TCP (TCP Round-Trip Delay или RTD) и круговых потерь TCP (TCP Round-Trip Loss Count).

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 4 тесно связанные записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

10.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

10.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 22-26 для именованных записей раздела 10. Сопоставление идентификаторов с именами приведено в параграфе 10.1.2.

10.1.2. Имя

22: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean

23: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min

24: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max

25: RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton4

26: RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

10.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton

URL: https://www.iana.org/assignments/performance-metrics/RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

10.1.4. Описание

RTDelay

Этот показатель оценивает круговую (round-trip) задержку пакетов TCP в одном соединении между парой хостов. Измерение такой задержки происходит в одной точке наблюдения (Observation Point или OP) [RFC7011] где-либо в сети. Результатом является круговая задержка для успешного обмена пакетами, выраженная как статистика условного распределения задержки, которая может принимать вид:
  • Mean
  • Min
  • Max

RTDelay Singleton

Этот показатель оценивает круговую задержку пакетов TCP, инициирующих 1 соединение (3-way handshake) между парой хостов. Рассматривается измерение круговой задержки в одной точке наблюдения (OP) [RFC7011] где-либо в сети. Выводом является одно значение Round-trip delay (Singleton).

RTLoss

Этот параметр оценивает число потерь пакетов TCP в одном соединении между парой хостов. Рассматривается число потерь5, обнаруженное в одной OP [RFC7011] где-либо в сети. Выводом является оценка числа потерь в интервале измерений.

10.1.5. Контролёр изменений

IETF

10.1.6. Версия (формата реестра)

1.0

10.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

10.2.1. Ссылки на определения

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

RFC с описанием пассивного измерения круговой задержки нет, а определение для активного измерения дано в [RFC2681].

В этом определении метрики применяется термин «время в линии» (wire time), как определено в параграфе 10.2 [RFC2330], а также термины «одиночный» (singleton) и «выборка» (sample), определённые в разделе 11 [RFC2330]. В параграфе 2.4 [RFC2681] приведено эталонное определение singleton-метрики круговой задержки (одно значение), а в параграфе [RFC2681] – это определение расширено для выборки нескольких значений.

Поскольку OP [RFC7011] обычно находится между участвующими в соединении TCP хостами, показатель круговой задержки требует 2 отдельных измерений между OP и каждым из хостов, чтобы объединение этих результатов (Spatial Composition) [RFC6049] давало одно значение round-trip delay (композиция двух значений односторонней задержки в круговую задержку субпути).

С учётом направления передачи TCP SYN для привязки хост A передаёт SYN, а хост B отвечает пакетом SYN-ACK в процессе организации соединения. Направление передачи SYN считается прямым (Forward) от A через OP хосту B (обратным будет направление от B через OP к хосту A).

Фильтры трафика сокращают поток пакетов на OP до нужного (Qualified) уровня двухсторонней передачи.

В приведённых ниже определениях соответствующие фильтру пакеты (Corresponding Packet) передаются в разных направлениях и имеют общее поле в заголовке TCP, которое определяет соответствие (насколько это возможно). Примером может служит поле временных меток TCP.

Для действительного числа RTD_fwd (круговая задержка в прямом направлении от OP к B в момент T’) требуется, чтобы в точке OP наблюдался Qualified Packet к хосту B в момент T’, хост B принял этот пакет и передал соответствующий пакет обратно хосту A, а точка наблюдения OP увидела этот пакет в момент (wire time) T’ + RTD_fwd.

Для действительного числа RTD_rev (круговая задержка в обратном направлении от OP к A в момент T”) требуется, чтобы точка OP наблюдала Qualified Packet к хосту A в момент T”, хост A получил этот пакет и передал соответствующий отклик хосту B, а точка наблюдения OP увидела этот пакет в момент T” + RTD_rev.

В идеале пакету от B к A в обоих приведённых выше определениях следует быть одним и тем же (при измерении сначала RTD_rev это относится к пакету от A к B).

Требуемая функция объединения (Composition Function) для одиночного измерения круговой задержки в момент T (более ранний среди указанных выше T’ и T”) имеет вид

   RTDelay = RTD_fwd + RTD_rev

Отметим, что при размещении OP на хосте A или B один из элементов RTDelay становится нулевым или пренебрежимо малым.

При обозначении согласования TCP применяется сокращение HS. Когда пакеты Qualified и Corresponding являются TCP-SYN и TCP-SYN-ACK, RTD_fwd == RTD_HS_fwd. Когда пакеты Qualified и Corresponding являются TCP-SYN-ACK и TCP-ACK, RTD_rev == RTD_HS_rev.

Требуемая функция объединения для одиночного (singleton) измерения круговой задержки при согласовании имеет вид

   RTDelay_HS = RTD_HS_fwd + RTD_HS_rev

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

Сегменты с нарушением порядка

Сегменты TCP передаются с монотонно возрастающими порядковыми номерами, но сегменты могут быть приняты с нарушением порядка. В разделе 3 [RFC4737] описывается понятие «следующего ожидаемого номера» (next expected), которое можно приспособить к сегментам TCP (для обнаружения нарушенного порядка). Наблюдение нарушающих порядок пакетов указывает потерю на пути до OP и пропуск в номерах.

Дубликаты сегментов

В разделе 2 [RFC5560] определены идентичные пакеты и это подходит для оценки пакетов TCP при обнаружении дубликатов. Дубликат ранее наблюдавшегося сегмента (и отсутствие соответствующего пропуска в наблюдаемых номерах) говорит о потере пакета на пути после OP (например, сегмент перекрывается с частью потока октетов, уже отмеченного в OP).

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

В приведённых выше наблюдениях для прямого направления число сегментов с нарушением порядка и дубликатов определяется как RTL_fwd. Соответствующие наблюдения в направлении Reverse определяются как RTL_rev.

Для интервала измерения (одно соединение TCP) от T0 до Tf требуемая функция объединения двух счётчиков подразумеваемых потерь для каждого направления имеет вид

   RTLoss = RTL_fwd + RTL_rev

10.2.2. Фиксированные параметры

Фильтры трафика

Заголовок IPv4

DSCP = 0
Protocol = 06 (TCP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 6 (TCP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок TCP

Флаги: ACK, SYN, FIN, установленные должным образом

Timestamps Option (Tsopt)

Указана, см. параграф 3.2 в [RFC7323]

10.3. Метод измерения

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

10.3.1. Ссылки на определения

Базовая методология для этой метрики определена в разделе 4 [RFC7323] на основе опции Timestamp с изменениями, разрешающими приложения на OP в в пути [RFC7011]. Дополнительные детали и применимая эвристика выведены из работ [Strowes] и [Trammell-14].

Фильтр трафика на OP настраивается для наблюдения одного соединения TCP. В процессе согласования SYN/SYN-ACK/ACK это предоставляет первую возможность измерить RTD_fwd (по паре SYN – SYN-ACK) и RTD_rev (по паре SYN-ACK – ACK). Обозначим это одиночное измерение RTDelay как RTDelay_HS (общая задержка для направления Forward и Reverse). RTDelay_HS нужно обрабатывать отдельно от значений RTDelay для пакетов данных и их ACK. Значение RTDelay_HS можно использовать для проверки согласованности композитных значений RTDelay для пакетов данных.

Для пакетов с данными OP измеряет интервал времени между наблюдением пакета с порядковым номером s и отклика ACK с тем же номером. При передаче данных от хоста A к хосту B это будет интервал RTD_fwd.

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

Поскольку передача данных во многих случаях является односторонней (например, в направлении Forward от A к B), для измерения RTD_rev необходимо использовать «чистые» пакеты ACK с временной меткой (TSval) и пакеты с «отражённой» временной меткой. Временной интервал между наблюдением ACK от B к A и соответствующим пакетом с полем Timestamp Echo Reply (TSecr) [RFC7323] определяет значение RTD_rev.

Эвристика фильтрации измерений задержки описана ниже.

  • Если данные (payload) передавались в обоих направлениях Forward и Reverse, может применяться правило измерения времени кругового обхода (Round-Trip Time Measurement) из параграфа 4.1 в [RFC7323]. Это правило по сути исключает какие-либо измерения, если пакет «не продвигается в передаче» (сдвиг левого края окна передачи в соответствии с [Strowes]).

  • Эвристика [Trammell-14] исключает RTD_rev со значениями больше наблюдавшихся ранее. Это ведёт к исключению измерений в обратном (Reverse) направлении, выполненных при отсутствии у приложения данных для передачи, поскольку в этом случае к RTD_rev может быть добавлено значительное время.

  • Отметим, что в приведённой выше эвристике предполагается, что хост A передаёт данные. Если этот хост является принимающим, эвристику следует применять к RTD_fwd.

  • Статистические расчёты задержки (RTDelay) нужно выполнять для условного распределения при условии успешных измерений в направлениях Forward и Reverse в соответствии с эвристикой.

Метод фиксации (Inferring) потерь указан ниже.

  • OP отслеживает порядковые номера и сохраняет пропуски для каждого направления передачи, а также следующий ожидаемый порядковый номер, как указано в [Trammell-14] и [RFC4737]. Потеря фиксируется по нарушению порядка или дублированию сегментов.

Эвристика фильтрации измерения потерь.

  • В [Trammell-14] добавлено окно оценки на основе RTDelay.

  • Следует отличать пакеты с нарушением порядка от сегментов с порядком, нарушенным в результате потери, поскольку пропуск в порядковых номерах заполняется в том же окне RTDelay. Обнаружение сегментов с нарушенным порядком в соответствии с [RFC4737] должно вести к снижению счётчика потерь выведенных на основе неупорядоченных сегментов.

  • Число ложных (ненужных) повторов передачи (наблюдаемых как дубликаты) также может быть снижено этим способом, как описано в [Trammell-14].

Источники ошибок.

  • Основным источником ошибок RTDelay является время обработки хостом для возврата пакета, который определяет завершение интервала измерения. Приведённая выше эвристика предназначена для смягчения этих ошибок за счёт исключения измерений, где время обработки хостом составляет значительную часть RTD_fwd или RTD_rev.

  • Основным источником ошибок RTLoss является потеря наблюдения, как описано в разделе 3 [Trammell-14].

10.3.2. Генерация потока пакетов

Неприменимо

10.3.3. Детали фильтрации (наблюдения) трафика

Указанные выше фиксированные параметры задают часть фильтров трафика. Другие аспекты задают рабочие (Runtime) параметры, описанные ниже.

10.3.4. Распределение выборки

Эта метрика требует полной выборки всех пакетов, соответствующих критериям Traffic Filter.

10.3.5. Рабочие параметры и формат данных

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

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Необязательное время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]) или длительность интервала измерения. Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. Кроме того, завершение интервала измерения может контролироваться измеряемым соединением, когда вторая пара пакетов (FIN и ACK) между хостами A и B фактически завершает интервал.

TTL или Hop Limit

Устанавливается желаемое значение.

10.3.6. Роли

Хост A

Запускает пакет SYN для организации соединения. Роль host A является синонимом адреса IP на хосте A.

Хост B

Отвечает пакетом SYN-ACK для организации соединения. Роль host B является синонимом адреса IP на хосте B.

10.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

10.4.1. Тип

Типы RTDelay рассматриваются ниже.

RTLoss – число потерянных пакетов.

10.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Конец интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. Конец интервала измерения может контролироваться измеряемым соединением, когда вторая пара пакетов (FIN и ACK) между хостами A и B фактически завершает интервал.

RTDelay_Passive_IP-TCP-HS

Круговая задержка при согласовании является одиночным результатом (Singleton).

RTLoss

Число потерянных пакетов.

Для статистики, Singleton и Loss Count применим один из описанных ниже вариантов.

10.4.2.1. Mean

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
10.4.2.2. Min

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
10.4.2.3. Max

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

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
10.4.2.4. Singleton

Одиночный результат (singleton) нужно рассчитывать с использованием RTD_fwd (для пары SYN и SYN-ACK) и RTD_rev (для пары SYN-ACK и ACK), как указано в параграфе 10.3.1.

Значение singleton – это время из результата, выраженное в секундах положительным числом типа decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

10.4.2.5. Счётчики потерь

RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

Число потерянных пакетов.

Наблюдение сегментов с нарушениям порядка или дублированием ведёт к фиксации потери после применения определений из параграфа 10.2.1 и эвристики для измерения потерь из параграфа 10.3.1. Определение круговых потерь выполняется в интервале измерения, которым является одно соединение TCP.

Для интервала измерения (одно соединение TCP) от T0 до Tf требуемая функция объединения двух счётчиков подразумеваемых потерь для каждого направления имеет вид

   RTLoss = RTL_fwd + RTL_rev

Packet count

Числовое значение результат выраженное количеством потерянных пакетов в форме целого числа типа uint64 (значение от 0 до 18446744073709551615 включительно, см. параграф 9.2 в [RFC6020]).

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

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • Mean
  • Min
  • Max

Одиночное измерение круговой задержки трехэтапного согласования TCP выражается в секундах.

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

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

Пассивные измерения в точке OP могут быть откалиброваны по активным измерениям (с эмуляцией потерь) на хосте A или B, где активное измерение определяет точность.

10.5. Административные элементы

10.5.1. Статус

Действует

10.5.2. Запросчик

RFC 8912

10.5.3. Выпуск

1.0

10.5.4. Дата выпуска

2021-11-17

10.6. Комментарии и заметки

Нет

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

Записи реестра не оказывают известных влияний на безопасность Internet. За исключением [RFC1035], все упомянутые здесь RFC содержат раздел «Вопросы безопасности». Кроме того, модель LMAP [RFC7594] обеспечивает при измерениях безопасность и приватность (конфиденциальность).

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

12. Взаимодействие с IANA

Агентство IANA заполнило реестр Performance Metrics, определённый в [RFC8911] значениями, указанными в разделах 4 – 10.

Дополнительная информация приведена в разделе «Взаимодействие с IANA» [RFC8911].

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

13.1. Нормативные документы

[RFC1035] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, “Framework for IP Performance Metrics”, RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.

[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”, RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC3393] Demichelis, C. and P. Chimento, “IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)”, RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, “Network performance measurement with periodic streams”, RFC 3432, DOI 10.17487/RFC3432, November 2002, <https://www.rfc-editor.org/info/rfc3432>.

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, “Packet Reordering Metrics”, RFC 4737, DOI 10.17487/RFC4737, November 2006, <https://www.rfc-editor.org/info/rfc4737>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC5481] Morton, A. and B. Claise, “Packet Delay Variation Applicability Statement”, RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>.

[RFC5560] Uijterwaal, H., “A One-Way Packet Duplication Metric”, RFC 5560, DOI 10.17487/RFC5560, May 2009, <https://www.rfc-editor.org/info/rfc5560>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6049] Morton, A. and E. Stephan, “Spatial Composition of Metrics”, RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>.

[RFC6673] Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information”, STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., “TCP Extensions for High Performance”, RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Delay Metric for IP Performance Metrics (IPPM)”, STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.

[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Loss Metric for IP Performance Metrics (IPPM)”, STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, “Registry for Performance Metrics”, RFC 8911, DOI 10.17487/RFC8911, November 2021, <https://www.rfc-editor.org/info/rfc8911>.

[Strowes] Strowes, S., “Passively Measuring TCP Round-Trip Times”, Communications of the ACM, Vol. 56 No. 10, Pages 57-64, DOI 10.1145/2507771.2507781, October 2013, <https://dl.acm.org/doi/10.1145/2507771.2507781>.

[Trammell-14] Trammell, B., Gugelmann, D., and N. Brownlee, “Inline Data Integrity Signals for Passive Measurement”, In: Dainotti A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and Analysis. TMA 2014. Lecture Notes in Computer Science, vol 8406. Springer, Berlin, Heidelberg, DOI 10.1007/978-3-642-54999-1_2, March 2014, <https://link.springer.com/chapter/10.1007/978-3-642-54999-1_2>.

13.2. Дополнительная литература

[RFC1242] Bradner, S., “Benchmarking Terminology for Network Interconnection Devices”, RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.

[RFC6390] Clark, A. and B. Claise, “Guidelines for Considering New Performance Metric Development”, BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <https://www.rfc-editor.org/info/rfc6390>.

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, “Reporting IP Network Performance Metrics: Different Points of View”, RFC 6703, DOI 10.17487/RFC6703, August 2012, <https://www.rfc-editor.org/info/rfc6703>.

[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, “A Framework for Large-Scale Measurement of Broadband Performance (LMAP)”, RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

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

Авторы благодарят Brian Trammell за предложенный термин Runtime Parameters, который позволил отделить рабочие параметры от фиксированных, например, для идентификации метрики экспорта данных потока IP IP (Flow Information Export или IPFIX) с помощью Flow Key, предложения метрики Passive TCP RTD Metric, ссылки для поддержки и множество иных конструктивных предложений. Спасибо Peter Koch за несколько полезных предложений по устранению неоднозначности последовательных запросов DNS для метрики откликов DNS Response.

Авторы также признательны Barbara Stark, Juergen Schoenwaelder, Tim Carey, Yaakov Stein и участникам рабочей группы LMAP за конструктивный обзор и полезные предложения. Спасибо Michelle Cotton за её ранние обзоры в IANA и Amanda Baber за ответы на вопросы, связанные с представлением реестра и доступностью полного шаблона по URL.

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

Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
United States of America
Phone: +1 732 420 1571
Email: acmorton@att.com
 
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
28911 Leganes Madrid
Spain
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
 
Philip Eardley
BT
Adastral Park, Martlesham Heath
Ipswich
United Kingdom
Email: philip.eardley@bt.com
 
Kevin D’Souza
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
United States of America
Phone: +1 732 420 2514
Email: kld@att.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3См. [RFC7679] с примером традиционного шаблона IPPM, в значительной степени основанного на шаблоне рабочей группы Benchmarking Methodology из [RFC1242], и похожий шаблон в [RFC6390].

4Отметим, что наблюдатель в промежуточной точке может получить лишь 1 значение RTDelay для согласования TCP.

5В оригинале ошибочно указана круговая задержка. См. https://www.rfc-editor.org/errata/eid6762. Прим. перев.

Запись опубликована в рубрике RFC, Измерения и тестирование. Добавьте в закладки постоянную ссылку.

Добавить комментарий