RFC 8911 Registry for Performance Metrics

Internet Engineering Task Force (IETF)                        M. Bagnulo
Request for Comments: 8911                                          UC3M
Category: Standards Track                                      B. Claise
ISSN: 2070-1721                                                   Huawei
                                                              P. Eardley
                                                                      BT
                                                               A. Morton
                                                               AT&T Labs
                                                               A. Akhter
                                                              Consultant
                                                           November 2021

Registry for Performance Metrics

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

PDF

Аннотация

Этот документ задаёт формат реестра IANA Registry для метрик производительности, а также даёт рекомендации для запрашивающих и рецензирующих регистрацию показателей производительности.

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

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

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

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

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

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. Введение

IETF задаёт и применяет показатели производительности (Performance Metrics) протоколов и приложений, доставляемых ими. Эти показатель являются важной частью сетевых операций, использующих протоколы IETF и в [RFC6390] даны рекомендации по их разработке.

Определением и использованием показателей производительности занимались в IETF несколько рабочих групп (working group или WG), наиболее важные из которых указаны ниже.

• Группа показателей производительности IP (IP Performance Metrics или IPPM) занимается в основном определениями показателей производительности в рамках IETF.

• Группа методологии тестирования (Benchmarking Methodology или BMWG) определила много показателей производительности для использования при лабораторном тестировании межсетевых технологий.

• Группа Metric Blocks for use with RTCP’s Extended Report Framework (XRBLOCK), работа которой уже завершена, задала множество показателей, относящихся к расширенным отчётам протокола управления RTP (RTP Control Protocol Extended Reports или RTCP XR) [RFC3611], задающим модель, позволяющую передавать новую информацию в RTCP, дополняя исходные блоки отчётов, заданные в «RTP: A Transport Protocol for Real-Time Applications» [RFC3550].

• Группа IP Flow Information eXport (IPFIX), завершившая свою работу, задала процесс IANA (Internet Assigned Numbers Authority) для выделения новых информационных элементов. Некоторые элементы, связанные с показателями производительности, предлагаются на регулярной основе.

• Группа Performance Metrics for Other Layers (PMOL), завершившая работу, задала некоторые показатели производительности для качества голосовой связи по протоколу SIP (Session Initiation Protocol) [RFC6035].

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

Несмотря на важность показателей производительности в отрасли имеются 2 связанных с этим проблемы.

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

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

Эти проблемы могут быть решены созданием реестра для показателей производительности в IANA. Для этого данный документ определяет новый реестр IANA для параметров производительности (Performance Metrics).

На основании этого документа агентство IANA создало и поддерживает Performance Metrics Registry в соответствии с процедурами и форматом, заданными ниже. Реестр Performance Metrics предназначен для использования IETF и другими. Хотя приведённые здесь спецификации форматирования реестра предназначены в основном для IANA, их могут применять и другие организации, желающие создать свой реестр показателей производительности. Авторы не гарантируют применимость формата реестра для всех наборов показателей производительности, но рекомендуют использовать этот формат. Далее в документе поддерживаемый IANA реестр показателей производительности называется просто Performance Metrics Registry, если явно не указано иное.

2. Терминология

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

Performance Metric – показатель (метрика) производительности

Количественная мера производительности, предназначенная для заданного IETF протокола или приложения, доставляемого по протоколу IETF. Примерами показателей производительности служат время отклика FTP для полной загрузки файла, время отклика DNS для распознавания адресов IP, время регистрации в базе данных (logging) и т. п. Это определение согласуется с определением показателя (метрики) в [RFC2330] и шире определения показателя производительности из [RFC6390].

Registered Performance Metric – зарегистрированный показатель производительности

Показатель производительности, включенный как запись в Performance Metrics Registry, администрируемый IANA. Такие показатели соответствуют всем критериям, заданным этим документом для включения в реестр.

Performance Metrics Registry – реестр показателей производительности

Реестр IANA, содержащий зарегистрированные показатели производительности.

Proprietary Registry – фирменный (приватный) реестр

Набор показателей, включённых в частный реестр, но не в Performance Metrics Registry.

Performance Metrics Experts – эксперты по показателям производительности

Группа экспертов, выбранных IESG [RFC8126], для проверки показателей производительности перед обновлением Performance Metrics Registry. Эти эксперты тесно сотрудничают с IANA.

Parameter – параметр

Элемент ввода, заданный как переменная в определении Performance Metric. Параметр – это число или иное значение из набора, определяющего показатель или условия работы. Все параметры должны быть известны для использования метрики и интерпретации результатов. Имеется два типа параметров – фиксированные и рабочие (Runtime). Для фиксированных параметров значение переменной задаётся в записи Performance Metrics Registry и разные значения параметра ведут к разным Registered Performance Metric. Для рабочих параметров значение переменной определяет метод измерения (Metric Measurement Method) и данный показатель поддерживает несколько значений параметра. Хотя рабочие параметры не меняют фундаментальной природы определения показателя производительности, некоторые из них оказывают существенное влияние на используемое свойство сети и интерпретацию результатов.

Примечание. Рассмотрим случай потери пакета в двух вариантах активного измерения. В первом случае потеря пакета является фоновой, когда установка рабочего значения параметра задаёт очень разреженный поток Пуассона и характеризует лишь время потери пакетов. Фактические пользовательские потоки вероятно будут выше в результате отбрасывания хвостов (tail drop) или ошибок в радиоканале. Во втором случае доля теряемых пакетов определяется коэффициентом дополнительной вероятности доставки, когда рабочее значение параметра задаёт очень плотный, прерывистый поток и характеризует потери, испытываемые потоками, близкими к пользовательским. Оба показателя являются «метрикой потерь», но различие в интерпретации результатов сильно зависит от рабочих параметров (по меньшей мере). В экстремальном случае коэффициент потерь фактически используется для вывода дополнительной вероятности – коэффициента доставки.

Active Measurement Methods – активные методы измерения

Методы измерения, применяемые к трафику, который служит лишь для измерительных целей, генерируется только для этого и имеет заранее известные характеристики. Полное определение активных методов дано в параграфе 3.4 [RFC7799]. Примерами активных методов являются методы измерения односторонней задержки из [RFC7679] и длительности кругового обхода из [RFC2681].

Passive Measurement Methods – пассивные методы измерения

Методы измерения, применяемые к трафику, создаваемому (1) конечным пользователем или (2) элементами сети и существующему независимо от проведения измерений. Полное определение пассивных методов дано в параграфе 3.6 [RFC7799]. Одной из характеристик пассивных методов является возможность наблюдения конфиденциальной информации и её сохранения в измерительной системе.

Hybrid Measurement Methods – гибридные методы измерения

Методы измерения, использующие комбинации активных и пассивных методов для доступа к активным и пассивным показателям, а также к новым показателям, выведенным a priori на основе знаний и наблюдений за интересующими потоками. Полное определение гибридных методов дано в параграфе 3.8 [RFC7799].

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

Этот документ предназначен для двух разных аудиторий.

1. Для тех, кто готовит потенциальные показатели производительности, документ предоставляет критерии, которым предложению следует соответствовать (раздел 5). Документ также содержит инструкции по написанию текстов для каждого столбца кандидата в показатель производительности и ссылок, требуемых для новой записи Performance Metrics Registry (вплоть до включения публикации неизменяемых документов, таких как RFC). См. раздел 7.

2. Для назначенных экспертов Performance Metrics и персонала IANA, администрирующего новый реестр IANA Performance Metrics Registry, документ задаёт набор критериев приемлемости при оценке кандидатов в Registered Performance Metric и требований к созданию записей в Performance Metric Registry.

Другие организации, стандартизующие показатели производительности, призываются использовать описанный здесь процесс для того, чтобы предлагать кандидатов в Registered Performance Metric. Кроме того, документ может быть полезен организациям, определяющим свои реестры показателей производительности, которые могут воспользоваться определёнными здесь свойствами Performance Metrics Registry.

Реестр Performance Metrics применим к показателям производительности, выведенных из активных и пассивных измерений, а также другим формам Performance Metric. Реестр предназначен для включения показателей производительности через IETF, особенно для технологий, заданных рабочими группами IPPM, XRBLOCK, IPFIX, BMWG. Документ анализирует прежнюю попытку создать Performance Metrics Registry и причины её неудачи [RFC6248].

Документ [RFC8912] задаёт исходное содержимое нового реестра.

4. Мотивы создания Performance Metrics Registry

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

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

Как и для других реестров IETF, основной задачей является поддержка регистрации идентификаторов для использования в протоколах. В конкретном случае Performance Metrics Registry имеется два типа протоколов, которые будут использовать показатели производительности из реестра в своей работе (через индексы).

Control Protocol – протокол управления

Этот тип протоколов применяется для того, чтобы один объект мог запросить выполнение измерений другим объектом с использованием конкретной метрики, определённой в Performance Metrics Registry. Одним из примеров является модель крупномасштабных измерений производительности широкополосных систем (Large-scale Measurement of Broadband Performance или LMAP) [RFC7594]. В терминологии LMAP реестр Performance Metrics применяется в LMAP Control Protocol, чтобы позволить контроллеру запланировать измерительную задачу (Measurement Task) для одного или нескольких агентов измерения. Для такого варианта использования записи в Performance Metrics Registry должны быть достаточно определёнными, чтобы реализация Measurement Agent могла запустить Measurement Task при получении сообщения Control Protocol. Это требование сильно ограничивает типы записей, подходящих для Performance Metrics Registry.

Report Protocol – протокол отчётов

Этот тип протокола служит для того, чтобы объект мог передать результаты измерений другому объекту. Указывая конкретную зарегистрированную метрику производительности, можно верно охарактеризовать передаваемые результаты измерений. В терминологии LMAP реестр Performance Metrics применяется в LMAP Report Protocol для того, чтобы Measurement Agent мог передать результаты измерений коллектору (Collector).

Следует отметить, что модель LMAP явно позволяет применять не только поддерживаемый IANA реестр Performance Metrics, но и другие реестры показателей производительности, т. е. (1) реестры, заданные другими организациями или (2) частные реестры. Однако тем, кто создаёт реестры для применения в контексте модели LMAP, рекомендуется использовать заданный в этом документе формат реестра, поскольку это упрощает разработчикам измерительных агентов LMAP использование сведений из таких реестров.

4.2. Единая точка ссылок на метрики производительности

Performance Metrics Registry служит единой точкой ссылок на показатели производительности, заданные различными группами в IETF. Как отмечено выше, определением Performance Metrics в IETF занимается несколько рабочих групп и было бы сложно отслеживать все группы. Группы могут создавать несколько определений похожих показателей производительности, пытающихся измерять одно и то же слегка различающимися (и несовместимыми) способами. Наличие реестра позволит сообществу IETF и другим лицам иметь единый список Performance Metrics, определённых IETF (и другими в подходящих случаях). Единый список также важен для обмена сведениями о показателях производительности, где разные объекты, запрашивают и выполняют измерения, а также сообщают о результатах и могут получить преимущества из общего понимания соответствующих показателей производительности.

4.3. Дополнительные преимущества

Наличие реестра даёт несколько дополнительных преимуществ. Во-первых, Performance Metrics Registry может служить перечнем полезных и используемых показателей производительности, которые обычно поддерживаются разными реализациями измерительных агентов. Во-вторых, результаты измерений с использованием Performance Metrics будут сравнимыми даже при измерении с помощью разных реализаций и в разных сетях, поскольку метрика производительности определена должным образом. В BCP 176 [RFC6576] проверялась эквивалентность результатов, созданных независимыми реализациями в контексте оценки полноты и чёткости спецификаций показателей. Документ [RFC6576] относится к категории BCP [RFC2026] и определяет развитие документов Standards Track для (Active) IPPM Metrics. Такого же процесса будет, вероятно, достаточно для проверки спецификаций Registered Performance Metrics по части сравнимости (или эквивалентности) результатов тестов. Если зарегистрированный показатель производительности прошёл такую проверку, это следует указать в категории Comments and Remarks (см. параграф 7.6) со ссылкой на результаты теста.

5. Критерии регистрации метрик производительности

Помещать все комбинации параметров каждого показателя производительности в Performance Metrics Registry нежелательно и нецелесообразно. Ниже указаны требования, которые показателям следует соблюдать.

1. Понятность для человека.

2. Реализуемость на программном или аппаратном уровне.

3. Возможность развёртывания сетевыми операторами.

4. Точность в части получения эквивалентных результатов, а также совместимость и развёртываемость продукции разных производителей.

5. Практическая полезность, что означает высокий интерес отрасли и/или уже наличие реализаций.

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

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

6. Performance Metrics Registry – предыдущая попытка

Попытка определить реестр показателей производительности уже была предпринята в [RFC4148]. Однако документ был отменен [RFC6248], поскольку «было обнаружено, что он недостаточно детализирован для однозначной идентификации показателей IPPM [много иных замечаний] возможны вариации в точных характеристиках показателей», что привело к тому, что IPPM Metrics Registry из [RFC4148] «имеет очень мало пользователей или их нет совсем».

Три интересных дополнительных цитаты из [RFC6248] могут помочь в понимании связанных с реестром проблем.

1. Не представляется возможным или полезным регистрировать каждую комбинацию Type P, параметров метрики и параметров потока (Stream) с использованием текущей структуры IPPM Metrics Registry.

2. Текущая структура реестра оказалась недостаточно детальной для однозначной идентификации показателей IPPM.

3. Несмотря на усилия по поиску имеющихся и даже потенциальных пользователей, никто не ответил на призыв проявить интерес к реестру RFC 4148 во второй половине 2010 г.

Текущий подход извлёк уроки из этого и чётко определяет каждый регистрируемый показатель производительности (Registered Performance Metric) с небольшим числом переменных (Runtime) параметров, которые нужно указать разработчику измерения, если таковые имеются. Идея состоит в том, что записи Performance Metrics Registry происходят от разных методов измерения, которым нужны входные (Runtime) параметры для установки таких значений, как адреса отправителя и получателя (это не меняет фундаментальной природы измерений). Обратной стороной такого подхода является возможность появления большого числа записей в Performance Metrics Registry. Имеется согласие, что в этом контексте «меньше значит больше» и лучше иметь сокращённый набор полезных показателей, чем большой набор показателей с сомнительной полезностью.

6.1. Почему от этой попытки ожидается успех

Как отмечено в предыдущем параграфе, одной из основных проблем предыдущего реестра был слишком общий характер включённых в него показателей, делавших их бесполезными. Этот документ задаёт более строгие критерии для регистрации показателей производительности (см. раздел 5) и экспертизу группой Performance Metrics Expert, которые предоставят рекомендации для оценки корректности спецификации Performance Metric.

Другим важным различием является то, что у нового реестра имеется хотя бы 1 очевидный пользователь – модель и протокол LMAP. Поскольку протокол LMAP будет использовать значения Performance Metrics Registry в своей работе, это фактически помогает проверить корректность определения метрики. В частности, поскольку ожидается, что LMAP Control Protocol позволит контроллеру запрашивать у Measurement Agent проведение измерений с использованием метрики путём встраивания Performance Metrics Registry Identifier в протокол. Метрика и методы будут указаны правильно, если они определены достаточно хорошо, чтобы было возможно (и практично) реализовать их в агентах измерения. Этого не удалось в прежней попытке, где запись реестра с неопределённым Type-P (раздел 13 в [RFC2330]) позволяла результатам измерений существенно различаться.

7. Определение реестра метрик производительности

Реестр Performance Metrics применим к показателям производительности при активных и пассивных измерениях, а также для иных форм измерений показателей производительности. Каждая категория измерений имеет уникальные свойства, поэтому некоторые из описанных столбцов применимы не ко всем категориям показателей. Т таких случаях в столбце следует указывать значение N/A (неприменимо). Однако такое значение недопустимо использовать в столбцах Identifier, Name, URI, Status, Requester, Revision, Revision Date, Description. В будущем новые категории показателей могут потребовать новых столбцов и такое добавление станет признанной формой расширения реестра. В спецификации нового столбца должны даваться общие рекомендации по заполнению для имеющихся записей.

Столбцы Performance Metrics Registry определены ниже и группируются в категории (Category) для упрощения использования реестра. Категории описаны в параграфах 7.x, столбцы – в параграфах 7.x.y. Приведённый ниже рисунок показывает их организацию. Каждая запись (строка) реестра даёт полное описание показателя производительности.

Каждый столбец является элементом контрольного списка и помогает избежать пропусков при регистрации и рецензировании (Expert Review) [RFC8126].

Формат категорий и столбцов реестра показан ниже.

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

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

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

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

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

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

Пустой шаблон реестра приведён в разделе 11.

7.1. Сводная категория

7.1.1. Идентификатор

В этом столбце указываются числовые идентификаторы зарезервированных показателей производительности. Идентификатор каждого зарегистрированного показателя должен быть уникальным. Отметим, что при пересмотре метрики по процедуре, описанной в параграфе 8.2 новая запись в Performance Metrics Registry сохраняет прежний идентификатор.

Идентификаторами зарегистрированных показателей производительности являются неограниченные целые числа от 0 до ∞. Идентификатор 0 следует оставить резервным. Идентификаторы от 64512 до 65535 резервируются для приватного и экспериментального использования и могут оказаться неуникальными.

При добавлении нового показателя в Performance Metrics Registry агентству IANA следует выделять наименьший доступный идентификатор. Если Performance Metrics Expert при рецензировании увидел причину выделить конкретный числовой идентификатор (возможно с пропуском некоторых значений), этому эксперту нужно уведомить IANA о таком решении.

7.1.2. Имя

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

Имена состоят из показанных ниже элементов, разделённых символом подчёркивания «_»

      MetricType_Method_SubTypeMethod_... Spec_Units_Output

MetricType

Комбинация связанных с направлением свойств и измеряемых показателей (указанных в таблице 1 или иных).

Таблица 1.

RTDelay	Round-Trip Delay – круговая задержка
RTDNS	Response Time Domain Name Service – время отклика DNS
RLDNS	Response Loss Domain Name Service – потери откликов DNS
OWDelay	One-Way Delay – задержка в одном направлении
RTLoss	Round-Trip Loss – круговые потери
OWLoss	One-Way Loss – потери в одном направлении
OWPDV	One-Way Packet Delay Variation – вариации односторонней задержки
OWIPDV	One-Way Inter-Packet Delay Variation – вариации односторонней задержки между пакетами
OWReorder	One-Way Packet Reordering – одностороннее нарушение порядка пакетов
OWDuplic	One-Way Packet Duplication – одностороннее дублирование пакетов
OWBTC	One-Way Bulk Transport Capacity – транспортная «ёмкость» в одном направлении
OWMBM	One-Way Model-Based Metric – односторонняя метрика на основе модели
SPMonitor	Single-Point Monitor – одноточечный монитор
MPMonitor	Multi-Point Monitor – многоточечный монитор

Method

Один из методов, определённых в [RFC7799], таких, что указаны в таблице 2, или иных.

Таблица 2.

Active	Зависит от выделенного потока измерительных пакетов и наблюдений за потоком, как указано в [RFC7799]
Passive	Зависит «исключительно» от наблюдения за одним или несколькими потоками, как описано в [RFC7799]
HybridType1	Наблюдение за одним потоком, сочетающее активные и пассивные методы, как описано в [RFC7799]
HybridType2	Наблюдение за несколькими потоками, сочетающее активные и пассивные методы, как описано в [RFC7799]
Spatial	Пространственная метрика, описанная в [RFC5644]

SubTypeMethod

Один или несколько субтипов, дополнительно описывающих свойства записи, как показаны в таблице 3, или иных.

Таблица 3.

ICMP	Internet Control Message Protocol – протокол управляющих сообщений Internet (ICMP)
IP	Internet Protocol – протокол IP
DSCPxx	xx заменяется кодом Diffserv
UDP	User Datagram Protocol – протокол UDP
TCP	Transport Control Protocol – протокол TCP
QUIC	QUIC transport protocol – транспортный протокол QUIC
HS	Hand-Shake, such as TCP’s 3-way HS – согласование, такое как 3-этапное согласование TCP
Poisson	Генерация пакетов с распределением Пуассона
Periodic	Периодическая генерация пакетов
SendOnRcv	Отправитель сохраняет один пакет, находящийся в пути, отправляя пакет по доставке предыдущего.
PayloadxxxxB	xxxx заменяется целым числом октетов или 8-битовых байтов в поле данных (Payload)
SustainedBurst	Тест «ёмкости» для худшего случая
StandingQueue	Проверка поведения очереди при наличии «пробки»

Значения SubTypeMethod разделяются дефисом (-), они относятся к одному элементу и порядок не имеет значения в плане уникальности Name.

Spec

Неизменяемый идентификатор документа с указанием раздела в нем. Для RFC указывается номер и раздел в RFC для этой записи реестра в форме RFCXXXXsecY, например, RFC7799sec3.³

Units

Единицы измерения для вывода, такие, как указано в таблице 4, или иные.

Таблица 4.

Seconds	Секунды
Ratio	Безразмерно
Percent	Процентная доля (значение, умноженное на 100%)
Logical	1 или 0
Packets	Пакеты
BPS	Бит/с
PPS	Пакет/с
EventTotal	Безразмерный счётчик
Multiple	Несколько типов единиц
Enumerated	Список результатов
Unitless	Безразмерные единицы

Output

Тип вывода с результатами измерений, такой, как указано в таблице 5, или иной.

Таблица 5.

Singleton	Одиночное значение
Raw	Множество одиночных значений (singleton)
Count	Счётчик
Minimum	Минимум
Maximum	Максимум
Median	Медиана
Mean	Среднее значение
95Percentile	95-й процентиль
99Percentile	99-й процентиль
StdDev	Стандартное отклонение
Variance	Вариация
PFI	Прошло, отказ, нет результата
FlowRecords	Описание наблюдаемых потоков
LossRatio	Отношение числа потерянных пакетов к общему числу (<=1)

Примером может служить представленное в разделе 4 [RFC8912] имя RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile.

Для частных реестров, придерживающихся описанного здесь формата, следует использовать префикс Priv_ или иное имя, не приводящее к неожиданным конфликтам (см. раздел 10). Записи приватных реестров обычно не связаны с RFC, поэтому элемент Spec не имеет чёткой интерпретации.

7.1.3. URI

Столбец URI должен содержать URL [RFC3986] с однозначным указанием местоположения Metric Entry, доступного через Internet. URL указывает файл, содержащий понятные человеку сведения из одной записи реестра. В URL нужно указывать файл (предпочтительно в формате HTML) с URL, указывающими RFC в формате HTML или иные спецификации. Эти файлы для разных записей можно легко редактировать и применять при подготовке новых записей. Точная форма URL для каждого файла и сам файл будут определяться IANA и храниться на сайте https://www.iana.org/. В разделе 4 [RFC8912] и других разделах этого документа содержатся ссылки на файлы HTML.

7.1.4. Описание

Описание Registered Performance Metric является письменным представлением отдельной записи реестра показателей производительности. Оно дополняет Registered Performance Metric Name, чтобы помочь пользователям реестра выбрать подходящие показатели производительности.

7.1.5. Ссылка

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

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

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

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

В этом столбце указывается номер версии формата реестра на момент регистрации Performance Metric. Для формата, соответствующего этому документу, должна указываться версия 1.0. Новый документ RFC, меняющий формат реестра, будет указывать для формата новый номер. Номер версии не следует менять, пока Registry Entry не будет обновлена в соответствии с новым форматом (по процедурам из раздела 8).

7.2. Категории определения метрики

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

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

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

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

Фиксированными (Fixed) называют параметры, значения которых должны быть указаны в Performance Metrics Registry. Измерительная система использует эти значения.

Если показатели предоставляют список параметров как часть своего описательного шаблона, подмножество этих параметров обозначается как Fixed Parameters. В качестве примера для активных показателей (Active Metric) фиксированные параметры задают все или большинство соглашений модели IPPM «пакеты Type-P», как описано в [RFC2330], таких как транспортный протокол, размер поля данных (payload), TTL и т. п. Примером для пассивных показателей (Passive Metric) является расчёт потерь RTP, основанный на проверке принадлежности пакета протоколу RTP, который представляет собой проверку нескольких пакетов, контролируемую переменной MIN_SEQUENTIAL, как указано в [RFC3550]. Изменение MIN_SEQUENTIAL может менять отчёт о потерях и эту переменную можно установить как фиксированный параметр.

Параметры должны иметь чётко заданные имена. Для человека предпочтителен стиль «обратного отступа» (hanging-indent) и имена и определения параметров, которые не указаны в спецификации эталонного метода, должны включаться в этот столбец (или в столбец Runtime Parameters).

Параметры должны иметь чётко заданный формат данных.

Параметры, являющиеся фиксированными для одной записи Performance Metrics Registry, могут быть обозначены как рабочие (Runtime) для другой записи реестра.

7.3. Категория метода измерения

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

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

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

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

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

Value

Имя дисциплины планирования пакетов.

Reference

Спецификация, где заданы параметры потока.

Для генерации потока пакетов могут потребоваться такие параметры, как средняя скорость передачи пакетов и значение отсечки распределения для патоков с распределением Пуассона для межпакетных интервалов. Если такие параметры нужны, их следует включать в столбец Fixed Parameters или Runtime Parameters, в зависимости от того, являются они фиксированными или служат входными данными для показателя.

Простейшим примером спецификации потока является одиночное (singleton) планирование (см. [RFC2330]), где выполняется одно атомарное измерение. Каждое такое измерение может включать передачу одного (например, запроса DNS) или нескольких (например, запрос web-страницы) пакета. Другие потоки поддерживают серии атомарных измерений, где поток пакетов следует планированию, задающему интервал между передачей пакетов, и атомарные измерения оценивают время между получением последовательных пакетов (например, измерение вариаций межпакетного интервала). Возможны более сложные потоки и измерительные взаимодействия. В метриках IPPM применяются в основном два типа потоков: (1) потоки с распределением Пуассона, описанные в [RFC2330] и (2) периодические потоки, описанные в [RFC3432]. Оба этих типа имеют свои уникальные параметры и соответствующий набор имён параметров следует включать в столбец Fixed Parameters или Runtime Parameters.

7.3.3. Фильтр трафика

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

Сам фильтр трафика зависит от потребностей показателя и баланса потребностей оператора в измерениях и требований к приватности пользователей Механизмами для установки критериев фильтрации могут быть пакетные фильтры BPF (Berkeley Packet Filter) или фильтры совпадения свойств PSAMP (выборка пакетов) [RFC5475], которые применяют IPFIX [RFC7012]. Примером строки BPF для сопоставления трафика TCP/80 с адресом сети удалённого получателя 192.0.2.0/24 является строка “dst net 192.0.2.0/24 and tcp dst port 80”. Более сложные системы фильтрации могут использовать сопоставление на основе глубокой инспекции пакетов (Deep Packet Inspection или DPI).

Traffic Filter включает указанную ниже информацию.

Type

Тип используемого фильтра, например, BPF, PSAMP, правило и т. п., как указано в нормативной ссылке.

Value

Фактический набор правил фильтрации.

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

Распределение выборки выбирает из всех пакетов, соответствующих Traffic Filter, один или несколько пакетов, фактически используемых для измерения. Один из возможных вариантов – all предполагает учёт всех прошедших фильтр пакетов, но могут применяться и иные стратегии выборки. Столбец включает указанные ниже сведения.

Value

Имя распределения выборки.

Reference definition

Указатель на спецификацию, где определено распределения выборки.

Для распределения выборки могут потребоваться параметры. В этом случае их следует в столбец Fixed Parameters или Runtime Parameters в зависимости от того, фиксированы они или служат входными данными для метрики.

Фильтры PSAMP описаны в «Sampling and Filtering Techniques for IP Packet Selection» [RFC5475], а в работе «A Framework for Packet Selection and Reporting» [RFC5474] представлены базовые сведения о фильтрации. Параметры распределения выборки могут быть заданы в соответствии с «Information Model for Packet Sampling Exports» [RFC5477] и процессом, описанным в «Flow Selection Techniques» [RFC7014].

7.3.5. Рабочие параметры

В отличие от фиксированных, рабочие параметры не меняют фундаментальной природы измерения и их значения не указываются в Performance Metrics Registry. Они остаются в реестре как переменные, чтобы помочь разработчикам и пользователям измерительной системы. Значения параметров задаются при исполнении через настройку системы измерения и указываются в результатах для полноты контекста.

Если метрика представляет список параметров как часть описательного шаблона, часть этих параметров помечается как рабочие (Runtime).

Параметры должны иметь чётко заданные имена. Для человека предпочтителен стиль «обратного отступа» (hanging-indent) и имена и определения параметров, которые не указаны в спецификации эталонного метода, должны включаться в этот столбец (или в столбец Runtime Parameters).

Формат данных для каждого параметра Runtime должен указываться в этом столбце для упрощения реализации и управления системами измерения. Например, параметры, включающие адрес IPv4, можно представлять 32-битовым целым числом (двоичное значение в кодировке base64) или в формате ip-address, заданном в [RFC6991]. Используемое фактически представление должно быть указано явно для каждого рабочего параметра. Адреса и опции IPv6 должны быть включены, чтобы зарегистрированные показатели производительности можно было использовать для этого семейства адресов. Допускается указание иных адресных семейств.

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

7.3.6. Роль

В некоторых методах измерения может задаваться несколько ролей. Например при активном измерении односторонней задержки один агент измерения генерирует пакеты, а другой принимает их. В этом столбце указываются имена ролей (Role) для данной записи. В примере с односторонней задержкой в столбце следует указать две записи – по одной для каждой роли (Source и Destination). Когда агенту измерения задана роль Source для показателя односторонней задержки, этот агент знает, что ему нужно генерировать пакеты. Значения для этого поля определяются эталонным методом измерения (Reference Method of Measurement), при этом часто используются сокращённые обозначения ролей, такие как Src.

Если в столбце Role записи реестра указано несколько ролей, значение Role нужно считать рабочим (Runtime) параметром и представлять для выполнения. Следует отметить, что в схеме LMAP [RFC7594] роли отличаются от других параметров Runtime.

7.4. Категория вывода

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

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

7.4.1. Тип

В этом столбце указывается имя типа вывода, определяющего 1 тип результата для данного процесса измерения. Это могут быть необработанные (raw) результаты (время отправки пакетов и одиночные измерения показателя) или какой-либо тип статистики. Спецификация типа вывода должна задавать формат вывода. В некоторых системах спецификация формата будет упрощать как реализацию измерений, так и задачи сбора и хранения результатов. В случаях, когда для одного измерения требуется два типа статистики (например, среднее значение процентиля X и Raw), должен быть задан новый тип вывода (Xth percentile mean AND Raw). Список типов вывода приведён в параграфе 7.1.2.

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

В этом столбце приводятся указатели на спецификации, где определён тип и формат вывода.

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

Результаты измерений должны указываться с использованием той или иной стандартной размерности или в единиц измерения. Столбец указывает эти единицы.

При сборе одиночных измерений (см. определения в разделе 11 [RFC2330]) эта запись задаёт единицы для каждого измеренного значения.

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

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

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

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

7.5. Административная информация

7.5.1. Статус

Эта запись указывает статус спецификации этой зарегистрированной метрики производительности. Разрешены значения Current (действует), Deprecated (отменено), Obsolete (устарело). Вновь опубликованные записи Registered Performance Metrics имеют статус Current.

7.5.2. Запросчик

Эта запись указывает сторону, запросившую Registered Performance Metric, которой может быть документ (например, RFC) или человек.

7.5.3. Выпуск

Запись указывает номер выпуска (revision number) Registered Performance Metric, начиная с 0 для записи в момент её первоначальной регистрации. Для каждого нового выпуска значение номера увеличивается. Если новый выпуск не совместим с предшествующими, выполняются требования параграфа 8.3.

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

Эта запись указывает дату принятия последнего выпуска Registered Performance Metric. Определение даты выпуска нужно отдавать IANA и экспертам-рецензентам (Performance Metrics Expert).

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

Помимо предоставления дополнительных сведений, которых нет в других категориях, эта открытая категория (1 столбец) позволяет решать непредвиденные вопросы путём простого обновления этой информационной записи.

8. Процессы управления группой Performance Metrics Registry

После того как показатель или набор показателей определены для данного применения, запись-кандидат для Performance Metrics Registry, подготовленную в соответствии с разделом 7, следует представить в IANA для рецензирования экспертами, как описано ниже. Этот процесс также применяется при изменении Performance Metrics Registry Entry, например, при пересмотре или отмене, как описано в этом разделе.

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

8.1. Добавление новой метрики в Performance Metrics Registry

Запросы на добавление Registered Performance Metric в реестр показателей производительности нужно представлять в агентство IANA, которое пересылает их назначенной IESG группе экспертов (Performance Metrics Experts). Рецензенты рассматривают запрос в соответствии с процедурой Specification Required [RFC8126], заданной для них. Эксперты рассматривают запрос на предмет соответствия данному документу и другим RFC, связанным с показателями производительности, а также текущему набору зарегистрированных показателей производительности. Наиболее эффективно начать представление заявки с подготовки проекта документа (Internet-Draft), содержащего предлагаемую для реестра запись на основе шаблона из разделе 11 – такой подход позволит воспользоваться преимуществами обычной обработки IETF для Internet-Draft (включая перевод в HTML).

Представление в IANA может происходить в процессе рецензирования IESG (ведущего к IETF Standards Action), где рассматривается документ Internet-Draft, предлагающий один или несколько регистрируемых показателей производительности для добавления в Performance Metrics Registry, включая текст предложенных для регистрации показателей производительности.

Если будущий RFC включает Performance Metric и предлагаемую запись Performance Metrics Registry, но рецензия Performance Metrics Expert указывает, что не выполняется один или несколько критериев из раздела 5, предлагаемая запись Performance Metrics Registry должна быть удалена из текста. Как только станет ясно, что предлагаемая запись соответствует критериям раздела 5, эту запись следует представить в IANA для оценки с участием экспертов Performance Metrics с целью регистрации записи.

Авторам предлагаемых Registered Performance Metric следует проверять соответствие спецификациям этого документа перед представлением в IANA.

Хотя бы один из Performance Metrics Expert должен выполнить своевременное рецензирование предложенной записи. Если запрос принимается, эксперты по показателям производительности представляют своё одобрение в IANA, а IANA обновляет реестр Performance Metrics. Если запрос неприемлем, эксперты могут координировать свои действия с запрашивающей стороной для изменения запроса в соответствии с требованиями. В иных случаях агентству IANA нужно координировать решение вопроса от имени эксперта. Эксперты Performance Metrics могут отклонить явно необоснованные или неприемлемые запросы на изменение, но такие случаи представляются маловероятными.

Если предложенная метрика в значительной степени уникальна, для её подобающего описания может потребоваться новый реестр элементов (Name Element Registry) или (более вероятно) новый элемент в существующем реестре Name Element Registry. Такое предложение является частью запроса на добавление новой метрики, поэтому оно проходит те же процедуры рецензирования и одобрения в IANA.

Решения экспертов Performance Metrics могут быть обжалованы в соответствии с разделом 10 в [RFC8126].

8.2. Совместимый с прежним выпуск Registered Performance Metric

Запросы на пересмотр разрешаются лишь в тех случаях, когда запрошенные изменения совместимы с поддерживающими прежний вариант реализациями Performance Metrics Registry Entry (backward compatibility), т. е. запись с меньшим номером версии, но теми же значениями Identifier и Name.

Поле Status в Performance Metrics Registry указывает текущий статус записи Current, Deprecated или Obsolete. Термин deprecated применяется в тех случаях, когда запись заменяется совместимым с прежней версией выпуском, как описано в этом параграфе или несовместимым с прежним выпуском (параграф 8.3).

Не задано политики пересмотра записей Performance Metric в реестре или исправления ошибок в них. Говоря точнее, изменения и отмены (deprecation) в Performance Metrics Registry не приветствуются и их следует избегать, когда это возможно. Однако при неизбежности изменения этот параграф определяет его внесение.

Пересмотр инициируется отправкой определения кандидата в Registered Performance Metric агентству IANA в соответствии с параграфом Section 8.1 с указанием имеющейся записи Performance Metrics Registry и разъяснением причин и способа пересмотра имеющейся записи.

Основным требованием при определении процедур управления изменениями в уже зарегистрированных показателях производительности является предотвращение проблем совместимости. Эксперты Performance Metrics должны заботиться прежде всего о поддержании совместимости.

Изменения в зарегистрированный показатель производительности могут вноситься лишь при обеспечении совместимости. Запрашиваемые изменения, которые не могут обеспечить взаимодействие с имеющимися совместимыми реализациями, должны приводить к созданию новой записи Registered Performance Metric (с новым значением Name, где изменена часть RFCXXXXsecY) и возможно к объявлению прежней метрики устаревшей (deprecated).

Изменение Registered Performance Metric нужно считать совместимым с прежними (backward compatible), когда выполняется хотя бы одно из приведённых ниже условий.

1. Изменение включает исправление ошибок и очевидно является лишь редакторской правкой.

2. Исправляется неоднозначность в определении Registered Performance Metric, которая может вызывать достаточно серьёзные проблемы использования Registered Performance Metric.

3. Добавляется пропущенная в определении показателя информация, не меняющая смысла определения (например, явно задаётся семантика числового значения без смены семантики типа данных).

4. Выполняется согласование с внешней ссылкой, которая указывает на изменённый документ.

5. Текущий формат реестра пересмотрен с добавлением столбца, который не имеет отношения к текущей Registered Performance Metric (т. е. в текущей метрике этот столбец содержал бы значение Not Applicable).

Если пересмотр Performance Metric сочтён допустимым и совместимым с прежней версией экспертами Performance Metrics в соответствии с правилами этого документа, IANA следует внести изменения в Performance Metrics Registry. Инициатор изменения добавляется к запросившему исходную регистрацию лицу или документу в Performance Metrics Registry. Имя пересмотренного показателя производительности, включая часть RFCXXXXsecY, нужно сохранять неизменным, даже при изменении реестра в результате IETF Standards Action. В пересмотренной записи реестра следует указывать новый неизменяемый документ, такой как RFC. Для других органов стандартизации может потребоваться ссылка на конкретную спецификацию с указанием даты в соответствующей категории и столбце.

Каждый зарегистрированный показатель производительности в Performance Metrics Registry имеет номер выпуска и нумерация начинается с 0. При каждом изменении Registered Performance Metric в соответствии с описанным процессом номер выпуска увеличивается на 1.

При восприятии изменённого показателя Registered Performance Metric в Performance Metrics Registry дата последнего выпуска помещается в столбец Revision Date для зарегистрированного показателя.

Когда это применимо, в столбцы Comments или Remarks следует включать дату и такие изменения не считаются пересмотром в соответствии с описанным здесь процессом.

Прежние версии обновляемых записей реестра сохраняются для архивных целей. Поля этих записей (включая Revision Date) не изменяются, но значение поля Status нужно заменить на Deprecated.

Этот процесс не следует считать позволяющим экспертам Performance Metrics отвергать согласование с IETF. В частности, любые зарегистрированные показатели производительности, добавленные в Performance Metrics Registry с согласия IETF требуют согласования их пересмотра или отмены с IETF.

8.3. Несовместимый с прежними выпуск Registered Performance Metric

В этом параграфе описана процедура несовместимого с прежним выпуском обновления Registered Performance Metric. Зарегистрированная метрика может быть отменена (deprecated) и заменена в 2 случаях.

1. Определение Registered Performance Metric содержит ошибку или недостаток, которые нельзя изменить в соответствии с параграфом 8.2. Совместимый с прежним выпуск Registered Performance Metric.

2. Отмена вызвана отменой документа, указанного ссылкой, которая была принята по действующей процедуре.

Запрос на отмену передаётся в агентство IANA, которое направляет его на рецензию экспертам Performance Metrics. При отмене Performance Metric описание метрики в Performance Metrics Registry должно быть обновлено с разъяснением отмены, а также ссылкой на новую метрику, заменяющую отменённую.

Когда несовместимая с прежней новая Performance Metric заменяет объявленную (сейчас) отменённой метрику, номер выпуска в новой Registered Performance Metric увеличивается по сравнению с имевшимся в отменённой номером и указывается текущая дата в поле Revision Date новой записи.

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

Недопустимо снова использовать имя и идентификатор отменённой метрики.

Отменённые записи сохраняются без изменения столбцов категории Administrative, за исключением поля Status, в котором указывается значение Deprecated.

8.4. Устаревшие записи реестра

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

1. Обнаружение существенной ошибки в Registered Performance, исправлять которую бессмысленно.

2. Одна или несколько важных ссылок указывает на документы или их разделы, которые признаны устаревшими.

3. Иные причины, доведённые до сведения IANA и экспертов реестра.

При объявлении записи Performance Metric Registry устаревшей (obsolete) описание Performance Metric в реестре обновляется с разъяснением причин признания записи устаревшей и отсутствия замены (отмена – Deprecation записи всегда включает её замену).

Устаревшие записи хранятся без изменения столбцов категории Administrative за исключением указания в поле Status значение Obsolete.

8.5. Версия формата реестра и её изменение

Версия формата реестра, определённая этим документом, имеет значение 1.0 и записи-кандидаты, соответствующие этому документу, должны использовать значение 1.0.

Формат реестра может быть обновлён публикацией RFC с новым форматом (Standards Action).

При создании или пересмотре зарегистрированной метрики производительности используется свежая версия Registry Format.

Предусмотрена лишь одна форма расширения реестра.

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

При расширении Performance Metrics Registry таким способом номер версии будущих записей, соответствующих расширению, нужно инкрементировать (в первом или втором элементе, в зависимости от значимости расширения).

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

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

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

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

С учётом предыстории и описанных выше процессов, агентство IANA предприняло действия, рассмотренные ниже.

10.1. Группа реестров

Новая группа реестров названа Performance Metrics. В этом документе она обозначается как Performance Metrics Group или Registry Group. Все регистрации доступны по ссылке https://www.iana.org/assignments/performance-metrics.

Для ясности отметим, что в этом документе и [RFC8912] используются указанные в таблице 6 соглашения для обозначения различных реестров IANA, связанных с Performance Metrics.

Таблица 6.

 

	RFC 8911 и RFC 8912	Web-страница IANA
Название страницы	Performance Metrics Group	Performance Metrics
Основной реестр	Performance Metrics Registry	Performance Metrics Registry
Строка реестра	Performance Metrics Registry Entry	Регистрация (и шаблон)

 

   Registration Procedure: Specification Required
   Reference: RFC 8911
   Experts: Performance Metrics Experts

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

Этот документ задаёт и заполняет реестры для Performance Metric Name Elements. Имя, назначенное записи Performance Metric Registry состоит из нескольких элементов, разделённых символом подчёркивания (_) в порядке заданном параграфом 7.1.2. Агентство IANA создало перечисленные ниже реестры с текущим набором возможностей для каждого элемента в Performance Metric Name.

MetricType

Method

SubTypeMethod

Spec

Units

Output

При создании агентство IANA заполнило Registered Performance Metrics Name Elements с использованием списка значений для каждого Name Element, указанного в параграфе 7.1.2. Регистр символов в именах имеет значение.

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

Кандидат в Metric Entry предлагает набор значений для элементов своего имени. Этот набор рассматривается IANA и экспертами реестра. Возможно, что кандидат предлагает новое значение Name Element (отсутствует в текущем списке возможных) или даже новый элемент имени. Такие новые назначения администрируются IANA по процедуре Specification Required [RFC8126], которая включает Expert Review (рецензия одного из экспертов Performance Metrics, назначаемых IESG по рекомендациям руководителей направления Transport).

10.3. Новый реестр Performance Metrics

Этот документ задаёт реестр Performance Metrics Registry, содержащий в категории Summary столбцы:

Identifier;

Name;

URI;

Description;

Reference;

Change Controller;

Version.

Описание этих столбцов и дополнительные сведения представлены в шаблоне записей реестра (категории и столбцы), а определения приведены разделе 7.

Идентификатор 0 следует оставлять резервным, выделяя в качестве уникальных идентификаторов Registered Performance Metric целочисленные значения от 1 до бесконечности. Диапазон 64512 – 65535 резервируется для приватного и экспериментального использования и значения из этого диапазона могут оказаться неуникальными. При добавлении в реестр новой метрики агентству IANA следует выбирать наименьшее доступное значение Identifier для новой записи Registered Performance Metric. Если выполняющий рецензирование эксперт Performance Metrics увидит причины выделить конкретное значение Identifier, возможно создающее временный пропуск в нумерации, эксперту нужно уведомить IANA об этом решении.

Имена с префиксом Priv_ резервируются для приватного использования и не рассматриваются для регистрации. Определение элементов столбца Name дано в разделе 7.

В столбце URI указывается идентификатор URL для каждой заполненной записи реестра. Текст записи нужно приводить в формате HTML, чтобы читатель мог пользоваться (как с Internet-Draft в формате HTML) ссылками на упомянутые разделы RFC или иных неизменяемых документов.

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

Новые назначения в Performance Metrics Registry администрируются IANA по процедуре Specification Required [RFC8126] (включает Expert Review, т. е. рецензию одного или нескольких экспертов, в данном случае – Performance Metrics Experts, назначаемых IESG по рекомендациям руководителей направления Transport) или Standards Action. Эксперты первоначально могут быть выбраны из числа руководителей рабочих групп, редакторов документов и членов Performance Metrics Directorate, а также среди других специалистов.

Расширения Performance Metrics Registry требуют процедуры IETF Standards Action. Предусмотрен лишь один способ расширения реестра, указанный ниже.

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

При расширении Performance Metrics Registry таким способом номер версии будущих записей, соответствующих расширению, нужно инкрементировать (в первом или втором элементе, в зависимости от значимости расширения).

11. Пустой шаблон реестра

В этом разделе представлен пустой шаблон для оказания помощи при подготовке к регистрации записи в IANA.

11.1. Summary

Эта категория включает индексы Registry Entry в форме идентификатора (element ID) и имени метрики (Metric Name).

11.1.1. ID (Identifier)

Целочисленный идентификатор метрики.

11.1.2. Name

Имя, соответствующее соглашению об именовании показателей.

11.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/ … <Name>.

11.1.4. Description

Описание метрики.

11.1.5. Reference

Указывается RFC или иная спецификация одобренного кандидата в Registry Entry.

11.1.6. Change Controller

Сведения об организации, отвечающей за одобрение пересмотра Registry Entry (включая контактные данные людей, если это приемлемо).

11.1.7. Version (of Registry Format)

11.2. Metric Definition

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

11.2.1. Reference Definition

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

11.2.2. Fixed Parameters

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

11.3. Method of Measurement

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

11.3.1. Reference Method

Ссылки на соответствующие неизменяемые разделы документов и иные сведения.

11.3.2. Packet Stream Generation

Список параметров генерации пакетов и ссылки на документы (с разделами) при необходимости.

11.3.3. Traffic Filtering (Observation) Details

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

11.3.4. Sampling Distribution

Детали распределения или его отличие от фильтра.

11.3.5. Runtime Parameters and Data Format

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

11.3.6. Roles

Список имён ролей для метода измерения.

11.4. Output

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

11.4.1. Type

Имя типа вывода – необработанные (raw) результаты или определённая статистика.

11.4.2. Reference Definition

Эталонный формат данных для каждого типа результатов.

11.4.3. Metric Units

Единицы, используемые в результатах измерения и их спецификация.

11.4.4. Calibration

Сведения о калибровке.

11.5. Administrative Items

Эта категория содержит административные сведения.

11.5.1. Status

Статус метрики (Current или Deprecated).

11.5.2. Requester

Имя запрашивающего лица, номер RFC и т. п.

11.5.3. Revision

Номер выпуска, начиная с 0.

11.5.4. Revision Date

Дата в формате YYYY-MM-DD.

11.6. Comments and Remarks

Дополнительные сведения для этой записи.

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

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

[RFC2026] Bradner, S., “The Internet Standards Process – Revision 3”, BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

[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>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC5644] Stephan, E., Liang, L., and A. Morton, “IP Performance Metrics (IPPM): Spatial and Multicast”, RFC 5644, DOI 10.17487/RFC5644, October 2009, <https://www.rfc-editor.org/info/rfc5644>.

[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>.

[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, “IP Performance Metrics (IPPM) Standard Advancement Testing”, BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, <https://www.rfc-editor.org/info/rfc6576>.

[RFC7799] Morton, A., “Active and Passive Metrics and Methods (with Hybrid Types In-Between)”, RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[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>.

[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>.

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

[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>.

[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>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications”, STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., “RTP Control Protocol Extended Reports (RTCP XR)”, RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/info/rfc3611>.

[RFC4148] Stephan, E., “IP Performance Metrics (IPPM) Metrics Registry”, BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2005, <https://www.rfc-editor.org/info/rfc4148>.

[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, “A Framework for Packet Selection and Reporting”, RFC 5474, DOI 10.17487/RFC5474, March 2009, <https://www.rfc-editor.org/info/rfc5474>.

[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, “Sampling and Filtering Techniques for IP Packet Selection”, RFC 5475, DOI 10.17487/RFC5475, March 2009, <https://www.rfc-editor.org/info/rfc5475>.

[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, “Information Model for Packet Sampling Exports”, RFC 5477, DOI 10.17487/RFC5477, March 2009, <https://www.rfc-editor.org/info/rfc5477>.

[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, “Session Initiation Protocol Event Package for Voice Quality Reporting”, RFC 6035, DOI 10.17487/RFC6035, November 2010, <https://www.rfc-editor.org/info/rfc6035>.

[RFC6248] Morton, A., “RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete”, RFC 6248, DOI 10.17487/RFC6248, April 2011, <https://www.rfc-editor.org/info/rfc6248>.

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

[RFC7012] Claise, B., Ed. and B. Trammell, Ed., “Information Model for IP Flow Information Export (IPFIX)”, RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>.

[RFC7014] D’Antonio, S., Zseby, T., Henke, C., and L. Peluso, “Flow Selection Techniques”, RFC 7014, DOI 10.17487/RFC7014, September 2013, <https://www.rfc-editor.org/info/rfc7014>.

[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>.

[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>.

[RFC8912] Morton, A., Bagnulo, M., Eardley, P., and K. D’Souza, “Initial Performance Metrics Registry Entries”, RFC 8912, DOI 10.17487/RFC8912, November 2021, <https://www.rfc-editor.org/info/rfc8912>.

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

Спасибо Brian Trammell и Bill Cerveny – сопредседателям IPPM во время подготовки документа за проведение «мозговых штурмов» по теме работы. Спасибо Barbara Stark и Juergen Schoenwaelder за подробные отклики и предложения. Спасибо Andrew McGregor за предложения по именованию показателей. Спасибо Michelle Cotton за её раннюю рецензию IANA и Amanda Baber за ответы на вопросы по представлению реестра и доступность полного шаблона по URL. Спасибо Roni Even за его обзор и предложения по обобщению процедур. Спасибо всем руководителям направлений за их рецензии.

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

 

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

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

nmalykh@protokols.ru