Топология сети и расчет пропускной способности

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

Видео через IP: исследование темы

NORM SLATER

Harris Corporation, Broadcast Communications

Division

Mason, Ohio

JAMES WELCH

IneoQuest Technologies, Inc.

Mansfield, Massachusetts

КРАТКИЙ ОБЗОР

Как и все коммерческие организации , вещатели и провайдеры находятся в постоянном поиске новых и эффективных технологических решений для увеличения статей своего дохода. Рост технического прогресса покровительствует всё большему вовлечению компьютерных систем в производство и передачу видео сигнала, увеличивая повсеместное развёртывание систем общего пользования типа Ethernet. Пока ещё основная часть передач видео материалов по сети осуществляется не в режиме реального времени, но уже остро встаёт необходимость и в «живых» трансляциях через Ethernet . Сможет ли Ethernet стать жизнеспособной альтернативой приватным сетям ?

Данная статья рассматривает коммерческое развёртывание системы Видео через IP для «живых» вещательных приложений типа 24/7. Сетевая видео технология использует стандарт RFC и основывается на стандартных сервисах Ethernet /IP. Эффект предупреждающей коррекции ошибок (Forward Error Correction FEC) и размера кадров в сравнении с сетевыми показателями будет рассмотрен далее. В дополнение, будет представлена новая методика тестирования , которая предназначена для более наглядного контроля за активностью IP сети.

ПОДОПЛЁКА

В вещательной и профессиональной видеоиндустрии существует множество стандартов, которые определяют какой сигнал хороший, а какой плохой. Шум, искажения, дифференциальные усиления и другие аномалии влияют на аналоговое видео. Цифровое видео не подвержено этим факторам, но тоже, не имеет полного иммунитета от проблем с сигналом. Исключая предсказуемые потери сигнала, связанные с затуханием, вещательные инженеры уверены, что подав один сигнал в хороший кабель, на его выходе они получат уже нечто другое. При сетевой же передачи материала, пакеты вошедшие в кабель могут затеряться по пути следования. Чем больше пакетов потеряно, тем хуже качество декодированного изображения. При просмотре полученного изображения можно увидеть : разбиение части изображения на блоки, заморозки кадров, пропуск кадров и другие неприятные вещи. Основанная на пакетном принципе передачи , сеть Ethernet, изначально не предусматривала «живое» видео, предлагая взамен передачу огромного количество данных по возможности без прерывания.

Идея передачи «в реальном времени » не была частью плана, так как данные не обязаны были передаваться именно в этом значении этой фразы. Ethernet пакеты передаются последовательно через сетевые устройства : рутеры и свитчеры. Неминуемо то, что много пакетов прибудут в какую-то точку сети одновременно , что повлечёт пропадание одного или нескольких пакетов. Для передачи в не-реальном режиме , характерно то, что потерянные пакеты можно допередать после. Что же касается случая с реальным способом передачи , то дополнительная передача утерянных пакетов не является оправданной, и они не успеют передаться к моменту, когда уже будут необходимы для отображения на дисплее. Схемы коррекции , такие как FEC, позволяют реконструировать утерянные пакеты без необходимости в их дополнительной передачи, но весьма накладны, ввиду использования дополнительной мощности в полосе пропускания. Передача по принципу в реальном времени сталкивается в последнее время с растущей проблемой излишнего пакетирования данных. Как только выходные буферы передатчиков наполняется до критических отметок, то они вынуждены уменьшать интервал между пакетами, что бы скорее слить, то чем они наполнены, что приводит к огромным выбросам пакетов в сеть, а это в свою очередь влечёт нестабильность временных параметров самих пакетов, что обозначается словом jitter (Джиттер)...........................

Читать полностью .......

Основная методика паспортизации пакетных сетей дается в рекомендации RFC-2544, которая определяет следующие параметры качества:

- пропускная способность (Throughput);

- задержка (Latency);

- девиация задержки, она же пакетный джиттер (Latency Distribution);

- количество потерянных пакетов (Frame Loss);

- количество пакетов с ошибками (Frame Error).

Даже с первого взгляда видно, что именно эти параметры являются образующими для фактора качества MDI. Следовательно, можно успокоиться: даже если производители не вдруг реализуют встроенные средства контроля качества услуг по MDI, простой алгоритм пересчета позволит использовать параметры паспортизации для квалификации уровня качества услуг. Логика здесь простая: если на транспортном уровне нет проблем, то и с услугами трудностей не возникнет. Логика, конечно, двухходовая, но довольно привлекательная.Но оказалось, что методика MDI далеко не так безупречна. Вмешался новый фактор – кодирование видеосигнала. Тот самый high-tech, который обусловил возникновение услуги IPTV, чрезвычайно запутал ситуацию в организации транспорта данных. Появившиеся методы компрессии видеоданных и кодирования привели к тому, что линейно установить связь между качеством услуг и качеством транспортной сети в случае IPTV в настоящее время невозможно. Самый простой пример – нелинейные искажения видеосигнала в результате адаптивного кодирования и компрессии.Объяснить неравномерность возникающих вследствие компрессии и кодирования нарушений качества в простых терминах MDI оказалось невозможно, так как сама логика кодирования и компрессии принципиально нелинейная.

Продолжение читайте в печатной версии журнала

IPTV со знаком качества

М. Вечерковский

20 марта 2008г.

Соглашение об уровне предоставляемых сервисов в IP сети (SLA) обычно выражается в определённых параметрах – Quality of Service, QoS. Это может быть полоса пропускания в мегабитах в секунду, временные задержки в миллисекундах, количество ошибочных, потерянных пакетов. Когда по сети в режиме реального времени передаётся аудио или видео, удобнее оперировать понятием «качества, исходя из опыта» – Quality of Experience, QoE. Это метод субъективный, свою оценку высказывают эксперты – в нашем случае, телезрители. QoE отражает степень удовлетворённости пользователей, их настроение. Вся проблема заключается в том, что об испортившемся настроении пользователей оператор обычно узнаёт слишком поздно – в лучшем случае, из гневных звонков в службу поддержки, а в худшем – по тому, как тает абонентская база, когда клиенты «голосуют ногами». QoE должно быть выражено в конкретных численных величинах и подвергаться постоянным измерениям.

Как измерять?

Можно выделись два основных подхода к измерениям QoE. Один из них предполагает, что если всё в порядке в сети, то всё будет хорошо и на телеэкране. Самый распространённый показатель – Media Delivery Index, MDI– включает в себя данные о потерянных и ошибочных пакетах, джиттере и задержках. Оценке подвергаются значения, полученные в произвольный короткий промежуток времени.

DF (Delay Factor) и MLR (Media Loss Rate) – ключевые параметры сети передачи, к которым чувствителен трафик реального времени. Потеря IP пакета, как правило, приводит к заметным искажениям на экране (например, провоцирует замирание кадра, ухудшает разрешение). 0,5% потерянных пакетов, скорее всего, уже будут различимы глазом, если же потери достигнут 5%, динамичные сцены будут настолько повреждены, что просмотр передачи придётся прекратить. Кроме того, потерянный пакет способен существенно увеличить время переключения канала. Вычисления MDI могут проводиться в режиме реального времени средствами протокола RTP (Real Time Protocol). Он предоставляет функциональность, позволяющую измерять джиттер и потери пакетов в заданные промежутки времени. Достоинства MDI – это относительная простота реализации, масштабируемость, независимость от методов кодирования трафика. Недостатки – непрямая зависимость индекса от фактического состояния «картинки» у клиента, исключение из поля зрения искажений, вносимых вне сети передачи (например, при кодировании, компрессии видеопотока).Итак, MDI контролирует состояние сети, по которой видео доставляется к пользователю.

Читать полностью....

К сожалению, в статье есть одна неточность. Правильный вариант опубликован здесь http://project.polyset.ru/projects/projects_main.php

Раздел документа называется, так же как и статья: «Топология сети и расчет пропускной способности».

Документ можно скачать в виде pdf файла размещенный справа на странице: «Методическое пособие по CCTV»

Алексей Степанович - для того что бы Вы сразу же не обиделись ;-)

- на Вашу статью я сразу же обратил внимание еще в бумажной версии "Алгоритма" и статья мне понравилась.

К сожалению, в статье есть одна неточность.

К сожалению в Вашей статье есть и другие "неточности":

1. Неточность методики расчета пропускной способности сети.

Это связано с тем что Вы исходите что сеть ИДЕАЛЬНА и не учитываете такие факторы как:

- количество потерянных пакетов (Frame Loss)

- количество пакетов с ошибками (Frame Error)

- задержка (Latency)

- девиация задержки, она же пакетный джиттер (Latency Distribution).

2. Ошибочно считать, что необходимый битрей сжатия (он же фактически необходимый трафик) - как-то повлияет на символьную скорость, а тем более на битовую скорость порта.

Битовая скорость порта на физическом уровне (зависящая только от символьной скорости) никак не зависит от битрейта камеры.

Скорость передачи на порту всегда неизменна и равна физической скорости работы порта и насколько бы не был ограничен трафик битрейтом сжатия - скорость прохождения пакетов будет определяться символьной скорости сегмента сети.

3. Объем трафика от множества АСИНХРОННО РАБОТАЮЩИХ КАМЕР - НЕЛИНЕЕН ВО ВРЕМЕНИ!

так как сама логика кодирования и компрессии принципиально нелинейная.

По этому, даже при исходящем трафике (битрейте) от каждой камеры равном 5-8 мб (т.е. равном всего лишь 5-6% от битовой скорости порта в 100 мБ) - при коммутации потока пакетов от 16 камер - на один "приемный" порт, - ВСЕГДА будут возникать моменты перегрузки порта сети работающего на "прием" - ДАЖЕ при его скорости в 1000 мб и при этом будет происходить постоянная потеря пакетов от любых 6 камер из 16.

Причем в этом легко убедиться - если просто начать получать поток сначала от 10, а затем от 16 камер, но не в TCP - а в UDP.

В сетях я не спец и именно желание разобраться заставило меня искать литературу по этой теме. Результат поиска – ничего конкретного нет. Пришлось разбираться самому.

Твоя ссылка на статью «Видео через IP: исследование темы» очень полезна, но это опять же разговор на уровне описания проблемы. И то, надо подумать, на сколько при наших потоках учет буфера актуален. Нам гораздо важнее знать закон изменения интенсивности параметров потока при разном движении людей перед камерой.

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

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

- количество потерянных пакетов (Frame Loss) – причина потери и влияние на картинку? В IP потеря пакетов может быть только при не правильном проектировании сети.

- количество пакетов с ошибками (Frame Error)– это о канале связи где даже коды исправляющие ошибки не работают? Мне кажется в IP таких каналов быть не может.

- задержка (Latency) – это и есть результат не правильного распределения потоков.

- девиация задержки, она же пакетный джиттер (Latency Distribution). – причины и влияние на изображение?

Если есть ссылки на статьи, материал которых поможет максимально корректно проектировать сеть, то я бы с благодарностью ознакомился с ними.

Тюрин: «Скорость передачи на порту всегда неизменна и равна физической скорости работы порта»

Вот это совершенно верное заключение, которое приводит к многократной перегрузке коммутатора.

Допустим, максимальная скорость на порт коммутатора, 100Мбит/с позволит подключить к одному порту камеру с потоком 50Мбит/с, а другой порт подключить к серверу. Остальные порты загружать нельзя – ПЕРЕГРУЗУА!!!! 50Мбит/с + 50Мбит/с = 100Мбит/с

Можно подключить к двум портам камеры с максимальным потоком на порт 25Мбит/с, а с третьего порта снимать поток 50Мбит/с идущий на сервер.

Можно подключить к пяти портам камеры с максимальным потоком на порт 10Мбит/с, а с шестого порта снимать поток 50Мбит/с идущий на сервер.

Коммутатор 100 мегабитный и суммарный поток на вход и выход не должен превышат это значение

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

В сетях я не спец и именно желание разобраться заставило меня искать литературу по этой теме. Результат поиска – ничего конкретного нет. Пришлось разбираться самому.

Да я вообщем-то тоже не большой специалист в деле построения настоящих структурированных сетей.:-(

Просто учиться разбираться в этом - меня заставила сама жизнь еще лет 10-14 назад, когда мы только развернули и начали эксплуатировать сеть РСПИ AES-intellinet, работа которой вообщем-то как раз основана на получении коммутируемых по времени пакетов от множества источников (объектов) - одним приемником (ЦСМ) на базе динамически строящейся маршрутизации (а-ля "тонка" IP-сеть на РК-50).

По поводу- "ничего конкретного нет", то для "гибких" IT технологий - это нормальная ситуация, причем данная проблема (ничего нет конкретного) имеет быть не только при передачи "гибкого" потока видеоинформации, но и существует для всех способов передачи информации в сети IP с временной коммутацией пакетов при её "гарантированной" доставки этих самых пакетов - но за нелимитированный период времени.

Лично мне кое в чем разобраться помогла вот эта интернет книга: Локальные сети на основе коммутаторов и всевозможная разрознена информация по IP сетям и цифровым способам СЖАТИЯ и передачи видиоинформации.

Тюрин: «Скорость передачи на порту всегда неизменна и равна физической скорости работы порта» Вот это совершенно верное заключение, которое приводит к многократной перегрузке коммутатора.

К многократной перегрузке приведет не сама по себе скорость сети, а скорость продвижения пакетов и их количество, потому как передаются пакеты (IP-кадры) в сети всегда на скоростях ПРОДВИЖЕНИЯ ПАКЕТА (pps):

http://www.rae.ru/snt/?section=content&op=show_article&article_id=4600

Рассчитаем теоретическую полезную пропускную способность Fast Ethernet. Служебная информация в кадрах Ethernet постоянно 18 байт, а размер поля данных кадра меняется от 46 до 1500 байт. Размер кадра может меняться от 46 + 18 = 64 байт до 1500 + 18 = 1518 байт. Поэтому для кадра минимальной длины полезная информация составляет всего лишь 46 / 64 ? 0,72 от общей передаваемой информации, а для кадра максимальной длины 1500 / 1518 ? 0,99 от общей информации.

Зная частоту следования кадров f и размер полезной информации V_п в байтах, переносимой каждым кадром, можно рассчитать полезную пропускную способность сети:

П_п (бит/с) = V_п · 8 · f.

Для кадра минимальной длины (46 байт) теоретическая полезная пропускная способность равна П_пт1 = 148 810 кадр/с = 54,76 Мбит/с, что составляет лишь немногим больше половины от общей максимальной пропускной способности сети.

Для кадра максимального размера (1500 байт) полезная пропускная способность сети равна П_пт2 = 8127 кадр/с = 97,52 Мбит/с.

Т.е. в независимости от скорости битрейта и способов сжатия видеопотока, пиковая исходящая скорость pps (скорость продвижения пакетов) от каждой камеры будет меняться: - от 54,76 Мбит/с до 97,52 Мбит/с.

Для того чтобы понять что на один "приемный" порт даже в 1000 мбит/сек гарантированно (т.е. в любой момент времени) можно передать поток всего лишь от 10 камер работающих с максимальной скоростью обновления видео кадров (25p) - при исходящей скорости порта ВК равном 100 мибт/с - проще всего рассматривать поток MPEG-2 (так как он является формализированным и имеет стандарты):

Стурктура GOP (групп кадров) MPEG-2:

В начале каждой GOP должен идти заголовок группы

Максимальное количество кадров на группу: 18 (NTSC) / 15 (PAL), то есть 0,6 секунды.

Скорости аудио- и видеопотоков:

Максимальная средняя: 9.8 Mbit/s

Максимальная пиковая: 15 Mbit/s

Минимальная: 300 Kbit/s

Как несложно понять - то в сети IP даже имея скорость на приемном порту в 1000 мбит/с будет не возможно гарантированно получить трафик от 10 но АСИНХРОННЫХ видеопотоков в формате сжатия MPEG-2, ТРЕБУЮЩИХ КАЖДЫЕ 0,6 СЕКУНДЫ ПИКОВОЙ СКОРОСТИ ДО 15 Мбит/с, потому как передача в сети IP в данном случае, будет осуществляться с максимальными размерами IP-кадров по 1500 байт (12000 бит) на скорости 97,52 Мбит/с (при необходимой пиковой передачи потока MPEG-2 15 Мбит/с (15 000 000 бит/с)).

Ну а поскольку, в нашем случае 10 видеопотоков асинхронны - то это неизбезно будет приводить к переполнению буферов портов коммутатора и потере IP-кадров именно в тех случаях, - когда пиковые скорости от 10 асинхронных видеопотоков, - будут совпадать во времени.

Но и даже при "средне-потолочной" скорости потока (битрейта) в 9.8 Mbit/s (9 800 000 bit/s) скорости продвижения пакетов, точно так же не хватит - поскольку пакеты будут передоваться IP-кадрами по 1500 байт (12000 бит) на скорости 97,52 Мбит/с, что потребует от сети IP иметь возможность передать с каждго из 10 портов 9 800 000 bit / 12000 бит = 816,6(6) IP-кадров (816,6(6) IP-кадров * 10 потоков = 8166(6) IP-кадров) - но за 0,6 секунды, при "потолке" IP-сети в 8127 IP-кадров за целую секунду.

PS

Единственное что в данном случае позволяет (на пределе возможности IP-сети) передать десять потоков в MPEG-2, так это наличие GOP состоящих из 15 (PAL) кадров, при этом каждый GOP состоит всего из одного ключевого и 14 кадров дельты.

Т.е. соотношение пиковой скорости 15 Mbit/s к минимальной скорости в 300 Mbit/s будет приблизительно равно 1:14.

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