Мультикаст & юникаст - что выбрать?

[sky star]

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

[skarxxl]

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

согласен, что что единственной такой причиной может стать дроп на порту, что у приличного оператора маловеротно.
в предидущем посту, я немного не корректно написал, что буфер не имеет отношения к мультикасту, это не совсем так т.к. мультикаст - это помимо UDP ещё и RTP, а вот особенность RTP - он действительно кешируется, следовательно его применение в рамках ГС более оправданно... как-то была у меня мысль перейти на RTP, но что-то меня удержало...
Следовательно, если нет дропов, то разницы между юникастом и мультикастом (RTP) нет (разумеется кроме многоадресности)?

[atx]

Не  увидит,  размер  буфера ,  как  правило  несколько  секунд,  за  это  время  пропавшие  пакеты  будут перезапрошены, но к мульти(уни) касту это  отношения уже не  имеет.

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

Буфер есть в любом случае, хоть с Tcp, хоть с Udp.

Да и вопрос даже не в этом, вопрос в юникате или мултикасте

И юникастом в тср вещают (hls как пример), но делается это прежде всего из-за того, что приходится отдавать потоки через "чужую" сеть (например интернет тв), или по каналам с значительным процентом негарантированной доставки пакетов (например по wifi на гаджеты). Там вариантов, кроме как отправлять по юникаст/тср и ждать буферизации больше и нету. Но там (инет тв или вещание по wifi на гаджеты) и битрейт потоков поскромнее, поэтому буферизация заметна только на низкоскоростном канале связи (или же при сильной потере пакетов на транспорте).

В межблочной комутации приемущество мултикаста именно в отсутствии дублирования трафика при необходимости отдать источник (битрейт*колво потоков) на разное оборудование/провайдеров/систему мониторинга и т.д. Мультикаст просто льется, дальше обо всем заботится коммутатор/маршрутизатор. Настроить это не сложнее прописать канал с транспондера, тут не надо мега знаний. Делается это один раз и забывается, оно просто работает.

Да юникасту тут тоже место есть, но в особых случаях (аритектура как у sky star). Однако свои замечания я уже по этому поводу говорил, считаю ее не оправдано избыточной. А для внешнего подключения коммерческих источников по IP, есть договор и SLA (соглашение о качестве услуг).

[atx]

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

согласен, что что единственной такой причиной может стать дроп на порту, что у приличного оператора маловеротно.
в предидущем посту, я немного не корректно написал, что буфер не имеет отношения к мультикасту, это не совсем так т.к. мультикаст - это помимо UDP ещё и RTP, а вот особенность RTP - он действительно кешируется, следовательно его применение в рамках ГС более оправданно... как-то была у меня мысль перейти на RTP, но что-то меня удержало...
Следовательно, если нет дропов, то разницы между юникастом и мультикастом (RTP) нет (разумеется кроме многоадресности)?

RTP имхо также мертворожден, как и FEC IP. Приемуществ (кроме возможности согласовать параметры "медиа-сесси") перед Тср у него нет. Фактически RTP конфетная обертка, а потоки все равно льются по UDP.

Если уж смотреть дальше в будущее, то оно за H.265 + HLS. Именно хорошие кодеки (соотв-но меньший обьем данных) и адаптивная (по битрейту) передача до получателя вытолкнет мультикаст. Хотя не исключен, что операторских сетях он будет успешно со-сущетсвовать с мультикастом: мультикаст магистрали, HLS на узлах в направлении пользователя. Вот только до будущего этого еще как до Марса на бензине

[DK]

О каких запросах дополнительных пакетов идет речь? Не забывайте, что все потоки, которые мы рассматриваем в данном контексте, это реалтайм и если пакет не доставлен, то он не доставлен и все.
Буфер есть в любом случае и UDP/RTP, multicast/unicast тут не при чем.
А вот MDI, который мы обсуждали несколькими страницами ранее, имеет отношение к буферу. В рамках этой методики есть показатель IAT, который оценивает время доставки транспортных (не MPEG-TS) пакетов. Если пакеты полетят быстрее, чем ожидает приемник, буфер переполнится, медленнее - опустошится. Отсюда вытекает проблема переменного битрейта. Именно переменный битрейт приводит к резким колебаниям времени доставки пакетов. У кого есть VB120/220 могут в этом легко убедиться. Как должны передаваться IP TS описывает стандарт TS 102 034.
Теперь о юникаст/мультикаст. Мое личное мнение. Я использую мультикаст. С ним тупо проще работать на межблочке. Завел стример, а дальше цепляю к нему столько приемников, сколько нужно. И при анализе потока я анализирую именно тот, который уходит в эфир, а не искусственно созданную копию.
Но, мультикаст всегда накладывает требования к коммутаторам и настройке коммутаторов.  Я не сисадмин, подробностей рассказать не могу, но очень часто встречаю ситуации, когда на ненастроенном, либо плохо настроенном гигабитном коммутаторе проблемы с потоками начинаются уже при общем битрейте 450-500Mbps. Мультикаст ломится везде, в том числе на тот порт, из которого он исходит. Про снупинг, PIM многие не знают.
Юникаст проще в своей сути. Это соединение точка-точка. Настроил и забыл. Не гибко, не универсально. Зато можно гонять через тупые хабы и не заморачиваться настройкой непонятных функций маршрутизации.
Т.е. здесь выбираем, либо надежность, либо гибкость. Кому что больше нравится.

[skarxxl]

Коллеги, вы уж простите мою дотошность, но давайте разберемся вот в чем:
вы говорите, что не важно юникаст/мультикаст есть буфер, тогда откуда возникают ошибки последовательности? По идеи если данные буферизируются, то и передаваться они должны в строгой последовательности.
Либо весь вопрос в размере буфера, для UDP он меньше, поэтому когда значения IAT первышают буфер возникает ошибка последовательности.

Не забывайте, что все потоки, которые мы рассматриваем в данном контексте, это реалтайм и если пакет не доставлен, то он не доставлен и все.

о перезапросе пакета я рассуждал в том ключе, что это TCP т.е. должно быть подтверждение удачной доставки пакета, если подтверждения нет, то пакет должен перепослаться. Если для TCP DVB это не актуально, тогда какой смысл использования юникаста? Только жесткое ограничение приемников сигнала? Тогда получается верно утверждение:

Зато можно гонять через тупые хабы и не заморачиваться настройкой непонятных функций маршрутизации.

[atx]

TCP - транспортный протокол гарантированной доставки данных. Все сегменты (куски данных) он нумерует, и принимающая сторона эту нумерацию проверяет. Получатель проверяет пришел ли сегмент с ожидаемым номером, пришел ли он битый (ошибка контр суммы) или отправитель не получил подтверждения от получателя, во всех этих случаех сегмент отправляется повторно. Медлено, но гарантировано.

Но беда не только в скорости передачи ТСР, беда в его сессионости. ТСР требует установления канала точка-точка для каждого нового получателя, и соответственно пересылает копии одних и тех же данных каждому отдельному получателю.

UDP фиолетово на гарантированность доставки пакетов, он изначально надеется на два фактора: канал идеальный и все ошибки исправит вышестоящий протокол/программа.

И ему впринципе все равно кто получатель, он просто шлет данные на сетевой интерфейс, через протокол сетевого уровня (например IP).
Все что требует UDP чтобы получатель знал с какого UDP-порта эти данные летят, а где они находятся получатель узнает из поля IP-адрес протокола IP.

Мультикаст особый вид/способ передачи трафика сетевым протоколом IP, когда не важен конечный получатель, а важен лишь отправитель и идентификация трафика (IP-адрес группы).

Имено поэтому IP-мультикасту, протокол UDP - роднее, они "говорят на одном языке". На канальном (Ethernet) уровне мультикаст IР-адреса отображаются в диапазон определенных МАС-адресов, таким образом коммутатор знает что это мульткаст, ему фиолетового кто его получатель, он просто шлет (копирует) этот траффик во все свои порты, кроме того откуда он пришел. Копирует - тут ключевое слово, т.е. одни и теже байтики множит по всем портам.

Вот тут то и задача L2/L3 фич коммутаторов/маршрутизаторов наводить порядок, доставля трафик только тем кому он нужен.

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

Данные UDP конечно тоже складываются в буфер, это прежде всего необходимо чтобы протокол IP успел их из буфера забрать и отдать вышестоящему протоколу UDP, который должен успеть отдать их дальше (например на вход MPEG-TS демультплексора).

В случае засранного ошибками канала, предпочтительнее для потоковых данных (видео, аудио) использовать UDP, который не получив пакет и не отдаст его выше, что просто сквадратит картинку или сжует звук (упрощенно . А ТСР будет до последнего выеживаться, пытаясь собрать пазл. И ведь все равно рано или поздно вышестоящий протокол во время не получивший очередную порцию данных, просто пропустит ее. Нафига тогда козе баян? если резльтат один и тот же.

Понятно что по инету передавать UDP для целей мультимедия просто жесть, т.к. это не твоя собственная сеть и гарантировать тебе никто и ничего не может. И мультикаст тебе по инету передавать никто не будет, слишком накладно (хотя и спорно). Пожтому там проще передавать юникаст, заране согласившись с тем что пакеты надо будет буферезировать, чтобы из этой каши выделить хоть какой то полезный поток видео/аудио. Ну и соответвенно т.к. это все равно юникаст, то передавть его проще по ТСР, который к тому же возьмет на себя устранение хоть части ошибок среды передачи.

Спасти конечно ситуацию (и спасает) может избыточное кодирование именно потоковых данных - FEC. Правда это сильно увеличивает накладные расходы на передачу потоковых данных (чем избыточнее кодирование, тем толще итоговый поток), но результат на лицо - за счет передачи в потоке избыточных данных, их проще восстановить на другом конце.

Так например делается в DVB-S/S2/T2, т.к. передача потрадиоканалу подвержена куче проблем - это не кабель, и даже не инет.

Сейчас пытаются пропихнуть IP FEC, но имхо сложность реализаци, несовместимость с уже существующим оборудованием без FEC, свидут все его усилия на нет.

[apog]

Подведем итог:

1. В пределах одной ГС (читай одного коммутатора) прелести гарантированной доставки данных по протоколу TCP вряд ли используются.

2. Передавая юникастом суммарный поток 400 Мбит/сек двум получателям мы порождаем 800 Мбит/сек трафик на коммутаторе ГС, трем получателям - 1,2 Гбит/сек, и т. д. Решайте много это или мало, и при скольких получателях станет узким порт источника. Да и кроме порта источника с возрастанием числа получателей возрастает нагрузка и на процессор источника, который выполняет работу по отправке данных.

3. Сложность настройки того или иного способа пока еще спорна:

3.1. С юникастом как будто бы наглядней маршрутизация. То есть ты заранее знаешь куда зарулить поток и никто более его не получит без надобности на то. Настройки коммутаторов, передающих этот самый поток практически не требуется. Отметим, что с юникастом работает меньше железок, чем с мультикастом.

3.2. С мультикастом наоборот минимум настроек источника и получателей, а с настройкой коммутатора надо чуток повнимательнее, дабы не зафлудить непотребным трафиком не нуждающиеся в нем устройства. По аналогии с предыдущим пунктом у мультикаста богаче выбор по оборудованию (на сколько я знаю).

[sky star]

2. Передавая юникастом суммарный поток 400 Мбит/сек двум получателям мы порождаем 800 Мбит/сек трафик на коммутаторе ГС, трем получателям - 1,2 Гбит/сек, и т. д. Решайте много это или мало, и при скольких получателях станет узким порт источника. Да и кроме порта источника с возрастанием числа получателей возрастает нагрузка и на процессор источника, который выполняет работу по отправке данных.

Справедливо только в том случае если Вы двух кратно или трех кратно резервируете что то на модуляции к примеру ,
в противном случае эта ситуация не возникнет . Тут надо понимать следующее, что все что ушло юникастом , для кого либо, второй раз туда же не отправляется , при этом сразу же все становиться на свои места
ДЛя примера , ну приняли Вы канал "спас"   Вам надо его сколько раз отправить в QAM ? , у меня один , сколько раз отправить в IP-PAL тоже один ! И магия сейчас в тот же IP -PAL у меня приходит 165 мегабит, При этом там РТРС 1 + РТРС 2 прямиком с DVB-T2, потом там же оцифрованный аналог, там же только то что со спутника  валит, степень ввода IP-PAL где то %80, часть каналов еще в ASI , потихоньку догребаю, как видно, страшных запредельных для понимания и созерцания цифр то нету

В QAM все еще легше , каналов которые в QAM Могут быть поданы ДВА раза всего 20 !
При чем в моем случае ситуация еще проще, в qAM эти 20 каналов придут тоже один раз,
они дважды или трижды или четырежды придут только в mpeg4--too SDI --mpeg2 и уже от туда полетят в qAM,
и только один раз (ну это когда все устаканиться)
Я думаю список что это за каналы писать не надо .
Отправить в IP TV - каналы что приходит в QAM , труд минимальный

Я повторюсь, нет страшных цифр .



3.1. С юникастом как будто бы наглядней маршрутизация. То есть ты заранее знаешь куда зарулить поток и никто более его не получит без надобности на то. Настройки коммутаторов, передающих этот самый поток практически не требуется. Отметим, что с юникастом работает меньше железок, чем с мультикастом.

Я уточню коллега , не КАК БУДТО БЫ , а именно НАГЛЯДНО
Вася отдает булочку Тане, не посредников, нет даже гипотетической возможности что булочка будет не вручена Тане.

На счет оборудования, то оборудование что не работает с юникастом я как раз и не считаю оборудованием,
ибо не полная поддержка сетевого стека, это уже настораживает, что там разработчик решил не поддерживать еще - тайна великая, гармоники, тандберги, циски, сумавижен - поддерживает юникаст в полный рост, для меня это ориентир.

[atx]

sky star, дофантазируем вашу схему чутка:

https://yadi.sk/i/2QU9eq0wp2z8k

холодным зимним утром ген. дир. сообщил: "Свершилось! Мы купили ИП Васю Пупкина. Он там аналог гонял 3 канала, надо людям счастье дать - надо дать IP, QAM и расширить аналог".

и вот у нас появились три региональных ЦГС.
волокно до города А у нас есть.
до городов Б и В можно добраться только через А, и к тому же оптики туда своей и Васеной нет, а есть только по каналу 1 Гбит/с от ТрансКолхозТелеком.

а людям еще и Инет надо раздовать - сразу!, сотовиков подвинуть с рынка.


пропуская всю лирику, следуя логике изначально устаканеной схемы ЦГС, как поступить? использовать "наглядный" юникаст или рациональный мультикаст. Религия или прагматизм?