Ранее...

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

Поскольку сети у нас TCP/IP, то первыми следует использовать наработки «Инженерного совета Интернета», более известного в широких кругах под английской аббревиатурой IETF. То есть, нас ожидает реестр, созданный в RFC-8912. Надо сразу заметить наперёд, что в данном случае и вообще во всём разделе мы будем просто коллекционировать метрики, не конкретизируя подробностей их получения и тем более алгоритмы. Потому что нас интересует значимость, а как правильно считать и почему это надо делать именно так, мы уже выяснили выше.

Итак, что же вообще предлагает исследовать RFC-8912? Запишем в таблицу для наглядности.

Таблица 2.

К сожалению, авторы RFC-8912 не сделали выбора, что же следует исполнять в первую очередь, а что может и подождать до лучших времён. Сразу отметём метрики для TCP и DNS, как очевидно наведённые, когда будет время, рассмотрим и это. А пока заметим, что все параметры со страшными названиями, отпугивающими сами собой даже подготовленных людей, в сущности сводятся к потерям, задержкам и, по большим праздникам, дрожанию задержки. Запомним.

И поскольку не только "Инженерный совет Интернета", но и Международный союз электросвязи подумал за нас, хотя и не столь интенсивно, изучим ещё и стандарты класса Y.15xx.

Таблица 3.

Здесь, по сравнению с предыдущим случаем, ситуация с выбором приоритетов уже лучше. Дело в том, что в связанном стандарте Y.1541 определяются требования к метрикам качества для отражения доступности сети в целом. И они после приведения к текущим, уже знакомым нам размерностям выглядят как неравенства:

Класс 0 (голос, видео)
Класс 1 (голос, видео через спутник)
Класс 2 (сигнализация, интерактив)
Класс 3 (транзакции, несрочный интерактив)
Класс 4 (средняя срочность, видеопоток)
Класс 5 (обычный поток)

Несложно видеть, что основные метрики вновь сводятся к потерям, задержкам и, для особо срочных данных, дрожанию задержки. Запишем второй раз. На сами же цифры в данный момент не стоит обращать внимания, мы этим ещё займёмся. Festina lente.

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

Таблица 4.

В итоге можно сказать, что министерство строго по стандартам МСЭ регламентировало к контролю оператором потери, задержки, для особо срочных данных, дрожание задержки, и добавило к ним пропускную способность. Запишем третий раз. Не пропадать же добру, раз его создавали!

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

1. Реализации RFC-2544.

Тут всё строго, читаем методику и видим: Throughput, Latency, Frame loss rate. Опустим то, что на самом деле все эти параметры означают совсем не то, что нам нужно. Критика у нас будет ниже. Пока фиксируем: пропускная способность, задержки, потери.

2. vendor lock.

Здесь мы объединим сразу трёх известных производителей оборудования и ПО, чтобы три раза не вставать.

Первый, со штаб-квартирой во граде святого Иосифа Гваделупского, предлагает рассчитывать метрики, приведённые на рисунке 17. А само это предприятие будем в дальнейшем в целях конспирации именовать V1. Вначале, честно говоря, мы хотели именовать его правильной русской буквой "Ы", чтобы никто не догадался, отдав тем самым дань уважения большому русскому режиссёру, но, подумав, решили уменьшить чад кутежа в книге до более разумных пределов.

Рисунок 17. Метрики производителя сетевого оборудования №1.

Второй, со штаб-квартирой в небольшом солнечном доле, рекомендует несколько иное, приведённое на рисунке 18. Ему мы дадим гордое имя V2.

Рисунок 18. Метрики производителя сетевого оборудования №2.

Ну а третий, со штаб-квартирой во граде королевы в государстве президента, рекомендует вообще самый простой набор, приведённый на рисунке 19, за который, не побоимся этих слов, должно быть стыдно! Впрочем, критика критической критики ещё предстоит. Ну а имя V3 будем применять для ссылки (в Сибирь. Убирать снег. Весь!).

Рисунок 19. Метрики производителя сетевого оборудования №3.

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

3. iperf3.

Неплохая утилита со свободным исходным кодом, изначально предназначенная для замера BW_r и BW_p, а теперь умеющая вдобавок посчитать LR_r, LR_p, OR_r, OR_p, APDV_p (неясно по верному ли алгоритму!) и ARTT. В блокнотик идёт новая запись.

4. ping.

Программа эта настолько широко знакома пользователям, что кажется, про неё всё известно. Однако, авторам приходилось встречать необычные обвязки вокруг этой простой утилиты. Обычно ping умеет выдавать готовый результат только в виде LR_p и ARTT. Однако, с помощью дополнительных несложных действий, которые мы оставим уважаемым читателям в качестве домашнего задания, он начинает уметь подсчитывать и RDV_p, APDV_p и AMDV_p. Отметим и это на память.

5. bwping.

Улучшенный ping, в который уже можно передать параметр B_s , что, конечно же, следовало сделать ещё в оригинальном коде. Выдаёт готовый результат в виде LR_p и ARTT и BW_p. Несложным дописыванием вы самостоятельно можете реализовать RDV_p, APDV_p и AMDV_p. Полезно, пора записать.

6. Реализации RFC-5357 (TWAMP).

Хороший стандарт, которым производители попытались закрыть нишу единства технологий. Не без недостатков на наш скромный взгляд, однако попытка очень и очень достойная внимания. Многие производители коммутаторов и маршрутизаторов внедрили этот стандарт в своё оборудование, что позволяет его использовать в качестве как агента-инициатора, так и сопряжённого (отзывающегося на запросы). Мы видели не меньше четырёх разных видов реализации. Поэтому опишем максимально подробно, что умеет данный протокол. Все реализации умеют рассчитывать LR_r, LR_p, ARTT, AD_r, AD_p и OR_p . Многие умеют вдобавок APDV_p и APDV_r . Некоторые умеют RR_p , BW_p , SR_p , LBW_p , RDV_p , RDV_r , AMDV_p , AMDV_r . Мы же говорили — стандарт вполне неплохо продуман. Запишем не только список, но и имя TWAMP на память!

7. Реализации RFC-4656 (OWAMP).

Первая версия предыдущего стандарта, которая не нашла столь же широкого применения. О причинах мы не судим, оставим их другим, просто подсчитаем, какие метрики OWAMP поддерживает, а какие несложны в реализации с его помощью. Безусловно, всякая реализация должна суметь подсчитать LR_r , AD_r и OR_r . А самые лучшие должны также суметь увидеть и RR_r , BW_r , SR_r , LBW_r , RDV_r , APDV_r и AMDV_r . Фиксируем это на твёрдый бумажный носитель.

Ох, что-то переполнился уже блокнот, "ещё немного и рванёт", нельзя ли сделать нагляднее? Можно. И нужно! Мы любим таблицы и любим наглядность.

Таблица 5.

Уф, «орешек знанья твёрд, но всё же, мы не привыкли отступать». Так что, раскололи. Формулируем итог в виде требований к поддержке метрик качества прикладным ПО для тестирования сети TCP/IP.

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

Метрики, таким образом, мы исчерпали, и начинаем черпать яства из посуды на протокольной кухне.

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

Далее...