Ранее...

И вот, когда рассказано очень многое, можно начать наконец-то описание метрик качества, про которые мы так долго говорили, прямо как большевики на втором съезде Советов. Вначале упомянем основные. Первый из них очевиден:

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

процент потерянных пакетов в тесте.

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

Рисунок 7. Сеть связи, на которой произошло событие потери пакета

где

Пакеты пользовательского трафика, направленные от CE1 до CE2

Узкое место на сети оператора связи, в котором нет свободной ёмкости в момент пропуска одного из пакетов

Событие отбрасывания одного из пакетов пользовательского трафика, который невозможно доставить из-за отсутствия свободной ёмкости

Пакеты пользовательского трафика, доставляемые по сети оператора связи после события потери одного из пакетов

На рисунке 7, конечно, число изображённых пакетов условное, в реальности их намного больше даже для тестового трафика (см. условие применимости 3), что уж говорить про пользовательский — их там без счёта. Тем не менее, даже если посчитать по рисунку, поставив N_s в 4, а N_r в 3, получим LR_r равным 25%. Нормальное же значение конечно должно быть 0%, что очевидно, как из рисунка, так и из логики. Впрочем, это в идеальном мире. О реальных нормах мы ещё поговорим.

Теперь упомянем то, что на практике слишком редко проверяется, однако на самом деле имеет очень большое значение в рабочих сетях с разделением трафика по классам сервиса:

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

число пакетов теста, успешно принятых на стороне приёма за время Tr, однако доставленных с классом сервиса, отличным от Cs

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

процент пакетов в тесте, доставленных с изменённым классом сервиса (процент перекраски)

Тут уже точно не обойтись без наглядности. Рекомендуем внимательно изучить весь рисунок, не зря же мы его создавали!

Рисунок 8. Сеть связи, на которой произошли события потери и изменения класса сервиса

где

Пакеты пользовательского трафика, направленные от CE1 до CE2, помеченные пользователем классом сервиса Cs

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

Событие понижения приоритета одного из пакетов пользовательского трафика для дальнейшей доставки

Доставка пользовательских пакетов без дальнейших изменений класса ввиду наличия свободной ёмкости

На рисунке 8, вновь число изображённых пакетов условное. Но мы всё-таки для наглядности посчитаем с карандашом в руках, что N_rr равно 1, а N_r , как и прежде 3, и получим RR_r равным 33,(3)%. Нормальное же значение конечно должно быть 0%. По крайней мере на сети оператора связи, который себя и клиентов уважает.

Почему данная метрика настолько важна, что мы её упоминаем второй? У тех операторов связи, которые борются за качество услуг, несомненно, уже внедрён на рабочих сетях пропуск трафика с учётом приоритетов. Иначе говоря, важнейший трафик обрабатывается P‑устройствами в первую очередь, менее важный во вторую, а трафик любимой социальной сети простого жителя Красного города‑сада — только тогда, когда для него есть свободная канальная ёмкость. Операторам же, которые ещё только думают, не сделать ли этот шаг, мы настоятельно рекомендуем шагнуть навстречу будущему быстрее.

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

В тех случаях, когда на сети фиксируется перекраска трафика, значит где-то есть узкое место в политиках профилирования. На рисунке 8 это место отмечено фиолетовым цветом. Пользователь пока ещё не видит проблемы и это логично, ведь пакеты‑то доставлены, однако служба эксплуатации на появление ненулевой метрики RR_r обязана реагировать, тем более, если этот факт уже не первый раз повторяется. Он может свидетельствовать как минимум о трёх вещах: либо пользователь выбрал заказанную полосу пропускания в классе сервис C_s, и ему требуется дополнительная, либо пользователь по недосмотру или намеренно пропускает неверный трафик, надеясь, что оператор добрый за свой счёт, либо на одном из транзитных каналов политика профилирования исчерпала свою ёмкость и тут уже оператору пора решать, что делать на данном участке. Как вы видите, метрика очень важная, но среди многочисленных сетевых администраторов, которых встречали на своём жизненном пути авторы, к сожалению, только у некоторых было понимание аналогичное нашему, поэтому мы и делаем на этом акцент. Надеемся подвижничеством добиться правильного, как сказано у Мф.7:7.

Отойдём от нетривиального и упомянем уже очевидное:

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

измеренная скорость среди успешно принятых пакетов на стороне приёма за время Tr

Этой характеристикой пользуются все, даже рядовые пользователи, поэтому она не должна вызывать вопросов. Но рисунок мы всё-таки приведём. Ибо связист в России больше, чем поэт!

Рисунок 9. Сеть связи, на которой производится измерение скорости

где

Измеритель скорости

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

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

Однако, заметим, скорость на приёме явно будет зависеть от количества потерь по пути следования пакетов. Более того, мы ожидаем, что на хорошо отстроенной сети должна быть корреляция между LR_r и (B_s-BW_r)/B_s. Разумеется, с учётом некоторой неопределённости, вносимой периодом T_max и распределением потерь.Что же касается нормального значения для скорости, мы более внятно погорим об этом, обсуждая нагрузочное тестирование.

Из основных метрик остались задержки, их тоже знают все:

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

минимальная задержка успешной доставки пакетов от стороны генератора до стороны приёма, измеренная за время Tr

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

максимальная задержка успешной доставки пакетов от стороны генератора до стороны приёма, измеренная за время Tr

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

среднее арифметическое задержек успешной доставки пакетов от стороны генератора до стороны приёма, измеренных за время Tr

Не откажем себе в удовольствии проиллюстрировать и эти метрики наглядным рисунком.

Рисунок 10. Сеть связи, на которой производится измерение задержек

где

Накопитель информации о параметрах T1i

Накопитель информации о параметрах T2i для измерения задержек

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

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

Ну и в финале определения первичных метрик не откажем себе в удовольствии устроить заочную полемику с отраслевым стандартом Y.1540. Ему многие поклоняются, как божеству, но писали его люди, они склонны ошибаться, а на ошибках надо учиться, а не поклоняться им без страха и упрёка. Итак, IPER или Internet Protocol packet Error Ratio. Кто‑то решил, что будет полезно измерять процент IP‑пакетов, доставленных с ошибкой. Не отрицая, что на каналах связи ошибки встречаются (см. выше в разделе 1.1), более того, подчёркивая, что эти события на некоторых физических средах являются более‑менее естественным явлением, мы тем не менее всегда помним, что эксплуатируем‑то мы всю сеть, как единое целое. А на сети TCP/IP ошибки купируются после приёма на коммутатор или маршрутизатор и дальше в исходящий интерфейс или в процесс, открывший сокет, не передаются! Странно, что вроде бы грамотные люди, писавшие Y.1540, не увидели очевидного: За пределами одного канала измерять процент ошибочно доставленных IP‑пакетов не имеет смысла! Ошибки по сети TCP/IP не транслируются в отличие от сетей с коммутацией каналов. Поэтому даже если на измерительном устройстве вы подмените своим приложением стек TCP/IP и доведёте ошибку в пакете до подпрограммы, способной увеличить счётчик на один, вы получите только ошибки «последнего дюйма». Это точно то, что вы ожидали? Жизненный опыт связистов подсказывает, что нет.

Именно по этой причине, хотя и зная, что ошибки на каналах есть, мы тем не менее вводить метрику, аналогичную Y.1540 IPER, не будем, считая этот увлекательный процесс стрельбой из единорогов Шувалова по воробьям.

cc: lj, telegraph, vk, telegram: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16, zen, AT, MMM

Далее...