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

["Morten V. Pedersen" <[e-mail]>]

Hi,
In general providing reliable multicast over WiFi is a challenging 
problem. We did our own implementation of such a transport some years 
back. We have a bit of public information on it here:
http://www.steinwurf.com/products/score.html

Multicast over WiFi is very challenging also due to the way 802.11 
treats multicast traffic:
https://www.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-01.txt

In my experience it is hard to avoid some form of FEC (erasure coding) 
if the multicast needs to be able to scale up to a substantial amount of 
receivers.

All the best,
Morten

On 11/08/2017 07:54 PM, Greg Shepherd wrote:
>
>
> On Wed, Nov 8, 2017 at 10:32 AM, Dino Farinacci <[e-mail] 
> <mailto:[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/
>     <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]
>     <mailto:[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/rfc6726>
>     > https://tools.ietf.org/html/rfc5740
>     <https://tools.ietf.org/html/rfc5740>
>     >
>     > AFAIK neither has wide usage, but there’s implementations:
>     > http://mad.cs.tut.fi/download.html
>     <http://mad.cs.tut.fi/download.html>
>     > https://www.nrl.navy.mil/itd/ncs/products/norm
>     <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
>     <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-pardue-quic-http-mcast-01>
>     > https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-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]
>     <mailto:[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] <mailto:[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]
>     <mailto:[e-mail]>
>     >
>     > _______________________________________________
>     > MBONED mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/mboned
>     <https://www.ietf.org/mailman/listinfo/mboned>
>     >
>     >
>     > _______________________________________________
>     > MBONED mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/mboned
>     <https://www.ietf.org/mailman/listinfo/mboned>
>
>     _______________________________________________
>     MBONED mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mboned
>     <https://www.ietf.org/mailman/listinfo/mboned>
>
>
>
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned