Re: Confirming source-routed multicast is dead on the public Internet

[Saku Ytti <saku () ytti fi>]

Hey Miles and Michael,

It is entirely fair to debate what the use-case would be, the
underlaying technical problem remains the same, if it becomes useful
(globally) we don't have the hardware to cater for it.

I'm sure both of your use cases are used extensively in internal
network. I've worked for company who distributed broadcast TV on their
MPLS IP backbone, two-plane network, red and blue, one copy for each
tv channel on both planes and far-end drops redundant copy. Very
attractive solution commercially for client and provider. But no
potential for global scale.


On Wed, 1 Aug 2018 at 20:44, Miles Fidelman <mfidelman () meetinghouse net> wrote:
> On 8/1/18 12:24 PM, Saku Ytti 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.
> Personally, I think the use case is a lot stronger for multi-person
> video conferencing.
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.  .... Yogi Berra


-- 
  ++ytti