Экстремальный мультикаст

[Robot_NagNews]

Материал:

Коммутаторы Extreme для хранения мультикаст таблицы могут использовать как L2-таблицу (FDB), так и L3-таблицу (RIB). Причем ранее, на предыдущих моделях чипов, использовалась только L3-таблица для мультикаст кеша, независимо от того L2 он или L3.

 

Полный текст

[Saab95]

Неужели еще кто-то использует мультикаст для вещания IPTV?

[zi_rus]

это провокационный вопрос, может вызвать начало срача

[Дятел]

Конечно, используют. Все телеканалы отдаются на М9 мультикастом. И головные станции его принимают стандартно...

[-Ars-]

Неужели еще кто-то использует мультикаст для вещания IPTV?

 

Есть такие незначительных размеров компании, как, например Бритиш Телеком, Телефоника - которые используют мультикаст для вещания IPTV. И, что характерно, у них все работает даже без использования Микротика нигде :-p

[Saab95]

Просто по мультикасту можно осуществлять только эфирное вещание, сервисы вроде видео по запросу, отложенного просмотра и т.п., реализуются юникастом.

 

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

[karpa13a]

Вот тут я бы поспорил. в зависимости от количества юзеров на ветке.

вообщем "не всё так однозначно")

[snvoronkov]

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

Марш в педивикию читать про малтикаст и IGMP!

[Sergey Gilfanov]

Вот тут я бы поспорил. в зависимости от количества юзеров на ветке.

<задумчиво рассматривая ту технологию, что торрент-tv использует>. Юникастом или хитрым вариантом L3-7 мультикаста считать будем?

[snvoronkov]

<задумчиво рассматривая ту технологию, что торрент-tv использует>. Юникастом или хитрым вариантом L3-7 мультикаста считать будем?

Это "Малтисоурс" ;-))).

[vIv]

Просто по мультикасту можно осуществлять только эфирное вещание, сервисы вроде видео по запросу, отложенного просмотра и т.п., реализуются юникастом.

 

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

1) Наличие мальтикаста не запрещает юникаста ;-)

2) Ты бы почитал про малтикаст, особенно про джойн/лив, а то выглядишь как Saab95

[pfexec]

просто микротики как роутиры не айс, а свичи из них вообще никак. т.е. igmp snooping не умет и вообще грустишка. вот мультикаст и растекается у сааба по всей сети. што поделать.

[Ivan_83]

IPTV мультикастом абоненту - это грусть.

Но новость вроде не про IPTV.

В IPv6 мультикаста много, это видимо для него.

[tunny]

грусть не грусть, но проза жизни

[zi_rus]

в ipv6 мультикаст link local, по сути от броадкаста мало отличается и вообще не имеет смысла как-то персонально рассматривать

[Дегтярев Илья]

К вопросу, о очередном желании использовать только юникаст.

 

НТВ+ раздает свой шифрованный сигнал в ip сети, есть уже один ресивер, который может

это все принимать в виде мультикаста. И хорошо бы это же по юникасту запустить.

Но вот представители Экотелеком, сделавшие это первыми как бараны твердят что надо пропускать мультикаст и сеть надо строить с коэф. потерь пакетов 0,000001%. Что нереально по определению - в сети куча линков дающих до 0,01% потерь, которые никак не влияют на интернет.

 

Никто их не хочет начать коллективно пинать, чтоб сделали поддержку юникаста?

[vIv]

Для броадкаста, который нужен не всем, лучше малтикаста ничего не придумано. Юникаст множит нагрузку.

[s.lobanov]

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

Марш в педивикию читать про малтикаст и IGMP!

 

IGMP не поддерживается микротиком. Как вы думаете, почему? (универсальный ответ - микротик не поддерживает или криво работает с "устаревшими" протоколами)

 

До тех пор, пока люди будут смотреть live-трансляции, multicast будет жить

[zi_rus]

в сети куча линков дающих до 0,01% потерь

у меня для вас плохие новости :)

нет, серьезно, магистральные линки с такими потерями?

то есть у вас сеть бог знает как построена, а бараны они?

[s.lobanov]

+1 к zi_rus

Если поместить мультикаст в (более)приоритетную очередь, то потерь на буферах/микробёрстах не будет. а если 0.01% это ошибки по физике, то это и в самом деле печально. на нормальных линках пролетают 0-1-2 ошибки только в момент включения патчкорда

[danilbal]

Да уж. Традиции надо чтить! Опять рекламно-информационную статью превратили в противостояние юникаста и мультикаста:)

[Дегтярев Илья]

в сети куча линков дающих до 0,01% потерь

у меня для вас плохие новости :)

нет, серьезно, магистральные линки с такими потерями?

 

А вы много реальных сетей эксплуатировали? 0,01% потерь по пакетам до конечного пользователя при размере пакета в 1250 байт = 10e-8 BER (а так как линков на пути несколько ~10e-9 BER на каждый линк) что является очень хорошим значением для кабеля, висящего между домами несколько лет.

 

Просто товарищи, запихивающие копию того, что идет со спутника в ethernet забывают, что одна ошибка на dvb-c/s приводит к выпаданию всего нескольких байт, а одна ошибка в udp пакете убивает весь пакет.

И приведенным требованиям может соответствовать только свежепостроенная сеть с кабелями в канализации.

[danilbal]

у меня для вас плохие новости :)

нет, серьезно, магистральные линки с такими потерями?

 

А вы много реальных сетей эксплуатировали? 0,01% потерь по пакетам до конечного пользователя при размере пакета в 1250 байт = 10e-8 BER (а так как линков на пути несколько ~10e-9 BER на каждый линк) что является очень хорошим значением для кабеля, висящего между домами несколько лет.

 

Просто товарищи, запихивающие копию того, что идет со спутника в ethernet забывают, что одна ошибка на dvb-c/s приводит к выпаданию всего нескольких байт, а одна ошибка в udp пакете убивает весь пакет.

И приведенным требованиям может соответствовать только свежепостроенная сеть с кабелями в канализации.

Не, реально бред. Единичные ошибки вполне себе корректируются не доходя до второго уровня. А у вас что - цепочка коммутаторов по меди "внутренней", висящей несколько лет? В таком случае - готов поверить в 10-8 ошибок... и даже больше.

Но это не отменяет плохих новостей для вас...

[zi_rus]

А вы много реальных сетей эксплуатировали? 0,01% потерь по пакетам до конечного пользователя при размере пакета в 1250 байт = 10e-8 BER (а так как линков на пути несколько ~10e-9 BER на каждый линк) что является очень хорошим значением для кабеля, висящего между домами несколько лет.

пока на руках только первая, но вот статистика с пары линков, не знаю канализация там или столбы, но оптике уже лет десять, и это не прямые линки, по пути есть промежуточные кроссы. итак:

номер раз

    16911287916674 packets input, 15568149367633300 bytes, 0 no buffer
    Received 24 broadcasts (2190763915208 IP multicasts)
    0 runts, 0 giants, 1888 throttles
    5 input errors, 4 CRC, 1 frame, 0 overrun, 0 ignored
    0 watchdog, 380480515 multicast, 0 pause input
    0 input packets with dribble condition detected

номер два

    3355344481278 packets input, 2921114277634818 bytes, 0 no buffer
    Received 1140499778637 broadcasts (1263301856 multicasts)
    0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 input packets with dribble condition detected

там есть местами queue дропы, но это qos-ом решается как уже написали.

по этой сети ходит мультикаст и никто не жалуется, все работает без проблем, по крайней мере в плане потерь данных на линках

 

одна ошибка в udp пакете убивает весь пакет.

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

[Дегтярев Илья]

Может оно в реальности и сильно лучше, но мы от монтажников принимали работу, если от центрального узла до абонентского коммутатора из 10000 пингов по 1500 байт ни одного потерянного нет. Это и есть не более 0,01% потерь пакетов.

 

При этом в приказе минсвязи (http://www.economy.gov.ru/minec/about/structure/depregulatinginfluence/doc20130301_07) именно такие значения (10-4 искаженных пакетов) и принимаются эталонными для сетей передачи данных.

 

Потыкался в порты на узле:

905116339 packets input, 729458268556 bytes, 0 no buffer

Received 389308 broadcasts (87657 multicasts)

688 runts, 0 giants, 0 throttles

9134 input errors, 3800 CRC, 3807 frame, 0 overrun, 0 ignored

 

Но кроме линка внутриоператораторского еще есть 100мбитный порт до пользователя, его роутер, линк от роутера до tv приставки.

 

В любом случае юникаст в некоторых случаях энономически выгоднее использовать.

Edited April 30, 2014 by Дегтярев Илья