On Fri, May 21, 2010 at 07:04:38PM +0300, Vladimir Litovka wrote:

привет,

обновил блог - если кому интересно - "Организация межоператорского Multicast-вещания" - верхний пост.

Enjoy reading & listening :)

Feedback (писалось практически в параллель с прослушиванием, так что местами может не учитывать то, что было сказано потом): - одновременность передачи информации. если этого нет, хрен тебе mcast поможет хоть что-то сэкономить. - в реальной жизни mcast-сети строят на mesh-группах а не на "одном RP на домен". - MP-BGP может использоваться гораздо больше чем просто для inet-unicast/inet-multicast. В частности, на прошлой работе по этим же сессиям ходили еще и inet6 и inet-labeled-unicast. - то, что у тебя не рассмотрены проблемы multicast в условиях mpls-сетей (классика - при использовании mpls te оно по умолчанию ломается, и нужны workaround'ы описанные, например, в вашей же MPLS TE book), особенно современные подходы для построения multicast-trees over MPLS backbones - ну, что делать :) - на базе ua-ix строить multicast exchange просто противопоказано. Опять же из реальной жизни - все exchange'ы которые предоставляют доступ не только к unicast-обмену но и к multicast - в лучшем случае используют для этого отдельный vlan (к которому подключено не более пяти процентов участников IX'а), либо вообще отдельную switched infrastructure. - посмотрел слайды про ua-ix - таки кто-то чего-то не понимает. см. про опыт других exchanges. - [ позднее ]: см. пункт 1 про одновременность. современные пользователи скорее построят near-realtime p2p network для распространения "почти одновременно интересного контента" (например, смотреть футбол с задержкой в пять минут гораздо интереснее, чем смотреть его через три часа, когда оно уже будет записано в файл. Более того, такие сети afair уже есть), чем на ua-ix'е будет построен нормальный multicast exchange. Траффик нынче дёшев :) - Основной IGMP на сейчас это именно v2 - IGMPv1 практически никто не использует. И, btw, то, что винда по умолчанию использует именно v3 и является основным showstopper'ом. - SSM это ни в коем случае не отказ от MSDP, по крайней мере на inter-as стыках ты никуда от msdp не денешься.

2010/5/21 Alexandre Snarskii - одновременность передачи информации. если этого нет, хрен тебе mcast

поможет хоть что-то сэкономить. - MP-BGP может использоваться гораздо больше чем просто для inet-unicast/inet-multicast. В частности, на прошлой работе по этим же сессиям ходили еще и inet6 и inet-labeled-unicast.

угу, факт :)

- в реальной жизни mcast-сети строят на mesh-группах а не на "одном RP на домен"

не помню, чтобы я говорил про "один RP на домен". Рисовал - да, но рисунок - это всего-лишь high-level representation реальной картины :) - Основной IGMP на сейчас это именно v2 - IGMPv1 практически никто

не использует. И, btw, то, что винда по умолчанию использует именно v3 и является основным showstopper'ом.

в винде это можно отключить - сам делал когда-то :) а вот то, что все коммутаторы доступа во всех городах и весях по всем операторам (как минимум - Участникам UA-IX) поддерживают IGMPv3 - в этом я сомневаюсь. Я не один раз слышал, что подъездный коммутатор за $200 - непозволительная роскошь, бо дорого когда тырят. И знаю, что операторы частенько пользуют инсталлированную базу неуправляемых железок по $20 за штуку. А вот это уже реальный showstopper, IMHO. - SSM это ни в коем случае не отказ от MSDP, по крайней мере на

inter-as стыках ты никуда от msdp не денешься.

why? если клиент знает об источнике (как - это уже из другой оперы), то механизм распространения информации об источниках лишен смысла.

- то, что у тебя не рассмотрены проблемы multicast в условиях mpls-сетей (классика - при использовании mpls te оно по умолчанию ломается, и нужны workaround'ы описанные, например, в вашей же MPLS TE book), особенно современные подходы для построения multicast-trees over MPLS backbones - ну, что делать :)

ну я как бы и не собирался ничего рассказывать про multicast в MPLS-сетях. Я даже специально сказал об этом ;-) Во-первых, в 15-минутную презентацию невозможно уложить "всё про multicast", во-вторых - задача такая не ставилась, в-третьих - преза была рассчитана на конференцию UA-IX, где MPLS'ом не пахнет. И еще есть "в-четвертых" ;-) - на базе ua-ix строить multicast exchange просто противопоказано.

Опять же из реальной жизни - все exchange'ы которые предоставляют доступ не только к unicast-обмену но и к multicast - в лучшем случае используют для этого отдельный vlan (к которому подключено не более пяти процентов участников IX'а), либо вообще отдельную switched infrastructure. - посмотрел слайды про ua-ix - таки кто-то чего-то не понимает. см. про опыт других exchanges.

я попытался показать (и на примере UA-IX в том числе), почему без костылей типа RGMP (что еще более fiction, чем IGMPv3), провайдерский ethernet multicast не имеет права на существование. Он, конечно, будет работать, пока трафика децул (хрен с ней, с пропускной полосой, пока broadcast помещается), но в случае "вдруг развития" - станет напряжно. И это не коррелирует с бизнес-обязательствами, буде таковые появятся (см. ниже). Поэтому мое предложение - создать отдельный routing domain, в котором будет работать работать IP Multicast, без каких-либо ограничений. - [ позднее ]: см. пункт 1 про одновременность. современные пользователи

скорее построят near-realtime p2p network для распространения "почти одновременно интересного контента"

Может построят. А может и нет. А может построят, а оно сломается в момент забивания финального гола :) Если раздача видео гарантируется оператором (приоритеты для трафика, резервирование источников, etc), то это гораздо более предпочтительно как для клиентов, так и для медиа-владельцев. А для последних вообще критично. Фишка ведь в том, что для распространения малтикаст требуется значительно меньшая пропускная полоса и производительность как транзитных устройств, так и генераторов потока. А это означает, что по сравнению с традиционнной unicast-раздачей себестоимость multicast-раздачи заметно ниже при бОльших гарантиях (потому что меньше bottlenecks в сети, соответственно - не нужно наращивать пропускную и гарантировать ее достаточность при network/node failures). То есть - если оператор может оформить сотрудничество с медиа-владельцем, то чем ниже себестоимость услуги, тем больше объем рынка. Поэтому выходит, что внедрение малтикаст в UA-IX может повлиять на развитие контент-рынка и рост операторских доходов. Да, именно повлиять, а не не быть краеугольным камнем, но разве этого мало? При низких-то капитальных (потому что поддержка multicast есть практически у всех вендоров). -- /doka /*-- http://doka-ua.blogspot.com/ --*/

On Tue, May 25, 2010 at 04:57:19PM +0300, Vladimir Litovka wrote:

2010/5/21 Alexandre Snarskii - [ позднее ]: см. пункт 1 про одновременность. современные пользователи

...

скорее построят near-realtime p2p network для распространения "почти одновременно интересного контента"

Может построят. А может и нет. А может построят, а оно сломается в момент забивания финального гола :) Уже построили - TVU player. Да, затыки бывают, и гарантий никаких, и ваще трафика жрёт порой в раза 2 больше, и т.д.... Но затыки в РТР - так они mpeg-поток тянут с того же места, откуда его все зрители берут - картинку сравнивал специально.

Если раздача видео гарантируется оператором (приоритеты для трафика, резервирование источников, etc), то это гораздо более предпочтительно как для клиентов, так и для медиа-владельцев. А для последних вообще критично. Если за деньги - критично, если на шару - неприятно.

Фишка ведь в том, что для распространения малтикаст требуется значительно меньшая пропускная полоса и производительность как транзитных устройств, так и генераторов потока. А это означает, что по сравнению с традиционнной unicast-раздачей себестоимость multicast-раздачи заметно ниже при бОльших гарантиях (потому что меньше bottlenecks в сети, соответственно - не нужно наращивать пропускную и гарантировать ее достаточность при network/node failures). То есть - если оператор может оформить сотрудничество с медиа-владельцем, то чем ниже себестоимость услуги, тем больше объем рынка. Ага. "оператор". ОДИН. Если их 100 - всем бежать, сотрудничество оформлять? Короче, совершенно новая бизнес-ситуация - типа "гугл наживается на наших клиентах, и нифига нам не платит". И гуглов таких = миллионы.

Поэтому выходит, что внедрение малтикаст в UA-IX может повлиять на развитие контент-рынка и рост операторских доходов. Да, именно повлиять, а не не быть краеугольным камнем, но разве этого мало? При низких-то капитальных (потому что поддержка multicast есть практически у всех вендоров). Может, но смысл? Что транслировать? А ещё - лицензии на "телевещание" вылезут... И палки в колёса воли-кабель/укртелеком просматриваются - как только контент будет. Я вот с 2007г без ТВ живу... Тюнер пылится где-то...

-- Best regards, Paul Arakelyan.

Привет, 2010/5/29 Paul Arakelyan Ага. "оператор". ОДИН. Если их 100 - всем бежать, сотрудничество оформлять?

Короче, совершенно новая бизнес-ситуация - типа "гугл наживается на наших клиентах, и нифига нам не платит". И гуглов таких = миллионы.

во-первых, никто никого не заставляет никуда бежать. Кто не хочет - тот продолжает заколачивать свою копеечку на доступе в Интернет. Побегут те, кому хочется увеличить ARPU. И вторые, в конечном итоге, сожрут первых. во-вторых, "оформлять сотрудничество" == "нам платят" (кто платит и сколько - вопрос каждого конкретного бизнес-кейса), поэтому см. п.1 Может, но смысл? Что транслировать? А ещё - лицензии на "телевещание"

вылезут... И палки в колёса воли-кабель/укртелеком просматриваются - как только контент будет. Я вот с 2007г без ТВ живу... Тюнер пылится где-то...

Паша, смотри на вещи шире ;-) -- /doka /*-- http://doka-ua.blogspot.com/ --*/

On Wed, Jan 26, 2011 at 09:28:36AM +0200, Vladimir Litovka wrote:

2010/5/25 Vladimir Litovka

...

- [ позднее ]: см. пункт 1 про одновременность. современные пользователи

...

скорее построят near-realtime p2p network для распространения "почти одновременно интересного контента"

Может построят. А может и нет. А может построят, а оно сломается в момент забивания финального гола :)

http://www.3dnews.ru/software-news/sozdatel-bittorrent-demonstriruet-potokov...

ppstream - вполне p2p, TVU networks - тоже... В последнем случае плохо одно - они ретранслируют интернет-трансляцию - в итоге подвержены всем минусам такого... -- Best regards, Paul Arakelyan.