RFC 7679 A One-Way Delay Metric for IP Performance Metrics (IPPM)

Internet Engineering Task Force (IETF)                          G. Almes
Request for Comments: 7679                                     Texas A&M
STD: 81                                                     S. Kalidindi
Obsoletes: 2679                                                     Ixia
Category: Standards Track                                   M. Zekauskas
ISSN: 2070-1721                                                Internet2
                                                          A. Morton, Ed.
                                                               AT&T Labs
                                                            January 2016

A One-Way Delay Metric for IP Performance Metrics (IPPM)

Метрика односторонней задержки для IPPM

PDF

Аннотация

Этот документ определяет метрику односторонней задержки пакетов на путях Internet. Документ основан на понятиях, введённых и описанных в документе «Framework for IP Performance Metrics» (RFC 2330). Предполагается знакомство читателя с этим документом. Данный документ заменяет RFC 2679.

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

Этот документ относится к категории проектов стандартов (Internet Standards Track).

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

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

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

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

Документ определяет метрику односторонней задержки пакетов на путях через Internet. Документ основан на понятиях, введённых и описанных в документе IPPM Framework [RFC2330]. Предполагается знакомство читателя с этим документом и его обновлённым вариантом [RFC7312].

Этот документ имеет структуру, аналогичную документу по измерению потерь пакетов (A One-way Packet Loss Metric for IPPM) [RFC7680].

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

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

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

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

• С использованием этого показателя определяется выборка (sample*) Type-P-One-way-Delay-Poisson-Stream для последовательности измерений односторонней задержки в соответствии с выборкой Пуассона, определённой в параграфе 11.1.1 [RFC2330].

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

1.1. Мотивация

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

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

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

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

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

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

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

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

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

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

• Производительность приложения может сильнее зависеть от производительности в одном из направлений. Например, при взаимодействии по протоколу TCP производительность может снижаться при перегрузке в одном из направлений. Поиск неполадок может упроститься, если определить направление с перегрузкой TCP.

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

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

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

{Комментарий. Приведённые ниже термины отличаются от определённых в документах ITU-T (например, G.810 «Definitions and terminology for synchronization networks» и I.356 «B-ISDN ATM layer cell transfer performance»), но согласуются с документом IPPM Framework. В общем случае различия обусловлены разным происхождением – документы ITU-T исторически связаны с телефонией, а авторы этого документа (и документов IPPM Framework) имеют опыт работы с компьютерными системами. Хотя определённые ниже термины не имеют прямых эквивалентов в определениях ITU-T, ниже приводится их «грубое» сопоставление. Следует отметить возможную путаницу – термин «часы» (clock) здесь относится к времени в операционной системе обозначает, а в ITU-T — к опорной частоте.}

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

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

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

Степень согласованности часов в части текущего времени. Например, часы одного хоста могут опережать часы другого на 5,4 мсек. {Комментарий. Грубым эквивалентом ITU-T является «ошибка времени» (time error).}

accuracy* – точность

Степень соответствия данных часов времени UTC. Например, часы хоста могут отставать от UTC на 27,1 мсек. {Комментарий. Грубым эквивалентом ITU-T является «отклонение времени от UTC» (time error from UTC).}

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

Наименьшая единица, на которую могут изменяться показания часов. Это определяет нижнюю граничу неточности часов. Например, часы в старых системах Unix могут «тикать» лишь каждые 10 мсек, поэтому они будут иметь дискретность 10 мсек. {Комментарий. Грубым эквивалентом ITU-T является «период выборки» (sampling period).}

skew* – перекос

Мера изменения точности или синхронизации с течением времени. Например, часы хоста могут отставать на 1,3 мсек за час и отставать на 27,1 мсек от UTC в данный момент, а через час они будут отставать от UTC лишь на 25,8 мсек. В этом случае мы говорим, что часы данного хоста имеют перекос в 1,3 за час относительно UTC в плане точности. Можно также говорить о перекосе одних часов относительно других в плане синхронизации. {Комментарий. Грубым эквивалентом ITU-T является «дрейф часов» (time drift).}

3. Определение одиночного измерения односторонней задержки

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

Type-P-One-way-Delay – односторонняя задержка пакетов Type-P.

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

Src

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

Dst

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

TT

Время.

Tmax

Время ожидания порога потерь.

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

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

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

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

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

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

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

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

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

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

• Поскольку значения задержки зачастую находятся в диапазоне от 100 мксек до 10 мсек, важна точная синхронизация часов Src и Dst. Система глобального позиционирования (Global Positioning System или GPS) позволяет синхронизировать часы с погрешностью порядка десятков микросекунд. Обычное применение NTP может обеспечить точность синхронизации в несколько миллисекунд, но зависит от стабильности и симметрии параметров задержки в используемых агентах NTP, а именно такие задержки и требуется измерять. Сочетание некоторых серверов NTP, привязанных к GPS, и аккуратно (консервативно) разработанных и развёрнутых серверов NTP должно обеспечить хорошие результаты. Это было протестировано в работе [RFC6808], где результаты измерений системы GPS сравнивались с результатами синхронизированной от GPS системы NTP для межконтинентального пути.

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

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

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

• Методика будет включать способ проверки стандартного формата пакетов, соответствия всем принятым по умолчанию критериям для всех определений показателей, заданным в разделе 15 [RFC2330], считая не соответствующие пакеты потерянными. Отметим, что в настоящее время проверка стандартного формата применима лишь к пакетам IPv4 (см. также [IPPM-UPDATES]).

3.6. Методики

Как и для всех иных показателей Type-P-*, конкретная методика будет зависеть от Type-P (например, номера протокола, порта UDP/TCP, размера, поля дифференцированных услуг (Differentiated Services или DS) [RFC2780]).

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

• Выполняется синхронизация Src и Dst, чтобы их часы указывали достаточно близкое и точное время.

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

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

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

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

• Если пакет не прибыл в разумные сроки, значение Tmax для односторонней задержки считается неопределенным (неформально, бесконечным). Отметим, что разумный срок является параметром метрики. Эти аспекты подробно рассмотрены в [RFC6703], включая предпочтения при анализе для назначения неопределённой задержки пакетам из-за трудностей, связанных с неформальным определением «бесконечной задержки» и оценкой верхнего предела ожидания пакетов, находящихся в сети. Задание постоянного времени ожидания для сохранённых одиночных измерений односторонней задержки согласуется с данной спецификацией и может позволить обрабатывать результаты измерений из нескольких источников.

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

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

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

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

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

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

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

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

• Любая ошибка синхронизации часов источника и получателя вносит вклад в ошибку измерения задержки. Будем говорить, что между часами источника и получателя имеется ошибка синхронизации Tsynch, если часы источника опережают часы получателя на Tsynch. Таким образом, при точной известной ошибке Tsynch можно скорректировать расхождение часов, прибавив Tsynch к разности Tdest – Tsource.

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

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

• Перекос часов является не столько дополнительной проблемой, сколько реализацией того, что Tsynch зависит от времени. Таким образом, при попытке измерить или ограничить (привязать) Tsynch, это нужно делать периодически. В течение некоторого времени эту функцию можно аппроксимировать как линейную с некоторыми членами более высокого порядка. В таких случаях одним из вариантов является использование значения линейной составляющей для корректировки часов. При использовании такой корректировки остаточное значение Tsynch становится меньше, но остаётся источником погрешности, которая должна учитываться. Будем использовать функцию Esynch(t) для обозначения верхней границы погрешности синхронизации. Таким образом, |Tsynch(t)| <= Esynch(t).

С учётом отмеченного выше укажем, что естественный расчёт Tdest – Tsource будет давать погрешность Tsynch(t) +/- (Rsource + Rdest). используя понятие Esynch(t), отметим, что проблемы, связанные с часами, вносят общую погрешность Esynch(t) + Rsource + Rdest. Эту оценку связанной с часами общей погрешности следует включать в анализ ошибок и погрешностей любой реализации измерения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Esynch(t) + Rsource + Rdest + Hsource + Hdest

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

Например, связанные с часами погрешности существенно снижаются при использовании времени от GPS. Сумма Esynch(t) + Rsource + Rdest будет мала и ограниченна в интервале измерений в результате привязки к глобальной системе точного времени.

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

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

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

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

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

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

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

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

3.8.1. Type-P

Как указано в разделе 13 документа IPPM Framework [RFC2330], значение показателя может зависеть от типа пакетов IP, применяемых для измерений – Type-P. Значение Type-P-One-way-Delay может меняться при смене протокола (UDP или TCP), номера порта, размера пакетов или особых условий (например, поле IP DS [RFC2780], явное уведомление о перегрузке (Explicit Congestion Notification или ECN) [RFC3168], RSVP).

Будут применимы также дополнительные различия пакетов, задаваемые будущими расширениями определения Type-P. В отчёт должно включаться точное указание Type-P при измерениях.

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

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

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

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

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

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

3.8.4. Путь

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

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

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

Отметим, что выборка Пуассона является лишь одним из вариантов выборки. Преимуществом её является ограничение смещения (bias), но в других ситуациях могут оказаться лучше иные методы выборки. Например, распределение Пуассона с отсечкой может потребоваться для предотвращения реактивной смены состояния сети в интервалах отсутствия активности (см. параграф 4.6 в [RFC7312]). Иногда целью являются выборки с известным смещением и в [RFC3432] описан метод периодической выборки со случайным временем начала.

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

Type-P-One-way-Delay-Poisson-Stream

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

Src

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

Dst

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

T0

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

Tf

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

Tmax

Время ожидания порога потерь.

lambda

Число измерений в секунду (или параметры иного распределения).

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

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

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

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

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

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

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

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

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

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

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

4.6. Методики

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

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

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

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

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

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

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

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

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

На основе выборки Type-P-One-way-Delay-Poisson-Stream предлагается несколько вариантов статистики. Описание статистики служит в основном для иллюстрации того, что можно сделать. Дополнительное рассмотрение статистики для разных аудиторий приведено в [RFC6703].

5.1. Type-P-One-way-Delay-Percentile

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

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

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

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

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

5.2. Type-P-One-way-Delay-Median

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

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

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

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

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

5.3. Type-P-One-way-Delay-Minimum

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

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

5.4. Type-P-One-way-Delay-Inverse-Percentile

Примечание. Эта статистика отменена данным документом по причине её редкого применения.

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

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

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

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

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

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

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

В части приватности участников измерения или тех, чей трафик измеряется, возможность раскрытия деликатных сведений посторонним существенно ограничена при использовании активных методов, которым посвящён этот документ. Пассивные наблюдения пользовательского трафика для измерений создают множество проблем приватности. Читателям рекомендуется обратиться к документу «Large Scale Measurement of Broadband Performance (LMAP) Framework» [RFC7594], где рассмотрены активные и пассивные методы измерений.

Сбор и использование результатов измерений для зондирования с целью организации атак на системы достаточно распространены. Доступ к результатам измерений и контроль над измерительными системами для зондирования следует тщательно оберегать. В разделе 7 [RFC7594] (Security Considerations of the LMAP Framework) рассмотрены системные требования, помогающие предотвратить компрометацию измерительных систем.

7. Отличия от RFC 2679

Приведённый выше текст является пересмотром RFC 2679³, имеющего статус Internet Standard. Здесь перечислены отличия от [RFC2679].

В [RFC6808] представлен план тестирования и результаты, поддерживающие продвижение [RFC2679] в процессе Standards Track в соответствии с процедурой [RFC6576]. Выводы [RFC6808] включают 4 указанных ниже изменения.

1. В параграфе 6.2.3 [RFC6808] отмечено, что допущение о постобработке для обеспечения постоянного порога времени ожидания разумно и это следует включить в текст RFC. Применимость постобработки добавлена в последний абзац параграфа 3.6.

2. В параграфе 6.5 [RFC6808] указано, что статистика Type-P-One-way-Delay-Inverse-Percentile была проигнорирована в обоих реализациях, поэтому она была кандидатом на удаление или отмену в этом документе (это незначительное несоответствие не влияет на процесс стандартизации). Статистика была отменена в параграфе 5.4.

3. В IETF достигнуто соглашение о рекомендациях по отчётам о показателях [RFC6703] и этот документ указан здесь для учёта при необходимости недавнего опыта. Ссылка добавлена в последние абзацы параграфов 3.6, 3.8 и раздела 5.

4. Имеется сообщение об ошибке со статусом Held for Document Update (EID 398) для [RFC2679] и соответствующий пересмотр и дополнительный текст включены в параграф 5.1.

Ряд обновлений [RFC2679] реализован в приведённом выше тексте ссылками на ключевые IPPM RFC, одобренные после [RFC2679], и учётом комментариев в почтовой конференции IPPM, описывающих текущие условия и опыт применения.

1. В конце параграфа 1.1 обновлён пример сети, использующей ATM, с разъяснение влияния TCP на занятость очередей, и обсуждается важность измерения односторонней задержки.

2. В параграфах 3.2 и 4.2 явно включён входной параметр максимального времени ожидания для отражения принятия этого параметра в более поздних RFC и ITU-T Recommendation Y.1540.

3. Добавлены ссылки на RFC 6703 при обсуждении времени существования пакетов и тайм-аутов приложений в параграфе 3.5.

4. Добавлена ссылка на принятое по умолчанию требование (стандартный формат пакетов) из RFC 2330 в качестве элемента списка в параграфе 3.5.

5. Для NTP на основе GPS в параграфе 3.5 был исключён статус «для проверки» (to be tested).

6. Предпочтения (precedence) заменены более современным термином DS Field в параграфах 3.6 и 3.8.1(со ссылкой).

7. Добавлены заключённые в скобки рекомендации по минимизации интервала между получением временной метки и отправкой пакета в параграфе 3.6.

8. В параграфе 3.7.2 отмечено, что некоторые современные системы устанавливают временные метки на оборудовании сетевого интерфейса.

9. Термин «инструмент» (instrument) заменён определенным термином «хост» (host) в параграфах 3.7.3 и 3.8.3.

10. Добавлена ссылка на RFC 3432 в части периодической выборки наряду с выборкой Пуассона а разделе 4, а также указано, что распределение Пуассона с отсечкой может потребоваться в современных сетях, как указано в обновлении IPPM Framework [RFC7312].

11. Добавлена ссылка на RFC 4737, связанная с метрикой разупорядочения, при обсуждении методик (параграф 4.6).

12. Изменён формат примера в параграфе 5.1 для соответствия оригиналу (преобразование в XML).

13. Уточнены заключения о двух связанных аспектах нарушения измерений (распознавание измерительного трафика с непредусмотренной трактовкой трафика измерений и имитирующего его злонамеренного трафика) в разделе «6. Вопросы безопасности».

14. Расширен и обновлён материал по приватности и добавлены предупреждения об использовании инструментов для зондирования (разведки) в разделе «6. Вопросы безопасности».

В параграфе 5.4.4 [RFC6390] предложен базовый шаблон для показателей производительности, частично выведенный из предшествующих RFC IPPM и рабочей группы BMWG (Benchmarking Methodology Working Group) с добавлением некоторых элементов. Учтены все нормативные части [RFC6390], но с некоторыми изменениями названий параграфов и ориентации. Учтены также несколько информационных частей. Поддержка стиля документов IPPM достаточно важна и минимизирует различия между пересмотренным RFC и современными, а также будущими IPPM RFC.

В [RFC6921] предложена область, для которой может потребоваться изменение этого документа. В сетях FTL (Faster-Than-Light) могут возникать отрицательные задержки и изменение порядка пакетов, однако оба этих обстоятельства учитываются в спецификации и не требуют её пересмотра (отметим, что [RFC6921] является первоапрельским).

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

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

[RFC791] Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.

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

[RFC2678] Mahdavi, J. and V. Paxson, “IPPM Metrics for Measuring Connectivity”, RFC 2678, DOI 10.17487/RFC2678, September 1999, <http://www.rfc-editor.org/info/rfc2678>.

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, “A One-way Delay Metric for IPPM”, RFC 2679, DOI 10.17487/RFC2679, September 1999, <http://www.rfc-editor.org/info/rfc2679>.

[RFC2780] Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers”, BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <http://www.rfc-editor.org/info/rfc2780>.

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

[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, <http://www.rfc-editor.org/info/rfc6576>.

[RFC7312] Fabini, J. and A. Morton, “Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)”, RFC 7312, DOI 10.17487/RFC7312, August 2014, <http://www.rfc-editor.org/info/rfc7312>.

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

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

[IPPM-UPDATES] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, “Updates for IPPM’s Active Metric Framework: Packets of Type-P and Standard-Formed Packets”, Work in Progress, draft-morton-ippm-2330-stdform-typep-02, December 2015.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.

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

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

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

[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, “Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track”, RFC 6808, DOI 10.17487/RFC6808, December 2012, <http://www.rfc-editor.org/info/rfc6808>.

[RFC6921] Hinden, R., “Design Considerations for Faster-Than-Light (FTL) Communication”, RFC 6921, DOI 10.17487/RFC6921, April 2013, <http://www.rfc-editor.org/info/rfc6921>.

[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, <http://www.rfc-editor.org/info/rfc7594>.

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

Применительно к [RFC2679] спасибо Vern Paxson из Lawrence Berkeley Labs за полезные комментарии по погрешности часов и статистике. Спасибо также Garry Couch, Will Leland, Andy Scherrer, Sean Shapira, Roland Wittig за полезные предложения.

Применительно к этому документу спасибо Joachim Fabini, Ruediger Geib, Nalini Elkins, Barry Constantine за предоставление их опыта измерения как части отзывов. Brian Carpenter и Scott Bradner представили полезные отклики на IETF Last Call.

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

Guy Almes

Texas A&M

Email: almes@acm.org

 

Sunil Kalidindi

Ixia

Email: skalidindi@ixiacom.com

 

Matt Zekauskas

Internet2

Email: matt@internet2.edu

 

Al Morton (редактор)

AT&T Labs

200 Laurel Avenue South

Middletown, NJ 07748

United States

Phone: +1 732 420 1571

Fax: +1 732 368 1192

Email: acmorton@att.com

URI: http://home.comcast.net/~acmacm/

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

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

nmalykh@protokols.ru