Хочу с вами поделиться описанием небесполезной фичи, которая реализуется совместными усилиями вендора 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. Как реализован пока не знаю (но скоро узнаю и расскажу) и продвигается соответственно Эрикссоном.
Это естественно не моя идея, я лишь хочу поделиться ей с сообществом чтобы оно задумалось об ее, идеи, пользе.
