Ранее...

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

Начнём с малого:

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

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

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

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

Очень хорошо данная метрика может быть показана на рисунке!

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

где

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

Канальное оборудование на сети оператора связи, в котором производится изменение порядка следования пакетов

Событие переставляющее жёлтый пакет со своего места

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

Посмотрим внимательно на рисунок 11, зафиксируем, что N_ro равно 1, а N_r равно 4, и получим OR_r равным 25%. Теперь обговорим подробности.

Средняя программа, использующая стек TCP/IP, как это не покажется удивительным, обычно ожидает, что первый пакет придёт первым, второй — вторым, и так далее. Бывает иначе, но это редкость. Ну и в самом деле, если вы говорите в трубку: «Алё, привет, ты где?», то ожидаете, что собеседник услышит это в нужном порядке. Так же и в программах. Но когда пакет ушёл в сеть, он уже не имеет информации ни о своём номере, ни о номере соседа. Умные транзитные P‑устройства стараются более‑менее сохранять порядок, например, используя так называемую технологию flow switching. Но, вообще говоря, делать этого не обязаны. Не будем далеко погружаться в тему, она любопытна, но не в разделе определений. Скажем здесь, что отслеживание процента нарушения очерёдности на ядре сети является на наш взгляд хорошим тоном правильного, кошерного оператора связи. Поэтому нормальным значением OR_r является 0%.

Теперь более нетривиальное:

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

число пакетов теста, успешно принятых на стороне приёма за время Tr, доставленных с минимально возможным полем TTL (Hop Limit)

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

процент пакетов в тесте, доставленных со значительным сдвигом в пути следования (процент сдвига пути)

Здесь вообще без иллюстрации будет трудно. А мы стремимся быть понятыми.

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

где

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

Канальное оборудование на сети оператора связи, в котором производится изменение путей следования пакетов

Доставка красного и зелёного пакетов по пути с одним транзитом

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

«Это что такое? И зачем?» - спросит наш уважаемый читатель. Немного предыстории. Один наш хороший друг работал в одном большом операторе связи. В середине сеть была построена почти так же, как автоматическая камера хранения на вокзале современного Кёльна: вы видите только терминал для приёма и передачи, а куда и как поехал ваш чемодан является тайной, покрытой мраком. Роботизация настигла их сети по программе‑максимум. В результате одинокий traceroute, проводимый в целях диагностики пути следования пакетов, сегодня ходил в Тацинскую, завтра в Сарепту, а послезавтра в Шексну. Это чертовски усложняло поиск неисправностей в ядре. Потому что производитель роботизированного оборудования, как несложно догадаться, в первую очередь думал о пропуске трафика, ну и об активных продажах, как же без этого, а вот про диагностику подумал только «опосля», как сказал бы наш хороший друг. В результате только так называемый «метод» полного перебора каждого из портов приводил к нахождению проблемного порта или канала. Требовалась некоторая автоматизация.

Мы подумали, что при прохождении трафика по ядру, если у вас не установлен TTL propagation, можно вычислить сколько пакетов в тесте прошло большее количество транзитных устройств, чем могло бы. Разумеется, при равенстве точек, пусть даже и разных, такую информацию не получить. Но при развитой сети вполне возможна ситуация, когда дешевле и быстрее пропустить трафик через два‑три транзита, чем через один, но уже перегруженный канал. На это и строится расчёт.

Метрика новая, ещё нигде не стандартизированная, но уже опробованная. На наш скромный взгляд, она достойна пристального внимания. Возможно, мы немного самонадеянны, но нам пока так не кажется. Широкое распространение SDN может породить высокий интерес к этому нашему изобретению. К дискуссии же мы всегда готовы. Ну и нельзя не отметить, что на рисунке 12 значение N_rl получается 2, значение N_r равно 4, соответственно SR_r получается 50%. Нормальным же значением мы полагаем 0%.

А вот вновь относительно простое и ясное понятие:

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

процент потерянной полосы пропускания при приёме теста (потерянная скорость)

Здесь иллюстрация та же, что и на рисунке 9, поэтому перейдём сразу к объяснениям.

Скорость можно измерять по‑разному. Можно в битах в секунду, можно в процентах от ожидаемой. А можно, как здесь — в процентах от так называемой «потерянной». Если обычная скорость чем больше, чем лучше и, заметим, дороже, то в этой метрике всё наоборот. Чем выше процент — тем хуже. А когда потерянная скорость достигает 95%, можно сказать, что оператора пора менять. Вы ведь не из такого оператора, правда?

Зачем это выворачивание наизнанку? Секрет прост — в системах мониторинга, за которые в итоге мы ратуем, может быть разный подход к фиксации проблем. Кто-то использует неравенства вида N_r>100 и раскраску «плохо» и «хорошо». Это хотя и просто, но не позволяет видеть гибкой градации. А кто-то использует набор порогов для «зелёных», «жёлтых», «красных» и «ужасных» событий, а к ним простое правило — чем больше параметр, тем хуже. Потери, задержки, процент перекраски, процент сдвига и процент беспорядка — всё растёт. Иногда — как на дрожжах. И только скорость стоит особняком. Чем она меньше, тем хуже и хуже, а когда она становится равной 2400 бит/с, можно начинать искать на антресолях старенький USR Courier и вспоминать, как правильно настраивается Bink/+ и BiP. Поэтому заведение потерянной скорости как хотя и наведённой, но разумной метрики, весьма душеспасительно при дальнейшем внедрении систем мониторинга. Так как она тоже, чем больше тем хуже. Это даёт нужную гибкость и в то же время не ограничивает от простых решений.

И последнее. Метрики, про которые многие слышали, и даже министерство, вслед за международными организациями, пытается их нормировать, но пока ещё на реальных, а не лабораторных сетях — не в коня корм. Дрожание. Обло, озорно, огромно, стозевно и лаяй. Все знают, никто не понимает. Итак:

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

дрожание задержки доставки пакетов от стороны генератора до стороны назначения, измеренное за время Tr по алгоритму RFC-3550

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

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

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

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

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

среднее арифметическое дрожания задержки доставки пакетов от стороны генератора до стороны приёма, измеренное за время Tr по алгоритму Y.1540 с использованием в качестве базиса минимальной задержки

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

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

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

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

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

среднее арифметическое дрожания задержки доставки пакетов от стороны генератора до стороны приёма, измеренное за время Tr по алгоритму G.1020

Что нам тут хочется сказать? Пока не будем растекаться мысью по древу. Любопытные подробности будут позже. Пройдёмся и по алгоритмам расчёта дрожания и по их авторам. Где-то паровым катком, а где-то — просто пожав плечами. Не волнуйтесь, всё будет. Пока примите как данность, потому что пора следовать дальше. Нас ждут трудности. А мы их и не боимся.

cc: lj, telegraph, vk, telegram: 1,2,3,4,5,6,7,8, zen, AT, MMM

Далее...