RFC 7680 A One-Way Loss Metric for IP Performance Metrics (IPPM)

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

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

Метрика односторонних потерь для производительности IP (IPPM)

PDF

Аннотация

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

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

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

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

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

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

Авторские права ((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 Delay Metric for IP Performance Metrics (IPPM)) [RFC7679]. Предполагается, что читатель знаком с этим документом.

Ключевые слова необходимо (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-Packet-Loss для однократного наблюдения потерь в одном направлении.

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

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

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

1.1. Мотивация

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

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

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

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

• Чувствительность приложений в реальном масштабе времени и транспортных протоколов к потере пакетов становится особенно важной, когда требуется поддержка путей в высоким значением произведения задержки на пропускную способность (delay*bandwidth).

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

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

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

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

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

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

1.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).}

2. Определение одиночного измерения потерь в одном направлении

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

Type-P-One-way-Packet-Loss

2.2. Параметры метрики

Src

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

Dst

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

TT

Время.

Tmax

Время ожидания, по истечении которого пакет считается потерянным.

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

Значением показателя Type-P-One-way-Packet-Loss является 0 (успешная передача пакета) или 1 (пакет потерян).

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

Нулевое значение Type-P-One-way-Packet-Loss при передаче от Src к Dst в момент времени T означает, что хост Src передал первый бит пакета Type-P хосту Dst в момент времени в линии (wire-time*) T и хост Dst получил этот пакет.

Значение 1 для Type-P-One-way-Packet-Loss от Src к Dst в момент T означает, что хост Src передал первый бит пакета Type-P по адресу Dst в момент времени в линии T, но пакет не пришел к Dst (в интервале Tmax).

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

Type-P-One-way-Packet-Loss имеет значение 0, когда задержка Type-P-One-way-Delay имеет конечное значение, и 1 при неопределённой (бесконечной) задержке Type-P-One-way-Delay.

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

• Методика должна включать способ определения, является потерей пакетов и очень большой (но конечной) задержкой. Как отметили Mahdavi и Paxson [RFC2678], можно использовать простую верхнюю границу (например, теоретическое ограничение срока существования пакетов IP в 255 секунд [RFC791]). Но на практике требуется понимать сроки существования пакетов.

  {Комментарий. Отметим, что для многих применений этого показателя негативное влияние трактовки очень большой задержки как потери, может отсутствовать или быть совсем незначительным. Например, голосовой пакет, полученный после момента его воспроизведение, можно считать потерянным. В параграфе 4.1.1 [RFC6703] приведено обсуждение необычных задержек пакетов и оценка производительности приложения.}

• Если пакет прибывает повреждённым, он считается потерянным.

  {Комментарий. Возникает искушение считать повреждённые пакеты полученными, поскольку повреждение и потеря пакета – связанные, разные события. Однако при повреждении заголовка IP нет уверенности в IP-адресах отправителя и получателя и, следовательно, в том, что это именно тестовый пакет. Если при других повреждениях можно сопоставить повреждённый пакет с отправленным тестовым пакетом и считать его полученным, это приведёт к несогласованности.}

  В разделе 15 [RFC2330] определён пакет «стандартного формата», который применим для всех показателей. Отметим, что на момент определения пакетами стандартного формата считались лишь пакеты IPv4 (см. [IPPM-UPDATES]).

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

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

2.6. Методики

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

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

• На хосте Src выбираются IP-адреса Src и Dst и создаётся тестовый пакет Type-P с этими адресами.

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

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

• Если пакет прибывает в течение разумного интервала времени, считается Type-P-One-way-Packet-Loss = 0 (временная метка берётся при получении пакета как можно скорее).

• Если пакет не прибывает в течение разумного интервала времени Tmax, считается Type-P-One-way-Packet-Loss = 1. Отметим, что значение «разумного интервала» здесь является параметром методики.

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

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

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

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

• синхронизация часов на хостах Src и Dst;

• пороговое значение фиксации потери (связано с синхронизацией часов);

• ограничения ресурсов сетевого интерфейса и программ на приёмном оборудовании.

Первые два источника ошибок связаны между собой и могут приводить к признанию потерянным тестового пакета с конечной задержкой. Type-P-One-way-Packet-Loss = 1, если тестовый пакет не приходит или приходит с разницей временных меток Src и Dst, превышающей «разумный интервал» или порог потерь. Если часы не синхронизированы точно, порог потерь может оказаться «неразумным», т. е. фактическое время доставки пакета будет существенно меньше определённого из метки Src. Если установлен слишком низкий порог потерь, многие пакеты будут сочтены потерянными. Порог потерь должен быть достаточно большим, а синхронизация – достаточно точной, чтобы прибывшие пакеты не считались потерянными слишком часто (см. обсуждение в двух предыдущих параграфах).

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

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

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

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

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

2.8.1. Type-P

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

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

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

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

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

2.8.4. Путь

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

3. Определение выборки для односторонних потерь

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

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

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

Type-P-One-way-Packet-Loss-Poisson-Stream

3.2. Параметры метрики

Src

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

Dst

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

T0

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

Tf

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

Tmax

Время ожидания, по истечении которого пакет считается потерянным.

lambda

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

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

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

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

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

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

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

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

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

Выборка определяется как пуассоновский процесс, чтобы избежать самосинхронизации и обеспечить выборку, статистически наиболее достоверную (unbiased). Пуассоновский процесс служит для планирования измерений задержки. Тестовые пакеты в общем случае не будут приходить на Dst в соответствии с распределением Пуассона, поскольку сеть оказывает влияние на их доставку. Каналы с временными интервалами (time-slot), описанные в параграфе 3.4 [RFC7312] могут существенно изменять характеристики выборки. Основной проблемой является то, что несмещенные (unbiased) потоки пакетов со случайными межпакетными интервалами будут приводиться к иному распределению в канале с временными интервалами, которое может оказаться строго периодическим.

{Комментарий. Конечно не принимается допущений о том, что реальный трафик Internet прибывает в соответствии с распределением Пуассона.

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

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

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

3.6. Методики

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

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

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

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

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

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

{Комментарий. Цель состоит в передаче тестовых пакетов «достаточно близко» к планированию Пуассона без возникновения периодической отправки.}

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

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

4. Определения статистики для односторонних потерь

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

4.1. Type-P-One-way-Packet-Loss-Ratio

Для данной выборки Type-P-One-way-Packet-Loss-Poisson-Stream усредняются значения L в потоке. Кроме того, Type-P-One-way-Packet-Loss-Ratio будет неопределённым для пустой выборки.

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

   Stream1 = <
   <T1, 0>
   <T2, 0>
   <T3, 1>
   <T4, 0>
   <T5, 0>
   >

Среднее значение составит 0,2.

Отметим, что «здоровые» пути Internet должны иметь потери меньше 1% (особенно при высоких значениях произведения задержки на пропускную способность (delay-bandwidth)), поэтому могут потребоваться выборки большого размера. Например, для определения потерь в доли процента с течение минуты может потребоваться несколько сотен выборок в минуту. Это ведёт к большим значениям lambda.

Хотя порог потерь следует устанавливать так, чтобы минимизировать ошибки при учёте потерь, возможны случаи, когда прибывшие пакеты будут считаться потерянными в результате нехватки ресурсов. Если такие «потери» велики, измерение Type-P-One-way-Packet-Loss-Ratio теряет смысл.

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

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

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

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

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

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

6. Отличия от RFC 2680

Приведённый выше текст является пересмотром RFC 2680, имеющего статус Internet Standard.

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

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

2. В параграфе 6.5 [RFC7290] указано, что статистику Type-P-One-way-Packet-Loss-Average чаще называют Packet Loss Ratio и она была переименована в этом документе (это незначительное несоответствие не влияет на процесс стандартизации). Переименование статистики указано в параграфе 4.1.

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

4. Имеется сообщение об ошибке со статусом Verified (EID 1528) для [RFC2680] и соответствующий пересмотр включён в раздел 1 и параграф 2.7.

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

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

2. Разъяснено определение термина resolution в параграфе 1.2.

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

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

5. Термин «предпочтения» (precedence) заменён современным термином DS Field в параграфах 2.6 и 2.8.1 (со ссылкой).

6. Добавлены заключённые в скобки рекомендации по минимизации интервала между получением временной метки и отправкой пакета в параграфе 2.6. Кроме того, в тексте сейчас различается процесс получения временной метки и практическое измерение системой задержки и потерь (что требует параметра максимального времени ожидания Tmax).

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

8. Отмечено, что канала в временными интервалами, описанные в [RFC7312] могут существенно менять характеристики выборки (параграф 3.5).

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

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

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

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

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

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, “A One-way Packet Loss Metric for IPPM”, RFC 2680, DOI 10.17487/RFC2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>.

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

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

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

[RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, “Test Plan and Results for Advancing RFC 2680 on the Standards Track”, RFC 7290, DOI 10.17487/RFC7290, July 2014, <http://www.rfc-editor.org/info/rfc7290>.

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

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

Применительно к [RFC2680] Matt Mathis за поддержку этой работы и привлечение внимания к вопросам измерения потерь пакетов. Спасибо Vern Paxson за ценные комментарии к ранним вариантам документа, а также Garry Couch и Will Leland за полезные предложения.

Применительно к этому документу спасибо 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