О пользе admission control для VoD
Хочу с вами поделиться описанием небесполезной фичи, которая реализуется совместными усилиями вендора VoD и сетевого вендора. Конкретные вендоры не важны, суть в самой идее. Итак. В незапамятные времена, когда каналы были узкими, умные люди придумали делать call admission control с резервированием полосы на сети. Мало кто это нынче использует для голосу, по скольку скорости современных пакетных сетей для голоса настолько большие, что проку в этом мало. Однако приход в сети видео-по-запросу, суть которого в отдельном юникаст потоке на каждую пользовательскую сессию похоже (пока, по крайней мере) требует вернуться к этой теме.
Представим ситуацию (только не придирайтесь к цифрам, это все для примера) когда на определенном участке сети (как мне видится эта проблема, это участок между концентратором доступа, неважно каким - коммутатором Ethernet или DSLAM и агрегацией) недостаточно полосы для обслуживания сессий VoD. Это может произойти запросто, даже при планировании. Я например полагаю что такую ситуацию может создать скорее TVoD, но не суть важно. И так, предположем на этом участке у вас есть 40Мбит. Идет 10 сессий по 4Мбит каждая. И тут приходит 11-й потребитель и запрашивает сессию. Что произойдет? К сожалению натура пакетных сетей такова, что сессия попрет, но при этом начнуться потери пакетов. Что очень печально, потери пакетов начнутся равномерно на всех 11 сессиях. Результат очевидет - не только 11-му не дали, но еще и первых 10 абонентов обидели. Нехорошо получается.
Теперь представим что на этом участке есть admission control, реализуемый сетью и серверами VoD (или TVoD). При попытке открыть 11 сессию, не удастся зарезервировать необходимые 4Мбит/сек на сети, и сессия обломится. Потребителю покажется грамотно сформулированное сообщение. Он конечно расстроится и будет материться, но однако, как мне кажется, при рассыпающейся картинке он матерился бы сильно больше это раз. Два - не будут материться еще 10 человек. Три - все 11 не будут звонить в службу поддержки и требовать компенсацию. Позвонит лишь один - последний, которому не хватило, и то, только если он не сможет посмотреть и позже. Четыре - если регистрировать такие отказы в обслуживании, будет очень легко мониторить ситуацию и своевременно планировать нагрузки на сети (не рассказывайте мне про мониторинг нагруженности линков - какое там при этом распределение полосы по разным классам обслуживания почему то мониторить пока не выходит…). Пять - регистрируя отказы мы можем тут же налету складывать их в CRM с привязкой к конкретному абоненту, и когда он позвонит жаловаться, мы уже можем внятно ему объяснить проблему и успокоить.
О механизамах. Один вариант решения этой задачи, известный мне, предлагается Cisco. Собственно ничего нового, RSVP, только для VoD со специальным клиентом на сервере. Второй вариант работает у Redback Networks. Как реализован пока не знаю (но скоро узнаю и расскажу) и продвигается соответственно Эрикссоном.
Это естественно не моя идея, я лишь хочу поделиться ей с сообществом чтобы оно задумалось об ее, идеи, пользе.
Творчесгих вам узпехов.
Виктор Белов
5 последних записей автора belovictor
- Мегаизобретатели из маркетинга Microsoft :-) - January 8th, 2009
- IBC - Первые ощущения - September 14th, 2008
- Сжимаем и расширяем! - September 11th, 2008
- Йамстердам! - August 29th, 2008
- Кто кого тут драйвит? - February 27th, 2008
Stan сказал,
Июнь 22, 2007 @ 7:42
Даешь прикручивание SBC к видео? :) Вообщем-то логично, и решения такие есть. Только безумно дорогие. Кроме SBC сразу вспоминаются разные Service Broker, SDP, Service Gateway и пр. Все это проблему массовой деградации качества решит (и то с оговорками), но сделает проекты IPTV абсолютно нерентабельными. Мне кажется, дешевле и эффективней делать так, как делают буржуи - избыточную полосу пропускания.
TaNGO сказал,
Июнь 22, 2007 @ 8:21
А обеспечить требуемую полосу до абонента через различные фичи типа shaping policy и etc, никак нельзя ?
ankirich сказал,
Июнь 22, 2007 @ 10:38
Скорее всего Redback расскажет про NetOp policy manager. В общем ничего нового, обычный off-paff control.
to TaNGO:
Фичи типа shaping-policy и иже с ним решают вопросы ограничения полосы для трафика передачи данных за счет дропов с последующей перепосылкой или его буферизации, и то и другое для передачи real-time трафика, понятно дело, не приемлимо.
to Stan
И причем здесь SBC ?!
TaNGO сказал,
Июнь 22, 2007 @ 13:05
to ankirich: спасибо, мда, отстал я от жизни - нужно почитать материалы по сетевым фичам коммутаторов/BRAS.. хотя всего не охватишь, да и времени нет. Насчет буферизации - при передачи и приеме видео она повсеместно применяется. Обычно, как раз для решения проблем потери пакетов (кадров) и восстановления качества.
Виктор Степанов сказал,
Июнь 22, 2007 @ 13:22
У известного вендора в ближайших планах есть интеграция с BRAS, а также т.н. Policy Manager от Redback/Juniper. Подробностями не располагаю, но эта тематика активно востребована производителями сетевого оборудования.
Если чесно, не уверен, что это будет использоваться в существенном проценте проектов, но в качестве marketing story потенциал большой.
Stan сказал,
Июнь 22, 2007 @ 13:45
То, о чем писал Виктор - давно известная и описанная в мире SIP-телефонии проблема массовой деградации качества. Одним из споосбов ее решения стало появление оборудования SBC, которое просто не пропускало лишние вызовы. Ему сказали впихнуть в гигабит 10 вызовов, и он 11-ый уже не пропустит, даже если ресурс есть. Соответственно, из того, что было описано, напрашивается для IPTV устройство, аналогичное SBC в мире телефонии, которое будет ограничивать число входящих каналов по жестким правилам. Причем не на уровне дропов пакетов, а на уровне сигнализации IPTV с возвратом на MW коректной причины не установления соединения. Сейчас это фантастика.
TaNGO сказал,
Июнь 22, 2007 @ 15:01
Переговорил с коллегами. Пришли к выводу, что нам в VoD софте делать смысла нет, так как сетевая среда, по сути для него только транспорт. А вот разработчикам Middleware - прямая туда дорога. Если пытается коннектиться лишний клиент, оно не дает разрешение VoDу на доп. сессию вещания, соотвественно при этом пишет окошко с ругательством, и делает запись в БД c логом.
a.bogorodsky сказал,
Июнь 22, 2007 @ 15:35
Зря вы QoS в сторону задвинули. Как-раз им и мониторингом такие задачки в мультисервисе решаются автоматически. Придушить по приоритету локальный p2p - мало кто заметит, если только сам мониторить не сядет.
Т.е. динамически выделяется полоса для важного трафика за счёт некритичного. Параллельно мониторится (это все NMS умеют) общая загрузка каналов. Всплеск выше 70% загрузки - это уже в связи “звоночек” для расширения каналов. А сравнив два лога - от NMS и от MW - получаем очевидный вывод. Пойдя дальше можно сделать экстраполяцию предыдущего роста нагрузки и на нужный срок спланировать апгрейд.
TaNGO сказал,
Июнь 22, 2007 @ 16:39
Andrey, вполне обоснованный с инженерной точки вывод. Вот только сдается мне, что умное оборудования с DiffServ, QoS - не у всех на сетях стоит..
А в некоторых сетях, типа КТВ + DOCSIS этого физически нет. Но при этом многие упорно твердят об интерактивных услугах VoD/TimeShift/PVR поверх DOCSIS 2.0/3.0
belovictor сказал,
Июнь 25, 2007 @ 10:38
Данная технология в первую очередь нужна для борьбы с всплесками на мой взгляд. Спросите у Телефоники, как ей понравилась ее премьера VoD в свое время, когда они сдуру туда первое что выложили - европейскую премьер лигу по футболу и в первый же день запуска услуги абоненты получили такой негатив, что надолго его запомнили. То же самое может произойти где угодно. Кроме того существуют критические ситуации. 11 сентября - и у вас за 1 час 70% рост трафика интернет и одновременно такой же рост в TVoD на просмотр записанных выпусков новостей… Лучше в доброжелательной форме отказать в бензине, чем залить фуфло, как мне кажется.
ankirich сказал,
Июнь 25, 2007 @ 13:26
to TanGO:
Если вы перенесете взаимодействие CAC на MW, то MW придется постоянно отслеживать состояние сессий на VoD сервере, так ? Иначе у него не будет актуальной информации о занятости ресурсов и, как следствие возможно не совсем корректная обработка CAC.
Насчет буферизации на STB для восстановления качества картинки - согласен, применяется ну не то, чтобы повсеместно, но есть преценденты, те же самы MS MSTV и Cisco VQE. Только я имел в виду, что буферизация при шейпинге должна быть на маршрутизаторе, что будет стоить как чугунный мост.
Дальше, про IPTV over DOCSIS2.0/3.0 - там как раз контроль ресурсов предпологается по полной программе, ибо базируются все эти идеи на базе PCMM
to a.bogorodskiy: На QoS никто не задвигал :) Естественно он должен быть, чтобы приоритезировать видеотрафик на трафиков данных. Только вот если за полосу начинают конкурировать один видео поток с другим, то тут QoS уже никак не поможет :)
to STAN: SBC - session Border Controller ? Необычное применение, однако. Я думал, что контроль ресурсов проще сделать на софтсвиче, чем на SBC. Впрочем, могу ошибаться :)
Stan сказал,
Июнь 25, 2007 @ 13:46
Контроль ресурсов на MGC (управляющий элемент софтсвитча) не сделать, поскольку он только сигнализацию обрабатывает. Делать для этого связь между MGC и шлюзами MG - сложно, одна стандартизация займет пару лет. А вендорам нужно срочно оборудование продавать. Поэтому решили просто проксировать в одном устройстве (SBC) трафик “голос+сигнализация”, и контролировать одно в связи с другим. То есть SBC (по сути маршрутизатор), оперирует внутри себя понятиями “голосовое соединение”, а не “пакет IP”.
На самом деле, общей инженерной мыслью в этой ветке к этому и приходят, и ИМХО, это правильно. В частности согласен с этим.
“…А вот разработчикам Middleware - прямая туда дорога. Если пытается коннектиться лишний клиент, оно не дает разрешение VoDу на доп. сессию вещания…”
Это в чистом виде идеология SBC - отказать лишним соединениям на основе сигнальной информации, а не информации о реальных сетевых ресурсах.
Уверен, что все рано или поздно к этому придут. Вот у Нортела есть железка, называемая RTP Proxy, выполняющая в Софтсвитчах функцию SBC. Но почему название RTP Proxy? Не Voice Proxy, Telephony Proxy, VoIP Proxy а именно RTP Proxy?
TaNGO сказал,
Июнь 25, 2007 @ 15:14
А коллеги.. вот мы плавно и подошли к моему умоизмышлению - есть идея создать технологический образец медиасофтсвитча, который как раз бы мог взять на себя контроль RTSP/RTP cессий, балансировку нагрузки при массовых запросах, перекодирование кучи разных медиаформатов в другие форматы (например файловые в стриминговые), а также соединение через SIP - клиент STB to клиент STB, прозрачно, без вских вывертов протоколов/видов вещания..
Ну и все это базируется на простой и понятно архитектуре x86, наращиваемой, кластеризируемой (типа Infinity Band/GFPS), FibreChannel SAN и прочие прелести параллельно обработки массива данных. Ну и единый стык со всем по IP (GE/10GE)… Ух.. сильно загнул, наверное ?
Stan сказал,
Июнь 25, 2007 @ 18:21
Не столько сильно, сколько дорого. Даже боюсь представить, сколько они наварят на железке такой мощности. :)
TaNGO сказал,
Июнь 26, 2007 @ 8:38
Почему дорого, обосновать можете? И кто наварится?
Железо может быть как в форм-факторе 1RU, так и в собранном виде как стойка кластер. Серверы стандартные - IBM,HP,Dell, Supermicro, Tyan
Если сравнивать с ценами на отдельные VoD/PVR решения, а также транскодеры от Harmonic\Thales\Tandberg - получается весьма ощутимо. При этом гибкость такого медиасофтсвитча на порядок выше любой спец. железки.
Уже сейчас чисто софт. кодеры производительнее, чем любой спец. кодер на ASIC/DSP процессере, и разумеется, дешевле. И современные многоядерные CPU позволяют гибко распараллеливать вычисления алгоритмов компрессии/декомпрессии видео/аудио. А на подходе 16-80 ядерные процессоры.
belovictor сказал,
Июнь 26, 2007 @ 10:42
Меня просто поражает - ну зачем нужны какие то мегахреновины? Софт что ли нельзя написать? Вон у нас вполне себе медиасвитч, который распределяет RTSP запросы (не мы естественно его писали, мы его купили) и по доступности, и по географии и так далее… даже таблица перенаправления rtsp запросов динамическая - она у нас от bgp зависит… Только при чем здесь admission control? Задача admission control однозначно должна решаться сетевой инфраструктурой и VOD серверами. MW тут совершенно ни при чем. Задача MW - интерфейс и услуги, а не управление сетевой инфраструктурой. Ну зачем из простого, прозрачного и понятного наворачивать сложное, глючное и неэксплуатируемое?
TaNGO сказал,
Июнь 26, 2007 @ 11:15
Мы видимо говорим о разном софте и разных задачах..
Я не говорю о мегахреновине. Софт - масштабируемый, от одного сервере, до кластера при необходимости. И на нем не только admission control, и это даже не основное - основное - обработать и пережевать любой видео/аудио поток, из любого файла, загруженного пользователем, при этом обеспечивая коннект между собой многоточечных сессий пользователей для обмена видео сессиями/видеофайлами внутри сети оператора. Все остальное - RTSP балансировка, управление Asset-ами, тот же пресловутый admission control - прикладные уровни. В данный момент такого пока не делает никто.
Можно привести аналогии из мира VoIP - первые шлюзы от Vocaltec, и современные софтсвитчы от Nortel (CS 2000) и Huawei
Stan сказал,
Июнь 26, 2007 @ 11:34
По моей информации (может быть устаревшей), SBC, обслуживающий 10 тыс. голосовых соединений, стоит около 60-100 тыс. Евро. При том же соотношении объемов трафика и железа, в случае IPTV это будет где-то 60-100 тыс. Евро на 156 видеосессий. Если предположить, что, например, у СтримТВ абонентская база 70 тыс. чел., а спрос на VoD 50% (заказ раз в месяц), то очень условно можно рассчитать, что одномоментно в сети существует около 6 тыс. однвременных потоков. То есть стоимость аналога SBC в таких условиях потянет на 2,2-3,7 млн. Евро, или приблизительно 84 Евро на абонента. При тарифе в 55 руб. окупаемость составляет 52 месяца.
TaNGO сказал,
Июнь 26, 2007 @ 12:04
156 видеосессий ?!.. за 60-100к EUR ?… вы где то явно ошиблись.
О каких кстати, видеосессиях идет речь? VoD? В случае с VoD MSS как раз выступает просто как свитч - перенаправляет потоки, рубит лишние сессии, выполняет функции RTSP Proxy.. VoD сервера к нему просто цепляются для обмена данными и управления - сами сессии вещаются с серверов VoD.
А вот для примера, рассчитайте стоимость HeadEnd которому нужно выплюнуть 70-150 каналов в SD H.264.. Например на Harmonic. А еще нужно переконвертировать 5-6 тыс. видозаписей пользователей в формат QCIF H.264 + HE-AAC для перенаправления на WAP портал (загрузка на моб. телефоны - к примеру пусть будет такой условный online сервис)
TaNGO сказал,
Июнь 26, 2007 @ 12:06
Переконвертировать в режиме онлайн !.. единовременно.
Stan сказал,
Июнь 26, 2007 @ 12:37
Я базируюсь на информации о ценах на SBC. Там, как я уже говорил, сервер ценой 60-100 тыс. Евро обслуживает 10 тыс. соединений (6-8 Евро на абонента, терпимо) пропуская через себя голосовой трафик. Трафик MPEG-2 в 64 раза больше. Отсюда я умозаключения и строил. К сожалению, цен на Headend не знаю, но предполагаю, что ниже, поскольку производство налажено, R&D отбиты и пр.
Уважаемый Tango, а Вы могли бы привести пример альтернативного расчета? Сколько может стоит сервер, проксирующий сигнализацию и трафик, определяющий доступность сетевых ресурсов, и перенаправляющий трафик на альтернативные маршруты или отбивающий сессии?
TaNGO сказал,
Июнь 27, 2007 @ 9:08
Участник Stan сказал:
“Я базируюсь на информации о ценах на SBC. Там, как я уже говорил, сервер ценой 60-100 тыс. Евро обслуживает 10 тыс. соединений (6-8 Евро на абонента, терпимо) пропуская через себя голосовой трафик. Трафик MPEG-2 в 64 раза больше. Отсюда я умозаключения и строил. К сожалению, цен на Headend не знаю, но предполагаю, что ниже, поскольку производство налажено, R&D отбиты и пр.”
————————————–
Цены на Head End - 2 канальный кодер Harmonic 15-20к (2 real time channels SD H.264/AVC + 2 CIF). У других - не сильно дешевле.
Итого на 80 ТВ каналов (+ 40 в мобильном формате) - 600-800k USD (без инсталляции и доп. опций) Доп. ставим RTSP Proxy/SIP SBC - Каssena + RedBack - 70-80к USD + 60-100к EURO… итого в среднем переваливаем за 1 млн. USD. Без остального софта, т.е. Middleware (+ ~90-150к на указанное кол-во коннектов). Цены примерные.
Участник Stan сказал:
——————-
Уважаемый Tango, а Вы могли бы привести пример альтернативного расчета? Сколько может стоит сервер, проксирующий сигнализацию и трафик, определяющий доступность сетевых ресурсов, и перенаправляющий трафик на альтернативные маршруты или отбивающий сессии?
——————–
Как я уже писал выше, я имел ввиду нечно более гибкое и универсальное.
TVoIP, VoD, PVR, video encoding for Mobile/consumer device + прочее.
Так, железо, способное перелопатить 80 ТV каналов в SD H.264/AVC Main Profile Level 3 + CIF под MobileTV будет стоит примерно - 70к в опте + 15-20к на платы захвата (если нужны SDI/ASI входы). Если выдавать SD Baseline Profile - немного меньше по деньгам.
Далее, 2-4 сервера с FC контроллера и массив под буфер/файлы конвертации - 16-20кUSD + 25-50к USD..
Софт может стоить (если таковой будет создан в предлагаемой конфигурации), ориентировочно - от 250к до 500к (на указанный объем каналов и пользовательских лицензий). Итого 400-650к - стоимость проектируемого решения .
Stan сказал,
Июнь 27, 2007 @ 21:34
Уф. Что-то сложно и непрозрачно. Давайте вычленим RTSP Proxy - 70 кUSD. Как я понял на 80 каналов. По той же методике, что я предложил - ситуация становится еще хуже, получается, стоимость RTSP Proxy на абонента - 160 Евро на абоннета, и сроки ее окупаемости зашкаливает. Наверное, лучше продолжить обсуждение не здесь, предлагаю по эл. почте (n g s z n i i s . r u). Пробелы убрать.
TaNGO сказал,
Июнь 28, 2007 @ 8:06
В том то и дело, что это не RTSP proxy.. Да и обсуждать, как вижу, не имеет смысла - идея не понята абсолютно.
Stan сказал,
Июнь 29, 2007 @ 8:12
Может, рисунком пояснить с обозначением пртоколов?
TaNGO сказал,
Июнь 29, 2007 @ 8:43
Я вам напишу. Мое мыло здесь есть, если не сложно, просьба скинуть тестовое письмо. Судя по ссылке, вы из ЦНИИС - вам это действительно может быть интересно.
Stan сказал,
Июнь 29, 2007 @ 14:41
К сожалению мыла не нашел, да и оно скорее всего закрыто. :( Подскажите где, или пошлите письмо по указанному выше адресу.
Oscar сказал,
Сентябрь 11, 2007 @ 15:20
hello , sorry i am writing in English , i do not know to write in Russian
first I saw about the problem you have mentioned about the quality of service , you always can use network management system (not very expensive ) like the product of Allot ( www.allot.com) or to use smart systems that know to push the Video closer to the client in more effective and dynamic way using smart management a distribution capabilities check BitBand solution (www.bitband.com)
eltelalvizel сказал,
Ноябрь 17, 2007 @ 2:56
rolelbo