Основы тестирования сетей TCP/IP для служб эксплуатации №1.5

CAE

Приём искусственного трафика

Очевидно, что все метрики качества на сети TCP/IP по итогам теста могут быть вычислены только после приёма пакетов, созданных на стороне передачи. Так же ясно, что время ожидания на приёме должно быть конечно, чтобы была возможность подвести итоги и создать возможные реакции. Сразу заметим, что в дальнейшем мы неявно предполагаем, что часы на обоих устройствах, занимающихся обработкой теста, должны быть синхронизированы. Это удобно для точности определений, хотя строго говоря, для расчёта большинства метрик качества необязательно.

Определение 20

абсолютное время начала отправки пакета с номером i от стороны генератора.

Определение 21

абсолютное время окончания приёма пакета с номером i на стороне приёма.

Следующие два определения ссылаются друг на друга, поэтому мы их вводим рядом, для лучшего понимания.

Определение 22

число пакетов теста, успешно принятых на стороне приёма за время T[r]

Определение 23

«Почему так сложно? У нас тут что — кружок любителей математики?» - спросит пытливый читатель. Не станем делать секрета, ведь мы ценим пытливого читателя. Одной из основных особенностей сети TCP/IP является асинхронный характер трафика. Программа‑инициатор создаёт пакет в произвольный момент времени, и вообще говоря, мы ничего не знаем про то, в какой именно момент. Это же относится и к тестовому трафику, да‑да‑да! Даже на транзитных P‑устройствах эта особенность сохраняется. Таким образом, на приёме с одной стороны, необходимо получить все пакеты теста, с другой стороны, не все пакеты могут быть доставлены. Вы ведь помните про потери? При этом полный период тестирования T[test] использовать нельзя, так как он определён на стороне инициатора, а для приёмной он может и будет зависеть от реального состояния сети. При наличии буферизации период приёма может даже уменьшиться! А если первый пакет теста не будет доставлен, то ориентироваться на кажущийся на первый взгляд очевидным финальный временной порог ожидания всех пакетов T2[1] + T[test] тоже никак нельзя. При пропуске же заметного числа пакетов в середине тестовой последовательности искусственного трафика, ситуация только ухудшается.

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

Алгоритм 1

На очередном шаге ждём не более T[max]
Если пакет не пришёл, остальные возможные пакеты считаются недоставленными. Переход на шаг 6.
Иначе рассчитываем метрики качества.
Если число принятых пакетов стало равно N[s], все пакеты теста доставлены, переходим на шаг 6.
Иначе возвращаемся на шаг 1.
Останов.

Несложно видеть, что T[r] с помощью алгоритма 1 легко получается именно в форме определения 23. И также несложно видеть, что у алгоритма есть важные условия применимости. Как в теории дифференциальных уравнений в задаче необходимы граничные условия, так и в теории расчёта метрик качества сетей TCP/IP нужно чётко понимать, где заканчиваются границы корректности даже у статистических величин.

Условие применимости 1 алгоритма 1

C[s] класс сервиса TOS/DSCP за всё время работы теста на стороне инициатора не меняется

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

Условие применимости 2 алгоритма 1

P[s] размер пакета за всё время работы теста на стороне инициатора не меняется

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

Если пропускать трафик с разными размерами пакетов в одном потоке, то мы получим общие метрики, а как тогда отделять случаи потерь пакетов определённого размера, что достаточно часто встречается на практике?

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

Кроме того, не забываем, что в стандарте RFC-6815 впрямую рекомендуется применять RFC-2544 только в отделённой среде тестирования (Isolated Test Environment), поэтому в службах эксплуатации рабочих сетей мы бы рассматривали RFC-2544 как хотя и полезный, но не строгий, а более факультативный.

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

Условие применимости 3 алгоритма 1

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

Наш коллега‑читатель уже догадывается, что мы скажем. Процент потерь пакетов от точки создания трафика до точки приёма имеет в знаменателе число пакетов в тесте (см. ниже определение 24). Поэтому чем больше пакетов пропущено, тем точнее будет эта метрика. Что же касается остальных, то число пакетов для них тоже имеет значение, поэтому не стоит тестировать качество слишком незначительным числом пакетов.

Кроме того, для тех работников операторов, которые предпочитают не число пакетов в качестве первичного параметра, а время тестирования, приведём формулу вычисления N[s] по остальным параметрам:

Проверим корректность типовыми настройками генератора. Воспользуемся знакомыми терминами.

При пропуске трафика IP‑телефонии с использованием кодека G.729 скорость для адресации IPv4 будет 24 килобита/с, размер пакета 32 байта, время тестирования выберем в 20 секунд. Число пакетов получается 1024. Более чем достаточно для достойной точности.

При пропуске трафика IP‑телефонии с использованием кодека G.711 скорость для адресации IPv4 будет 79 килобит/с, размер пакета 172 байта, время тестирования выберем в 20 секунд. Число пакетов получается 1011. Тоже вполне достаточно.

Условие применимости 4 алгоритма 1

скорость генерации теста должна быть такой, чтобы двойной межпакетный интервал не превышал T[max]

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

Рисунок 3

Нормальный приём теста по алгоритму 1 при T[max]>2⋅IPI[s]

где T[r0]– время начала работы по приёму.

Наглядно видно, что каждый новый шаг ожидания с фиксацией периода T[max] на будущее гарантированно перекрывается вновь поступающим пакетом. Условия останова будут выполнены, когда все N[s] пакетов придут, как и предусмотрено третьим пунктом определения 23. Теперь предположим, что сеть находится не в идеальном, а реальном состоянии и допустим, что на ней есть потери. Причём каждого второго пакета, гулять так гулять, скажем, что на дворе 7 или 17 мая!

Рисунок 4

Приём теста по алгоритму 1 при T[max]>2⋅IPI[s] и наличии потерь

где перечёркнутым крестом прямоугольниками отмечены потенциальные пакеты, которые в реальности так и не дошли до приёмника.

На рисунке 4 видно, что из-за выполнения условия применимости 4 мы всё ещё можем получать пакеты, даже несмотря на потери каждого второго! А останов в этом случае произойдёт, когда в попытке дождаться пакета № N[s] исчерпается T[max] в N[r]+1-й раз, как назначено вторым пунктом определения 23. Разумеется, если сеть придёт в ещё более удручающее состояние, не поможет даже это, но помним, что пока у нас главное — иллюстрация для лучшего понимания пытливым умом связиста. Что же будет, если всё-таки «мы пойдём иным путём», уменьшив скорость генерации теста и, тем самым, увеличив межпакетный интервал (см. определение 19)? Вначале на идеальной сети.

Рисунок 5

Приём теста по алгоритму 1 при T[max]<2⋅IPI[s]

«Да всё нормально же! Кто придумывал эти условия?» - скажет бегущий впереди нас читатель. Согласны, вначале кажется, что ничего по сравнению с рисунком 3 не поменялось. Подумаешь, IPI[s] уменьшился! Алгоритм-то по-прежнему работает и даже останавливается там, где надо. Но! Во-первых неравнодушным мы даём задание самостоятельно нарисовать рисунок при T[max]<IPI[s] в целях иллюстрации, что нижняя граница для скорости генерации всё-таки нужна! А во-вторых, приведём реальную сеть, ведь мы только что были в идеальном вакуумном сферическом мире, а пора бы вернуться на поверхность геоида.

Рисунок 6

где красным текстом отмечены проблемные места.

Вот теперь понятно, что начались проблемы. Пакеты-то ещё пойдут, но за счёт того, что T[max] меньше двойного межпакетного интервала, алгоритм 1 остановится раньше, чем нужно. Первый пакет успеет приняться, пройдут нехитрые расчёты, про которые мы когда-то тоже поговорим пристально, начнётся ожидание следующего, но он придёт слишком поздно, когда процесс уже завершится. И хотя у нас и не чертёж, но размерные линии с выносом вправо хорошо иллюстрируют, какое событие случится первым. Третье же ожидание потому и отмечено красным, что его в реальности не будет! Завершение процесса досрочно грозит не только неполными данными, но и бессмысленной нагрузкой на сеть. А мы боремся за разум.

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

Не забудем проверить разумность формулы и алгеброй. Воспользуемся уже знакомыми параметрами. 32 байта кодека G.729 при рекомендованном времени ожидания 3 секунды дают минимально нужную скорость в 320 бит/с. Разумный минимальный выбор, реальность (см. выше условие применимости 3) быстрее более чем в 70 раз.

Проверим иначе. Возьмём произвольный протокол с размером пакета 1472, а время ожидания оставим тем же. Получаем 8000 бит/с минимально необходимой скорости. Это 1,5 секунды межпакетного интервала. То есть при потере двух пакетов подряд (вполне реальный случай) алгоритм завершится заранее. Что приведёт к недостаточной точности итоговых статистических величин. Видим, что условие применимости 4 абсолютно разумно. В реальных случаях тестирования, исходя из своей практики, мы рекомендуем использовать как минимальную скорость 32768 бит/c, чтобы купировать возможные всплески потерь.

Условие применимости 5 алгоритма 1

B[s] не должна превышать физические скорости интерфейсов аппаратной платформы

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

cc: net-probe, lj, vk, telegram: 1,2,3,4,5,6,7,8,9, zen, AT

Далее...