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

[Toerless Eckert <[e-mail]>]

The CableLabs solution does not carry IP multicast across the home network.
It makes the home gateway an HTTP proxy where IP multicast + NORM is used
on the uplink to retrieve the content in a scalable fashion between content
server and gateways - via a fairly well controlled SP network only.
The amount of loss that NORM has to cope with should be very small, but of
course it needs to be 0 to support the use case, thats why you still need a
reliable transport protocol.

I was always hoping that there was still a chance to build
the transport solution for rate adaptive video on top of RTP because it
would create a lot less ABR problems like overhead and delay (talk about sports
and delay). I thought there are some solution architectures on the mobile side
that may use RTP, but not quite sure. I've helped build solutions that
do use rate adaptive RTP and i thought that worked very well (low latency et.al.).

For walled garden IPTV use cases, the cablelabs approach should be quite attractive 
you just need to eliminate all the cable specific pieces you don't need, which
shouldn't be difficult. You just won't get a good score on the soccer-goal-delay rankings. 

If we're talking federated or OTT video which is what AMT was looking to support,
then this cablelabs approach direction would rather be an alternative: Just put
an HTTP cache on your home-gateway  to enable local retransmissions from cache
on the gateway and rely on TCP (HTTP(s)) from gateway to client. No multicast
needed.

Cheers
    Toerless

On Wed, Nov 08, 2017 at 06:22:23PM +0000, Holland, Jake 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

-- 
---
[e-mail]