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

[Dino Farinacci <[e-mail]>]

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

> 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