Confirming source-routed multicast is dead on the public Internet

Wed Aug 1 17:27:24 UTC 2018

What if... Bear with me for a moment here, we don't try to force VoD onto a
multicast setup? Multicast is used extensively by all major ISPs(if they
have the rights) to deliver IPTV. One issue you brought up is people
unwillin to wait 1 or 5 mins for a show, well before the days of youtube
people waited weeks for OTA programming that started with or without delay,
depending on how many relays you were going through. As a use case of
multicast over the internet, a Real time TV rebroadcaster would be a really
good use case. The federal govt already subsidises super expensive energy
hogging TV broadcast towers, who's to say they wouldn't prefer it to just
go over the interwebs? Bit rate's not a problem, a 720i stream takes 1 or 2
mbps, which is a fraction of a home broadband connection(25mbps down 3 up,
last time i checked). I think we all on nanog would agree internet is more
important than TV. Govt money might better be spent on a better internet
than TV radios. Of course that might mean some internet backbone
upgrades(maybe even govt subsidised upgrade), but i would never say that
there isn't a commercial use case for it.

On 1 August 2018 at 10:24, Saku Ytti <saku at ytti.fi> wrote:

> Hey Mankamana,
>
> > other than billing problem, is there any other reasons why multicast
> would not be viable for public internet ?
>
> Imagine someone like youtube or netflix would like to use multicast,
> instead of caches. They'd need to start new multicast stream for every
> content with small delay (to get more viewers on given stream), how
> much delay would consumer tolerate before content starts? 1min? 5min?
> So every minute or every 5 minute new stream of movie would be sent,
> except it would need to be sent many times, for each bitrate
> supported.
> Each of these streams is wide (wider than unicast) HW state that needs
> to be stored on every device on path, for unicast we only store 1
> narrow HW state per destination, for multicast we store 1 wide HW
> state per flow/stream, we don't have the hardware to do that, if there
> would be any significant demand for multicast.
> It only works when there is no use-case for it, and even then, it's
> insecure DoS vector.
>
> --
>   ++ytti
>