Ранее...

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

Начнём с обсуждения, каким протоколом следует пользоваться для расчёта метрик. Для этого вспомним нашу сверхзадачу — дать экономически обоснованный путь для отслеживания качества на сети. Она может быть выполнена только при использовании широко распространённых протоколов, то есть TCP, UDP, ICMP. Экзотические способы можно, конечно, рассматривать, ведь тот же UDP-lite уже давно существует, вот только их широкое внедрение будет либо затруднено, либо мы попадём в ловушку одного-двух производителей, а это явно то, чего хочется любому оператору связи в последнюю очередь.

Далее докажем, что для создания теста наиболее рационально использовать прикладное ПО, а не системное. Многие производители настойчиво рекомендуют путь соединения с ядром ОС с разной аргументацией, но отнюдь не мы. Итак:

1. Реализация в виде модуля ОС сразу ограничивает нас только определёнными аппаратными платформами. Так как универсальная системная разработка под несколько ОС будет стоить дорого, как при заказе сторонней организации, так и внутри. Неразумно тратить бюджет, там где можно его сэкономить.

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

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

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

Исходя из всех перечисленных причин мы и полагаем, что использование обычного прикладного ПО (даже простого ping!) вместо системного – это не только разумный, но и эффективный способ для проверки качества сети TCP/IP.

Теперь обсудим протоколы. Очевидно. что TCP для процесса расчёта метрик подходит слабо, ведь он скрывает для пользовательского ПО потери. Собственно, для этого его и придумали. Однако нам требуется, чтобы проблемы на сети отражались на доставке пакетов. Поэтому TCP – неверный выбор.

Как насчёт ICMP? Ведь он, собственно, для этого и предназначен, как кажется? Да и какой протокол внутри ping? Однако, на прикладном уровне (впрочем, на системном тоже!) вновь возникает проблема мультиплексирования потоков при одновременной посылке и приёме пакетов, упомянутая выше. Это заставляет обрабатывать некоторое количество «мусорных» пакетов, которые изначально не предназначались данному сокету. Что увеличивает нагрузку на процессор без особой пользы. Так что, минус всё-таки есть.

В противовес TCP и ICMP у протокола UDP – одни достоинства. И все ошибки передаются на пользовательский уровень. И мультиплексирование работает отлично. Прямо на уровне ядра ОС. Да и большинство приложений использует UDP, что дополнительно позволит проверять доступность пропуска трафика того или иного вида по сети. Поэтому его мы и рекомендуем.

Итак, формулируем итог.

Требование 1.

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

1. Это постоянная нагрузка на сеть, что не разумно. Ведь у нас сеть с коммутацией пакетов, а мы пытаемся превратить её в сеть с коммутацией каналов!

2. В BER-решении нет гибкости, так как полносвязное тестирование между всеми точками сети создать на практике нереально. А ведь именно к этому и подталкивает постоянность тестирования.

3. Начальная инициация соединения и его завершение для любого вида протокола сами по себе хорошо моделируют поведение пользователя в отличие от постоянного пропуска искусственного трафика. А служба эксплуатации работает именно для пользователя.

4. В случае регулярного пропуска мы теряем гибкость настроек, особенно P_s , B_s , C_s , которые придётся фиксировать на длительный срок. Это опять-таки усложняет жизнь.

5. Простой алгоритм 1 на приёме усложнится. Нам кажется, лучше выбирать разумные и простые решения, чем пытаться объять необъятное.

Исходя из всего вышеперечисленного, вводим определение.

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

время ожидания запуска очередного теста.

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

Требование 2.

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

Нижняя граница частоты запуска теста, исходя из того, что писалось в разделе 1.4, на наш взгляд не должна быть меньше 60 секунд, а верхняя не должна превышать одного часа, так как за это время, как показывают личные наблюдения, средний пользователь способен прорваться через три уровня первичной поддержки до реальной службы эксплуатации с сообщением: «проснитесь, у вас сеть упала».

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

В левой колонке указаны либо протоколы общего назначения, либо конкретные, предназначенные для пропуска голосового трафика.

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

В третьей — размер полезной информации в пакете UDP/ICMP. Так как именно это определяет характер трафика пользователя.

В четвёртой колонке указано рекомендованное нами число пакетов для данных B_s и P_s , вычисленное по выше указанным условиям с тем, чтобы тест продлился 30 секунд. Этот период — разумный компромисс между полнотой сбора данных и тестовой нагрузкой на сеть.

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

В шестой указано вычисленное по формуле из раздела 1.4 время тестирования. Не забывайте, что T_test задаёт время работы генератора, а реальное время приёма T_r или T_p будут отличаться от него, как правило в сторону роста, в зависимости от поведения сети!

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

Таблица 1.

Информации вышло много, поэтому откроем пресс-конференцию.

В: «Почему некоторые строки подсвечены серым?» - спрашивает нас неравнодушный читатель.

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

В: «Почему все настройки у кодеков VoIP такие похожие?»

О: Да потому что там как раз важен параметр IPI_s , он один и тот же, ведь фактически это шаг квантования в АЦП, а скорость в данном случае является вычисляемым параметром.

И раз уж здесь зашёл разговор про межпакетный интервал, сразу скажем, почему мы его так не любим (см. раздел 1.4). Дело в удобстве эксплуатанта. Известные производители сетевых устройств из одной солнечной области одной далёкой страны хотя в целом и неплохи для сетевых задач, но вот вместо указания скорости на своих патентованных решениях проверки качества предпочитают межпакетный интервал. Причины очевидны — встроенной в аппарат ОС проще получить от конфигуратора сразу готовый параметр, чем его пересчитывать, что хорошо описывается русской пословицей «Лень раньше меня родилась». Но вот посмотрите на таблицу 1. Там заметно, что как только меняется P_s , то на той же скорости нам необходимо пересчитать IPI_s (за исключением случаев пропуска VoIP-трафика). Удобно ли это администратору? Нет, потому что пользователь сети закупил пропускную способность и, коль скоро мы проверяем качество сети как единого целого, то и исходным параметром у нас должна быть скорость, а не загадочный межпакетный интервал. Как только мы хотим проверить, доступно ли 10% от заказанной пропускной способности, нам достаточно умножить заказанное на 0.1 (ну или разделить на 10, если вам так удобнее) и получить правильный B_s . А сколько расчётов нужно сделать, чтобы получить правильный IPI_s ? А если сменился P_s , это получается надо менять два параметра вместо одного? Вот так номер! Робот должен выполнять человеческие указания строго по Азимову, а человеку должно быть удобно — вот наш принцип. А не наоборот! Впрочем, памятуя, что в жизни ситуации могут быть разные, и если вам досталась в наследство сеть с подобными устройствами, глупо их не использовать, ведь капитальные затраты уже понесены. Для таких случаев мы приводим поле IPI_s , чтобы в случае необходимости вы могли взять готовое значение, не проводя дополнительных расчётов.

В: «Почему в размерах пакетов вы не следуете рекомендациям RFC-2544?»

О: Вопрос правильный, но ответ простым быть не может. Всё дело в том, что мы, в отличие от авторов стандартов, всегда шли от практики. «Теория без практики —-мертва!» - так ведь говорили до нас и будут ещё долго говорить после нас. Поэтому пользуясь случаем подвергнем сомнению догмы стандартов, как и положено прилежным связистам с высшим образованием. Сразу опустим мнение авторов RFC-2544 о Token Ring, мы его в России вживую так и не увидели, и опустим почивший FDDI. Остаётся вечно живой, как один политический деятель, Ethernet.

Заметим, что в указанном тексте написано английским по белому ”frame sizes”, а значит речь идёт о полной длине на втором уровне, а не о размере поля данных. Поэтому, 64 на уровне IP-протокола превращается в 46, а 1518 в 1500. Не забываем, что P_s мы указываем как полезную нагрузку UDP-пакета (см. раздел 1.4). Следовательно, 46 превращается, как те знаменитые брюки, для IPv4 в 18, а 1500 в 1472. Что же касается IPv6, то внезапно выясняется, что 64-байтовый Ethernet frame никак не может поместить даже заголовок IPv6-пакета, включающего UDP. «Удар состоялся, заседание продолжается» - как говорил сын турецко-подданного. В общем, пора брать власть и командовать парадом, не обращая внимания на дутые авторитеты. Какой вообще минимально необходим пакет данных? Проанализировав несколько протоколов контроля качества, как документированных, так и зачем-то патентованных, мы честно скажем — без наличия как минимум 16 байт полезной нагрузки у вас не получиться разумно измерить даже статистические величины! А лучше 20. А ещё лучше 40. Потому что в этом случае в полезную нагрузку помещаются почти все протоколы. Ну и дополнительным аргументом будет фраза из RFC-791, посвящённая минимально необходимому размеру IP-пакета без фрагментации. Там указано число 68, что на уровне UDP равно 40. Отличный выбор! На уровне Ethernet это будет 86 байт для IPv4 и 106 для IPv6 нагрузки внутри пакета. Не забыли, что свежие адресные типы тоже крайне желательны к поддержке? Мы помним, а авторы «стандарта» об этом забыли. И после этого многие продолжают ставить ЭТО в пример и техзадание? Да вы смеётесь!

Идём дальше. 128 (на уровне UDP – 82 и 62) имеет только теоретический смысл для сугубо специфических протоколов, если вам хочется, то можете по формулам сами всё рассчитать, а для 256 (на уровне UDP – 210 и 190) мы хотя и привели значения, но не рекомендуем к постоянному использованию.

Теперь про 512 (на уровне UDP 466 и 446). Такой трафик у пользователей возникать может, поэтому для варианта адресации IPv6 мы его и указываем. Что же касается IPv4, то большого смысла проверять фреймы именно 512 байт за пределами лаборатории нет, так как доблестные писатели стандартов пропустили существенно более важный близкий размер – 576 байт пакета IP (фрейм Ethernet 594, UDP размер 548). Такой пакет должны обрабатывать все устройства IPv4 по RFC-791, так как это своего рода MTU последней надежды. и поэтому его как раз следует тестировать время от времени на реальной сети, а вот 512 нужно оставить для студенческих изысканий в лабораторных работах.

Наиболее любопытный вопрос касается фреймов размером 1024 и 1280. Во-первых, мы не видим смысла тестировать трафик и тем и другим. Так как размеры близки, реальные проблемы с прохождением трафика только определённого размера (далёкого от стандартного максимального MTU!) из этих двух могут возникать разве что в специально созданных выделенных средах тестирования. Во-вторых, фрейм размером 1280 выбран авторами RFC-2544 строго по русской пословице «слышал звон, да не знает где он». Потому что в реальности это явный аналог минимального необходимого MTU для IP-протокола стандарта v6! А не размер Ethernet-фрейма! Который должен в этом случае равняться 1298 (на уровне UDP 1232) конечно же. Но, это прошло мимо внимания писателей и читателей, не говоря уже про переводчиков, поэтому нам приходится взваливать на свои плечи нелёгкую ношу разъяснений с аргументацией. Что же касается стандарта IPv4, то мы не видим большого смысла проверять фрейм 1280, поэтому выбрали 1024 (на уровне UDP 978). Теперь читатель-друг понимает, что стандарты нужны не для того, чтобы им слепо следовать, как рекомендуют директора по маркетингу, близкие к деньгам, но далёкие от науки, а для того, чтобы их модифицировать под реальную жизнь. Вы всё ещё поклоняетесь RFC-2544? Добро пожаловать в ад критики. En guarde!

Ну а пакет максимального для стандартного Ethernet размера 1518 (на уровне UDP 1472 и 1452) мы, разумеется, включаем в таблицу 1 без вопросов. Более того, рекомендуем его использовать регулярно.

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

В: «Ну ладно, список размеров понятен и аргументация разумна. Но в реальной сети неужели надо, чтобы все размеры использовались для постоянного тестирования да ещё и по всей сети?»

О: Правильный вопрос. А правильный ответ мы сформулируем в виде двух требований:

Требование 3.

Требование 4.

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

Требование 5.

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

Итак, требования 1-5 достаточно полно описывают рекомендуемые нами настройки тестов для получения метрик качества. Теперь займёмся выбором протоколов тестирования. Для этого нам придётся определить, что нам нужно рассчитать в первую очередь, а что может и подождать.

сс: lj, telegraph, vk, telegram: 1,2, zen, AT, MMM

Далее...