Re: [MBONED] deploying internet-wide multicast (RE: deprecating MSDP)

[Greg Shepherd <[e-mail]>]

On Wed, Nov 8, 2017 at 10:32 AM, Dino Farinacci <[e-mail]> wrote:

> Note I use LISP all the time to get multicast over Wifi via
> https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast/.
>
> If anyone wants to try it, please send me a private note.
>
> Dino


Exactly. ANY unicast encap of multicast over wifi will gain from the wifi
loss retransmission.

Greg


> > On Nov 8, 2017, at 10:22 AM, Holland, Jake <[e-mail]> wrote:
> >
> > Hi,
> >
> > FLUTE and NORM are the reliable multicast transports I’ve seen:
> > https://tools.ietf.org/html/rfc6726
> > https://tools.ietf.org/html/rfc5740
> >
> > AFAIK neither has wide usage, but there’s implementations:
> > http://mad.cs.tut.fi/download.html
> > https://www.nrl.navy.mil/itd/ncs/products/norm
> >
> > If I understand correctly, Cablelabs’s IP Multicast ABR system uses a
> sort of bastardized version of NORM with a path for out-of-band unicast
> repair that doesn’t let receivers prevent the transmit window from sliding
> forward, since the streaming video use case can’t use the norm approach of
> letting receivers slow down the transmit:
> > https://apps.cablelabs.com/specification/?category=VIDEO&
> subcat=IP%20MULTICAST&query=&doctype=&content=false&archives=false
> >
> > There’s some more speculative ongoing work I know of that might be
> relevant.
> > https://tools.ietf.org/html/draft-pardue-quic-http-mcast-01
> > https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-01
> >
> > I think FLUTE or NORM implementations could be made to work today for a
> non-time-critical download service, if there were multicast connectivity.
> >
> >
> > I agree with Mikael that there’s more work to do before ordinary
> implementations of open standards can be used to operate a video service
> over multicast IP. I do want to operate a multicast video service, but not
> without FEC or some kind of repair.
> >
> > I also agree that AMT can be a helpful way to get multicast IP over wifi
> as unicast at layer 2 (though I would rather see native multicast to the
> home and either AMT relay or DMS (or both) at the wifi router, instead of
> AMT relays in the ISP, because multicast can help a lot on the access
> network for PON or CMTS, though I do take the point that in some cases
> relay in the ISP is more practical to deploy).
> >
> > But I agree with Stig that it’s not very helpful to make AMT reliable,
> as compared to making a sufficiently reliable multicast transport protocol
> that can work for streaming video.
> >
> > -Jake
> >
> > On 11/8/17, 7:53 AM, "Stig Venaas" <[e-mail]> wrote:
> >
> > Hi
> >
> > I only meant that with AMT and Wi-Fi, the experience should hopefully
> > be equivalent to regular native multicast. I agree you often need FEC
> > to protect against loss, and also in some cases some kind of
> > retransmission or unicast assistance. Assuming there is no loss in the
> > core until an AMT relay is reached, then I suppose an AMT specific
> > solution could work, but I would like a generic solution that can work
> > for native multicast. I don't remember exactly what was done for
> > reliable multicast in the IETF now. Anyone remember better than me? I
> > remember proposals including how to do retransmissions.
> >
> > Stig
> >
> >
> > On Wed, Nov 8, 2017 at 1:50 AM, Mikael Abrahamsson <[e-mail]>
> wrote:
> >> On Tue, 7 Nov 2017, Stig Venaas wrote:
> >>
> >>> Hi
> >>>
> >>> I don't think AMT needs to be more reliable than regular multicast. If
> >>
> >>
> >> Deploying multicast for linear TV without FEC is an operational
> nightmare
> >> that never stops. You need to constantly measure customer experience
> >> (preferrably in the STBs, all of this with proprietary solutions afaik)
> or
> >> try to measure it in your network (using expensive equipement).
> >>
> >> I recommend all my enemies to deploy this at large scale.
> >>
> >>> you are concerned about Wi-Fi, then by using AMT to the device, the
> >>> packets will be unicast packets, so the regular Wi-Fi handling of
> unicast
> >>> packets (including retransmissions) should be sufficient. Do you need
> >>> additional retransmissions?
> >>
> >>
> >> Unicast will be far superior to multicast over wifi, but it's probably
> still
> >> not enough to give a good enough customer experience without FEC.
> >>
> >> FEC in this aspect means the application deteriorates gracefully under
> >> packet loss, by smearing out infomation across packets and degrading
> quality
> >> without for instance magenta squares gliding along the screen until the
> next
> >> full screen update (that might be a second into the future (or more)).
> >>
> >> This "FEC" can also be (as some have done), by the devices receiving
> >> multicast packets and then requesting (via unicast) from a server of
> some
> >> kind, to get the packets it lost. The few solutions available when I was
> >> involved in this before, were all proprietary. They were also used to
> speed
> >> up channel changes by providing full screen update immediately, before
> same
> >> information came via the multicast stream.
> >>
> >> In packet networks, packets are lost. It's a fact. They're designed to
> >> behave this way. From what I can see, there are two ways to handle this.
> >> Either we come up with a standards based retransmission mechanism for
> >> multicast streams that anyone can use, or we punt the problem to the
> >> application layer, and let them figure it out. We need to be perfectly
> clear
> >> to everybody what our choice is.
> >>
> >>
> >> --
> >> Mikael Abrahamsson    email: [e-mail]
> >
> > _______________________________________________
> > MBONED mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mboned
> >
> >
> > _______________________________________________
> > MBONED mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mboned
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>