Re: [Pearg] [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

[Phillip Hallam-Baker <[e-mail]>]

I was trying to be polite. Folk who have been peddling a technology which
meets a need faced by essentially all Internet users that is being utilized
by essentially none of them after 30+ years should be willing to take the
win and move on.

The people who are choosing not to use multicast are serious engineers who
are fully aware of the existence of multicast. They are doing things
differently for a reason and being dismissive about their engineering
choices as clearly unfounded and incorrect is not the way to persuade them.

On Thu, Jan 5, 2023 at 7:56 PM Dino Farinacci <[e-mail]> wrote:

> > Wall street is likely to be in a unique class here.
>
> Definitely a domain specific case.
>
> > I don't think we need to consider multicast a failure if it doesn't end
> up being used because the functionality is being provided at a higher level
> in the stack.
>
> Yes, but the worse place to do packet replication is at the appliation
> source. You simply kill the lower speed access links that leave the source.
> Which means you can only put content sources in centralized places with a
> lot of resources.
>

Seems like a rather narrow minded view of the issues. Multicast always
struck me as a layering violation with a rather indistinct use model and
fuzzy set of semantics. I am not surprised to see folk choosing to do it
differently.

Doing packet duplication at the transport layer means that reliability can
be provided in the network rather than at the packet origin.

> At some point we should do a QUIC like transport for Multicast/Packet
> Duplication.
>
> Ditto above comment.
>

Again, seems like you are better at dismissing different ideas than
explaining your position.

>From my point of view as an application protocol developer, multicast is
essentially useless because I have to do my own work to provide a reliable
transport and that in turn means I can't make use of WebRTC libraries and
the like.

I was rather annoyed to be watching the Times Square new years eve
celebrations on You Tube TV with a 15 second delay. That could have been
avoided if multicast had been a part of the distribution technology. But I
can understand why it wasn't.

The only way I can see multicast being useful in the context of Internet
broadcast events is as one component in a hybrid scheme which looks like
QUIC to the receiving endpoint application with a multicast stream from the
data source being supplemented by a separate branching control channel
providing authentication and reliability.

Such a scheme would have to address security differently from the handling
in QUIC because it is the nature of AEAD/MAC schemes that anyone who can
authenticate the data can inject fake data. Thus it is necessary to either
use public key or to provide each recipient with their own authentication
feed.

But no, go on. Perhaps we should give it another 30 years. Lets just keep
doing what we are doing and maybe things will change.