IPTV

Я, когда приезжаю в гости к маме, вечерком сажусь перед телевизором, типа попробовать. Нажимаю кнопку - футбол, нажимаю другую - петросян, нажимаю третью - хинштейн. Ну, куплю я себе наконец телевизор и какое-нибудь стрим-тв, и что? Чем оно будет отличаться от эфирного телевизора у мамы дома? Будет у меня 200 кнопок: 100 с петросяном, 100 с хинштейном, ну и футболу чуть-чуть. Причем футбол, петросян и хинштейн будут у меня в то время, когда захочет дяденька или тетенька, которые сетку вещания составляли. Это от эфирного вещания отличается только количественно, а от CATV так вообще ничем. И они все мне одинаково не нужны.

Это совершенно очевидным образом приводит к идее VOD - Video on Demand. Это я знаю, что я хочу посмотреть и когда, а составитель сетки - нет, и не может. И даже если б знал, все равно не смог бы удовлетворить мои хотелки, хотя бы потому, что я и мой сосед Вася хотим смотреть разные вещи и в разное время. VOD отличается от вещания качественно, а не количественно. VOD - это действительно фишка.

Делаю предсказание: VOD победит вещание. VOD разнообразней: на N каналов вещания N программ, а с VOD'ом сколько пользователей, столько и программ. VOD удобней: когда хочу, тогда и смотрю, могу перемотать, могу поставить на паузу, дофига чего могу, чего с бродкастной передачей не сделаешь.

Только не надо мне говорить, что, мол VOD и вещание - разные и не пересекающиеся вещи, что одно другому не мешает и т.п. Пересекающиеся. Практически все виды контента, что сейчас вещаются, только выиграют от их доступности on demand. Исключений я знаю два вида:

1. Real-time. Футбол, когда фанаты хотят видеть забитый гол в ту же секунду (с поправкой на скорость света), Путин под елочкой в новый год и т.п.
   
2. Полная херня (читай петросянохинштейн), которую по своей воле никто не закажет, и которую, ежели кто нынче и "смотрит", то только потому что забыл переключить программу.

Причем футбол в real-time нужен только кучке совсем уж отмороженных фанатов. Большинство с удовольствием посмотрят в записи в удобное время.

Очевидно, что с точки зрения сети VOD - это ужасно. Если вещание потребляет ресурсов O(N), где N - число каналов, то VOD - O(M), где M - число пользователей.  И узкое место понятно где - в VOD-сервере и в его окрестности. Это не зависит от технологии сети, на самом деле. Есть не-IP'шные реализации VOD'а по CATV, по спутниковым каналам и т.п. Они все страдают от того же.

Есть ли решение? Есть. Причем это решение уникально для IP-сети и служит оправданием всей идее передачи видео через IP-сеть (да, да, я знаю про конвергенцию, про мультисервисность, про управление одной сетью вместо нескольких - но этого мало). Это решение изначально заложено в архитектуре интернета. Все уже догадались, что речь про peer-to-peer.

Чем peer-to-peer хорош для целей распространения видео через IP? Тем, что масштабируется. Он устраняет (ну, почти устраняет) вышеупомянутое узкое место, "размазывая" трафик по сети. Чем он плох? Тем, что это downloading, а не streaming. Streaming VOD начнет показывать сразу же, а в случае downloading придется немного подождать.

Страшно ли это? Да нет, не страшно. Мне надо всего лишь немножко прогнозировать, что я захочу посмотреть. Это не трудно. Я, придя с работы, захочу посмотреть новости и очередную серию любимого сериала (IER, скажем, или 24). А если мне вдруг стукнуло в голову ознакомиться с очередным шедевром киноисскуства, то все равно пиво и пицца не появятся немедленно - придется идти в магазин или заказывать, а значит и кино мне нужно не в ту же секунду.

В чем еще плюсы такого подхода к VOD'у? В том, что это downloading, а не streaming. Парадоксально, правда? Streaming - это real-time действие и это накладывает жесткие требования к сети. Нельзя терять пакеты - для видео это смерть, нельзя их слишком долго буферизовать - dejitter buffer не бесконечен. А с downloading'ом проще: потерялся пакет - перепошлется, delay variation вообще пофигу (в разумных пределах). Соответственно, когда файл уже у меня, то проигрываться он будет гладко и чисто, чтобы там дальше в сети ни творилось, и картинка у меня точно никуда не рассыплется.

Таких сервисов уже есть - IPLayer, например. И будет больше, ибо за ними будущее.

Что это означает с практической стороны для операторов? Это означает, что с P2P не надо бороться, с P2P надо сотрудничать. Как сотрудничать?

1. При проектировании сети надо учитывать, что пользователи будут активно говорить друг с другом, а не только с дырочкой в интернет. Сетей, в которых разговор пользователей между собой обходится очень дорого, есть.
2. Рассчитывать свои stateful устройства на большое количество сессий. Вы до сих пор NAT'ите своих клиентов? Сочувствую. И вам, и клиентам.
   
3. Сотрудничать напрямую. Вот так, например.
4. Сотрудничать с контент-провайдерами и доставлять популярный контент по своей CDN (content distribution network) ближе к пользователю и "сидить" со своих серверов. Это даст возможность оператору заработать кроме как на bit moving'е. Особенно, если оператор возьмет на себя взаиморасчеты с пользователем за контент.
   

Достаточно ли этого или сам P2P надо как-то улучшить? Да, очень хотелось бы. Дело в том, что нынешний P2P не совсем "честно" конкурирует с другими приложениями за полосу. TCP'шный congestion control честно делит полосу между сессиями. Но, поскольку P2P использует сразу много соединений, то он способен удушить практически все, что угодно. Это не есть принципиально нерешаемая проблема, но ее решение потребует разработки нового траспортного протокола для P2P с более вменяемым congestion contol.

А что же с мультикастом, с мультикастом-то что? Столько сил и денег потрачено на эту технологию. Неужто помрет? Не совсем. Найдет применение том же CDN, например. Там объемы и коэффициент репликации вполне оправдывают применение мультикаста. Правда требования к этому мультикасту не такие строгие, как для стриминга. Если при заливке на content server'а потерялись какие-то пакетики, ничего страшного, их перезапросят и т.д. Время восстановления от аварии на так уж важно. Все существенно расслабленней. Так что, получается, зря изобретали p2mp MPLS? Нет, конечно, все хотелки по сокращению количества состояния в ядре сети, по traffic engineering'у мультикаста остаются и никуда не деваются. Этот труд не пропадет.