1.5. Приём искусственного трафика
Очевидно, что все метрики качества на сети TCP/IP по итогам теста могут быть вычислены только после приёма пакетов, созданных на стороне передачи. Так же ясно, что время ожидания на приёме должно быть конечно, чтобы была возможность подвести итоги и создать возможные реакции. Сразу заметим, что в дальнейшем мы неявно предполагаем, что часы на обоих устройствах, занимающихся обработкой теста. должны быть синхронизированы. Это удобно для точности определений, хотя строго говоря, для расчёта большинства метрик качества необязательно.
Определение 20.
Определение 21.
Следующие два определения ссылаются друг на друга, поэтому мы их вводим рядом, для лучшего понимания.
Определение 22.
Определение 23.
«Почему так сложно? У нас тут что — кружок любителей математики?» - спросит пытливый читатель. Не станем делать секрета, ведь мы ценим пытливого читателя. Одной из основных особенностей сети TCP/IP является асинхронный характер трафика. Программа‑инициатор создаёт пакет в произвольный момент времени, и вообще говоря, мы ничего не знаем про то, в какой именно момент. Это же относится и к тестовому трафику, да‑да‑да! Даже на транзитных P‑устройствах эта особенность сохраняется. Таким образом, на приёме с одной стороны, необходимо получить все пакеты теста, с другой стороны, не все пакеты могут быть доставлены. Вы ведь помните про потери? При этом полный период тестирования T[test] использовать нельзя, так как он определён на стороне инициатора, а для приёмной он может и будет зависеть от реального состояния сети. При наличии буферизации период приёма может даже уменьшиться! А если первый пакет теста не будет доставлен, то ориентироваться на кажущийся на первый взгляд очевидным финальный временной порог ожидания всех пакетов T2[i]+T[test] тоже никак нельзя. При пропуске же заметного числа пакетов в середине тестовой последовательности искусственного трафика, ситуация только ухудшается.
Поэтому наиболее практичным подходом для служб эксплуатации будет следующий алгоритм 1, который весьма прост в реализации и при достаточном количестве пакетов в тесте позволяет получать корректные статистические величины. Если же у читателя есть своё мнение, мы приглашаем его к дискуссии, к которой всегда готовы. Итак:
Алгоритм 1.
- На очередном шаге ждём не более T[max]
- Если пакет не пришёл, остальные возможные пакеты считаются недоставленными. Переход на шаг 6.
- Иначе рассчитываем метрики качества.
- Если число принятых пакетов стало равно N[s], все пакеты теста доставлены, переходим на шаг 6.
- Иначе возвращаемся на шаг 1.
- Останов.
Несложно видеть, что T[r] с помощью алгоритма 1 легко получается именно в форме определения 23. И также несложно видеть, что у алгоритма есть важные условия применимости. Как в теории дифференциальных уравнений в задаче необходимы граничные условия, так и в теории расчёта метрик качества сетей TCP/IP нужно чётко понимать, где заканчиваются границы корректности даже у статистических величин.
Условие применимости 1.
С[s] класс сервиса TOS/DSCP за всё время работы теста на стороне инициатора не меняется
Это вполне логичное требование. Ведь мы собираемся тестировать трафик разного вида. Пользователь, используя приложения, критичные к задержкам, вправе использовать нужные метки пакетов (конечно, если он закупил у оператора связи соответствующий сервис). Поэтому, проверяя как готовность сети, так и возможные узкие места на всём транзите, мы должны метить и тестовый трафик правильным образом. И уж, конечно, выбранный класс нужно использовать всё время тестирования. Если же хочется полной картины для всех классов, то следует всего лишь провести несколько тестов в каждом требуемом классе.
Условие применимости 2.
P[s] размер пакета за всё время работы теста на стороне инициатора не меняется
Это условие уже не такое очевидное. Многочисленные отраслевые стандарты (например, RFC-2544) обычно рекомендуют для теста использовать пакеты разных размеров, мотивируя это тем, что пользовательский трафик различен и, дескать, результат должен показывать сразу всю картину. Не отрицая факта различия размеров в пользовательском трафике, мы тем не менее готовы задать встречные вопросы:
Если пропускать трафик с разными размерами пакетов в одном потоке, то мы получим общие метрики, а как тогда отделять случаи потерь пакетов определённого размера, что достаточно часто встречается на практике?
А если рассчитывать метрики для каждого размера пакетов отдельно, то чем этот случай отличается от нескольких потоков с фиксированным размером в течение всего теста?
Кроме того, не забываем, что в стандарте RFC-6815 впрямую рекомендуется применять RFC-2544 только в отделённой среде тестирования (Isolated Test Environment), поэтому в службах эксплуатации рабочих сетей мы бы рассматривали RFC-2544 как хотя и полезный, но не строгий, а более факультативный.
Резюмируя и памятуя предыдущее условие применимости 1, можно сказать, что практической полезностью обладает именно фиксация размера пакета на всё время теста. Если же хочется полной картины для всех размеров, то следует всего лишь провести несколько тестов с каждый требуемым размером.
Условие применимости 3.
N[s]>=200 число пакетов в тесте должно быть достаточным для расчёта метрик с нужной точностью
Наш коллега‑читатель уже догадывается, что мы скажем. Процент потерь пакетов от точки создания трафика до точки приёма имеет в знаменателе число пакетов в тесте (см. ниже определение 24). Поэтому чем больше пакетов пропущено, тем точнее будет эта метрика. Что же касается остальных, то число пакетов для них тоже имеет значение, поэтому не стоит тестировать качество слишком незначительным числом пакетов.
Кроме того, для тех работников операторов, которые предпочитают не число пакетов в качестве первичного параметра, а время тестирования, приведём формулу вычисления N[s] по остальным параметрам:
Проверим корректность типовыми настройками генератора. Воспользуемся знакомыми терминами.
При пропуске трафика IP‑телефонии с использованием кодека G.729 скорость для адресации IPv4будет 24 килобита/с, размер пакета 32 байта, время тестирования выберем в 20 секунд. Число пакетов получается 1024. Более чем достаточно для достойной точности.
При пропуске трафика IP‑телефонии с использованием кодека G.711 скорость для адресации IPv4будет 79 килобит/с, размер пакета 172 байта, время тестирования выберем в 20 секунд. Число пакетов получается 1011. Тоже вполне достаточно.
Условие применимости 4.
скорость генерации теста должна быть такой, чтобы двойной межпакетный интервал не превышал T[max].
Вот тут потребуются более подробные разъяснения. Когда мы собираемся получать тестовый трафик даже при большом числе потерь в сети, нам потребуется, чтобы периоды ожидания в процессе приёма были конечны и не превышали T[max]. Этого можно добиться, если поставить достаточно большую скорость передачи. В предположении, что на сети может быть 50 процентов потерь пакетов (в реальности это очень плохо, сеть близка к гибели) мы должны создавать трафик более быстро, чем он будет теряться, чтобы алгоритм 1на приёме успел получить хотя бы часть тестового трафика.
Проверим разумность формулы. Воспользуемся уже знакомыми параметрами. 32 байта кодека G.729 при рекомендованном времени ожидания 3 секунды дают минимально нужную скорость в 320 бит/с. Разумный минимальный выбор, реальность (см. выше условие применимости 3) быстрее более чем в 70 раз.
Проверим иначе. Возьмём произвольный протокол с размером пакета 1472, а время ожидания оставим тем же. Получаем 8000 бит/с минимально необходимой скорости. Это 1,5 секунды межпакетного интервала. То есть при потере двух пакетов подряд (вполне реальный случай) алгоритм завершится заранее. Что приведёт к недостаточной точности итоговых статистических величин. Видим, что условие применимости 4абсолютно разумно. В реальных случаях тестирования, исходя из своей практики, мы рекомендуем использовать как минимальную скорость 32768 бит/c, чтобы купировать возможные всплески потерь.
Условие применимости 5.
B[s] не должна превышать физические скорости интерфейсов аппаратной платформы
Это простое и разумное требование. Предлагаем читателю доказать его необходимость самостоятельно. А мы, после длительной подготовки, наконец начнём определять метрики качества.
сс: net-probe, telegraph, vk, telegram: 1,2,3,4,5,6,7,8,9, lj
Далее...
