RFC 6390 Guidelines for Considering New Performance Metric Development

Internet Engineering Task Force (IETF)                          A. Clark
Request for Comments: 6390                         Telchemy Incorporated
BCP: 170                                                       B. Claise
Category: Best Current Practice                      Cisco Systems, Inc.
ISSN: 2070-1721                                             October 2011

Guidelines for Considering New Performance Metric Development

Рекомендации по разработке новых показателей производительности

PDF

Аннотация

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

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

Документ относится к категории Internet Best Current Practice.

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

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

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

Авторские права (Copyright (c) 2011) принадлежат 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).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

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

Разработка показателей производительности (PM) включает по меньшей мере три этапа:

1. определение показателя и единиц измерения;

2. спецификация метода измерения;

3. спецификация формата отчётов.

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

Целевая аудитория этого документа включает участников IETF, готовящих документы по PM, рецензентов таких документов, членов Performance Metrics Directorate и других заинтересованных лиц.

1.1. Предыстория и мотивы

Предшествующие работы IETF, связанные с отчётами о применении PM, включают «Real-time Application Quality-of- Service Monitoring (RAQMON) Framework» [RFC4710]. Эта схема расширяет семейство спецификаций удалённого мониторинга (remote monitoring или RMON), позволяя в реальном масштабе времени отслеживать качество обслуживания (quality-of-service или QoS) для различных приложений, работающих на таких устройствах, как IP-телефоны, клиенты систем мгновенного обмена сообщениями (Instant Messaging), мобильные телефоны и другие носимые компьютерные устройства. Кроме того, в документах «RTP Control Protocol Extended Reports (RTCP XR)» [RFC3611] и «Session Initiation Protocol Event Package for Voice Quality Reporting» [RFC6035] определены протоколы, поддерживающие в реальном масштабе времени отчёты о качестве восприятия (Quality of Experience или QoE) систем VoIP³ и других приложений, выполняющихся на таких устройствах, как IP-телефоны и мобильные гарнитуры.

IETF также активно участвует в разработке надёжных транспортных протоколов, таких как TCP [RFC0793] и SCTP⁴ [RFC4960], которые будут влиять на взаимосвязь производительности IP и приложений.

В уставах рабочих групп IETF (Working Group или WG) имеется пробел — разработка показателей производительности для протоколов выше и ниже уровня IP, которые можно использовать как характеристики действующих сетей.

Подобно документу «Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions» [RFC5706], который является справочным руководством для IETF Operations Directorate, этот документ следует использовать при рецензировании новых показателей производительности членами Performance Metrics Directorate.

1.2. Организация документа

Помимо раздела «Назначение и область применения» этот документ содержит две основных части. Первая включает определения и описание PM и ключевых аспектов показателей, во второй рассматривается процесс разработки показателей, применимый в среде IETF.

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

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

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

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

Директорат показателей производительности (Performance Metrics Directorate) предоставляет рекомендации по разработке PM в IETF. В состав Директората следует включать экспертов в сфере производительности, возможно, отобранных среди членов рабочих групп по IP PM (IP Performance Metrics или IPPM), методологии тестирования (Benchmarking Methodology или BMWG) и PM для других уровней (Performance Metrics for Other Layers или PMOL).

2.3. Качество обслуживания

Качество обслуживания (Quality of Service или (QoS) определяется аналогично разделу «Quality of Service (QoS)» в [E.800], т. е. как «Совокупность характеристик телекоммуникационной службы, влияющих на её способность удовлетворять заявленные или подразумеваемые потребности пользователя данной услуги».

2.4. Качество восприятия

Качество восприятия (Quality of Experience или QoE) определяется аналогично разделу «QoS experienced/perceived by customer/user (QoSE)» в [E.800], т. е. как «заявление, выражающее уровень качества с точки зрения клиента (пользователя)».

Примечания

1. Уровень QoS, воспринимаемый клиентом (пользователем) может выражен оценочным мнением.

2. QoE имеет два основных компонента — количественный и качественный. На количественную составляющую могут влиять сквозные эффекты (включая устройства пользователя и инфраструктуру сети).

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

4. QoE можно также рассматривать как QoS с точки зрения пользователя с учётом влияния на его восприятие соответствующих качественных аспектов.

2.5. Показатель производительности

Показатель производительности (PM) — это количественная мера производительности, относящаяся к заданному IETF протоколу или конкретному приложению, использующему заданный IETF транспортный протокол. Примерами PM являются время отклика FTP для полной загрузки файла, время отклика DNS для распознавания адреса IP, время записи в базу данных и т. п.

3. Назначение и область применения

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

Область применения документа охватывает рекомендации для членов Performance Metrics Directorate при рассмотрении новых PM и способы взаимодействия директората с другими подразделениями IETF. Документ не предназначен для замены имеющихся методов работы в рамках WG, уже занимающихся этими вопросами.

Описываемый процесс не предназначен для регулирования разработки PM в существующих IETF WG, сосредоточенных на разработке показателей производительности, таких как IPPM и BMWG. Однако приведённые здесь рекомендации могут быть полезны в таких работах и могут применяться там, где они подходят. Типичным примером является разработка PM для экспорта в протоколе IPFIX⁵ [RFC5101] с конкретными элементами информации IPFIX [RFC5102], для которых может быть полезна описанная в документе модель.

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

4. Связь между QoS, QoE и показателями приложения

Качество обслуживания (QoS) оценивает производительность сети и протоколов, а QoE — восприятие качества работы пользователем в контексте задачи или услуги. Вопросы PM, относящихся к приложениям, включают измерение производительности на уровнях между IP и пользователем. Например, показатели QoS (потери и задержки пакетов, а также вариации задержки [RFC5481]) могут служить для оценки связанных с приложением PM (размер буферов для сокращения вариаций задержки и потери пакетов на уровне RTP), а затем в сочетании с другими известными аспектами приложений VoIP (такими, как тип кодека) с помощью соответствующего ITU-T P.564 [P.564] алгоритма, для оценки MOS⁶ [P.800]. Однако QoE для конкретного пользователя VoIP зависит от контекста (например, обычный разговор, деловая конференция, вызов экстренных служб). QoS и относящиеся к приложению PM являются количественными характеристиками, а QoE — качественной. Кроме того, QoS в сети и PM для приложения могут быть напрямую или косвенно понятными пользователю, а восприятие качества (QoE) очевидно непосредственно.

5. Разработка PM

В этом разделе приведены основные определения и классификация показателей производительности (PM).

5.1. Определение и классификация целевой аудитории

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

Во всех документах, определяющих PM, следует указывать основную аудиторию и связанные с ней требования. Целевая аудитория может влиять как на определение показателя, так и на методы измерения.

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

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

• Измерения в лабораторной среде или в сети развёрнутых устройств.

• Точность результатов.

• Доступ к точкам измерения и данным конфигурации.

• Топология измерения («точка-точка» или многоточечная).

• Масштаб измерительной системы.

• Непрерывные измерения или измерения по запросам.

• Требуемый формат и периоды отчётности.

• Критерии выборки [RFC5474] (например, систематическая или вероятностная).

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

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

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

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

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

2. сопоставление PM с предоставляемыми пользователю (человеку или приложению) значениями QoS и QoE;

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

4. необходимость разработки правил (SLA⁷ и, возможно, SLC⁸) на основе PM.

Рассмотрим, например, распределённое приложение, работающее через сетевые соединения с потерей пакетов. Показатель частоты потери пакетов (Loss Rate или PLR) определён как среднее число теряемых за единицу времени пакетов. Если приложение плохо работает через соединения с высокими потерями пакетов и всегда работает хорошо при отсутствии потерь, показатель производительности PLR будет в некоторой степени полезен. Некоторые приложения чувствительны к кратковременным пикам потерь (bursty loss) и сравнительно мало чувствительны к отдельным потерям, для них PLR будет слабо коррелировать с производительностью приложения. «Лучший» показатель производительности будет учитывать долю потерь и распределение отдельных потерь. Если производительность приложения падает при достижении некоторого значения PLR, полезным PM будет измерение частоты и продолжительности интервалов, когда PLR выше соответствующего значения (например, как в RFC 3611).

5.3. Расчётные PM

5.3.1. Составные PM

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

Ниже приведено несколько примеров составных PM и их определений.

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

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

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

В контексте записи потоков в IPFIX модель IPFIX Mediation Framework [RFC6183], основанная на документе «IP Flow Information Export (IPFIX) Mediation: Problem Statement» [RFC5982], включает некоторые аспекты временной и пространственной композиции.

5.3.2. Индекс

Индексом называют показатель, для которого диапазон выходных значений выбран для удобства и ясности, а поведение — для облегчения понимания, например, R Factor [G.107]. Детерминированная функция для индекса зачастую разрабатывается после задания диапазона и поведения индекса.

5.4. Спецификация PM

5.4.1. Схема определения

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

5.4.2. Нормативная часть определения PM

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

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

   В качестве имён PM рекомендуется выбирать строки, уникальные в рамках уровня протокола или контекста, где показатель будет применяться. Хотя строгая уникальность может быть недостижима (см. реестр IPPM [RFC6248] как пример реестра IANA для показателей, не имеющего должной конкретизации), необходимо выполнить широкий обзор во избежание совпадения имён. Отметим, что Performance Metrics Directorate может помочь при выборе уникальных имён при регистрации показателя в IANA. Имя PM может быть описательным.

2. Описание показателя

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

3. Метод измерения или расчёта

   Метод измерения или расчёта должен указывать, что будет измеряться или рассчитываться, и конкретный алгоритм, а также тип измерений (пассивные или активные). Такие термины, как «среднее», должны быть уточнены (например, среднее за запуск или некоторый интервал). Исключения также следует указывать вместе с соответствующим методом обработки. Например, имеется ряд часто применяемых показателей, связанных с потерей пакетов, но у них зачастую не указаны критерии фиксации потери пакета (отличие от значительной задержки) или способ обработки пакетов-дубликатов. Скажем, если сообщается среднее значение PLR за некоторый интервал времени, а прибытие пакета переходит из одного интервала в другой, возникает сложность — к какому интервалу относить пакет?

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

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

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

   Должны чётко указываться единицы измерения.

5. Точки измерения и возможная область измерений

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

   В определении PM следует указать, как показатель может меняться в зависимости от выбора конкретной точки измерения. Например, время между запросом SIP [RFC3261] и финальным откликом может существенно различаться в точках клиента (User Agent Client или UAC) и сервера (User Agent Server или UAS) пользовательского агента.

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

6. Хронометраж измерений

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

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

5.4.3. Информационная часть определения PM

Информационная часть спецификации PM предназначена для поддержки реализации и использования показателя. В эту часть следует включать указанные ниже данные.

1. Реализация

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

2. Проверка

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

3. Использование и приложения

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

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

   2. уровень сигнала при голосовой связи обычно выражается в dBm0. Если представить результат как

      Speech level = -7 dBm0

      но это не будет понятно пользователю, не являющемуся специалистом в телефонии. Если же в определении показателя сказано, что типовой диапазон сигнала составляет от -18 до -28 dBm0, значения выше -18 будут говорить об избыточном уровне сигнала (громко), а значения ниже -28 — недостаточный (тихо) и пользователю станет проще интерпретировать показатель.

4. Модель отчётов

   Определение модели отчётов предназначено для указания взаимосвязи показателя и модели отчётов. Зачастую такие взаимосвязи подразумеваются, однако они не всегда очевидны для реализации. Например, если показатель представляет собой среднее значение за краткий скользящий интервал времени (например, вариации интервалов между пакетами [RFC3550]) и такие значения сообщаются с интервалом 6-10 секунд, результирующее измерение может оказаться недостаточно точным из-за нестабильности вариаций задержки.

5.4.4. Шаблон определения PM

Нормативные

• Metric Name — имя показателя.

• Metric Description — описание показателя.

• Method of Measurement or Calculation — метод измерения или расчёта.

• Units of Measurement — единицы измерения.

• Measurement Point(s) with Potential Measurement Domain — точки измерения и возможная область измерений.

• Measurement Timing — хронометраж измерений.

Информационные

• Implementation — реализация.

• Verification — проверка.

• Use and Applications — использование и приложения.

• Reporting Model — модель отчётов.

5.4.5. Пример: Loss Rate

В примере используется показатель доли потерь, заданный в RFC 3611 [RFC3611].

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

LossRate

Описание показателя

Доля потерянных пакетов данных RTP от источника с начала восприятия.

Метод измерения или расчёта

Целая часть результата деления общего числа потерянных пакетов (после применения средств защиты от ошибок, таких как FEC⁹) на общее число ожидаемых пакетов, умноженного на 256 с ограничением максимума (255) во избежание переполнения.

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

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

Точки измерения и возможная область измерений

Показатель измеряется на приёмной стороне потока RTP, передаваемого в течение звонка Voice over IP.

Хронометраж измерений

Этот показатель можно использовать в широком диапазоне интервалов. Интервалы более 1 часа могут препятствовать обнаружению вариаций значения показателя в результате изменения загрузки сети с течением времени. Вариации продолжительности временных интервалов следует делать не более +/- 2%.

Реализация

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

Проверка

Значения показателя лежат в диапазоне от 0 до 255.

Использование и приложения

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

Модель отчётов

Показатель нужно связывать с определенным интервалом времени, который может быть фиксированным или плавающим (скользящим). В контексте RFC 3611 показатель измеряется непрерывно с начала потока RTP, а выборки значений передаются в отчётах RTCP XR VoIP Metrics.

5.5. Зависимости

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

5.5.1. Точность хронометража

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

Если требуется сопоставлять собранные значения или интервалы, важно обеспечить точность отсчёта интервалов выборки или начала и завершения временного интервала, достаточную для приложения (например, +/- 2%).

5.5.2. Зависимость определения PM от связанных событий или показателей

Определения PM могут явно или неявно зависеть от факторов, которые могут оказаться не очевидными. Например, признание пакета потерянным основывается на том или ином методе определения фактической потери (например, порядковый номер RTP) и временном параметре, по которому отсутствие принятого пакета считается фактом потери. Важно учесть такие зависимости и включить их в определение показателя.

5.5.3. Связь PM с показателями производительности нижележащих уровней

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

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

2. сопоставление входных переменных (измеряемых) с производительностью приложения;

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

5.5.4. Присутствие промежуточных устройств

Наличие промежуточных устройств [RFC3303], например, прокси, трансляторов адресов (network address translation или NAT), серверов перенаправления, контроллеров границ сессий (session border controller или SBC) [RFC5853] и шлюзов прикладного уровня (application layer gateway или ALG) может вносить изменчивость или ограничивать область измерений показателя. Например, SBC, не обрабатывающий пакеты RTP loopback, может блокировать или локально завершать трафик, не передавая его целевому узлу.

5.6. Организация результатов

Модель IPPM Framework [RFC2330] организует результаты измерения показателей по трём категориям:

• одиночный (singleton) — элементарный экземпляр или «неделимое» (atomic) значение;

• выборка (sample) — набор одиночных измерений с некими общими и некими меняющимися свойствами;

• статистика (statistic) — значение, полученное из выборки путём определённых расчётов (например, среднее).

Показатели производительности могут использовать такую организацию результатов, применяя или не применяя термины рабочей группы IPPM. Дополнительные сведения можно найти в разделе 11 RFC 2330 [RFC2330].

5.7. Переменные показателя производительности (параметры)

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

Во всех документах, определяющих PM, следует указывать все ключевые параметры для каждого показателя производительности

6. Процесс разработки показателя производительности

6.1. Новые предложения для PM

Здесь рассмотрены дополнительные соображения в части процедуры принятия новых работ, описанной в RFC 2026 [RFC2026] и RFC 2418 [RFC2418]. Отметим, что новые предложения PM нужно принимать с использованием имеющихся процессов IETF. Для каждого предложения будут учитываться указанные ниже критерии.

Предложения следует готовить как документы Internet-Draft, описывающие PM и максимально соответствующие приведённым выше требованиям. Предложениям следует быть результатом работы соответствующих групп (WG) по разработке протоколов. Таким образом, предложения следует рассматривать в этой рабочей группе до представления в Performance Metrics Directorate. Этот аспект процесса включает оценку необходимости предлагаемого показателя производительности и поддержки его разработки в IETF.

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

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

В предложениях следует указывать любые применимые требования безопасности и требования IANA. Вопросы безопасности могут включать возможность раскрытия данных, указывающих пользователя, или возможные злоупотребления активными тестовыми инструментами. В разделе «Взаимодействие с IANA» может указываться необходимость реестра для PM.

6.2. Рецензирование PM

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

• Определён ли чётко показатель производительности?

• Заданы ли единицы измерения?

• Задан ли чётко интервал измерения, если это применимо?

• Ошибки измерений выявлены и рассмотрены?

• Обеспечивает ли метод измерений воспроизводимость результатов?

• Представляется ли показатель или метод измерения реализуемым (имеются ли работающие реализации)?

• Существуют ли недокументированные допущения относительно базового процесса, способные повлиять на реализацию или интерпретацию результатов?

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

• Имеются ли связи с показателями, определёнными в IETF или иных SDO?

• Достаточно ли учтены соображения безопасности в части DoS¹¹-атак, нежелательного вмешательства в показатели и измерения, а также конфиденциальности данных пользователей (в рабочих сетях)?

6.3. Взаимодействие Performance Metrics Directorate с рабочими группами

Директорату PM нужно предоставлять рекомендации соответствующим рабочим группам по разработке протоколов при рассмотрении Internet-Draft с PM для протоколов. Для консультаций по проекту должно быть выделено достаточное число экспертов. Если соответствующая рабочая группа завершила свои функции, комментарии к предложению все равно следует запрашивать у ключевых авторов RFC и бывших руководителей группы.

Как и в случае с рецензиями экспертов в других подразделениях, рекомендуется провести формальный обзор к моменту рассмотрения документа руководителями направлений (Area Director) или IETF Last Call.

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

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

6.4. Стандартизация PM

Performance Metrics Directorate будет оказывать содействие в предоставлении RFC статуса Standards Track (см. [IPPM-STANDARD-ADV-TESTING]). Это может включать подготовку планов тестирования для проверки разных реализаций показателя, чтобы убедиться в чёткости и однозначности определений (в зависимости от окончательной версии упомянутого выше документа).

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

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

Здесь актуальны все вопросы безопасности, связанные с активными измерениями в рабочих сетях (см. [RFC4656]).

Актуальны и вопросы безопасности, относящиеся к пассивным измерениям в работающий сетях (см. [RFC5475]).

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

Авторы признательны Al Morton, Dan Romascanu, Daryl Malas, Loki Jorgenson за комментарии и вклад в работу, Aamer Akhter, Yaakov Stein, Carsten Schmoll и Jan Novak за их рецензии.

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

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

[RFC2026] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2418] Bradner, S., «IETF Working Group Guidelines and Procedures», BCP 25, RFC 2418, September 1998.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, September 2006.

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

[E.800] «ITU-T Recommendation E.800. E SERIES: OVERALL NETWORK OPERATION, TELEPHONE SERVICE, SERVICE OPERATION AND HUMAN FACTORS», September 2008.

[G.107] «ITU-T Recommendation G.107. The E-model: a computational model for use in transmission planning», April 2009.

[IPPM-STANDARD-ADV-TESTING] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, «IPPM standard advancement testing», Work in Progress¹², June 2011.

[P.564] «ITU-T Recommendation P.564. Conformance Testing for Voice over IP Transmission Quality Assessment Models», November 2007.

[P.800] «ITU-T Recommendation P.800. Methods for subjective determination of transmission quality», August 1996.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, May 1998.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, June 2002.

[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, «Middlebox communication architecture and framework», RFC 3303, August 2002.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 3550, July 2003.

[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., «RTP Control Protocol Extended Reports (RTCP XR)», RFC 3611, November 2003.

[RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, «Real-time Application Quality-of-Service Monitoring (RAQMON) Framework», RFC 4710, October 2006.

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, September 2007.

[RFC5101] Claise, B., Ed., «Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information», RFC 5101, January 2008.

[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, «Information Model for IP Flow Information Export», RFC 5102, January 2008.

[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, «A Framework for Packet Selection and Reporting», RFC 5474, March 2009.

[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, «Sampling and Filtering Techniques for IP Packet Selection», RFC 5475, March 2009.

[RFC5481] Morton, A. and B. Claise, «Packet Delay Variation Applicability Statement», RFC 5481, March 2009.

[RFC5706] Harrington, D., «Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions», RFC 5706, November 2009.

[RFC5835] Morton, A., Ed., and S. Van den Berghe, Ed., «Framework for Metric Composition», RFC 5835, April 2010.

[RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, «Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments», RFC 5853, April 2010.

[RFC5982] Kobayashi, A., Ed., and B. Claise, Ed., «IP Flow Information Export (IPFIX) Mediation: Problem Statement», RFC 5982, August 2010.

[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, «Session Initiation Protocol Event Package for Voice Quality Reporting», RFC 6035, November 2010.

[RFC6049] Morton, A. and E. Stephan, «Spatial Composition of Metrics», RFC 6049, January 2011.

[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, «IP Flow Information Export (IPFIX) Mediation: Framework», RFC 6183, April 2011.

[RFC6248] Morton, A., «RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete», RFC 6248, April 2011.

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

Alan Clark

Telchemy Incorporated

2905 Premiere Parkway, Suite 280

Duluth, Georgia 30097

USA

EMail: alan.d.clark@telchemy.com

Benoit Claise

Cisco Systems, Inc.

De Kleetlaan 6a b1

Diegem 1831

Belgium

Phone: +32 2 704 5622

EMail: bclaise@cisco.com

---

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

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

nmalykh@protokols.ru

---